TIA Grossen DB vor Verlusten schützen

vollmi

Level-3
Beiträge
5.423
Reaktionspunkte
1.403
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

Ich habe hier eine Anlage mit einer 1512SP plus ein TP1900 Comfort Panel. Darin habe ich einen recht grossen strukturierten DB (viele Arrays). Ich sammle in diesem die Energiedaten über ein Jahr.

Im Panel wähl ich dann entsprechend Monat und die CPU spuckt mir dazu die Wirkenergie des Entsprechenden Monats aus.
Das panel greift also mehr oder weniger nur auf die Resultate der Berechnung zu ich kommuniziere nicht den gesamten Baustein.

Jetzt besteht aber natürlich das übliche Problem. Man will Updates der Software machen. Ggf wird auf V14 noch ein Update folgen etc. Und immerwieder steht man vor dem Problem das TIA möglicherweise den DB initialisieren möchte.

Jetzt überlege ich mir verschiedene Möglichkeiten den DB regelmässig wegzusichern.

Eine Möglichkeit könnte ja sein den DB regelmässig mit READ_DBL WRITE_DBL in den Ladespeicher zu sichern (das dürfte aber die Karte recht belasten) und bei notwendigkeit zurückzulesen.

Die andere Möglichkeit wäre wirklich das Konzept der 1500er zu nutzen, da gibts Logging funktionen mit denen ich mich noch nicht beschäftigt habe (interesse wäre da aber Zeit ist grad noch etwas knapp)
Aber vielleicht hat sich dem schon jemand angenommen? Funktioniert das gut auf die Karte CSV? Ist das nicht auch sehr zerstörerisch wenn da sekündlich Daten auf die Karte gesichert werden?

Rein von dem was ich in der Hilfe gelesen habe. Wären diese Datenlogs eigentlich ein wirklich edler Weg langzeitaufzeichnungen zu machen.

Habt ihr sonst noch Ideen? Eingebungen?

Hier habe ich mal das Beispiel der Energie und Energieersparnisberechnung abgelegt. Quellen kann man irgendwie nicht im Forum hochladen darum Dropboxlink.
https://www.dropbox.com/sh/adbr5fjqwjq4b46/AACs2mIGX0tOgDme6WTz97n4a?dl=0

mfG René
 
Schau mal auf Seite 21 in dem PDF. Dort wird beschrieben, wie man DB´s als CSV speichert und auch wieder von CSV in den DB importiert.
Es sollte eigentlich gehen.

Mit Grüßen
 
Schau mal auf Seite 21 in dem PDF. Dort wird beschrieben, wie man DB´s als CSV speichert und auch wieder von CSV in den DB importiert.
Es sollte eigentlich gehen.

Du meinst statt Logs das ganze als Rezepturen behandeln? Das wäre auch ne möglichkeit. Leider erspart mir das aber dann keinen Arbeitsspeicher nur etwas Remanenz. Da ich den DB wieder abfüllen könnte wenn er gelöscht wird.

Derzeit bin ich mit Remanenzspeicher am ende. Trotzdem wäre es schön ich könnte das ganze Täglich auf die Karte sichern und dann nur z.B. den Monat wieder zurückladen den ich brauche.

Müsste ich die Rezepturen in Monate und Anlagen aufteilen, nicht nur in Anlagen. Wäre ein Ansatz.

mfG René

mfG rené
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin auch deiner Meinung, dass eine tägliche Sicherung sinnvoll ist. Ich habe es selber noch nicht umgesetzt, werde es allerdings
demnächst benötigen ( Langzeitaufzeichnung an einer Biogasanlage ). Wenn du es umgesetzt hast, könntest du ja einmal kurz
deine Erkenntnisse schicken.

Das wäre nett

Mit Grüßen und viel Erfolg
 
Ich bin auch deiner Meinung, dass eine tägliche Sicherung sinnvoll ist.
Auf der 300 haben wir das eigentlich schon immer mit WRIT_DBL gemacht. So alle 2-Tage automatisch bei Anlagenstillstand.
Einfach einen ganzen DB-Nummernbereich, z.B. 1-x von der CPU in 1-x auf der MMC.
Schon alleine aus dem Grund dass ja bei CPU-Tausch, z.B. durch defekt, die Daten sonst weg bzw. auf dem Stand der MMC sind.

Auf der 300 war das einfach, auf der 1500 mit optimierten Datenbausteinen geht das aber nicht mehr wirklich.
  • Speichert WRIT_DBL auf DBs die schon auf der MMC existieren (mit TIA geladen wurden), dann werden die Zeitstempel verändert.
  • Man kann dem WRIT_DBL optimiert nicht den ganzen Datenbaustein, sondern nur einzelne Variablen/Strukuten etc. übergeben.

Bin auch auf der Suche nach was neuem...
 
Argl. Da gibts dann das Problem Offenbar kann man aus dem SPS Programm nur in Logs schreiben, nicht wieder drauf zugreifen oder gar darin suchen.

mfG René

Musst Du wirklich auf alle im Log abgespeicherten Daten wieder zugreifen? Das ist für Logs eher ungewöhnlich. Wenn nicht, könntest Du alle Daten im Log speichern und lediglich diejenigen im Speicher behalten, die Du wieder brauchst.

Sekündliches Logging ist übrigens nicht unbedingt ein Problem. Es kommt auf die Datenmenge an und auf die Größe der Speicherkarte bzw. den freien Speicher für die Log-Dateien:
https://support.industry.siemens.com/cs/de/de/view/109482591
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, er möchte auf alle Daten im Falle eines Datenverlustes zugreifen, so dass ein initialisierter DB wieder auf den letzten gesicherten Stand zurückgeschrieben werden kann.

Mit Grüßen
 
Jetzt hier müsste ich nicht auf alle Daten zugreifen. Aber wenn ich im Panel monat Januar anwähle, müsste ich irgendwie an alle Tageswerte des Monats januar kommen (0..31 Array of Struct). Und bei Logs kann ich ja überhaupt nicht mehr auf die Daten zugreifen.

Da wäre Rezeptur ein ansatz, wenn ich die Monatsweise mit Anlagennamen und Monatsbenennung abspeichern könnte (maximal 12 Rezepturen pro Anlage) und dann Monatsweise wieder in eine Monatsstruktur zurückladen könnte.

mfG René
 
Sekündliches Logging ist übrigens nicht unbedingt ein Problem. Es kommt auf die Datenmenge an und auf die Größe der Speicherkarte bzw. den freien Speicher für die Log-Dateien:
https://support.industry.siemens.com/cs/de/de/view/109482591

Das kann man theoretisch noch weiter entschärfen, indem man immer mindestens Daten in Blockgröße der Speicherkarte schreibt, da auch beim Schreiben eines einzelnen Byte immer ein kompletter Block gelöscht und neu geschrieben werden muß.
Im Beispiel von Siemens kommt also eine irre große Zahl bei 160 Byte raus. Ist die physikalische Blockgröße z.B. 512 Byte wird jedes Byte 4 mal geschrieben, bevor der Block voll ist (wearleveling hat also viel zu tun!). Bei der physikalischen Blockgröße eines Flashmediums bin ich mir nicht sicher, daher schreibe ich mindestens 4kB am Stück.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wie währe es den, wenn du den Umweg über das Panel nimmst und mit ein
paar Scripten die Daten auf einen Sicheren Medium speicherst.

Siemens währe mir für deine Anwendung zu kribbelig, da ja mal wieder der
Generationswechsel V13 -> V14 ansteht.
 
wie währe es den, wenn du den Umweg über das Panel nimmst und mit ein
paar Scripten die Daten auf einen Sicheren Medium speicherst.

Das wäre eine Möglichkeit. Ich hab schon an einen Sekundengenauen Trend gedacht den ich dann Stündlich in Energie umrechne und per Skript ablege. Aber das würde dann so richtig aufwändig werden. Das Panel müsste auch immer da sein. Und wenn zwei Panel da sind gibts motze wenn die verschiedene Werte Aufgezeichnet haben. Hatte ich schon mit zwei WinCC OA rechnern die den Report selber gemacht haben. Da hatten die einen Rechner für Wochen nicht am netz und Jahre Später ist ihnen dann aufgefallen das der Energiereport auf beiden Kisten unterschiedliche Daten liefert.

Siemens währe mir für deine Anwendung zu kribbelig, da ja mal wieder der
Generationswechsel V13 -> V14 ansteht.

Darum wäre mir ein CSV das man per Webserver auch wegspeichern könnte recht symphatisch gewesen.
Aber die Logs lassen kein Lesen aus der CPU zu. Und die Rezepturen verlangen noch einiges an Einarbeitung meinerseits. Aber ich denke auf die dürfte es rauslaufen.

Aber z.B. das Zitat aus der Hilfe finde ich schonmal niederschmetternd.
Export schrieb:
Als Dateiname der erstellten CSV-Datei wird der Name des Datenbausteins verwendet. Wenn bereits eine CSV-Datei mit dem gleichen Namen vorhanden ist, wird diese beim Export überschrieben.
Import schrieb:
  • Der Name der CSV-Datei muss mit dem Namen des Datenbausteins am Parameter RECIPE_DB identisch sein

Ich will doch nicht zwingend einen ganzen DB in eine Rezeptur sichern. Und zurücksichern will ich ja nur in einen Teil eines Arrays nicht einen kompletten DB überbügeln.

Aber ich geh mal davon aus, dass die Hilfe noch nicht wirklich fertig ist.

mfG René
 
Auf der 300 war das einfach, auf der 1500 mit optimierten Datenbausteinen geht das aber nicht mehr wirklich.
  • Speichert WRIT_DBL auf DBs die schon auf der MMC existieren (mit TIA geladen wurden), dann werden die Zeitstempel verändert.
  • Man kann dem WRIT_DBL optimiert nicht den ganzen Datenbaustein, sondern nur einzelne Variablen/Strukuten etc. übergeben.

Bin auch auf der Suche nach was neuem...

Das geht bei der 1500er schon auch.
Ich hab das z.B. mal so angedeichselt.
Code:
#dummy := READ_DBL(REQ := NOT "EnergysaveDB".Init, SRCBLK := "EnergysaveDB_save", BUSY => #readBusy, DSTBLK => "EnergysaveDB");


IF NOT #readBusy THEN
    "EnergysaveDB".Init := true;
END_IF;


#dummy := RD_LOC_T(#DatenTime);


IF #DatenTime.DAY <> #Daysave THEN
    #SavetoDB := true;
    #Daysave := #DatenTime.DAY;
END_IF;


#dummy := WRIT_DBL(REQ := #SavetoDB, SRCBLK := "EnergysaveDB", BUSY => #writeBusy, DSTBLK => "EnergysaveDB_save");
IF NOT #writeBusy THEN
    #SavetoDB := false;
END_IF;

Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen. Sobald die CPU aber einmal auf diesen was sichert wird er von TIA als unterschiedlich erkannt und TIA will diesen dann IM LADESPEICHER initialisieren. Das heisst TIA löscht dann den SicherungsDB UND den DB im Arbeitsspeicher.
EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet (was ja noch sinnvoll wäre, dann sind die Bausteine immer gleich)

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie wäre es denn eine "Hybrid" Lösung zu machen. Also die Daten in der CPU Puffern und dann über die HMI per Script in eine .csv exportieren. So wäre auch bei zB einem Reboot der WinCC die Aufzeichnung in Betrieb und keine Daten gingen verloren.
Vielleicht hilft dabei dieser Thread, da hat PN/DP einen Lösungsweg geäußert http://www.sps-forum.de/hmi/47637-p...-speicherkarte-eines-tp277-6-speichern-2.html
 
Das geht bei der 1500er schon auch.
Ich hab das z.B. mal so angedeichselt.

Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen. Sobald die CPU aber einmal auf diesen was sichert wird er von TIA als unterschiedlich erkannt und TIA will diesen dann IM LADESPEICHER initialisieren. Das heisst TIA löscht dann den SicherungsDB UND den DB im Arbeitsspeicher.
EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet (was ja noch sinnvoll wäre, dann sind die Bausteine immer gleich)

mfG René


Den Konflikt mit dem TIA-Portal könntest Du vermeiden, indem Du den DB in der CPU anlegst (mit der Instruktion CREATE_DB). Der DB ist dann allerdings nicht optimiert, d.h. die Daten müsstest Du dann über Serialize/Deserialize übertragen.
 
Das geht bei der 1500er schon auch.

Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen.
EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet
Haha, das ist ja mal wieder spannend, hab grad ein wenig probiert.

  • Nicht optimierter Datenbaustein kann komplett an WRIT_DBK übergeben werden
  • Optimierter Datenbaustein geht nicht
  • Optimierter Datenbaustein aus UDT abgeleitet geht schon
Aus UDT-abgeleitet geht, Standard-Db nicht. Sogar irgendwie logisch.

Alles was mit UDT ist, ist im Endeffekt nur teiloptimiert, da diese im Speicher immer als ganzer Block abgelegt werden.
Mann kann ja bei UDT-Daten die Remanenz ja auch nur für den Block festlegen. Das lässt sich leichter als Block übergeben.

Um einen Optimierten-Standard-DB als ganzes an WRIT_DBL zu übergeben müsste man alles in eine Gesamt-Struktur packen.
Die Idee finde ich nicht besonders spannend.

Das nächste Problem ist dann wie oben angesprochen der geänderte Zeitstempel.
Wie von Mediator gemeint kann man zwar auf ein Duplikat mittels CREATE-DB sichern, aber das macht es auch nicht viel besser.

Wenn ich 20 DBs mittels WRIT_DBL sichern möchte, müsste ich folgendes machen:
  • Alle Daten in DBs in eine übergeordnete Struktur packen. Das widerspricht sich gewaltig mit den optimierten DBs.
  • 20 CREATE_DB_Aufrufe ausprogrammieren. CREATE_DB könnte man zumindest in einer Schleife aufrufen, müsste die DBs aber mit ordentlich Reserve erstellen. Man kann während der Laufzeit bei optimierten DBs keine Bytegröße mehr auslesen um die Größe des erstellten DBs optimal zu dimensionieren.
  • 20 WRIT_DBL-Aufrufe programmieren. Die muss man wirklich programmieren. Kenne keinen Weg um die symbolische Übergabe der DBs zu dynamisieren.
  • 20 READ_DBL-Aufrufe programmieren. Irgendwer muss ja die Daten zurückladen.

Ein Arsch voll Arbeit, man muss die komplette Datenstruktur danach ausrichten und die MC muss auch doppelt so groß sein.

Hierzu muss ich noch sagen dass er mir hierbei eher nur darum geht dass die Daten/Einstellwerte beim CPU-Tausch nicht futsch sind.
Je nachdem wie viele Anlagenteile man hat können das schon mal schnell 20/30 DBs sein. Auf der 300 machen wir das mit nem Mini-FB der WRIT_DBL in einer Schleife aufruft.
Einfach DBNr100 bist DBNr150 sichern, Start, Danke.

Sowas würd ich halt auch gern mit optimierten FBs vernünftig können.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
äh da kommt mir grad noch das unter:
CHREATE_DB schrieb:
  • Bit 2 = 0: DB remanent (nur bei DBs, die im Ladespeicher erzeugt werden). Der DB gilt als remanent, wenn mindestens ein Wert remanent gesetzt wurde.

Ja super. Dann nimmt mir ein DB den ich nur auf der Karte hab, auf den ich nicht direkt zugreifen kann und sonst zu nix nütze ist, trotzdem Remanenzspeicher weg?
Bin ich denn bescheuert?

mfg René
 
äh da kommt mir grad noch das unter:


Ja super. Dann nimmt mir ein DB den ich nur auf der Karte hab, auf den ich nicht direkt zugreifen kann und sonst zu nix nütze ist, trotzdem Remanenzspeicher weg?
Bin ich denn bescheuert?

mfg René
Nein, brrrr;)
Es war so gemeint : Du erzeugst mit CREATE_DB einen nicht remanenten DB, der nur im Ladespeicher liegt und groß genug für alle Datensätze ist, die Du dort speicher willst. Später kannst Du mit WRITE_DBL einen Datensatz dort sichern oder von dort lesen. Da der DB nicht optimiert ist, must Du vor dem Schreiben eines Datensatzes den Datensatz serialisieren (serialize) und vor dem Lesen deserialisieren (deserialize). Hierfür brauchst Du im Programm einen nicht optimierten DB, der einen Datensatz aufnehmen kann.

Ich hatte Dich so verstanden, dass Du im Programm immer nur einen Datensatz brauchst, aber auf der Karte zwölf Datensätze.
 
Nein, brrrr;)
Es war so gemeint : Du erzeugst mit CREATE_DB einen nicht remanenten DB, der nur im Ladespeicher liegt und groß genug für alle Datensätze ist, die Du dort speicher willst.

Dann verstehe ich die Hilfe nicht.
CHREATE_DB schrieb:
  • Bit 2 = 0: DB remanent (nur bei DBs, die im Ladespeicher erzeugt werden). Der DB gilt als remanent, wenn mindestens ein Wert remanent gesetzt wurde.

Wenn ich DBs die im Ladespeicher erzeugt werden nur als remanent oder nicht remanent auswählen kann. wozu dann einen im Ladespeicher erzeugen. Ich war der meinung dbs im Ladespeicher können eh nur mit writedb geschrieben werden und diese werte sind sowieso nur so veränderlich also müssen keinen Remanenzspeicher haben da sie ja im Ladespeicher also auf der Speicherkarte fest geschrieben also unveränderlich sind.


Später kannst Du mit WRITE_DBL einen Datensatz dort sichern oder von dort lesen. Da der DB nicht optimiert ist, must Du vor dem Schreiben eines Datensatzes den Datensatz serialisieren (serialize) und vor dem Lesen deserialisieren (deserialize). Hierfür brauchst Du im Programm einen nicht optimierten DB, der einen Datensatz aufnehmen kann.

Ich hatte Dich so verstanden, dass Du im Programm immer nur einen Datensatz brauchst, aber auf der Karte zwölf Datensätze.

Ich muss ja die Datensätze nicht optimiert ablegen. Also ist deserial nicht zwingend nötig.
Das hast du richtig verstanden. Ich arbeite immer nur mit dem aktuellen Monat, den kann ich dann täglich auf der Karte sichern und rücklesen bei firstrun oder init.

Ich muss mir das nochmal ansehen. Lesen und schreiben in eine CSV hätte mir aber besser gefallen.
Das wäre dann wohl die Panellösung. Allerdings habe ich von Scripten derzeit noch sowas von keine Ahnung.

mfG René
 
Zurück
Oben