# Beckhoff Retain wirklich so umständlich?



## L.T. (3 Juni 2012)

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.


----------



## Chräshe (3 Juni 2012)

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


----------



## L.T. (4 Juni 2012)

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.


----------



## trinitaucher (4 Juni 2012)

Wenn ein NOVRAM vorhanden ist, kann man dieses auch mittels FBs beschreiben. Dann entfällt das Performance-fressende, zyklische kopieren:

http://infosys.beckhoff.com/index.p...iofunctions_fb_novramreadwriteex.htm&id=12776
Beachte dazu:
http://infosys.beckhoff.com/index.p...lclibiofunctions_fb_getdpraminfo.htm&id=12777


----------



## L.T. (5 Juni 2012)

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.


----------



## Chräshe (5 Juni 2012)

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


----------



## Gerri (5 Juni 2012)

*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.


----------



## L.T. (5 Juni 2012)

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


----------



## Gerri (6 Juni 2012)

nein, das ist wirklich das Hard Disk laufewerk. unter TwinCAT/Boot siehst du das


----------



## trinitaucher (6 Juni 2012)

L.T. schrieb:


> Hallo trinitaucher,
> 
> danke für die Links.
> Aber das ist ja genau das was ich mit umständlich gemeint habe.
> ...


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.


----------



## L.T. (6 Juni 2012)

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.


----------



## Cassandra (6 Juni 2012)

L.T. schrieb:


> ich kann das gerade leider nicht testen, aber was passiert wenn ich in MyStruct eine Var lösche?



Hallo LT,

probiere das doch einfach aus – im schlimmsten Fall lernst du was... 

LG Cassandra


----------



## L.T. (6 Juni 2012)

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 )
Oder anders gesagt, ich hab sie noch nicht auf dem Tisch....

Gruß L.T.


----------



## Chräshe (7 Juni 2012)

L.T. schrieb:


> 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 )
> 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


----------



## Thomas64 (7 Juni 2012)

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


----------



## L.T. (8 Juni 2012)

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.


----------



## IBFS (8 Juni 2012)

Thomas64 schrieb:


> .....
> hier ein paar weiterführende Details:
> .....



Das war ja mal ein richtig guter Einstandsbeitrag

Gruß

Frank


----------



## Thomas64 (8 Juni 2012)

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


----------



## snej (3 September 2012)

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


----------



## Thomas64 (4 September 2012)

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


----------



## DADBösen (18 September 2012)

Hallo Leute,
bin ein S7 Programmierer der sich nun auch für Beckhoff interessiert.
Wenn ich aber die vorherigen Beiträge lese glaube ich aber dass bei Beckhoff einiges schief läuft. 
Es kann doch nicht sein dass es so umstämdlich ist remanete SPS Daten zu bekommen. ( Früher brauchte mann bei S5 eine Batterie, heute gehts sogar ohne Batterie.
Gebt mir bitte Bescheid ob es wirklich so umständlich ist, bleibe sonst lieber bei meiner S7-300.


----------



## Thomas64 (18 September 2012)

Hallo DADBösen,

wenn du eine Lösung mit integrierter 1sek USV, wie im CX80xx oder CX50xx, oder mit den USV-Modulen für CX10xx oder CX20xx realisierst, ziehen die Retaindaten mit dem Flash von CPU zu CPU mit um. Wenn ich mich recht erinnere (war selbst mal S7 Kunde in den 90er) kann das eine S7 nicht. Du kannst die Retaindaten-Datei auch über den Dateiexplorer kopieren, sichern etc.. Ich denke das ist deutlich komfortabler und eine deutlich bessere Lösung als bei einer S7.


----------



## IBFS (18 September 2012)

Thomas64 schrieb:


> . Ich denke das ist deutlich komfortabler und eine deutlich bessere Lösung als bei einer S7.



Komfortabel ist aber oft nicht robust genug. Daher ist das "besser" relativ zu betrachten.

Grüße

Frank


----------



## Cassandra (19 September 2012)

IBFS schrieb:


> Komfortabel ist aber oft nicht robust genug. Daher ist das "besser" relativ zu betrachten.



Hallo Frank,

 Denkst du an so was robustes wie das oder das?
 Kritisch ist es, wenn es weder komfortabel noch robust ist...   

 LG Cassandra


----------



## Majestic_1987 (21 September 2012)

Immer diese Abwerhhaltung der S7-Programmierer gegen moderne Systeme...schrecklich (und ich komme aus der S7-Welt). Du kannst auch ein Array aus Relais auf ne Platine löten und deine remanenten Daten in Hardware sichern. Das ist mit ner USV sogar extrem robust....


----------



## IBFS (21 September 2012)

Cassandra schrieb:


> Denkst du an so was robustes wie das oder das?



Eine S7-1200 ist Spielzeug, darüber müssen wir hier nicht reden.




Majestic_1987 schrieb:


> Immer diese Abwerhhaltung der S7-Programmierer gegen moderne Systeme...schrecklich
> (und ich komme aus der S7-Welt). Du kannst auch ein Array aus Relais auf ne Platine löten und deine remanenten
> Daten in Hardware sichern. Das ist mit ner USV sogar extrem robust....



Modern ist auch relativ, modern ist oft Dot.Net-Überfrachtet und daher unnötisch langsam.
Daher ist mir ein STEP7 Classic oder ein gutes Codesys-Target V2.3 (aber bitte WAGO oder BOSCH-Rexroth) lieber als
unfertige Softwarkonstrukte, wo du als Programmierer dann zwar für diverse Fehlfunktionen nichts kannst (Datenverlust)
aber dennoch in die Pfanne gehauen wirst.


*DER QUALITÄTSANSPRUCH an das Softwareprogramm von Maschinen ist in letzter Zeit leider umgekehr proportional zur Qualität verwendeten Programmiersoftware und deren Hardware.

Man soll in kürzerer Zeit ausgereifte absolut fehlertolerante Maschinen programmieren, aber hat dazu halbfertige V0.3-Software. 

DAHER bin ich, speziell was SPS-Software angeht lieber unmodern als dass ich Tage und Wochen mit toller Programmiersoftware auf der Baustelle herlungere. So sieht das aus!*

Frank


----------



## Chräshe (22 September 2012)

Hallo Frank,

 bist du mal mit Beckhoff besonders auf die Nase gefallen, dass deine Schrift hier blau und Fett wird? Auch wen nicht alles perfekt ist, setze ich die Beckhoff- Produkte inzwischen am liebsten ein.

 Ich bin auch enttäuscht wie unausgereift viele Neuerungen auf den Markt geschmissen werden. Wenn etwas als ganz neu beworben wird, mache ich einen Bogen darum, sofern es machbar ist.

 Wenn ich bedenke, was von Sondermaschinen an Aufwand in der Software gefordert wird und bei Software von der Stange die zig-tausendfach angewandt wird, noch alles fehlerhaft ist, dann stimme ich dir voll zu – mit fehlerhaftem Werkzeug kann man keine 100% abliefern.  
 Das ist aber keine Rechtfertigung für die SPS- Hersteller um über 10 Jahre auf der Stelle zu treten und langsame Steuerungen mit wenigen kb Arbeitsspeicher für viel Geld zu verkaufen. Nur müssen die Neuerungen ein Minimum an Zuverlässigkeit erreicht haben, ehe sie auf den Markt geschmissen werden.
 Da ist bei den meisten Hersteller noch ein gewisses Potential zur Qualitäts-Steigerung vorhanden... 

 Gruß
Chräshe


----------



## L.T. (23 September 2012)

Äh ich störe nur ungern eure Unterhaltung über die Vor- & Nachteile der verschiedenen Hersteller, aber ich hab da noch eine Frage zum Thema ;-)

Ich hab jetzt mal das genannte Beispiel IPC_X86 getestet und find´s soweit auch gut.
Allerdings wäre es mir lieber wenn ich die Persistent Variablen einzeln definieren könnte und nicht in einer Struktur.
Im Beispiel ist das ja denke ich gemacht worden um eine Veränderung erkennen zu können und dann einen Speichervorgang auszulösen (Alte Daten ungleich aktuelle Daten löst Speichervorgang mit FB_WritePersistentData aus.)
Wenn ich nun einzelne Persistent Var deklariere müsste ich für jede Var auch eine lok. Hilfsvar. deklarieren um eine Veränderung erkennen zu können.

Und jetzt meine Frage:
Gibt´s eine Möglichkeit z.b. eine Art Prüfsumme der abgelegten und der aktuellen Persistentdaten zu erzeugen um mit dieser dann die Speicherung zu triggern?

Danke für die Antworten!! 

Gruß L.T.


----------



## Chräshe (23 September 2012)

Hallo L.T. ,

hättest du anstatt dem CX90xx ein CX50xx oder sonst eine Steuerung mit 1s-USV, dann wäre das auch der Fall:
 Du müsstest nur die Variablen als „PERSISTENT“ deklarieren und im Programm die Funktion FB_S_UPS aufrufen...  (Variante 1)

Jetzt hast du nurnoch die Möglichkeit, wie hier beschrieben zwischen Variante 2 und 3 zu mischen:


Einstellungen,     die selten geändert werden, in die Struktur und mit WritePersistentData bei Änderung sichern (Variante 2).   
- hast du ja schon verwendet -
Variablen     die sich schnell und häufig ändern direkt in das NOVRAM verlinken     (Variante 3).
  Deine Idee mit der Prüfsumme ist prinzipiell möglich, aber nicht praktikabel und viel zu Fehleranfällig.    

 Vermutlich haben andere Anwender noch ein paar andere Lösungen. Das kann aber nicht das Ziel sein, das es 10 oder mehr Lösungsansätze gibt, um auf einer SPS irgendwelche Daten zu speichern. :evil:

 Schade, dass die 1s- USV nicht in jedem Gerät verbaut ist!  

Gruß
Chräshe


----------



## Thomas64 (24 September 2012)

*1sek USV mit CX9000*

Hallo L.T.,

mit dem CX1100-0900 (20As) Modul kannst du auch einen CX9000 mit einer 1sek-USV nachrüsten, hält jedoch ein paar Sekunden länger. Einfach den Power-Fail-Ausgang des Moduls auswerten und Write Persistent auslösen. Mit 235€ Listenpreis für den CX9000 leider etwas teuer. Aber das macht Beckhoff aus, für jeden Zweck kann die Lösung entsprechend skaliert werden. Bei den neuen CX2000 macht es 200€ mehr aus, dafür bekommst hier satte 120As integriert im Netzteilmodul.

Gruß
Thomas


----------



## StructuredTrash (24 September 2012)

Thomas64 schrieb:


> Aber das macht Beckhoff aus, für jeden Zweck kann die Lösung entsprechend skaliert werden.


Wobei der Zweck eines Automationsgerätes ohne vernünftiges RETAIN-Handling im Dunkeln bleibt. Ich bin mit Beckhoff durchaus zufrieden, aber das Thema "remanente Daten" ist nicht gut gelöst. Mir wäre ein ferromagnetischer Speicher von begrenzter Grösse (sagen wir mal 32 kB) irgendwo im Speicheradressraum lieber als eine USV. Aber dafür könnte man wohl nicht noch nachträglich Geld vom Kunden verlangen.


----------



## lux (20 März 2013)

Hallo,
Habe eine Frage zu einem CX5020 von Beckhoff.
Gibt es bei diesem IPC mit 1sec USV so etwas wie einen OB100 von Siemens der nur einmalig beim Systemstart ausgeführt wird?
Kann man so etwas mit Tasks realisieren.
Ich möchte einmalig beim aufstarten des IPC's Werte aus Persistenten Speichern in Positionen für NC-Achsen schreiben.
Vielen Dank für eur Hilfe

MfG Lux


----------



## mkd (20 März 2013)

Bau dir doch ein Bit selber 
Da gibt es viele Möglichkeiten z.B.

- Ein R_TRIG mit nem TRUE am Input
- Ein Bit am Anfang des Main Bausteins setzen. Am Ende rücksetzen
- Das First Cycle Bite aus dem SystemTaskInfoArr ( liegt in den globalen Variablen, siehst du online )


Gruß


----------



## MasterOhh (20 März 2013)

Wenn du die TcSystem.lib eingebunden hast, steht dir das globale Array SystemTaskInfoArr (vom Typ SystemTaskInfoType) zur verfügung.

SystemTaskInfoArr[1].firstCycle ist ein bool der nur im ersten Zyklus nach dem Start auf true steht. (Der Array-index [1-4] ist der jeweilige Task)


```
If SystemTaskInfoArr[1].firstCycle then
  MacheIrgendwasNurImErstenZyklus();
end_if
```


----------



## Majestic_1987 (21 März 2013)

Du kannst - sofern der CX ein NOVRAM hat, wovon ich ausgehe - auch die Daten (als Struktur oder wie auch immer) dort ablegen und die SPS-Variablen aus diesem Speicher beim Start initialisieren lassen. Das spart vor allem Programmcode und funktioniert ziemlich komfortabel.


----------



## StructuredTrash (21 März 2013)

Thomas64 schrieb:


> 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
> ...


Zyklisches Schreiben in den NOVRAM schön und gut, aber die Variablen werden beim Stop der Task nicht nur auf 0 gesetzt, sondern manchmal werden die Nullen auch noch in den NOVRAM geschrieben. Eine Ausnahme macht die EL6080, die ich mittlerweile nur noch als NOVRAM einsetze. Dort muss das zyklische Schreiben im SPS-Programm durch Control-/Statusword getriggert werden. Beim Stop der Task passiert deshalb nichts mehr.
Dass man auf diese Weise die Daten im günstigsten Fall nur in jedem 2. Zyklus schreiben kann, nehme ich dabei in Kauf.


----------



## onikos (1 November 2013)

lux schrieb:


> ... so etwas wie ein OB100 von Siemens der nur einmalig beim Systemstart ausgeführt wird...


Das Frage ich mich gerade auch. Gibt es so etwas auch bei Beckhoff?Wenn ich die PLC neustarte sind dann alle Variablen auf FALSE die vorher auf 1 waren (sofern sie nicht ursprünglich gesetzt wurden)?Vielen Dank,Niko


----------



## Ghosty (1 November 2013)

Die Frage wurde doch von MasterOhh schon beantwortet. Es gibt die System Task Info.Dort gibt es die Variable firstCycle. Die ist im ersten Zyklus True.
Hier kannst du das selbst nochmals nachlesen. http://infosys.beckhoff.com/english...m/html/tcplclibsys_systemtaskinfotype.htm&id=


----------

