Step 7 Datenbausteine aus AG Abzug wieder verwenden ?

[All4one]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
eine Frage hinsichtlich Anfangswert und Aktualwert.
Ich habe einen Kunden im Asiatischen Raum und suche die günstigste Variante,ein SW-Update übertragen zu können.

Wenn ich im vorhandenen AG Abzug änderungen in FC's und FB's durchführe,das ganze Projekt mit den Datenbausteinen aus dem AG Abzug auf SD Karte übertrage, entnimmt das Programm automatisch alle Aktualwerte aus den DB's, wenn man vor Ort die SD-Karte einsetzt?

 

[PN/DP]

Von welcher Steuerung sprichst Du?
Siemens-SPS können nicht mit SD-Karten betrieben werden. Die brauchen spezielle MMC MicroMemoryCards.

Falls Du Siemens S7-300 meinst:
Wenn man eine neue MMC in die CPU einsetzt, dann fordert die CPU beim nächsten Einschalten das Urlöschen an und initialisiert dadurch die Aktualwerte der DB mit den Anfangswerten.

Harald

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

..Falls Du Siemens S7-300 meinst:
Wenn man eine neue MMC in die CPU einsetzt, dann fordert die CPU beim nächsten Einschalten das Urlöschen an und initialisiert dadurch die Aktualwerte der DB mit den Anfangswerten..

Bist du dir da sicher? Urlöschen ist klar, aber werden dann wirklich die Anfangswerte verwendet, wenn bereits Aktualwerte in den DBs der MMC vorhanden sind? Ich dachte immer, die Anfangswerte werden nur ein einziges mal verwendet, nämlich dann wenn der DB neu angelegt bzw. in der Struktur verändert wurde. Ich wechselte, soweit ich zurück denken kann, allerdings noch nie eine MMC mit aufgespieltem Programm, bin mir daher auch nicht sicher.

Gruß, Onkel

 

[All4one]

Hallo zusammen.
Aus dem Handbuch bzw. Siemens Support werden die Aktualwerte der DB's, die sich auf der MMC (meinte ich!) befinden, nach dem Urlöschen übernommen.

@ Onkel Dagobert: Wenn man Anfangswerte einträgt, kann man diese dann, wenn man in die Ansicht "Datenansicht" Ctrl+4 wechselt, dann initialisieren. D.h. werden die Anfangswerte in die Aktualwerte eingetragen.

Ich habe es folgendermaßen im Büro simuliert:

1. DB1 Bereich DBD0- DBD4 online über VAR Tabelle mit Werten bestückt
2. Dann Offline im DB1 DBD5-DBD6 mit Anfangswerten initialisiert
3. Programm über Prommer auf Karte übertragen
4. eingesetzt, urlöschen
5. online überprüft,ob die Werte auch darin stehen

Ergebiss: ERFOLGREICH!!! Die Werte die man in die Aktualwerte einträgt, werden nach dem Urlöschen und dem Start der SPS von der MMC übernommen und das Programm arbeitet dann mit den Werten.

Gruß Rolle

 

[PN/DP]

Mysterium "Anfangswert" bei DB in S7-300

..Falls Du Siemens S7-300 meinst:
Wenn man eine neue MMC in die CPU einsetzt, dann fordert die CPU beim nächsten Einschalten das Urlöschen an und initialisiert dadurch die Aktualwerte der DB mit den Anfangswerten..

Bist du dir da sicher?

OK, ich korrigiere und präzisiere:
Wenn man eine neue MMC in die CPU einsetzt, dann fordert die CPU beim nächsten Einschalten das Urlöschen an und wenn die neue MMC ein Programm enthält überschreibt sie dadurch die momentanen Aktualwerte der DB im Arbeitsspeicher mit den Werten vom Ladespeicher (MMC). Diese Werte heißen aber nicht "Anfangswerte" sondern es sind die Werte, die im offline-Projekt in der Spalte "Aktualwert" festgelegt wurden.


Seit es die S7-300 CPUs mit MMC gibt, dokumentiert Siemens das geänderte Verhalten des "Anfangswert" (Initialwert) von DB-Variablen in unklaren, sich widersprechenden und teilweise auch falschen Aussagen.

Früher bei den CPU mit MC war klar: Variablen in DB haben nur einen Wert - im Arbeitsspeicher den Aktualwert und im Ladespeicher den Anfangswert. Beim Urlöschen werden die DB neu vom Ladespeicher in den Arbeitsspeicher geladen und deshalb die Aktualwerte auf die Anfangswerte gesetzt. Sehr logisch.
Wie funktioniert das Kopieren des Anwenderprogramms vom Ladespeicher in den Arbeitsspeicher ohne PG bei einer S7-300 CPU mit MC-Slot?

CPU kopiert den ablaufrelevanten Teil des Programms vom Ladespeicher in den Arbeitsspeicher. Insbesondere werden dadurch die Datenbausteine im Arbeitsspeicher intialisiert (erhalten wieder ihre Anfangswerte).

Dieses Verhalten mit MC (oder integriertem EPROM-Ladespeicher) wurde bei den CPU mit MMC geändert.
Remanenzverhalten der S7-300 CPU 31x sowie der Komplettgeräte C7-6xx mit MMC

2. Die Daten werden auf die Aktualwerte aus dem Ladespeicher zurückgesetzt. Dies sind die letzten Aktualwerte, die vom PG in die CPU geladen oder mittels SFC84 oder die STEP 7-Funktion "RAM nach ROM kopieren ..." in den Ladespeicher geschrieben wurden.
[...]

Abläufe nach dem Urlöschen bei gesteckter MMC:

• Wenn eine MMC gesteckt ist, kopiert die CPU im Anschluss an das Urlöschen das Anwenderprogramm und die auf der MMC gespeicherten Systemparameter in den Arbeitsspeicher. Bei Datenbausteinen werden die Aktualwerte aus den Datenbausteinen auf der MMC neu geladen.
• Wo in diesen Datenbausteinen auf der MMC keine Aktualwerte vorhanden sind, da werden die Anfangswerte aus dem Ladespeicher geladen.

was soll uns der letzte Satz sagen???

Welche Bedeutung haben die Anfangs- und die Aktualwerte eines Datenbausteins?

Für die CPU ist ausschließlich der Wert von Bedeutung, welcher sich in der Spalte "Aktualwert" befindet. Auch wenn der Anfangswert mit auf die CPU geladen wird und dort im Onlinemodus beobachtbar ist, so wird dieser Wert von der CPU nicht verwendet.

Hier kommen wir der Realität schon langsam näher, allerdings noch nicht ganz korrekt. Die Hilfe zu Step7 V5.5 klärt dann endlich auf:

Anfangswert
Hierbei handelt es sich um den Anfangswert, den Sie für die Variable festgelegt haben, wenn die Software nicht den Defaultwert für den eingegebenen Datentyp übernehmen sollte.

Der Anfangswert wird beim erstmaligen Speichern des Datenbausteins für die Variable als aktueller Wert übernommen, falls Sie nicht explizit einen aktuellen Wert der Variable festlegen.

Bitte beachten Sie: Im Gegensatz zu den Aktualwerten können Anfangswerte nicht in die CPU geladen werden!

und

Wählen Sie hierfür den Menübefehl Bearbeiten > Datenbaustein initialisieren.

Alle Variablen werden wieder mit ihrem vorgesehenen Anfangswert versorgt, d.h. die aktuellen Werte aller Variablen werden durch den jeweiligen Anfangswert überschrieben.

Der Anfangswert wird nur im offline-Projekt verwendet, wie dieses "Datenbaustein initialisieren" und das Initialisieren bei der Konsistenzprüfung.

Kurz gefasst:
Bei den S7-300 CPU mit den MMC gibt es in der CPU gar keinen "Anfangswert" mehr! Der Wert im Ladespeicher wird "Aktualwert" genannt - weil es ist der Wert der offline in der Spalte "Aktualwert" festgelegt wird - er verhält sich aber wie ein Anfangswert. Beim Urlöschen wird der DB genauso wie früher neu vom Ladespeicher (MMC) in den Arbeitsspeicher geladen und die Variablen haben danach die anfangs offline projektierten Aktualwerte. Die Werte im Ladespeicher sind aber nicht mehr die als "Anfangswert" projektierten Werte, sondern die offline in der Spalte "Aktualwert" projektierten Werte.

Wieso Siemens das so verwirrend ändern mußte, das mag verstehen wer will.

Genauso die Formulierung "wenn bereits Aktualwerte vorhanden sind" bzw. "Wo auf der MMC keine Aktualwerte vorhanden sind" - gibt es denn überhaupt DB-Variablen, welche (noch) keinen Aktualwert haben? Ich meine: Was für ein Schwachsinn.

Testergebnis
Weil der Test von All4one methodisch fehlerhaft durchgeführt wurde, habe ich das Problem heute mal an 2 verschieden alten S7-300-CPU getestet (eine aktuelle 315-2 PN/DP V3.2.3 und eine 314C V1.0).
Dabei wurden in DB Variablen mit dem Anfangswert 1 und dem Aktualwert 2 angelegt. Nach dem erstmaligen Laden der DB in die CPU wurden erwartungsgemäß sofort die "Aktualwerte" aktiv - die Variablen hatten sofort den Wert 2. Nun wurden per VAT die Variablen auf den Wert 3 gesetzt und danach Urlöschen durchgeführt (mit PG und auch mit Betriebsartenschalter). Nach dem Urlöschen hatten die Variablen wieder den Wert 2 - den offline projektierten "Aktualwert".

Die neuere CPU unterstützt das DB-Attribut "non-Retain". Diese setzt jedem Stop/Run-Übergang die Aktualwerte der non-Retain-DB auf die offline festgelegten Aktualwerte zurück, d.h. auf den Wert 2. (verschiedene Dokumentationen behaupten, die non-Retain-Variablen würden auf 0 gelöscht! was also nicht korrekt ist)

Egal was ich mit den CPU angestellt habe, die DB-Variablen wurden NIE auf die projektierten "Anfangswerte" 1 gesetzt.


PS:
Man müßte mal noch testen, welchen Anfangswert Online-DB haben/erhalten, wenn das offline Projekt nicht vorhanden ist, also einfach in ein leeres Projekt herausladen. Dann wüßte man, ob die Anfangswerte in die MMC geladen werden oder nicht.

Harald

 

[All4one]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Harald,
kurz gesagt: Wenn man im Datenbaustein Anfangswerte einträgt,über Ctrl+4 in die Datenansicht wechselt,den Baustein dann über Bearbeiten "Datenbaustein initislisieren" die Aktualwerte mit den Anfangswerten überschreibt,lädt die CPU beim Neustart diese Aktualwerte in den Arbeitsspeicher.
Hat den Hintergrund: Wenn man an einer laufenden Anlage ein Update durhführt,vorher ein AG-Abzug gemacht hat,kann man alle DB's aus dem AG Abzug wieder übernehmen,und alle (Aktual..)Parameter wie Chargenzähler bleiben erhalten.
Schönen Feiertag
Gruß Rolle

 

[PN/DP]

Wenn man im Datenbaustein Anfangswerte einträgt,über Ctrl+4 in die Datenansicht wechselt,den Baustein dann über Bearbeiten "Datenbaustein initislisieren" die Aktualwerte mit den Anfangswerten überschreibt,lädt die CPU beim Neustart diese Aktualwerte in den Arbeitsspeicher.

Hallo Rolle,

(1) diese Aussage ist in der suggerierten Kausalität mit Anfangswerten leider nicht ganz richtig. Es bedarf überhaupt keiner Anfangswerte. Nur die eingetragenen Aktualwerte sind von Belang.

(2) Definiere, was Du mit "Neustart" meinst. Ich verstehe darunter einen Stop/Run-Übergang (Neustart/Warmstart) - aber nicht das Urlöschen.

Schon beim Laden vom PG in die CPU werden die offline-"Aktualwerte" in den Arbeitsspeicher geladen - nicht erst bei einem "Neustart". Außerdem betrifft dieses Laden der Aktualwerte vom Ladespeicher in den Arbeitsspeicher bei einem "Neustart" nur DB mit "non-Retain"-Attribut bei CPU die dies unterstützen. Bei DB ohne dieses "non-Retain"-Attribut werden die Aktualwerte nur bei Urlöschen vom Ladespeicher in den Arbeitsspeicher geladen. Und das tut die CPU auch dann, wenn man keine Anfangswerte einträgt oder die Anfangswerte völlig verschieden von den eingetragenen Aktualwerten sind.
Die Anfangswerte werden von der CPU völlig ignoriert.

Hat den Hintergrund: Wenn man an einer laufenden Anlage ein Update durhführt,vorher ein AG-Abzug gemacht hat,kann man alle DB's aus dem AG Abzug wieder übernehmen,

Dieser Vorgang hat mit Anfangswerten nichts zu tun. Dafür ist es nicht nötig, irgendwelche Werte in die Anfangswerte einzutragen.
Und Vorsicht! Es gibt Anwendungsfälle, wo es nötig ist, daß DB-Variablen nach Urlöschen keinen alten Aktualwert sondern 0 (oder einen anderen definierten Anfangswert) enthalten müssen. Solche DB dürfen dann nicht aus AG-Abzügen übernommen werden.

und alle (Aktual..)Parameter wie Chargenzähler bleiben erhalten.

natürlich die Werte, die zum Zeitpunkt des AG-Abzuges die aktuellen Werte waren. Von nun an werden bei jedem Urlöschen die Aktualwerte auf die Werte zum Zeitpunkt des AG-Abzugs gesetzt.


Den einzigen Vorteil und wahrscheinlichen Grund, warum Siemens dieses verwirrende Aktualwert-Spiel nun so handhabt sehe ich darin, daß es so möglich ist per RAM-nach-ROM-kopieren bzw. programmgesteuert mit SFC84 die aktuellen Aktualwerte vom Arbeitsspeicher in den Ladespeicher zu sichern, damit diese beim nächsten Urlöschen die "anfänglichen" Aktualwerte werden.


Schönen Feiertag! Hier an der Ostseeküste ist leider kein Feiertag.

Harald

 

[PN/DP]

Man müßte mal noch testen, welchen Anfangswert Online-DB haben/erhalten, wenn das offline Projekt nicht vorhanden ist, also einfach in ein leeres Projekt herausladen. Dann wüßte man, ob die Anfangswerte in die MMC geladen werden oder nicht.

Das habe ich nun heute getan.
Mit einem anderen PG in ein neues leeres Projekt das Programm aus beiden CPU herausgeladen - und siehe da, die DB haben den offline projektierten Anfangswert 1 - der Anfangswert wird also doch in die CPU geladen, die Aussage der Step7 Hilfe ist also falsch oder zumindest irreführend formuliert.

Doch es kommt noch besser: die herausgeladenen DB haben als Aktualwert den aktuellen Wert aus dem Arbeitsspeicher eingetragen, NICHT den Wert, der im Ladespeicher als Aktualwert drinsteht. Das herausgeladene Programm entspricht NICHT dem tatsächlich in der CPU vorhandenen Programm!
Ein Bausteinvergleich sagt aber, daß zwischen dem online vorhandenen DB und dem herausgeladenen DB kein Unterschied besteht!

Würde man nun in der CPU ein Urlöschen machen, dann würden die Aktualwerte auf die ursprünglich im Ladespeicher hinterlegten Aktualwerte gesetzt (in meinem Test auf 2). Würde man die gerade herausgeladenen DB wieder in die CPU laden, dann würden nach einem Urlöschen die Aktualwerte abweichend auf 3 gesetzt.

Zum Nachvollziehen:
1. offline einen DB erstellen mit einer INT-Variable mit Anfangswert 1 und Aktualwert 2
2. den DB in die CPU laden --> die Variable hat nun den Wert 2
3. per VAT die Variable auf den Wert 3 setzen
4. den DB aus der CPU herausladen
5. Urlöschen ausführen --> die Variable wird auf 2 gesetzt
6. den gerade herausgeladenen DB wieder in die CPU laden
7. Urlöschen ausführen --> die Variable wird auf 3 gesetzt

Es ist also nicht mit Sicherheit vorhersehbar, welche Werte die DB-Variablen im Arbeitsspeicher nach einem Urlöschen haben werden, weil man mit einem PG nicht die "Aktualwerte" aus dem Ladespeicher herauslesen kann (nur das Programm kann sie mit SFC83 lesen). Oder kennt jemand eine Möglichkeit, die DB vom Ladespeicher ins PG zurückzuladen ohne daß Step7 (oder die CPU) daran manipuliert?

PS:
Ein wirklich identisches Backup erhält man anscheinend nur, wenn man direkt die MMC liest/kopiert.

PPS:
Dieses Verhalten könnte man für eine Art "Kopierschutz" oder Manipulations-Erkennung nutzen.

Harald

 

[Toki0604]

Zuviel Werbung?
-> Hier kostenlos registrieren

Respekt, ich habe dieses Thema immer für bedeutend einfacher gehalten...

Gruß, Torsten

 

[MRose]

Hallo

...
Doch es kommt noch besser: die herausgeladenen DB haben als Aktualwert den aktuellen Wert aus dem Arbeitsspeicher eingetragen, NICHT den Wert, der im Ladespeicher als Aktualwert drinsteht.
...

Ein anderes Verhalten hätte mich jetzt auch erstaunt. Ich will ja beim Rückladen aus der CPU den aktuellen Stand, also die aktuellen Aktualwerte, und nicht irgendwelche alten Aktualwerte.

 

[Onkel Dagobert]

Hallo Harald,

du hast dir aber eine Menge Arbeit gemacht. Ich gebe mal meinen Senf dazu.

Zum Nachvollziehen:
1. offline einen DB erstellen mit einer INT-Variable mit Anfangswert 1 und Aktualwert 2 - ok
2. den DB in die CPU laden --> die Variable hat nun den Wert 2 - ok
3. per VAT die Variable auf den Wert 3 setzen - ok, 3 steht jetzt als Aktualwert im Arbeitsspeicher
4. den DB aus der CPU herausladen - wird mit Aktualwert 3 aus dem Arbeitsspeicher von online nach offline gesichert
5. Urlöschen ausführen --> die Variable wird auf 2 gesetzt - weil die 2 derzeit im Ladespeicher als Aktualwert steht
6. den gerade herausgeladenen DB wieder in die CPU laden - wird jetzt vom PG mit Aktualwert 3 in den Ladespeicher geladen, im Arbeitsspeicher steht noch die 2
7. Urlöschen ausführen --> die Variable wird auf 3 gesetzt - wird aus dem Ladespeicher mit Aktualwert 3 in den Arbeitsspeicher geladen

Also durchaus nachvollziehbar und logisch.
Hättest du Schritt 3a oder alternativ 3b nicht vergessen, wäre alles mit Aktualwert 3.

3a. RAM nach ROM kopieren - Aktualwerte werden aus dem Arbeitsspeicher in den Ladespeicher gesichert.
3b. Spannungsausfall - Aktualwerte werden aus dem Arbeitsspeicher in den Ladespeicher gesichert.


Gruß, Onkel

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Onkel,

ein paar Anmerkungen und Widersprüche von mir.

6. den gerade herausgeladenen DB wieder in die CPU laden - wird jetzt vom PG mit Aktualwert 3 in den Ladespeicher geladen, im Arbeitsspeicher steht noch die 2
der Aktualwert im Arbeitsspeicher wird sofort 3

3a. RAM nach ROM kopieren - Aktualwerte werden aus dem Arbeitsspeicher in den Ladespeicher gesichert.
Ja, RAM-nach-ROM hat den gleichen Effekt wie herausladen und wieder hineinladen.

3b. Spannungsausfall - Aktualwerte werden aus dem Arbeitsspeicher in den Ladespeicher gesichert.
Die Aktualwerte aus dem Arbeitsspeicher werden in einen von außen wahrscheinlich unzugänglichen Bereich auf die MMC geschrieben, aber nicht in den Ladespeicher. Der Aktualwert im Ladespeicher bleibt unverändert, wie man mit einem Urlöschen sehen kann.
Aktualwerte in DB mit dem non-Retain-Attribut werden beim Spannungsausfall nicht gesichert, sondern beim nächsten bzw. bei jedem Stop/Run-Übergang mit dem Aktualwert aus dem Ladespeicher initialisiert.

Harald

 

[PN/DP]

Kurz gefasst:
Schreiben in die CPU geht immer in den Ladespeicher und wird dann sofort in den Arbeitsspeicher kopiert.
Beim Lesen aus der CPU wird immer der Aktualwert aus dem Arbeitsspeicher genommen.

Direktes Herauslesen des Aktualwertes aus dem Ladespeicher ist offenbar nicht möglich.

Harald

 

[PN/DP]

...
Doch es kommt noch besser: die herausgeladenen DB haben als Aktualwert den aktuellen Wert aus dem Arbeitsspeicher eingetragen, NICHT den Wert, der im Ladespeicher als Aktualwert drinsteht.
...

Ein anderes Verhalten hätte mich jetzt auch erstaunt. Ich will ja beim Rückladen aus der CPU den aktuellen Stand, also die aktuellen Aktualwerte, und nicht irgendwelche alten Aktualwerte.

Dieses Verhalten ist ja auch richtig so, weil es der Erwartung entspricht. Allerdings ist es dadurch nicht möglich, ein Backup des Ladespeichers zu machen. Die Kopie einer CPU per AG-Abzug verhält sich beim Urlöschen anders als das Original.

Harald