Daten sammeln und speichern (SQL)

[Flex_x]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich arbeite gerade an einem Projekt im Rahmen einer Abschlussarbeit bei dem mithilfe einer Maschine Daten eines Bearbeitungsprozesses gesammelt und gespeichert werden sollen. Dabei werden die Daten z.T. automatisiert erfasst (Sensordaten) viele Eingaben stammen allerdings auch vom Benutzer und werden vor bzw. nach der Bearbeitung per Hand in das System eingepflegt. Ziel ist es die so pro Versuch gesammelten Daten in einer Datenbank ab zu legen und zu speichern. Insgesamt sollen so ca. 150 Variablen pro Versuch mitgeschrieben werden, plus einem FIFO Speicher mit ca. 10 Variablen und je ca. 300 Einträgen.

Angefangen habe ich mit einem Versuchsaufbau Daten aus der vorhandenen Siemens SPS (S7-1500) per OPC UA mittels NodeRed (node-red-contrib-opcua) abzufragen und in eine Postgres Datenbank (SQL) zu schrieben. Für einzelne Messwerte klappt dies auch ganz gut. Versucht man allerdings mehrere Messwerte und größerer Mengen an Daten zu Lesen (auslesen des FIFO‘s) funktioniert die Kommunikation nicht mehr zuverlässig (Messwerte werden verschluckt oder durcheinander abgelegt). Zudem geht die Zykluszeit bei der Verwendung des Onboard OPC Servers ganz schön in die Knie.

Nun die eigentlichen Fragen: Hat jemand schon mal versucht mit der SPS gesammelte und von Benutzer ergänzte Daten in eine Datenbank zu speichern? Wie war dort die Strategie? Ich bin mir unsicher ob OPC UA und NodeRed dort so das richtigen ist, kenne allerdings auch keine Alternative Daten in eine Datenbank zu schreiben. Welche Systeme und Kommunikationswege verwendet ihr?

Ich bin für jede Idee, Gedankenanstoß, Bsp. usw. dankbar.

Grüße

Flex_x

 

[Thomas_v2.1]

Was für ein Aufzeichnungsintervall schwebt dir denn vor?

 

[Flex_x]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
die vom Benutzer eingegebenen Daten sollen im Grunde genommen vor jeder Bearbeitung gespeichert werden, vlt. alle 5 min einmal.
Messwerte die Während des Prozesses aufgenommen werden sollen minimal alle zehntel Sekunde aufgenommen werden. Diese Daten werden allerdings in einem FIFO Speicher abgelegt, der nach der Bearbeitung in ruhe geleert werden könnte. Mit dieser vorgehen könnten die Aufzeichnungsintervalle Theoretisch sehr groß werden, da die Zeit zwischen der Bearbeitung genutzt werden kann zum speichern.

Grüße

 

[Thomas_v2.1]

Grundsätzlich ist das ja nichts außergewöhnliches, nur ob du das Handling mit dem Fifo so über NodeRed zuverlässig abgewickelt bekommst? Dürfte zumindest einige Frickelei werden. Bei einem Fifo benötigst du ja auch noch eine Art Handshake, wo die SPS sagt "Bitte Fifo auslesen", dein Programm macht das, schreibt diese mit dem vermutlich ebenso in der SPS vorhandenen Zeitstempel in die Datenbank, und wenn alles ausgelesen und gespeichert ist, Meldung an SPS "fertig".
Hast du denn eine Zeitstempelung in der SPS?

 

[Ralle]

Wir hatten hier im Forum schon diverse Threads zu diesem Thema. U.a. hier: #2
Ich hatte auch schon mal eine Messung gemacht, wie schnell man Daten mit Snap7 (Python) auslesen und in eine SQL-DB (SQLite) schreiben kann. Das findet sich hier irgendwo im Forum, bitte mal die Suche bemühen mit Stichworten SQL, Python, Snap7. Im Netz finden sich auch viele Programmierbeispiele dazu, also es ist wirklich nicht zu anspruchsvoll.

Nachtrag: Messung: #35

 

[Flex_x]

Zuviel Werbung?
-> Hier kostenlos registrieren

Grundsätzlich ist das ja nichts außergewöhnliches, nur ob du das Handling mit dem Fifo so über NodeRed zuverlässig abgewickelt bekommst? Dürfte zumindest einige Frickelei werden. Bei einem Fifo benötigst du ja auch noch eine Art Handshake, wo die SPS sagt "Bitte Fifo auslesen", dein Programm macht das, schreibt diese mit dem vermutlich ebenso in der SPS vorhandenen Zeitstempel in die Datenbank, und wenn alles ausgelesen und gespeichert ist, Meldung an SPS "fertig".
Hast du denn eine Zeitstempelung in der SPS?

Den Handshake habe ich mit einem Bit realisiert welches Signalisiert, dass ein Datensatz vorhanden ist welches zurückgesetzt wird wenn die Daten gelesen und in die Datenbank geschrieben wurden. Wie du vermutest ist das Handling dort recht fehleranfällig. Stößt man das Bit in der SPS manuelle an klappt, alles noch, lasse ich das FIFO automatisiert leeren werden die Daten durcheinander gewürfelt, trotz einiger delais.
In dem Datensatz der Übertragen wird ist ein Zeitstempel vorhanden.

Wir hatten hier im Forum schon diverse Threads zu diesem Thema. U.a. hier: #2
Ich hatte auch schon mal eine Messung gemacht, wie schnell man Daten mit Snap7 (Python) auslesen und in eine SQL-DB (SQLite) schreiben kann. Das findet sich hier irgendwo im Forum, bitte mal die Suche bemühen mit Stichworten SQL, Python, Snap7. Im Netz finden sich auch viele Programmierbeispiele dazu, also es ist wirklich nicht zu anspruchsvoll.

Nachtrag: Messung: #35

Die Geschwindigkeit mit der dort Daten gelesen hast haben mich beeindruckt! Das schafft Nod-Red in meiner Konfiguration nicht.
Ich werde versuchen mit mein Testsetup die Daten mit Snap7 zu übertragen!

Danke für euren Input!

 

[Thomas_v2.1]

Du kannst auch in NodeRed anstelle von OPC-UA den node-s7-contrib verwenden. Der verwendet das gleiche Protokoll wie auch Snap7 wie von Ralle beschrieben. Du erhältst darüber aber nur Zugriff auf sogenannte "nicht optmierte" Datenbausteine, und musst auch Put/Get Zugriff in der CPU freigeben. Also wenn der Flaschenhals bei OPC-UA liegt, könnte das schon ausreichen. Dein Handshake hast du aber nach wie vor.

Aber wenn du vorhast auf Snap7 zu wechseln, dann würde ich überlegen ob ich nicht auf BSEND/BRECV umsteige. Das hat bei deinem Anwendungsfall den Vorteil, dass deine Anwendung die SPS nicht pollen muss, sondern die SPS von sich aus aktiv Daten schicken kann. Und dazu auch konsistente Blöcke von bis zu 8192 Bytes. D.h. deine PC Anwendung macht erstmal nichts außer die Verbindung zur SPS aufrecht zu halten, und wenn dein SPS Programm einen Messablauf beendet hat (oder der interne Puffer voll ist) und die Daten intern in einem Puffer abgelegt hat, schickt sie den ganzen Block über BSEND an deine Anwendung, und diese kann die entsprechend verarbeiten.

 

[inray]

Hallo!
Wir haben für diese Art von Anwendungen in unserem OPC-Router (www.opc-router.de) einen Message-Trigger entwickelt. Im Grunde signalisiert die SPS hier über einen Zähler neue Daten und bekommt als Antwort den Zähler zurück und nach Bedarf auch noch ein Bit auf 1 gesetzt. Das sorgt für sehr zuverlässige Fifo-Leerungen und ermöglicht auch das Feststellen von Kommunikationsstörungen, wenn die Zähler längere Zeit nicht übereinstimmen. Das Vorgehen ist natürlich unabhängig vom eingesetzten Produkt. Funktioniert aber gerade über mehrere Layer (inkl. OPC UA) sehr gut.

 

[Flex_x]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du kannst auch in NodeRed anstelle von OPC-UA den node-s7-contrib verwenden. Der verwendet das gleiche Protokoll wie auch Snap7 wie von Ralle beschrieben. Du erhältst darüber aber nur Zugriff auf sogenannte "nicht optmierte" Datenbausteine, und musst auch Put/Get Zugriff in der CPU freigeben. Also wenn der Flaschenhals bei OPC-UA liegt, könnte das schon ausreichen. Dein Handshake hast du aber nach wie vor.

Aber wenn du vorhast auf Snap7 zu wechseln, dann würde ich überlegen ob ich nicht auf BSEND/BRECV umsteige. Das hat bei deinem Anwendungsfall den Vorteil, dass deine Anwendung die SPS nicht pollen muss, sondern die SPS von sich aus aktiv Daten schicken kann. Und dazu auch konsistente Blöcke von bis zu 8192 Bytes. D.h. deine PC Anwendung macht erstmal nichts außer die Verbindung zur SPS aufrecht zu halten, und wenn dein SPS Programm einen Messablauf beendet hat (oder der interne Puffer voll ist) und die Daten intern in einem Puffer abgelegt hat, schickt sie den ganzen Block über BSEND an deine Anwendung, und diese kann die entsprechend verarbeiten.

Der Hinweis das die Palette node-s7-contrib auch snap 7 verwendet ist interessant. Anfangs hatte ich mir kurz die Erweiterung kurz angeschaut aber dann doch aus anderen Gründen verworfen.

Der Gedanke den gesamten Block zu übertragen finde ich auch nicht verkehrt. Ich muss nur dann den Block an Daten wieder auseinander nehmen und in die Datenbank schieben. Ich versuche mir offen zu halten flexibel auch noch mehr FIFO Einträge als die 300 zu übertragen. Da scheint mir der Handshake wenn er denn steht ganz gut geeignet zu sein.

BSEND/BRECV kannte ich nicht werde ich mir aber merken!

Ich versuche mich als erstes in Python ein zu arbeiten um dort mit Snap-7 mein Testsystem auszulesen.

Hallo!
Wir haben für diese Art von Anwendungen in unserem OPC-Router (www.opc-router.de) einen Message-Trigger entwickelt. Im Grunde signalisiert die SPS hier über einen Zähler neue Daten und bekommt als Antwort den Zähler zurück und nach Bedarf auch noch ein Bit auf 1 gesetzt. Das sorgt für sehr zuverlässige Fifo-Leerungen und ermöglicht auch das Feststellen von Kommunikationsstörungen, wenn die Zähler längere Zeit nicht übereinstimmen. Das Vorgehen ist natürlich unabhängig vom eingesetzten Produkt. Funktioniert aber gerade über mehrere Layer (inkl. OPC UA) sehr gut.

Danke für den Hinweis. Im ersten Schritt versuchen wir ohne Kauf Lösung aus zu kommen. Aber danke für den Hinweis auch die Anwendung ist gemerkt.

Grüße

 

[Thomas_v2.1]

Der Hinweis das die Palette node-s7-contrib auch snap 7 verwendet ist interessant. Anfangs hatte ich mir kurz die Erweiterung kurz angeschaut aber dann doch aus anderen Gründen verworfen.

Nein, es verwendet nicht Snap7, aber das gleiche Protokoll das ursprünglich für die S7-300/400 verwendet wurde, was als Kompatibilitätsmodus für den Variablenzugriff auch in den S7-1200/1500 noch aktiviert werden kann. Es hat den Vorteil, dass es einigermaßen schlank und darum auch recht schnell und bandbreitensparend ist. Zumindest im Vergleich zu OPC-UA oder dem eigentlichen Nachfolgeprotokoll für die 1x00.

 

[ifi]

Hallo zusammen,

ich arbeite gerade an einem Projekt im Rahmen einer Abschlussarbeit bei dem mithilfe einer Maschine Daten eines Bearbeitungsprozesses gesammelt und gespeichert werden sollen. Dabei werden die Daten z.T. automatisiert erfasst (Sensordaten) viele Eingaben stammen allerdings auch vom Benutzer und werden vor bzw. nach der Bearbeitung per Hand in das System eingepflegt. Ziel ist es die so pro Versuch gesammelten Daten in einer Datenbank ab zu legen und zu speichern. Insgesamt sollen so ca. 150 Variablen pro Versuch mitgeschrieben werden, plus einem FIFO Speicher mit ca. 10 Variablen und je ca. 300 Einträgen.

Angefangen habe ich mit einem Versuchsaufbau Daten aus der vorhandenen Siemens SPS (S7-1500) per OPC UA mittels NodeRed (node-red-contrib-opcua) abzufragen und in eine Postgres Datenbank (SQL) zu schrieben. Für einzelne Messwerte klappt dies auch ganz gut. Versucht man allerdings mehrere Messwerte und größerer Mengen an Daten zu Lesen (auslesen des FIFO‘s) funktioniert die Kommunikation nicht mehr zuverlässig (Messwerte werden verschluckt oder durcheinander abgelegt). Zudem geht die Zykluszeit bei der Verwendung des Onboard OPC Servers ganz schön in die Knie.

Nun die eigentlichen Fragen: Hat jemand schon mal versucht mit der SPS gesammelte und von Benutzer ergänzte Daten in eine Datenbank zu speichern? Wie war dort die Strategie? Ich bin mir unsicher ob OPC UA und NodeRed dort so das richtigen ist, kenne allerdings auch keine Alternative Daten in eine Datenbank zu schreiben. Welche Systeme und Kommunikationswege verwendet ihr?

Ich bin für jede Idee, Gedankenanstoß, Bsp. usw. dankbar.

Grüße

Flex_x

plcdirectsql.com offers a direct connection between S7-1200/1500 and MS SQL or MySQL