TIA S7-1500 nicht optimierten DB laden ohne Stopp

[MaurerT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen, ich hab mal eine Frage zum Bausteinladen bei einer 1500er CPU und TIA V15.1. Ich habe einige nicht optimierte DB´s im Projekt und dort extra Reserven vorgesehen damit bei Erweiterungen eben genau diese nicht eintritt. Jetzt habe ich im DB bei einem Bool nur den Text geändert von Reserve auf was anderes und wollte diesen dann in die CPU laden. Dies ist jetzt aber nur mit Reinitialisierung und CPU Stopp möglich. Wie kann ich dieses Problem lösen bzw. geht das überhaupt bei nicht optimierten Bausteinen? Bei optimierten Bausteinen kann ich das vermutlich ja über die DB Einstellung "Laden ohne Reinitialisierung" bewerkstelligen.
Vielen Dank

 

[hucki]

Dies ist jetzt aber nur mit Reinitialisierung und CPU Stopp möglich. Wie kann ich dieses Problem lösen bzw. geht das überhaupt bei nicht optimierten Bausteinen?

Beliebtes Frust-Thema bei TIA.

Geht nicht.
Warum nicht, weiß nur Siemens.
Ist für Siemens aus unerfindlichen Gründen scheinbar aber auch keine Priorität.


Ducati hat sich IMHO damit intensiver beschäftigt und eine "Lösung" über Copy-DBs.
Wie ich ihn kenne, meldet er sich sehr wahrschlich noch zu diesem Reizthema.

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist für Siemens aus unerfindlichen Gründen scheinbar aber auch keine Priorität.

Wer nicht mehr seiner eigenen Software arbeitet, versteht auch die Probleme nicht.
Ist auch für viele andere TIA-Probleme die einzige Erklärung ...

Die arrogante Entwicklung lebt ja schon lange auf anderen Planeten.
"Echte" Alienware !

 

[escride1]

Ich würde mich mit optimierten Bausteinen anfreunden.

"Nicht optimierte Bausteine sind in S7-1200/1500 Steuerungen nur ausKompatibilitätsgründen vorhanden."

Auf kurz oder lang sind die Nicht-optimierten weg, bestimmt. Und ich weiß auch gar nicht wozu ich die noch brauche und warum es immer Diskussionen über etwas gibt das sehr viel besser funktioniert wie vorher.

 

[TP-Inc]

Reinitialisieren ist mir bekannt, aber CPU Stop braucht man nur wenn das Safety Programm geladen wird.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Reinitialisieren ist mir bekannt, aber CPU Stop braucht man nur wenn das Safety Programm geladen wird.

Ebenso wenn zuviele Änderungen durchgeführt wurden oder aber ein Global-DB eine Änderung bekommen hat die sich auf, keine Ahnung, 50% aller Bausteine auswirkt.
Allerdings kann man hier dann immer noch unsynchronisiert laden, also einzeln.

 

[TP-Inc]

Ebenso wenn zuviele Änderungen durchgeführt wurden oder aber ein Global-DB eine Änderung bekommen hat die sich auf, keine Ahnung, 50% aller Bausteine auswirkt.
Allerdings kann man hier dann immer noch unsynchronisiert laden, also einzeln.

Ach ok, das mit dem Laden ohne Synchronisieren habe ich schon oft gesehen, aber nie verstanden. Was genau bedeutet das?

 

[Thomas_v2.1]

Manche Dinge gehen halt nur über "nicht optmierte" Datenbausteine, z.B. Simatic.Net OPC-Server über OPC-DA kann nur auf "nicht optimierte" zugreifen, warum zum Teufel auch immer.

Ich habe in einigen Projekten mit "nicht optimierten" DBs auch so eine automatische Wiederherstellungsfunktion mit einem Backup-DB. Läuft wirklich völlig problemlos wenn es passend programmiert ist, eigentlich wie man das erwarten würde wie das von Siemens hätte realisiert werden sollen.

Das mit dem Backup.DB funktioniert leider dann nur mit "nicht optimierten" DBs, weil du auf "optimierte" keinen Blockmove über n Bytes ausführen kannst. Dann bist du an den Siemens-Zauber gebunden. Wobei ich noch nicht dokumentiert gefunden habe, was das mit der Speicherreserve auf sich hat die man dann voreinstellen muss. Ist die nach x Ladevorgängen irgendwann aufgebraucht und dann wird doch reinitialisiert? Oder kann ich bei einer Reserve von z.B. 100 Bytes keine Struct mit 101 Byte hinzufügen? Ist mir alles nicht klar, und das auszuprobieren was das auf sich hat kann nicht Sinn der Sache sein, weil sich der Zauber dann nämlich auch mit dem nächsten Firmwareupdate oder TIA-Version wieder ändern kann.

Das ist der Vorteil am eigenen Backup-DB, da weiß man wie es funktioniert, und dass es funktioniert.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Manche Dinge gehen halt nur über "nicht optmierte" Datenbausteine, z.B. Simatic.Net OPC-Server über OPC-DA kann nur auf "nicht optimierte" zugreifen, warum zum Teufel auch immer.

Ich habe in einigen Projekten mit "nicht optimierten" DBs auch so eine automatische Wiederherstellungsfunktion mit einem Backup-DB. Läuft wirklich völlig problemlos wenn es passend programmiert ist, eigentlich wie man das erwarten würde wie das von Siemens hätte realisiert werden sollen.

Das mit dem Backup.DB funktioniert leider dann nur mit "nicht optimierten" DBs, weil du auf "optimierte" keinen Blockmove über n Bytes ausführen kannst. Dann bist du an den Siemens-Zauber gebunden. Wobei ich noch nicht dokumentiert gefunden habe, was das mit der Speicherreserve auf sich hat die man dann voreinstellen muss. Ist die nach x Ladevorgängen irgendwann aufgebraucht und dann wird doch reinitialisiert? Oder kann ich bei einer Reserve von z.B. 100 Bytes keine Struct mit 101 Byte hinzufügen? Ist mir alles nicht klar, und das auszuprobieren was das auf sich hat kann nicht Sinn der Sache sein, weil sich der Zauber dann nämlich auch mit dem nächsten Firmwareupdate oder TIA-Version wieder ändern kann.

Das ist der Vorteil am eigenen Backup-DB, da weiß man wie es funktioniert, und dass es funktioniert.

https://cache.industry.siemens.com/...he_PLC_memory_function_manual_de-DE_de-DE.pdf Seite 28

Speicherreserve von Global-DBs und Instanz-DBs
Jeder Funktions- oder Datenbaustein mit aktiviertem Attribut "Optimierter Bausteinzugriff"enthält per Voreinstellung eine Speicherreserve, die Sie für nachträglicheSchnittstellenänderungen verwenden können. Die Speicherreserve wird zunächst nichtgenutzt. Wenn Sie den Baustein übersetzt und geladen haben und anschließend feststellen,dass Sie Schnittstellenänderungen nachladen wollen, aktivieren Sie die Speicherreserve.Alle Variablen, die Sie daraufhin deklarieren, werden in die Speicherreserve gelegt. Beimanschließenden Laden werden die neuen Variablen auf Ihre Startwerte initialisiert. Diebereits geladenen Variablen werden nicht reinitialisiert.

Die Einstellung der Speicherreserve finden Sie in STEP 7 unter den DatenbausteinEigenschaften in der Kategorie "Laden ohne Reinitialisierung".

 

[Thomas_v2.1]

Was passiert bei Datenbaustein mit Speicherreserve und aktiviertem "Laden ohne Reinitialisierung für remanente Variablen aktivieren" wenn ich den Namen einer Variable ändere? Demnach wird der DB dann reinitialisiert, toll.

 

[escride1]

Richtig, ist ja auch nur für nachträgliche Änderungen gedacht. Wenn die Variable umbenannt wird, dann verschiebt sich der interne Offset, wodurch alle neu eingestellt werden müssen. Aber auch das kann umgangen werden.

1) DB kopieren (STRG+C/STRG+V)
2) Momentaufnahme machen und in Startwerte kopieren
3) Variablennamen bearbeiten
Optional: 4) Speicherreserve aktivieren
Optional: 5) Neue Variable hinzufügen
6) Übersetzen und Laden (Reinitialisierung erfolgt mit Startwerten, also der Momentaufnahme/Aktualwerte)
7) Startwerte durch Startwerte im kopierten DB ersetzen (Copy&Paste über mehrere Zeilen hinweg)
8 ) Übersetzen & Laden ohne Reinitialisieren

Ein Umweg, aber machbar, vielleicht aber wird Siemens das ja auch irgendwann anbieten.

edit:
Der Umweg geht natürlich nur glatt wenn die Werte von Momentaufnahme bis zum Laden nicht geändert werden.

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit dem Backup.DB funktioniert leider dann nur mit "nicht optimierten" DBs, weil du auf "optimierte" keinen Blockmove über n Bytes ausführen kannst.

Anstatt MOVE_BLK, mit Serialize/Deserialize sollte es gehen. Funktioniert mit alle Typen von Strukturen und mit und ohne Optimisierte Daten.

 

[Olli_BS]

Der Umweg geht natürlich nur glatt wenn die Werte von Momentaufnahme bis zum Laden nicht geändert werden.

Und genau das macht es ja sehr unpraktisch.
Wenn ich eine Änderung im Büro vorbereite scheitert der Weg ja schon mal.

Also mache ich einen neuen DB. Bei der Beschriftung geht mir dann nach 2-3 solchen Vorgängen auch langsam die Phantasie aus und sauber strukturiert ist das mit den Leichen natürlich auch nicht.
Aber voll "Modern"!
Oder ich nehme MERKER. Dann ist das Problem gelöst. Remanenz kann dann allerdings schnell ein neues werden. Merker sind natürlich auch gegen die TIA Programmier "Richtlinien".

Ich warte eigentlich seit 3 Jahren auf die einzige Lösung (das Speichermanagement scheint ja zu unflexibel zu sein...):

CPU muss zwischen Zyklus Ende und Anfang alle Aktual-Inhalte gleicher (Name+Typ) Variablen umkopieren.
Das könnte bei großen Änderungen viel Zykluszeit kosten wäre aber in 99% der Fälle die beste Lösung.
Das sollte bei DB-Änderungen die Default-Lade-Einstellung sein. Platt machen/Initialisieren nur auf manuelle Anforderung.

Bedeutet natürlich erst mal ein Firmware-Upgrade. Darum schon lange lange lange überfälllig....

 

[escride1]

Es ist natürlich schwierig alles abzudecken. Aber den DB kopieren, diesen bearbeiten und auf der Baustelle beim aktuellen die Momentaufnahme zu machen, in diesen DB hineinkopieren und dann die DBs tauschen, den alten danach löschen, sollte eigentlich nicht so arg schwer sein.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist natürlich schwierig alles abzudecken. Aber den DB kopieren, diesen bearbeiten und auf der Baustelle beim aktuellen die Momentaufnahme zu machen, in diesen DB hineinkopieren und dann die DBs tauschen, den alten danach löschen, sollte eigentlich nicht so arg schwer sein.

Wenn du das Programm auf einen anderen DB vorbereitet hast, dann musst du aber anschließend noch alle DB-Zugriffe anpassen. Also im Grunde kannst du nichts wirklich 100% vorbereiten wie das bisher möglich war.
Das mit der Momentaufnahme ist auch nur sehr eingeschränkt nutzbar. Machst du eine Momentaufnahme und änderst etwas am DB, dann sind auch die Momentaufnahmewerte weg.

Im Grunde hast du bei "optimierten" für den Fall dass du die Aktualwerte behalten willst mehr Nachteile als Vorteile. "Optimiert" ist dort nur die Praxisuntauglichkeit.

 

[Thomas_v2.1]

Anstatt MOVE_BLK, mit Serialize/Deserialize sollte es gehen. Funktioniert mit alle Typen von Strukturen und mit und ohne Optimisierte Daten.

Wäre ein Versuch wert. Ich schätze aber das benötigt sehr reichlich Zykluszeit, wenn du einen Datenbaustein mit mehreren tausend Variablen serialisieren willst.

 

[escride1]

Wenn du das Programm auf einen anderen DB vorbereitet hast, dann musst du aber anschließend noch alle DB-Zugriffe anpassen. Also im Grunde kannst du nichts wirklich 100% vorbereiten wie das bisher möglich war.
Das mit der Momentaufnahme ist auch nur sehr eingeschränkt nutzbar. Machst du eine Momentaufnahme und änderst etwas am DB, dann sind auch die Momentaufnahmewerte weg.

Im Grunde hast du bei "optimierten" für den Fall dass du die Aktualwerte behalten willst mehr Nachteile als Vorteile. "Optimiert" ist dort nur die Praxisuntauglichkeit.

Ich bereite ~50% aller Änderungen offline vor. Inklusive Änderungen von DBs und FBs. Ich habe keinerlei Probleme und die Zeit auf der Baustelle für die Umwege beschränken sich auf weniger als 1-2 Minuten.

Ich kann sehr wohl ohne Verluste der aktuellen Werte die Datenbausteine tauschen:

- Kopiere Deinen DB 2 mal
- Ändere am neu erstellten, also der Kopie, den Variablennamen, füge neue hinzu, füge welche ein.
- Gehe online
- Momentaufnahme des alten DB erstellen, kopieren und in die Startwerte des veränderten, darauf aufpassen das bei eingefügten oder entfernten Variablen die Struktur stimmt, entsprechend öfter kopieren bei eingefügten Variablen.
- Gehe offline
- Lösche alten DB
- Benenne geänderten so um das er anstelle des alten tritt: Umbennenen und _1 entfernen
- Gehe online
- Laden und übersetzen
- Startwerte vom 2. kopierten in den DB kopieren
- Lösche 2. Kopie
- Laden und übersetzen

Wenn die Struktur des DBs geändert wird, also neue Variablen dazwischen eingefügt werden, dann muss man mit dem kopieren der Werte eben aufpassen. Aber das war noch nie anders.
Und nein, wenn ich am DB etwas ändere dann verliere ich nicht die Momentaufnahmen, nur die aktuelle Beobachtung kann nicht fortgesetzt werden.
Und auch alle Verlinkungen im Programm werden richtig angepasst, selbst wenn der Variablenname sich ändert oder eine Variable dazwischen eingefügt wird.

Es ist also ohne Probleme, jedoch mit Umweg (der dank der sehr viel einfacheren Handhabung des TIA-Portals vs S7-Classic sehr zügig abgearbeitet werden kann) möglich DBs zu ändern. Selbst bei IDBs kann ein leicht abgewandeltes Vorgehen gewählt werden.

Die Option Speicherreserve/Laden ohne Reinitialisierung ist gedacht um bei der Inbetriebnahme/Online etwas hinzuzufügen. Das funktioniert einwandfrei.
Wenn man aber grundlegend die Struktur oder Namen ändern will, dann muss eben darauf geachtet werden was man tut. Doch es ist möglich, und durch ein übersichtlicheres Projektfenster natürlich leichter und angenehmer als mit S7-Classic.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, meine eigene Backup-DB Funktion kümmert sich um das alles von selber so wie ich es eigentlich von der Programmierumgebung erwarten würde. Ich kann die Programmänderung vorbereiten, und ohne irgendwelche Vorbereitungen Laden. Das Einzige was ich beachten muss, ist keine Adressen zu verschieben, und das geht halt leider nur mit "nicht optimierten" DBs mit allen Nachteilen die sich daraus ergeben.

Hast du bei deiner DB Umkopierere mal getestet was mit einer Visualisierung passiert die auf diesen DB symbolisch zugreift? Meiner Meinung nach sind nach der Änderung keine Zugriffe mehr möglich weil die Symbole eine neue ID bekommen werden, und du musst die Visualisierung / HMI neu übersetzen und Laden um diese IDs zu aktualisieren.

Mit den Startwerten ist auch eine Variante die man nicht unbedingt haben möchte. Wenn du in deinem DB Störmeldungen anstehen hast und es stehen gerade ein paar Meldungen an, oder es sind andere Funktionen aktiv die nicht der Normalzustand ist (Handbetrieb, Simulationswerte aktiv), dann werden diese zukünftig als Startwert angenommen.

 

[PN/DP]

Einfach Aktualwerte als Startwerte übernehmen ist oft zu kurz gedacht. Dann hilft bei manchen Programmfehlern nicht mal Aus/Einschalten und selbst Urlöschen hilft dann nicht aus der "unmöglichen" Situation.

Harald

 

[escride1]

Naja, meine eigene Backup-DB Funktion kümmert sich um das alles von selber so wie ich es eigentlich von der Programmierumgebung erwarten würde. Ich kann die Programmänderung vorbereiten, und ohne irgendwelche Vorbereitungen Laden. Das Einzige was ich beachten muss, ist keine Adressen zu verschieben, und das geht halt leider nur mit "nicht optimierten" DBs mit allen Nachteilen die sich daraus ergeben.

Ja, Du darfst nix verschieben. Ich schon, ohne Nachteile.

Hast du bei deiner DB Umkopierere mal getestet was mit einer Visualisierung passiert die auf diesen DB symbolisch zugreift? Meiner Meinung nach sind nach der Änderung keine Zugriffe mehr möglich weil die Symbole eine neue ID bekommen werden, und du musst die Visualisierung / HMI neu übersetzen und Laden um diese IDs zu aktualisieren.

Ja, die HMI muss aktualisiert werden wenn darauf zugegriffen wird, stand bisher aber nicht zur Debatte. Aber um genau zu werden: Alle Variablen öffnen, Alle auswählen - Synchronisieren - Pfad, Datentyp und absolute Adresse muss übereinstimmen, Übersetzen, Laden.
Ist es bei S7-Classic einfacher mal eben Variablen in einem DB einzufügen wenn sich der Offset ändert dies mit WinCC flex aktuell zu halten? Bei einer gewissen Grenze funktioniert es auch hier nicht, und die ist schneller erreicht als mit dem aktuellen Portal.

Mit den Startwerten ist auch eine Variante die man nicht unbedingt haben möchte. Wenn du in deinem DB Störmeldungen anstehen hast und es stehen gerade ein paar Meldungen an, oder es sind andere Funktionen aktiv die nicht der Normalzustand ist (Handbetrieb, Simulationswerte aktiv), dann werden diese zukünftig als Startwert angenommen.

[/quote]
Deswegen ja auch zwei mal kopieren um den 2. DB als Speicher für die Startwerte zu haben. Selbstverständlich will ich keinen StörmeldeDB mit Startwerten als true haben.