TIA TIA Portal DB Laden ohne reinitialisieren

DeltaMikeAir

User des Jahres 2018; 2023
Beiträge
21.953
Reaktionspunkte
7.298
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe gerade in den TIA Neuigkeiten auf S. 64 gelesen, dass man in der Länge geänderte DB´s ohne reinitialisieren
laden kann. D.h. die neuen Variablen sind eingefügt und die alten mit den Werten vor dem laden noch erhalten.

Leider nur mit optimierten DB´s. Hat schon jemand Erfahrungen damit gesammelt. Funktioniert dass oder muss man noch etwas beachten?
Welche konkreten Nachteile haben optimierte DB´s?

Mit Grüßen

Hier der Link zum PDF:
https://www.google.de/url?sa=t&rct=...ck.pdf&usg=AFQjCNGMTd4cIaehnIgfGv-dt_RRj-9NHw
 
Hallo Delta,

optimierte DB's sind größer (belegen mehr Speicher) als normale DB's.
Beispiel eines DB's von mir:
Optimierter BausteinzugriffNormaler Bausteinzugriff
Ladespeicher2482 Bytes2259 Bytes
Arbeitsspeicher196 Bytes72 Bytes

Ein absoluter Zugriff ist auf einen optimierten DB nicht möglich.

Gruß Anubis
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Anubis,

ich habe mir die Vorteile eines optimierten DB´s einmal bei Siemens durchgelesen.
Ja, eine absolute Adressierung macht keinen Sinn, da man vermutlich nie weiß, auf
welcher Adresse die Variable liegt. Gibt es sonst noch Stolpersteine, wenn man dies
aktiviert. Ich programmiere nur symbolisch.

Mit Grüßen
 
ich habe mir die Vorteile eines optimierten DB´s einmal bei Siemens durchgelesen.
Ja, eine absolute Adressierung macht keinen Sinn, da man vermutlich nie weiß, auf
welcher Adresse die Variable liegt. Gibt es sonst noch Stolpersteine, wenn man dies
aktiviert. Ich programmiere nur symbolisch.

Diverse. Aber die wichtigstens sind effektiv.
Kein Zugriff von "fremden" HMI/SCADA auf die Adressen des DB
Wegsichern von optimierten DBs auf zur Laufzeit erstellte DBs ist auch nicht möglich.
Das laden ohne zu initialisieren ist mir noch nicht so Vertrauenswürdig. Kann aber sein dass das mittlerweile tadellos funktioniert, ausprobiert hab ichs noch nicht da ich normalerweise solche DBs vor einer Reinit schützen will auf welche auch das SCADA seine Sollwerte und Befehle schreibt (schliesst Optimierung von vorneherein aus)

mfG René
 
Die Speicherreserve ist Gruetze weil:
Man bestehende Variablen nicht umbenennen kann und man neue Variablen nur am Ende anfügen kann und nicht mitten drin in nem Struct zum Beispiel... Also fuer mich nicht zu gebrauchen...
Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, dass man nicht mittendrin einfügen kann ist sehr schlecht. Wenn man einen Struct ändert, dann steckt hinter der Reihenfolge der Variablen
ein System. Wenn man aber alles nur hinten dran hängen kann, besteht ja keine Möglichkeit mehr, sein System einzuhalten.

Schade
 
Ja, dass man nicht mittendrin einfügen kann ist sehr schlecht. Wenn man einen Struct ändert, dann steckt hinter der Reihenfolge der Variablen
ein System. Wenn man aber alles nur hinten dran hängen kann, besteht ja keine Möglichkeit mehr, sein System einzuhalten.

Fazit ist eigentlich. Man muss es eigentlich genauso machen wie seit jeher wenn man mit DBs arbeitet.

Früher hat man die DBs einfach genügend gross gemacht und dann einmal geladen. Später immer nur hinzugefügt den DB aber nicht mehr geladen.
Seit man Symbolisch programmiert hat man dann einfach eine Bausteinkonsistenzprüfung gemacht und den DB trotzdem nicht neu geladen sondern nur die Bausteine mit neuen Zeitstempeln.

Siemens hat das jetzt verschlimmbessert. Man muss immernoch hinten anfügen. Aber man muss sich jetzt zusätzlich noch drum kümmern das Speicherreserve vom Tool reserviert wird. Man kann nicht verhindern das ein DB neu geladen und reinitialisiert wird (weil man sich nicht mehr selbst um reserven in nicht optimierten Bausteinen kümmern kann). Ueberhaupt wird einem die Ganze Sache zwar aus der Hand genommen aber nicht so das man irgendwie Vertrauen in die den Datenerhalt haben könnte.
Früher musste man zwar Mitdenken. Aber wenn man das gemacht hat hat man keine Daten verloren oder DBs neu initialisieren müssen. Heute ist man manchmal gezwungen zu laden obwohl man ganz genau weiss das die Daten verloren gehen werden. Und das Laden garnicht nötig wäre.

Ich kann mit allen möglichen Unzulänglichkeiten von TIA leben. Abstürze, langsames Online etc. kann man alles akzeptieren. Aber das man Onlinewerte nicht vor einem neudownload sichern kann bzw diese garnicht sichern muss das ist absoluter Scheiss.

Ja man kann die Aktualwerte sichern und als Startwerte übernehmen. Das muss man aber machen BEVOR man irgendwas an der Struktur verändert. Das bringts nicht wenn in den Speicherbereichen Zustände sind die sich ändern können während man im Büro seine Erweiterungen programmiert.

mfG Re^meinRantdesMonats^né
 
Früher musste man zwar Mitdenken

Genau dass ist der Knackpunkt. Früher musste man mitdenken aber es passierte nur genau das, was man auch auslöste. Ich habe
früher genau gewusst, was ich geändert habe und in welcher Reihenfolge ich laden muss ( bei vielen Änderungen eine Änderung laden,
testen, dann nächste Änderung... ). Mittleiweile passiert so viel automatisiert, dass manchmal die Reaktion der Anlage beim laden nicht
abschätzbar ist. Früher habe ich immer an großen Anlagen programmiert und das so gut wie immer im laufenden Betrieb. Man musste immer
gut mitdenken. Wir hatten noch keine richtig großen Anlagen mit TIA aber aktuell graußt es mir auch davor.

Mit Grüßen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... Ich habe früher genau gewusst, was ich geändert habe und in welcher Reihenfolge ich laden muss ( bei vielen Änderungen eine Änderung laden, testen, dann nächste Änderung... ). Mittleiweile passiert so viel automatisiert, dass manchmal die Reaktion der Anlage beim laden nicht abschätzbar ist. ...

Genau das sehe ich auch als ein sehr großes Problem an. Früher konnte man Änderungen nach und nach einspielen und testen. Das geht heute theoretisch immer noch nur muss man heute dafür sehr viele Versionen eines Projektes anlegen und diese dann nach und nach in die CPU laden. :-(
 
Rein Interessehalber

Hat schon jemand auf einer Anlage sich bewusst für oder gegen Optimierung entscheiden müssen um z.B. Geschwindigkeitsvorteile oder Speichervorteile zu nutzen?
Bei mir waren es bisher nur die Siemens Bausteineinschränkungen welche eine Optimierung bzw eine nicht Optimierung erzwangen. Echte Systemrelevante Unterschiede die meine Anlage gestört hätten, konnte ich noch nicht ausmachen.
Allerdings nehme ich derzeit die CPUs eher ne Nummer grösser als kleiner das ich mir noch echt schwer tue den Speicher und CPU bedarf einzuschätzen die ein Programm sich am Ende genehmigen wird.
Ich konnte bis dato erst den Remanenzspeicher an den Anschlag bringen (ET200sp)

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja man kann die Aktualwerte sichern und als Startwerte übernehmen. Das muss man aber machen BEVOR man irgendwas an der Struktur verändert. Das bringts nicht wenn in den Speicherbereichen Zustände sind die sich ändern können während man im Büro seine Erweiterungen programmiert.

Das trifft es eigentlich, das bei großen Anlagen eine Änderung nicht nur fast, sondern völlig Ummöglich gemacht wird,
wenn Daten Konsitent bleiben müssen.


Rein Interessehalber

Hat schon jemand auf einer Anlage sich bewusst für oder gegen Optimierung entscheiden müssen um z.B. Geschwindigkeitsvorteile oder Speichervorteile zu nutzen?
Bei mir waren es bisher nur die Siemens Bausteineinschränkungen welche eine Optimierung bzw eine nicht Optimierung erzwangen. Echte Systemrelevante Unterschiede die meine Anlage gestört hätten, konnte ich noch nicht ausmachen.
Allerdings nehme ich derzeit die CPUs eher ne Nummer grösser als kleiner das ich mir noch echt schwer tue den Speicher und CPU bedarf einzuschätzen die ein Programm sich am Ende genehmigen wird.
Ich konnte bis dato erst den Remanenzspeicher an den Anschlag bringen (ET200sp)

mfG René

Ich nutze es zur Zeit bei den 1200er bewusst und werde demnächst die 1507 einsetzen mit Optimierten Bausteinen,
allerdings spielt es bei meinen Maschinen keine Rolle ob ich mal eben Reinitalisiere, wichtige Daten werden bei mir
sowieso in Rezepturen gespeichrt und werden nicht Zyklisch geändert, da es eigentlich nur Maschinenparameter sind.
 
Hallo zusammen,

ich mache es meistens so: (TIA V13 SP1.9, bis jetzt nur 300/400)

  • DB Inhalte Symbolisch
  • Für die wichtigen Sollwertvariablen eine bzw. mehrere Variablentabellen anlegen
  • im Status die Beobachtungswerte in die Steuerwerte übertragen, evtl. für später speichern
  • den neuen, erweiterten DB (mit eingefügten und/oder angefügten Variablen) in die SPS kopieren
  • in der Variablentabelle die Steuerwerte mit "steuern" zur SPS übertragen -> die original Werte sind wieder in der SPS in den richtigen Variablen
  • evtl. Variablentabelle erweitern, um die neuen, zusätzlichen Variablen auch anzeigen zu können

Grüße
Peter
 
  • DB Inhalte Symbolisch
  • Für die wichtigen Sollwertvariablen eine bzw. mehrere Variablentabellen anlegen
  • im Status die Beobachtungswerte in die Steuerwerte übertragen, evtl. für später speichern
  • den neuen, erweiterten DB (mit eingefügten und/oder angefügten Variablen) in die SPS kopieren
  • in der Variablentabelle die Steuerwerte mit "steuern" zur SPS übertragen -> die original Werte sind wieder in der SPS in den richtigen Variablen
  • evtl. Variablentabelle erweitern, um die neuen, zusätzlichen Variablen auch anzeigen zu können

Grüße
Peter
Das kannst Du aber nicht bei einer laufenden Anlage machen.
(Jedenfalls nicht ohne Herzrasen ;) )

Oder verstehe ich da was falsch.
In der Zeit zwischen der DB-Übertragung und dem Nachfummeln über die VAT rennt die Anlage doch mit
"falschen" Werten?

Und was ist, wenn sich Istwerte ändern, in der Zeit zwischen "Bereitstellen in VAT" und "Senden von VAT"?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich mache es meistens so: (TIA V13 SP1.9, bis jetzt nur 300/400)

  • DB Inhalte Symbolisch
  • Für die wichtigen Sollwertvariablen eine bzw. mehrere Variablentabellen anlegen
  • im Status die Beobachtungswerte in die Steuerwerte übertragen, evtl. für später speichern
  • den neuen, erweiterten DB (mit eingefügten und/oder angefügten Variablen) in die SPS kopieren
  • in der Variablentabelle die Steuerwerte mit "steuern" zur SPS übertragen -> die original Werte sind wieder in der SPS in den richtigen Variablen
  • evtl. Variablentabelle erweitern, um die neuen, zusätzlichen Variablen auch anzeigen zu können

Grüße
Peter

Ich habe eine Frage: Machst Du den Schritt "den neuen, erweiterten DB (mit eingefügten und/oder angefügten Variablen) in die SPS kopieren" im Stop oder im Run? Falls im Run: kann es hierbei nicht zu Problemen kommen weil Variable reinitialisiert bzw. auf veraltete Werte zurückgesetzt werden, die keine Sollwerte sind und sich hochfrequent ändern? Oder geht es um DBs, die ausschließlich Sollwerte enthalten, die von der Steuerung sowieso nie geändert warden?
 
Hallo,

natürlich geht das nur im Maschinenstillstand, also z.B. im Einrichtbetrieb und nicht im Automatikbetrieb der Maschine, aber die SPS kann in "run" bleiben.

Es geht mir ja auch nur darum, dass evtl. geänderte Werte trotz geändertem DB gesichert und auch wieder zu SPS übertragen werden können.

die Variablentabelle sucht sich die zum Symbol dazugehörige Adresse und es wird die alte bzw. nach übertrage des db's die neue Adresse angezeigt
 
Hallo,

natürlich geht das nur im Maschinenstillstand, also z.B. im Einrichtbetrieb und nicht im Automatikbetrieb der Maschine, aber die SPS kann in "run" bleiben.

Es geht mir ja auch nur darum, dass evtl. geänderte Werte trotz geändertem DB gesichert und auch wieder zu SPS übertragen werden können.

die Variablentabelle sucht sich die zum Symbol dazugehörige Adresse und es wird die alte bzw. nach übertrage des db's die neue Adresse angezeigt

Alles klar, danke!

Andere Teilnehmer hier im Forum haben sicherlich andere Ziele, z.B. Änderungen von Sollwertvariablen im Automatikbetrieb, Einfügen neuer Sollwertvariablen im Automatikbetrieb, Einfügen neuer Arbeitsvariablen im Automatikbetrieb, ... . Für das Verständnis einer Vorgehensweise ware es wichtig, den jeweiligen Anwendungsfall kurz zu beschreiben.

Andere Frage: Bei V13 gibt es die Möglichkeit, DB-Variable als Einstellwerte zu markieren und diese später auf Startwerte zu reinitialisieren. Das sollte eigentlich zu Deinem Anwendungsfall passen. Hast Du es schon mal probiert? Falls ja, welche Erfahrung hast Du damit gemacht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Diese ganze Thematik mit reinitialisieren und mit aller Gewalt konsistent halten löst bei mir immer
wieder nur ungläubiges Kopfschütteln aus.
Wie weit sind diese Typen, die sich das ausgedacht haben, eigentlich von der Praxis weg?

Wenn TIA ein Auto wäre...
Man könnte nicht schalten ohne den Motor aus zu machen.
Und man kommt niemals von der Straße ab,
auch dann nicht wenn es mal sein muss und man es will.
Das Ganze würde auch noch als Fortschritt angepriesen werden.
 
Diese ganze Thematik mit reinitialisieren und mit aller Gewalt konsistent halten löst bei mir immer
wieder nur ungläubiges Kopfschütteln aus.
Wie weit sind diese Typen, die sich das ausgedacht haben, eigentlich von der Praxis weg?

Wenn TIA ein Auto wäre...
Man könnte nicht schalten ohne den Motor aus zu machen.
Und man kommt niemals von der Straße ab,
auch dann nicht wenn es mal sein muss und man es will.
Das Ganze würde auch noch als Fortschritt angepriesen werden.

Bei der Geschwindigkeit wie das TIA-Auto fährt, ist ein von der Straße abzukommen,
fast unmöglich. Ich glaube man kann getrost ein 6Km/h Schild drauf machen,
dann braucht es auch keine Straßenzulassung. Blöd nur wenn man damit Über
die Autobahn zum Kunden muss, da man eigentlich nur Landstraßen benutzen
kann.
 
Zuletzt bearbeitet:
Bei den 300/400ern lassen sich DBs auch verlängern ohne die Aktualdaten zu verlieren, indem man sie in der Online-Sicht bearbeitet.
Bei anderen Änderungen (z.B. umstellen von zwei Int in eine Real Variable), konnte man sich auch behelfen. Man hat sich einen ausreichend großen Dummy-DB hochgeladen, dei Sollwert-DB per Blockmove in den Dummy-DB schreiben, anschließend zu Beginn des OBs per Blockmove vom Dummy-DB in den Sollwert-DB. Dann den Sollwert-DB laden, und Blockmove löschen.

Gibts da einen Trick wie man sowas bei optimierten DB hinbekommt? D.h. die Daten eines DBs mit diversen Typen auf einen DB z.B. mit einem Byte-Array kopieren und umgekehrt. Dann könnte man sich damit ebenfalls behelfen.

Ich weiß auch nicht wieso Siemens das wieder so kompliziert machen muss, da ist das bei Codesys ja sogar mittlerweile einfacher und zuverlässiger. Bei diesem "optimierten" Bausteinen überwiegen die Nachteile.
 
Zurück
Oben