TIA V18 - Messwertdaten zwischenspeichern - danach in SQL Server speichern

[tomlei]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Kollegen,

ich lesen Messdaten aus einem Energy Meter und möchte sie zyklisch in einem SQL Server speichern.
In einem anderem Projekt habe ich das Lesen und Schreiben der Daten schon umgesetzt (Verbindung zum Server / DB steht). Hier muss ich jetzt aber sicherstellen, dass bei einem temporären Verbindungsabbruch zum Server keine Daten verloren gehen.

Deswegen wollte ich die Messwerte in einem Datenpuffer (Array / Datenbaustein) speichern und mit einer zweiten Funktion die Daten des Puffers in den SQL Server übertragen.
- wie müsste man das angehen, gibt es vorgefertigte Lösungen / Beispiele von Siemens, die man anpassen könnte - bis jetzt habe ich nichts Passendes finden können
- wenn die Daten in dem Puffer gespeichert werden (pro Datensatz 10 Real Werte , Zyklus 60sek) - hat jemand Erfahrungen wie sich das auf den zur Verfügung stehenden Speicher der CPU (S7 1215 + ET200sp) auswirkt (1 Tag Ausfall der Datenverbindung = 1440 DS)
- kann mir jemand einen Hinweis geben, wie man das in SCL so umsetzt, dass nicht DS doppelt gespeichert werden (im Server kann man das verhindern, aber wie löst man das in SCL) und den gespeicherten DS aus dem Array entfernen (wie stellt man sicher, dass der DS auch wirklich in der DB gespeichert wurde
- wie habt ihr das Problem mit der Zeitumstellung und den doppelten DS gelöst

Ich benötige keine fertige Lösung, würde mich aber über jeden Denkanstoß freuen. Vielen Dank.
Tom

 

[LucasMucas]

Die Energy Suite hate den Puffer in der SPS oder einem überlagerten WinCC-System schon fertig eingebaut und es muss nur angehakt werden.

SIOS

support.industry.siemens.com

SIMATIC Energy Suite - SiePortal - Siemens WW

SIOS

support.industry.siemens.com

SIOS

support.industry.siemens.com

SIOS

support.industry.siemens.com

SIOS

support.industry.siemens.com

 

[tomlei]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Energy Suite hate den Puffer in der SPS oder einem überlagerten WinCC-System schon fertig eingebaut und es muss nur angehakt werden.

Da hast Du natürlich Recht. Allerdings kostet das wieder mehrere Tausend EUR für die notwendigen Lizenzen und die wollte ich meinem Chef nicht zumuten. Zumal es hier um vielleicht 10 Messstellen geht.

Da ich die Datenhaltung in einer DB auf dem SQL Server schon realisiert habe, suchte ich nur noch nach der "sicheren" Datenspeicherlösung. Für die Visualisierung nutze ich kein WinCC sondern Grafana mit Anbindung an den SQL Server.

 

[Botimperator]

wie müsste man das angehen, gibt es vorgefertigte Lösungen / Beispiele von Siemens, die man anpassen könnte - bis jetzt habe ich nichts Passendes finden können

Hast du dir für das schaufeln der Daten von der SPS in den Server mal diesen Beitrag angeschaut?
https://support.industry.siemens.co...s7-1200-cpu-s7-1500-cpu-an-eine-sql-datenbank

Für den FIFO könntest du den Baustein aus der Siemens LGF-Bibliothek nehmen (Vorsicht, die Umlaufzeiger sind bei dem nicht remanent).
Wenn du die gepufferte Datenmenge nicht komplett im Speicher halten willst, wäre dieser Beitrag evtl einen Blick wert:
https://www.sps-forum.de/threads/24h-prozessdatenpuffer-remanent-in-der-sps.115269/#post-925974
Das ist ein FIFO, der zusätzlich Daten auf die SMC auslagern kann.
(Eigenwerbung, yay (⁠✿⁠^⁠‿⁠^⁠) )
Ich weiß aber nicht auswendig ob die 1200er auch das File Handling beherrschen, müsstest du prüfen.

kann mir jemand einen Hinweis geben, wie man das in SCL so umsetzt, dass nicht DS doppelt gespeichert werden (im Server kann man das verhindern, aber wie löst man das in SCL) und den gespeicherten DS aus dem Array entfernen (wie stellt man sicher, dass der DS auch wirklich in der DB gespeichert wurde

Du könntest einen kleinen Zustandsautomaten schreiben, um den Ablauf des Speicherns und abrufens der Daten definiert zu handhaben.
Templates dazu findest du in der Siemens LGF-Bibliothek.
Etwa so wie in dem Prozessdatenpuffer aus dem Beitrag, den ich dir oben verlinkt habe.
Der macht genau das, nur eben mit Files schreiben/lesen auf der SMC und nicht mit schreiben von Daten in einen SQL-Server.

Das mit dem immer nur einmal den Datensatz im DB zu haben, verstehe ich (glaube ich) nicht ganz.
Wenn du prüfen willst ob der Datensatz bereits im Speicherarray enthalten ist, musst du dieses per Schleife einmal durchlaufen und jeden Datensatz auf Gleichheit prüfen.
Das ist enorm Leistungshungrig, wenn du jedes Mal den kompletten Speicher prüfen willst.
Macht aus meiner Sicht mehr Sinn den Code sauber zu schreiben, sodass doppelte einträge gar nicht erst auftauchen können.

wenn die Daten in dem Puffer gespeichert werden (pro Datensatz 10 Real Werte , Zyklus 60sek) - hat jemand Erfahrungen wie sich das auf den zur Verfügung stehenden Speicher der CPU (S7 1215 + ET200sp) auswirkt (1 Tag Ausfall der Datenverbindung = 1440 DS)

Naja, die größe des Puffer-DBs ist beim erstellen bekannt.
Und da die SPS die Arraygröße nicht zur Laufzeit ändern kann....¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯
Ein Tag in deinem Beispiel wären 57600byte + ein paar Byte für die Definition des DBs.
Rest hängt vom verfügbaren Speicher in deiner SPS ab.
Deine 1215 hat 200kb Arbeitsspeicher, laut Datenblatt.
Kommt also drauf an wie viel abzüglich deines Programms noch verfügbar ist.

wie habt ihr das Problem mit der Zeitumstellung und den doppelten DS gelöst

Bezug von Timestamps immer auf Systemzeit, nicht Lokalzeit.
Die SPS-Systemzeit ist UTC/Weltzeit.

 

[tomlei]

Hast du dir für das schaufeln der Daten von der SPS in den Server mal diesen Beitrag angeschaut?
https://support.industry.siemens.co...s7-1200-cpu-s7-1500-cpu-an-eine-sql-datenbank

Ja. Nach diesem Muster habe ich es realisiert.

Für den FIFO könntest du den Baustein aus der Siemens LGF-Bibliothek nehmen (Vorsicht, die Umlaufzeiger sind bei dem nicht remanent).
Wenn du die gepufferte Datenmenge nicht komplett im Speicher halten willst, wäre dieser Beitrag evtl einen Blick wert:
https://www.sps-forum.de/threads/24h-prozessdatenpuffer-remanent-in-der-sps.115269/#post-925974
Das ist ein FIFO, der zusätzlich Daten auf die SMC auslagern kann.
(Eigenwerbung, yay (⁠✿⁠^⁠‿⁠^⁠) )
Ich weiß aber nicht auswendig ob die 1200er auch das File Handling beherrschen, müsstest du prüfen.

Den Fifo Baustein (LGF) habe ich mir schon angesehen. Wenn ich ehrlich bin - das zu verstehen und auf meinen Fall anzupassen, fällt mir noch etwas schwer. Ich muss mich noch weiter damit befassen.

Das mit dem immer nur einmal den Datensatz im DB zu haben, verstehe ich (glaube ich) nicht ganz.
Wenn du prüfen willst ob der Datensatz bereits im Speicherarray enthalten ist, musst du dieses per Schleife einmal durchlaufen und jeden Datensatz auf Gleichheit prüfen.
Das ist enorm Leistungshungrig, wenn du jedes Mal den kompletten Speicher prüfen willst.
Macht aus meiner Sicht mehr Sinn den Code sauber zu schreiben, sodass doppelte einträge gar nicht erst auftauchen können.

Wenn der DS aus dem Array in die DB geschrieben wurde, muss der DS ja auch aus dem Array entfernt werden. Wie stelle ich sicher, dass nicht der Speichervorgang von der PLC nur angestoßen aber vom Server nicht entgegen genommen wurde (Verbindungsproblem, Zugriffsproblem, etc). Man müsste dann ja von der PLC aus prüfen, ob der DS auch gespeichert wurde... Vielleicht ist das ja auch etwas zu kompliziert gedacht - den Gedanken von Transactions muss man wahrscheinlich hier nicht weiterspinnen...

Naja, die größe des Puffer-DBs ist beim erstellen bekannt.
Und da die SPS die Arraygröße nicht zur Laufzeit ändern kann....¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯
Ein Tag in deinem Beispiel wären 57600byte + ein paar Byte für die Definition des DBs.
Rest hängt vom verfügbaren Speicher in deiner SPS ab.
Deine 1215 hat 200kb Arbeitsspeicher, laut Datenblatt.
Kommt also drauf an wie viel abzüglich deines Programms noch verfügbar ist.

Ich glaube ich muss nochmal abklären, wie wichtig die Daten wirklich sind. Bei dem Energiezähler wird der Stand ja in der PLC erhalten. Da fehlt dann halt die Art der Veränderung des Zählerstandes. Die Live Werte (Leistung, Strom, Spannung, Frequenz, etc) sind für Spitzenbelastungswerte interessant (15minutes avg max). Ob das benötigt wird, muss ich nochmal klären.

Bezug von Timestamps immer auf Systemzeit, nicht Lokalzeit.
Die SPS-Systemzeit ist UTC/Weltzeit.

Da hast Du recht. Mein Fehler.
Ich habe mich von den Daten irritieren lassen, die vom derzeitigen System (Wago, CSV, FTP Server) generiert werden. Dort existieren Daten in CSV Dateien mit doppelten Zeitstempeln. Ist das Zeitmanagement bei Codesys anders...?



Fazit:
Ich sehe mir die Fifo Bausteine nochmal an und werde klären, welche Daten wirklich in welchem Zyklus benötigt werden.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Fifo Baustein (LGF) habe ich mir schon angesehen. Wenn ich ehrlich bin - das zu verstehen und auf meinen Fall anzupassen, fällt mir noch etwas schwer. Ich muss mich noch weiter damit befassen.

Ein FIFO speichert bei Anforderung einen Datensatz in einem Array oder gibt den ältesten, noch nicht abgerufen Datensatz wieder aus.
Nicht mehr und nicht weniger.
Ich würde vorschlagen den FIFO lediglich in deinem Programm zu verwenden & nicht den FIFO-Baustein selbst auf deine Zwecke anzupassen.

Wenn der DS aus dem Array in die DB geschrieben wurde, muss der DS ja auch aus dem Array entfernt werden.

Die Speicherverwaltung macht der FIFO intern, darum brauchst du dir erstmal keine Gedanken machen.
Dein Programm müsste sich lediglich um Aufrufe im Sinne von "speichere diesen Datensatz" oder "Gib mir den nächsten Datensatz, damit ich diesen weiter verarbeiten kann" kümmern.

Wie stelle ich sicher, dass nicht der Speichervorgang von der PLC nur angestoßen aber vom Server nicht entgegen genommen wurde (Verbindungsproblem, Zugriffsproblem, etc). Man müsste dann ja von der PLC aus prüfen, ob der DS auch gespeichert wurde.

Du rufst einen Datensatz aus dem FIFO ab und speicherst diesen in einer statischen Variable.
Vom SQL-Verbindungscode bekommst du ein erfolgreich/Fehler zurück.
Dementsprechend kannst du dann den nächsten Datensatz aus dem FIFO holen oder mit einer Fehlerreaktion fortfahren (übertragung nochmal versuchen oder sowas).

Dort existieren Daten in CSV Dateien mit doppelten Zeitstempeln. Ist das Zeitmanagement bei Codesys anders...?

Prinzipiell Mal nicht.
Kannst natürlich die Zeitstempel in deinen Daten in Lokalzeit und Systemzeit ablegen.
Liegt ganz bei deinen Anforderungen.

 

[PN/DP]

Der Einfachheit halber legt man Datensätze üblicherweise nicht mit Lokalzeit ab, sondern UTC (sollte Systemzeit sein). Bei Ablage mit Lokalzeit bekommt man beim Ende der Sommerzeit die selben Zeitstempel zwischen 02:00 und 03:00 mehrmals.

 

[tomlei]

Ein FIFO speichert bei Anforderung einen Datensatz in einem Array oder gibt den ältesten, noch nicht abgerufen Datensatz wieder aus.
Nicht mehr und nicht weniger.
Ich würde vorschlagen den FIFO lediglich in deinem Programm zu verwenden & nicht den FIFO-Baustein selbst auf deine Zwecke anzupassen.

Die Speicherverwaltung macht der FIFO intern, darum brauchst du dir erstmal keine Gedanken machen.
Dein Programm müsste sich lediglich um Aufrufe im Sinne von "speichere diesen Datensatz" oder "Gib mir den nächsten Datensatz, damit ich diesen weiter verarbeiten kann" kümmern.

Du rufst einen Datensatz aus dem FIFO ab und speicherst diesen in einer statischen Variable.
Vom SQL-Verbindungscode bekommst du ein erfolgreich/Fehler zurück.
Dementsprechend kannst du dann den nächsten Datensatz aus dem FIFO holen oder mit einer Fehlerreaktion fortfahren (übertragung nochmal versuchen oder sowas).

Wenn klar ist, welche Daten sie in welchen Zyklen wirklich benötigen, dann werde ich es so versuchen.
Die Netzwerkstabilität ist schon ein Thema (single mode Glasfaser über 15-20 km, unter Tage im Bergwerk, Auswerteeinheit über Tage). Da kann man nicht mal eben eine Ringleitung realisieren. Wäre wahrscheinlich auch over dressed...

Wenn ich nicht weiterkommen sollte, dann melde ich mich hier zum Thema nochmal.
Eigentlich machen wir maximal Wartung und Instandhaltung an Bestandsanlagen und ein Projekt wie dieses ist schon eine Herausforderung für uns. Aber, da interessant - unser Ding.

 

[tomlei]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Einfachheit halber legt man Datensätze üblicherweise nicht mit Lokalzeit ab, sondern UTC (sollte Systemzeit sein). Bei Ablage mit Lokalzeit bekommt man beim Ende der Sommerzeit die selben Zeitstempel zwischen 02:00 und 03:00 mehrmals.

Ja, siehe oben. In einer anderen Anwendung hatte ich die Systemzeit schon verarbeitet und vergessen, dass das UTC0 war...
Schönen Sonntag.