TIA Strategie um Datenstände vor Verlust (reinit) zu schützen (z.B.Betriebsstundenzähler)

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Rein Interessehalber. Ich kann unmöglich der Einzige sein, der immernoch mit dem Reinitwahn von TIA anneinandergerät.

Als Beispiel. Ich habe eine etwas betagtere Beleuchtunganlage im Ausland (V13) in der ist 1kb Energiedaten vorhanden und diverse Betriebsstundenzähler.
Betriebsstundenzähler hab ich mir mal n Baustein geschrieben.

FUNCTION_BLOCK "Betriebsstunden"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT 
      Betrieb : Bool;
   END_VAR


   VAR_IN_OUT 
      Betriebsstunden : Int;
      Betriebssekunden : DInt;
      saveBetriebssekunden : DInt;
   END_VAR


   VAR 
      Takt {InstructionName := 'R_TRIG'; LibVersion := '1.0'} : R_TRIG;
   END_VAR




BEGIN
	#Takt(CLK := "Taktgeber_dyn"(1.0));
	
	IF #Betriebsstunden >= 0 THEN
	    #saveBetriebssekunden := #Betriebssekunden;
	ELSIF #Betriebsstunden = -1 THEN
	    #Betriebssekunden := #saveBetriebssekunden;
	END_IF;
	    
	IF #Betrieb AND #Takt.Q THEN
	    #Betriebssekunden += 1;
	END_IF;
	
	#Betriebsstunden := DINT_TO_INT(#Betriebssekunden / 3600);
	    
END_FUNCTION_BLOCK

hiermit sichere ich die Betriebsstunden zustätzlich in einem Merkerdoppelwort (an save Betriebssekunden). Das funktioniert recht gut. Wenn sich am DB der an der Schnittstelle angeschlossen ist, was ändert, dann wird reinitialisiert es steht -1 drin, darum wird der Wert aus dem Merkerwort wiederhergestellt. Alles tiptop. Aber man muss sich um Merkerrerservationen kümmern etc.

Bei einem Grösseren DB in dem ich z.B. energiedaten über Jahre sichere. habe ich ein Programm geschrieben, der diesen DB auf einen Programmgenerierten DB im Ladespeicher sichert (z.B. einmal Täglich) und rücksichert wenn eine Initialisation des DBs stattfindet.
Schon etwas anspruchsvoller, aber für den Benutzer einfach und zuverlässig.
Hat einen gewaltigen Nachteil. Wenn man mit einem neuen Softwarepaket kommt (von V13 auf V15) dann macht Tia einen reinit inklusive Delete sämtlicher zur laufzeit erstellen Daten im Ladespeicher. Zu diesem Zeitpunkt ist es auch nicht möglich aus einer V13 CPU die Aktualdaten in das aktuelle V15 Projekt zu ziehen.
Ein weiterer Nachteil ist, dass der DB der gesichert werden soll, fürs umkopieren als nicht optimiert vorhanden sein muss.

Nun interessiert mich mal eure Stategien die ihr so fahrt? Dass man Parametersicherungen z.B. über ein übergeorndetes SCADA machen könnte, lassen wir mal aussen vor.

 

[ducati]

Es gibt eigentlich 3 Problemsituationen im Zusammenhang mit der Reinitialisierung:

1: Verlust von Zählwerten, wie bei Dir
2: Verlust von Einstellparametern, z.B. Grenzwerte für irgendwas
3: Verlust irgendwelcher Variablenwerte bei Änderung im laufenden Betrieb von Anlagen. Hier darf ich kein Setze/Rücksetzebit verlieren, keinen Flankenmerker, keine Zeitverschiebung bei Timern usw...

je nachdem, was jetzt für jemanden relevant ist, muss man sich halt den passenden Rettungsmechanismus dafür ausdenken... Der sieht nicht immer gleich aus. Ist aufwändig. Und von jemand fremden schlecht zu durchschauen...

Also alles großer Mist, und keine Besserung in Sicht.

Wie machen wir das:

Wir haben alles in Global-DBs, welche sich nicht ändern, weil sie eine feste Struktur haben. Die Variablen darin sind durchnummeriert und es gibt ne Liste, wo drin steht, was die Numemrn bedeuten. Alternativ kannst auch in den Kommentar was reinschreiben, dadurch wird nicht reinitialisiert...
Für Timer nehmen wir die S5-Timer.
Sonst haben wir noch einen Instanz-DB, wo die Variablennamen im Klartext stehn, bzw. der auch mal verlängert wird. Für diesen DB gibts einen identischen Rettungs-DB, welcher am Ende vom OB1 gesichert wird und am Anfang vom OB1 wieder rückgesichert wird...

Gruß.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt eigentlich 3 Problemsituationen im Zusammenhang mit der Reinitialisierung:

1: Verlust von Zählwerten, wie bei Dir
2: Verlust von Einstellparametern, z.B. Grenzwerte für irgendwas
3: Verlust sämtlicher Variablenwerte bei Änderung im laufenden Betrieb von Anlagen. Hier darf ich kein Setze/Rücksetzebit verlieren, keinen Flankenmerker, keine Zeitverschiebung bei Timern usw...

zu 2 finde ich gut, dass sie Parameterwerte jetzt getrennt behandeln. Man also Einstellparameter getrennt als Startwerte sichern kann. Muss man aber natürlich auch tun, bevor man die TIA Version wechselt oder irgendwelche änderungen am DB durchführt. Sobald ein Unterschied in der Struktur ist, wird ein Parameterabzu verunmöglicht. Was ich wiederum nicht verstehe, denn wenn z.B. die Symbole gleich bleiben, ist ja eine Zuordnungsmöglichkeit da. Es wäre verständlich wenn man nur die Parameter nicht sichern kann wo auf einmal kein zugehöriges Symbol mehr auffindbar ist.

3 zu schützen dürfte recht anspruchsvoll sein. in IDbs landen ja oft auch recht komplexe typen z.B. von Kommunikationsbausteinen oder Reglern. Oder gar Achspositionierern. Da darf dann so richtig nix schiefgehen. Aber toll wärs schon.

Also alles großer Mist, und keine Besserung in Sicht.

Ich kanns ehrlichgesagt nicht ganz nachvollziehen. Gerade bei der erzwungenen Symbolischen Adressierung müsste es doch auch bei Unterschieden möglich sein, den neuen DB runterzuladen. die Werte wo Namensgleichheit besteht in den geladenen DB zu schreiben und den neuen DB dann zu aktivieren.
Dass das nicht weiterverfolgt wird, deutet für mich darauf hin, dass kein allzugrosses Interesse seitens Kundschaft besteht.

Sonst haben wir noch einen Instanz-DB, wo diw Variablennamen im Klartest stehn, bzw. der auch mal verlängert wird. Für diesen DB gibts einen identischen Rettungs-DB, welcher am Ende vom OB1 gesichert wird und am Anfang vom OB1 wieder rückgesichert wird...

Kannst du das Verfahren und den Sinn dahinter etwas näher erläutern?

 

[ducati]

zu 2 finde ich gut, dass sie Parameterwerte jetzt getrennt behandeln. Man also Einstellparameter getrennt als Startwerte sichern kann. Muss man aber natürlich auch tun, bevor man die TIA Version wechselt oder irgendwelche änderungen am DB durchführt. Sobald ein Unterschied in der Struktur ist, wird ein Parameterabzu verunmöglicht.

Ja, man kann/muss rücklesen, bevor man was an der Software ändert... dann darf aber in der Zwischenzeit niemand an der Anlage Parameter ändern...

3 zu schützen dürfte recht anspruchsvoll sein. in IDbs landen ja oft auch recht komplexe typen z.B. von Kommunikationsbausteinen oder Reglern. Oder gar Achspositionierern. Da darf dann so richtig nix schiefgehen. Aber toll wärs schon.

Wir verwenden keine MultiinstanzDBs, von daher werden IDBs von Standard-FBs ja in der Regel nicht verändert und nicht reinitialisiert... Wenn man komplexe Strukturen oder UDTs benutzt, sollte man sich schon sicher sein, dass die dann mal so gut sind und sich nicht 100 mal ändern. Einmal erstellen, testen, für gut befinden, ENDE.

Kannst du das Verfahren und den Sinn dahinter etwas näher erläutern?

Für unsere Automatikfunktionen haben wir einen FB, da gibts im IDB pro Netzwerk eine feste Struktur mit Variablen, z.B. 16 Bools Res_01 bis Res_16. Diese Struktur wird nicht verändert, es werden halt nur die Variablen umbenannt, wenn sie benutz werden. Also wenn ich im Netzwerk 16 jetzt nen Flankenmerker brauch, wird in der Struktur für NW16 jetzte aus Res_01 -> FP_Taster_EIN...
Bei zusätzlichen Netzwerken werden zusätzliche Strukturen im IDB hinten angehangen... (das ist dann aber komplizierter, deshalb sind von Beginn an normalerweise schon genug Reserven vorhanden)
Am Ende vom OB 1 sichere ich jetzt immer diesen IDB komplett in einen Global-DB (nicht optimiert mit nem genügend großen Array ob BYTE).
Am Anfang vom OB1 prüfe ich anhand einer Test_Variablen, ob der IDB reinitialisiert wurde, falls ja, kopiere ich vom Global-DB in den IDB...

Hoffe es ist verständlich...

PS: größere Änderungen an der Software mach ich aber mit TIA nicht mehr im laufenden Betrieb, dann fällt Problem 3 schonmal weg. Und TIA Versionen zieh ich an Bestandsanlagen nie hoch, schon garnicht bei laufender Anlage...

 

[ducati]

Dass das nicht weiterverfolgt wird, deutet für mich darauf hin, dass kein allzugrosses Interesse seitens Kundschaft besteht.

Ich denke, das Reinitialisierungsproblem wurde schon vielfach an Siemens herangetragen. Da die aber selber keine Anlagen programmieren (also die TIA-Entwicklungsleute), haben die das Problem nicht verstanden und machen deshalb nix...

Ich beschwer mich da auch nicht mehr, da ich anderes zu tun hab und für mich auch ne Lösung gefunden hab...

Wenn man das Reinitialisierungsproblem aber umgehen will, wirft man eigentlich das ganze symbolische-UDT-Multiinstanzkonzept über den haufen und ist wieder bei absoluten Global-DBs oder Merkern aus S5-Zeiten Also man kann keine Variablen mitten drin in einem DB einfügen, dafür hab ich auch keinen proktikablen Ansatz für einen Rettungsmechanismus...
Es läuft darauf hinaus, an den richtigen Stellen immer genügend Reservevariablen zu haben. Falls man nen rettungsmechanismus hat, kann man die umbenennen, falls nicht, heissen die dann bis zum Weltuntergang Res_01

Gruß.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann doch die Momentanwerte laden, danndiese als neue Startwerte festlegen und den DB aus der Steuerung ins TIA laden.
Nun Änderungen/Erweiterungen vornehmen und beim Reinitialisieren werden die alten Werte" als Startwerte geladen.
Klar, in der Zwischenzeit, wenn man erweitert, darf nichts geändert werden, was bei einer laufendne Anlage auch wieder dumm ist.
Ich hab zum Glück i.d.R. Sondermaschinen, die ich leerfahren kann, dann erweitern und wieder starten. Datenverluste sind da auch eher nicht so schlimm.

PS: Siemens weiß gaz sicher ganz genau, das und was sie da anrichten. Die tun nichts, weil es schon im Ansatz von TIA versaut wurde und wohl mit extremem Aufwand verbunden wäre. Lieber jedes Jahr eine neue Version rausknallen und das Chaos noch vergrößern. Bin mal gespannt, wann genau Siemens dieser ganze Misthaufen so richtig um die Ohren fliegt. Spätestens wenn irgendwo ein AKW hochgeht, weil das Datum nicht paßt etc. etc. ...

 

[ducati]

ja Ralle, das ist mein Fall 2. Den kann man so lösen, vorausgesetzt die Programmänderungen sind nicht so groß, dass da Wochen zwischen Auslesen und Einspielen liegen.
Aber Fall 1 und 3 krigst Du damit garnicht gelöst...

 

[rostiger Nagel]

Könnte man den nicht auch so wichtige Werte als CSV Daten auf die Speicherkarte
auslagern? Diese könnte man doch dann vorher beim CPU Tausch auch noch einmal
sichern.
https://support.industry.siemens.co...it-simatic-s7-1200-und-s7-1500?dti=0&lc=de-DE

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

ja man kann vieles tun...
Hintergrund ist doch folgender:
Du hast nen x-beliebigen FB mit evtl. komplexeren UDTs oder Structs. Da willst Du jetzt mittendrin ne Variable hinzufügen oder nen Tippfehler umbenennen... Dabei wird der komplette IDB reinitialisiert. Klar kannst Du jetzt mit viel Aufwand irggrndwas sichern und retten. Das steht aber in keinem Aufwandsverhältnis zur Arbeitsaufgabe (ne Variable schnell umzubenennen)...
Gruß.

 

[TP-Inc]

Wir haben bei allen Anlagen einen PC mit SQL Datenbank verbunden und speichern bzw. laden alle relevanten Werte dort. Weiß nicht ob das eine Option für dich wäre.

 

[ducati]

naja, für Punkt 2 aber nicht für 1 und 3...
Und wie krigst Dus vom SQL wieder zurück in den DB, wenn die Struktur des DB sich geändert hat?


Das ist das Gleiche wenn ich den DB in einen Rettungs-DB kopiere. Solange sich nur Namen ändern geht das. Aber wenn eine Variable mittendrin hinzukommt oder nen UDT sich ändert, wirds aufwändig...

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schon irgendwie schräg. Ich meine, früher musste man sich Gedanken machen, Daten bei einer bestimmten Aktion nicht zu verlieren und musste behutsam vorgehen. Jetzt muss man sich auch noch Gedanken machen, wie man sie überhaupt behalten kann.

 

[skorpion37]

Mit Siemens Simotion ganz einfach: Es gibt einen Programmbefehl mit dem man einen kompletten DB symbolisch in eine XML Datei sichern kann. Und das gleiche umgekehrt wenn man feststellt, dass der DB initialisiert wurde. Für alle Werte, die sich symbolisch zuordnen lassen. Warum können sie die Funktion nicht auch einfach in TIA einbauen?

 

[TP-Inc]

naja, für Punkt 2 aber nicht für 1 und 3...
Und wie krigst Dus vom SQL wieder zurück in den DB, wenn die Struktur des DB sich geändert hat?


Das ist das Gleiche wenn ich den DB in einen Rettungs-DB kopiere. Solange sich nur Namen ändern geht das. Aber wenn eine Variable mittendrin hinzukommt oder nen UDT sich ändert, wirds aufwändig...

Auf dem PC läuft eine Software in der man den UDT importieren kann. Die stellt dann den Zusammenhang zwischen der SQL Variable und der Variable in der SPS her. Wie genau das läuft kann ich leider nicht sagen. Wir haben eigene Leute für die ganzen PC/Datenbank Geschichten.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben das in unserer eigenen Visu so gelöst, das die Werte immer in einer Archivtabelle gesichert werden. Falls der Wert kleiner ist als der letzte den die Visu kannte wird ein neuer Datensatz angelegt, ansonsten geupdatet. So können wir über eine Summe über alle Werte den wirklichen Wert rausfinden.