Persistent Variablen - Systemverhalten und Implementierung

[klaus313]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

folgendes Problem (TC2):
Habe alle PERSISTENT Variablen in einem Array. Dieses speichere ich bei Änderung eines Wertes (memcmp) über den Baustein FB_WritePersistentData gezielt ab.
Über die Bootflags aus TypeSysteminfotype (bit4) sehe ich das die PERSISTENT Variablen nach RESET korrekt geladen wurden. Soweit so gut.

Wie verwende ich nun die Variablen korrekt, so dass sie nach dem Start des Systems wieder zur Verfügung stehen. Leider funktioniert folgender Ansatz nicht korrekt:
Ich ändere zum Beispiel BOOL Variablen über einen Taster. Hierzu habe ich einen FB "Toggel" implementiert. Dieser soll im ersten Zyklus den Wert der Persisten Variable (pre_load) auf sich selbst schreiben.
Nachfolgend soll bei Tastendruck dann der Wert toggel

IF NOT init THEN
init := TRUE:
out := pre_load;
ELSE
IF in:= TRUE AND alt_in = FALSE THEN (* Flanke *)
out:= NOT out;
END_IF
alt_in := in;
END_IF

Diesen verwende ich wie folgt:

Was mache ich falsch, bzw. wie machts man richtig ? ;-)

Danke
Klaus

 

[Mavorkit]

Hi,

Wäre es nicht einfacher die entsprechenden Variablen einfach als persistent zu deklarieren?

Gruß

Mavorkit

Gesendet von meinem SM-G389F mit Tapatalk

 

[Passion4Automation]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sehe ich auch so, ich deklariere diese variablen auch und fertig.
Steckt da ein tieferer Sinn dahinter?

 

[Guga]

Prinzipiell werden beim herunterfahren des TwinCAT Systems die als persistent deklarierten Daten automatisch gesichert (und beim hochfahren ebenso automatisch wieder in die Variablenwerte geschrieben). Das Speichern ist de-facto eine Dateioperation.
Da es aber auch Systeme gibt ohne USV o.ä. und arbeiten und es somit einfach vorkommt das keine Zeit (Energie) mehr vorhanden ist die Dateioperation auszuführen gibt es diesen Baustein.
Zum Ausführungszeitpunkt schreibt er die Datei. Wird häufig benutzt im Zusammenhang mit der TargetVisu wenn z.B. eine Rezeptur manuell geändert wurde...
Die Datei ist also dann schon geschrieben...
Es ist wenn du es so willst ein Hosenträgerprinzip basierend auf dem Wissen das bei deiner HW der Gürtel nicht ausreicht...

Guga

P.S. Man sollte im SystemManager (TC2) bzw. equivalent in TC3 aber noch definieren das falls die letzte Backup korrupt ist er auf die n-1- Datei zurückgreifen soll.

Guga

 

[Mavorkit]

Hi Guga,

Das heißt es gibt bei Beckhoff Systeme ohne internen Power Cap? Ich kommev aus der Wago Welt und dort hat selbst der kleinste Controller einen Kondensator der bei Spannungsausfall ausreicht um die Variablen in eine Art EEPROM geschrieben. Der Speicher ist hier logischerweise je nach Controller beschränkt.
Mit einer richtigen USV hat das eigentlich nichts zu tun, das Puffert nur kurz, genügt jedoch zum Variablen sichern.

Gruß

Mavorkit

Gesendet von meinem SM-G389F mit Tapatalk

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das heißt es gibt bei Beckhoff Systeme ohne internen Power Cap?

Leider ja! Das war bisher auch immer mein Haupt-Kritikpunkt bei Beckhoff. Man kann damit umgehen, aber für Umsteiger von anderen Steuerungen, ist das eine üble Stolperfalle.
Daher wenn möglich, immer eine CPU mit 1-Sekunden-USV.

Schau mal hier:
FAQ: alles rund um TwinCAT 2

 

[Guga]

ja. das hängt einfach vom Spektrum der Controller ab.
Oder kannst du dir einen i7 Rechner mit einem bezahlbaren PowerCap vorstellen?
Also wie so oft: 3 Personen 5 Meinungen -- (aber billig muss es sein).
Es gibt genügend Anlagen ohne ohne Persisten Daten. Genauso gibt es Anlagen wo eine USV in der Maschine ist um die Achsen noch definiert in eine position zu steuern. Der Verbrauch des Controllers ist da unerheblich - er wird einfach an die AnlagenUSV mit aufgeschaltet..

Guga

 

[Mavorkit]

Oh okay, das bedeutet es muss zyklisch geschrieben werden oder eine Lösung, die bei Wertänderung das Schreiben anstößt.
Betrifft dann aber hauptsächlich die IPC Lösungen.

Gesendet von meinem SM-G389F mit Tapatalk