Beckhoff Retain wirklich so umständlich?

L.T.

Level-2
Beiträge
190
Reaktionspunkte
25
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich bin gerade dabei ein neues Projekt mit Beckhoff CX90xx umzusetzen.
Bin seither von CoDeSys basierten Steuerungen (ja ich weiß Twincat und CoDeSys sehen nur ähnlich aus..) im Bezug auf Retain, Persistent, Retain Persistent,..... Var gewohnt diese einfach in der Var-Tabelle zu deklarieren und gut.
Bei Beckhoff habe ich aber bis jetzt nur gefunden, dass man die Retain Var über FB´s ins NOVRAM schreiben/lesen muss.
Ist das wirklich so umständlich zu machen oder stell ich mich doof an?

Ein Array mit n paar hundert Var auf ein Schlag zu schreiben und zu lesen is ja nicht das Ding.
Aber eigentlich gefällt mir das nicht wenn meine Retain-Var dann alle gleiche Namen tragen und sich nur im Index unterscheiden.
Da kennt sich ja kein Mensch mehr aus im Prog. und wenn dann noch zwischendrin Var nicht mehr benötigt werden, hat man x Lücken die verschwendet werden.
Gibt es nicht wenigstens die Möglichkeit die "ganz normal" deklariereten Retain-Var über einen FB zu sichern/Lesen??

Vielen Dank für jede Antwort!

Gruß L.T.
 
Hallo L.T. ,

als ich das erste mal drauf gestoßen bin, war ich auch nicht begeistert. :|
Man kann sich aber gut helfen. Sieh mal hier...

Wenn du nicht sehr viele Variablen hast (<200) und deine SPS- Zykluszeit eher gemütlich ist (>=20ms) dann sollte "Variante 3" ausreichen.
Ansonsten musst du den Aufwand von "Variante 2" einmal betreiben und kannst künftig die Funktionen von Projekt zu Projekt übernehmen...

Gruß
Chräshe
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Chräshe,

vielen Dank für die Antwort.
Werde es mir die Tage mal anschauen und dann im Zweifelsfall nochmal auf Dich zurückkommen.

Gruß L.T.
 
Hallo trinitaucher,

danke für die Links.
Aber das ist ja genau das was ich mit umständlich gemeint habe.
Entweder ich kopiere jede Var Einzeln mit dem verlinkten Baustein ins NOVRAM.
(Dann hab ich aber 150 FB Aufrufe nur für das Speichern von ein paar Retain Daten hätte aber für jede Retain Var ein ordentliche Bezeichnug (z.B. MD_1515_Setpoint_ValueA)
Vorteil:
- Jede Var ist am Namen zu bestimmen
- Gelöschte Var werden beim kompilieren angemeckert und können gelöscht werden
Nachteil:
- Wahnsinns Aufwand
- werden Var gelöscht muss die Lücke händisch im NOVRAM neu belegt werden (Index der Speicherbelegung muss ja durch den Nutzer bestimmt werden)

Oder ich würde ein Array anlegen und das dann mit einem FB-Aufruf ins NOVRAM kopieren.
Dann hätte ich aber als einzigen Unterschied bei den ganzen Var im Programm nur den Index meines Array (z.B. Retain_Elemente[1]).
Vorteil:
- alle Retain werden auf einen Schwung gesichert
Nachteil:
- keiner kennt sich im Programm aus da die Var nicht an der Bezeichnung zu erkennen ist
- werden nachträglich Var im Prog. gelöscht bleiben im Array Lücken die fast nicht mehr zu finden sein dürften
somit wird Speicherplatz verschenkt

Gruß L.T.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo L.T. ,

lege doch deine Variablen an wo du willst. Gib ihnen die Namen die du willst.
Wenn du jetzt diese Variablen direkt mit dem NOVRAM verknüpfst, hast du doch was du willst.

Nur übertreiben solltest du das nicht, weil es Ressourcen frisst. ;)

Wen du viele Variablen hast, die sich aber selten ändern, dann ist das Beispiel mit Variante 2 das richtige.

Gruß
Chräshe
 
FLash

Du kannst deine Daten auf in den Flash schreiben. Da muss man nur bei jedem Flashspeichern den FB aufrufen. Der spiechert dann alle Retain/ Persistent variablen im Flash.
Da bei sehr häufigen peichern der Flash aber kaputt gehen kann würde ich das speichern über eine USV oder wenn möglich als zusätzliche Anforderung bei bestimmten Tasten der HMI senden.

Bei relativ kleinen Programmen kommt man damit recht gut über die runden.
 
Hallo Gerri,

mit Flash meinst du jetzt aber ja jetzt wieder nicht das NOVRAM, oder?
Welche FB´s regeln lesen/Schreiben vom Flash-speicher?

Danke!

Gruß Lars
 
Hallo trinitaucher,

danke für die Links.
Aber das ist ja genau das was ich mit umständlich gemeint habe.
Entweder ich kopiere jede Var Einzeln mit dem verlinkten Baustein ins NOVRAM.
(Dann hab ich aber 150 FB Aufrufe nur für das Speichern von ein paar Retain Daten hätte aber für jede Retain Var ein ordentliche Bezeichnug (z.B. MD_1515_Setpoint_ValueA)
Vorteil:
- Jede Var ist am Namen zu bestimmen
- Gelöschte Var werden beim kompilieren angemeckert und können gelöscht werden
Nachteil:
- Wahnsinns Aufwand
- werden Var gelöscht muss die Lücke händisch im NOVRAM neu belegt werden (Index der Speicherbelegung muss ja durch den Nutzer bestimmt werden)

Oder ich würde ein Array anlegen und das dann mit einem FB-Aufruf ins NOVRAM kopieren.
Dann hätte ich aber als einzigen Unterschied bei den ganzen Var im Programm nur den Index meines Array (z.B. Retain_Elemente[1]).
Vorteil:
- alle Retain werden auf einen Schwung gesichert
Nachteil:
- keiner kennt sich im Programm aus da die Var nicht an der Bezeichnung zu erkennen ist
- werden nachträglich Var im Prog. gelöscht bleiben im Array Lücken die fast nicht mehr zu finden sein dürften
somit wird Speicherplatz verschenkt

Gruß L.T.
Vielleicht Variante 2, aber mit Strukturen? So hab ich's immer gemacht. Aufruf ist dann einfach per MyStruct.VarName möglich.

Es gibt bei den PC-basierten Steuerungen nur diese vier Wege für remanente Daten:
1. Automatisches Speichern der RETAIN oder PERSISTENT Variablen (bei Shutdown des Rechners) => evtl. USV erforderlich (ggf. 1 Sek-USV)
2. Speichern der RETAIN oder PERSISTENT Variablen per FB.
3. NOVRAM mit zyklischem Schreiben => frisst Performance, je nach Zykluszeit.
4. NOVRAM mit Schreiben bei Bedarf => aufwändiger zu programmieren, schont aber Ressourcen

Für Variante 3 könnte man zum Schonen der Ressourcen auch eine langsame Task anlegen und damit das NOVRAM beschreiben.
 
Hallo Trinitaucher,

ich kann das gerade leider nicht testen, aber was passiert wenn ich in MyStruct eine Var lösche?
Kann die Steuerung die restlichen Var beim Einschalten, laden, schreiben noch zuordnen oder geschieht die Zuordnung nicht über Name sondern über ID?
Wenn die Var dann noch gelesen werden könnten wär das wohl meine Wahl.
Dann werden Retain-Var eben nicht in den Globalen Var deklariert sondern im Datentyp. Könnt ich (gut)mit leben....

Gruß L.T.
 
Hallo Cassandra,

vielen Dank für den Vorschlag.
Aber ich hätte sagen sollen, dass die SPS im Augenblick noch sehr virtuell ist (um nicht zu sagen bei Beckhoff lötet da noch jemand dran rum :p)
Oder anders gesagt, ich hab sie noch nicht auf dem Tisch....

Gruß L.T.
 
Aber ich hätte sagen sollen, dass die SPS im Augenblick noch sehr virtuell ist (um nicht zu sagen bei Beckhoff lötet da noch jemand dran rum :p)
Oder anders gesagt, ich hab sie noch nicht auf dem Tisch....

Hallo L.T. ,

das könntest du sehr wohl testen. Internet-Anschluss und einen PC scheinst du ja zu haben.
TwinCAT kannst du hier runter laden.

Die Funktion WritePersistentData funktioniert auf jedem PC, auf dem du TwinCAT installiert bekommst.
Das Beispiel IPC_X86.zip ist bereits eine fertige Vorlage.

Zum testen am lokalen PC oder Notebook einfach im System-Manager eine leere Konfiguration aktivieren. Schon kann das Programm hochgeladen werden.

Ich würde erwarten, dass die Persistenten Daten verloren gehen, wenn man den Datentyp ändert. Für den Fall dass die Entwickler von Beckhoff im Hintergrund mit XML-Dateien arbeiten, könnte das sogar ohne Datenverlust möglich sein.
Viel Erfolg...

Gruß
Chräshe
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

hier ein paar weiterführende Details:
1.Was sind die Unterschiede zwischen persistenten und retain Variablen?
1.1 Retain:
- Retain Variablen werden durch das Schlüsselwort RETAIN gekennzeichnet.
- Retain Variablen liegen in einem speziellen Speichersegment
- Beim Shutdown von TwinCAT wird der Inhalt des Speichersegments binäre 1:1 auf die
Festplatte geschrieben (TwinCAT\Boot\TCPLC_R_x.wbp, x=1..4 Nummer LZS)
Vorteil
- Laden und Speichern geht sehr schnell.
Nachteile
- Wenn Bootprojekt und Retain-Datei nicht 100% zusammenpassen, dann kann das
TwinCAT System nicht starten!
Hinweis:
!! Wegen der Nachteile wird die Verwendung nicht empfohlen!!
1.2 Persistent:
-Persistente Variablen werden durch das Schlüsselwort PERSISTENT gekennzeichnet.
- Persistente Variablen liegen an ganz unterschiedlichen Stellen im Speicher.
- Beim Shutdown von TwinCAT werden die markierten Variablen gesammelt und in eine
strukturierte binäre Datei geschrieben (TwinCAT\Boot\TCPLC_T_x.wbp, x=1..4). Name
und Pfad, Größe und Wert der Variablen werden gespeichert .
Vorteil
- Beim Aufstarten werden alle Variablen geprüft. Wenn die Variablen entsprechende
Pendants im Projekt haben werden die Werte geladen. Wenn nicht, dann nicht.
Nachteile
- Laden und Speichern dauert etwas länger.
- Die persistent Variablendatei ist etwas größer.
Hinweis:
-Soll eine Variable einer Instanz eines FB oder einer Struktur gespeichert werden,
so wird die gesamte Struktur gespeichert.
- Bei XP/Win7 embedded : Der Ordner für die remanenten Daten darf nicht
von einem EWF oder FBWF geschützt sein!

2. Persistente Variablen können aus der Applikation geschrieben werden.
- Baustein FB_WritePersistentData
Hinweis:
- Es werden nicht automatisch auch Backups der Dateien angelegt!

3. Speicherung der Dateien: TwinCAT\Boot
- Retain: TCPLC_R_n.wbp (Backup mit ~)
- Persistent: TCPLC_T_n.wbp (Backup mit ~)
Aufstart-Sequenz:
- System Service startet PLC Server
- PLC startet mit Initialwerten
- PLC lädt persistente Variablen
- Wenn eine persistente Variable zu einer Variablen des Bootprojektes passt, dann
wird der Wert der Variablen geladen. Initialwert wird überschrieben.
- Wenn eine persistente Variable nicht zu einer Variablen aus dem Bootprojekt passt,
passiert gar nichts.
- Wenn das Laden beendet ist, werden die Daten als Backup kopiert.
Das erfolgreiche Laden der remanten Daten kann aus der Applikation geprüft werden.
Dazu gibt es in der System Info Struktur die Variable bootdata:
Bit Nummer Beschreibung
0 RETAIN variables: LOADED (without error)
1 RETAIN variables: INVALID (the back-up copy was loaded, since no valid
data was present)
2 RETAIN variables: REQUESTED (RETAIN variables should be loaded, a
setting in TwinCAT System Control)
3 reserved
4 PERSISTENT variables: LOADED (without error)
5 PERSISTENT variables: INVALID (the back-up copy was loaded, since
no valid data was present)
6 reserved
7 reserved

Was ist zu tun bzw. Was macht TwinCAT automatisch, wenn die remanenten Variablen
nicht geladen werden können?
- Default-Reaktion: Die Backup-Dateien werden geladen!
- Sollte das nicht die richtige Reaktion für die Applikation sein, dann kann in der Registry
umgestellt werden:
[HKEY_LOCAL_MACHINE\SOFTWARE\Beckhoff\TwinCAT\Plc]
"ClearInvalidRetainData"=dword:00000000
"ClearInvalidPersistentData"=dword:00000000
Hinweis:
- Der Wert von "ClearInvalidRetainData" oder von "ClearInvalidPersistentData" muss
dann auf 1 gesetzt werden. Die Standardeinstellung ist 0 für XP und 1 für CE.
- Sollte die Einstellung bei einem CE System im System Manager oder in der
Registry geändert werden ? Shutdown notwendig (ansonsten werden die Daten
nicht gespeichert)

4. NOVRAM
Variablen können auch im sogenannten non-volatile-RAM (Novram) gespeichert werden
Novram ist verfügbar auf verschiedenen CPUs:
- Standard PC: mit optionalem Novram auf einer Feldbuskarte (z.B. FC31xx), oder
einer optionalen Mini-PCI-Karte mit Novram
- CX10xx: 8kB
- CX90xx: 128kB
- EL6080: 128kB
Novram als Standard-I/O:
- Bedeutet: in jedem Zyklus werden die verknüpften Variablen in das Novram kopiert
- Hinweis: Beim Stopp der Task (BP oder Stop der SPS) werden die Variablen auf
Null gesetzt!
- Flag „Auto Init linked PLC Variables“ sollte im System Manager gesetzt werden.
- Novram direkt aus der Applikation genutzt:
- FB_NovRamReadWriteEx aus der TcIoFunctions.lib zum Lesen und Schreiben von
Variablen ins Novram
Hinweis:
- Beim Spannungsausfall während des Kopiervorgangs muss der Speicher in
Bereiche geteilt werden und auf Konsistenz geprüft werden.

5. Was passiert beim Spannungsausfall?
5.1 Ohne USV
- Kein TwinCAT Shutdown.
- Bedeutet: Kein Speichern von Retain und/oder Persistent Daten.
- Nach Neustart werden die Variablen entweder initialisiert oder das letzte Backup
wird geladen. Das Verhalten ist einstellbar!
5.2 Mit Standard-USV
- Im Falle einer Spannungsunterbrechung wird von der USV wird ein Signal an den
TwinCAT System Service gesendet.
- Der TwinCAT System Service leitet den Shutdown von TwinCAT ein (Stoppen aller
Tasks usw.) und speichert die remanenten Variablen..
- Wenn alle Daten geschrieben sind, leitet der TwinCAT System Service den
Betriebssystem Shutdown ein.

6. Unterschied zwischen einer Standard-USV und einer 1-s-USV?
6.1 Standard UPS
- Erstens: TwinCAT Shutdown mit Speichern der remanenten Variablen
- Zweitens: Betriebssystem Shutdown
- Konfiguration über das Betriebssystem Power Management im Control Panel
6.2 CX1190-USV (CX1100-0900..-0930)
- Erstens: TwinCAT Shutdown mit Speichern der remanenten Variablen
- Zweitens: Betriebssystem Shutdown
- Konfiguration via System Manager, aus der Applikation via FB_CxSimpleUPS
6.3 1-s-UPS CX80x0 und CX50x0
- Erstens: FB_S_UPS / FB_S_UPS_EX (BIOS-API) schreiben die persistenten
variablen (kein TwinCAT Shutdown, keine Retain Daten)
- Zweitens: FB_S_UPS / FB_S_UPS_EX leitet einen Stopp des IPC ein
- Keine Konfiguration nötig, S-UPS muss allerdings im BIOS aktiv sein

Grüße
Thomas
 
Hallo Thomas,

super! Vielen Dank für die genau Auflistung!
Kannst du mir noch was zu "Retain Persistent" bzw. "Persistent Retain" sagen?
Werden diese Var "atuomatisch" wie Persistent Variablen behandelt was die Speichermethode betrifft oder macht das bei Beckhoff keinen Unterschied?

Bei Wago, ELAU.... ist das ja nochmal ein unterschied im Lade-/Initialisierung-/Löschverhalten.

Gruß L.T.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo L.T.,

der Compiler lässt es zu beides - Retain und Persistent - in einer Zeile zu nutzen, dies macht jedoch keinen Sinn. Es werden beide Files angelegt, TCPLC_R_n.wbp und TCPLC_T_n.wbp. Vorrang hat jedoch immer Persistent, jedenfalls bei Beckhoff. Also, die Retaindaten werden von den Persistdaten überschrieben. Retain ist aufgrund der Nachteile (keine Prüfung ob die Daten zum Bootprojekt passen, da die Variablenbezeichnung fehlt) ein Auslaufmodell und sollte nicht mehr genutzt werden. Wenn eine 1-sek USV genutzt wird, werden hier nur persistente Daten genutzt, Retain funktioniert nicht. Also klare Empfehlung: kein Retaindaten nutzen!

Gruß
Thomas
 
Habe mir gerade mal den Beitrag durchgelesen.
Ich arbeite auf einem CX8031 und rufe die Funktion FB_S_UPS im Hauptprogramm auf.
Außerdem habe ich 2 Integervariablen als Persistent deklariert.
Leider werden die Daten bei einem Powerfehler aber nicht gespeichert.
Was mache ich hier noch falsch.
Aufgefallen ist mir das der Ausgang bPowerFailDetect der Funktion FB_S_UPS nicht gesetzt wird, wenn die Spannung weg ist.
Kann es damit Zusammenhängen was Thomas geschrieben hat:
Keine Konfiguration nötig, S-UPS muss allerdings im BIOS aktiv sein

Hoffe ihr könnt mir weiterhelfen.

Gruß snej
 
Hallo snej,

mit der FB_S_UPS geht das nicht. Du benötigst den Baustein FB_S_UPS_CX80xx aus der System-Lib des CX8000 - TcSystemCX80xx.lib. Dieses ist in der Doku enthalten. Da der CX noch den Vorserienstatus inne hat, ist diese noch nicht frei verfügbar, daher die Lib als Anhang.

Gruß
Thomas
 

Anhänge

  • TcSystemCX80xx.zip
    7,4 KB · Aufrufe: 27
Zurück
Oben