TIA Verbindung S7 1500 und MS SQL Datenbank

[chriwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Forum,

ich muss für meine Abschlussarbeit unter anderem ein Konzept entwickeln, Daten (möglichst standardisiert) aus mehreren Steuerungen zu archivieren.
Die verwendeten CPUs sind die S7 1500 1515-F2PN mit der MS SQL Server Express 2019 Datenbank .

Die Daten:
-Teile des Prozessabbildes mit Zeitstempel zyklisch im Bereich 50mS...200 mS
-Zustandsänderungen von Schrittketten, Betriebsmodi, Fehlermeldungen jeweils mit ein paar Zusatzinformation (Zeitstempel, Bezeichnung etc.)

Diese Daten werden im Nachgang analysiert um z.B. im einfachsten Fall zeitliche Verläufe von Variablen darzustellen.

Ich habe schonmal ein bisschen rumgeschaut und ein paar Lösungsansätze gefunden.

- Direkt aus der SPS die SQL-Befehle an die Datenbank mittels Bibliotheken senden. Z.B. PDSql Library von plcdirectsql.com: Wäre elegant, da die SPSen ereignisbasiert direkt an die Datenbank senden können und keine weitere Software benötigt wird.

- Mit einem Zwischenprogramm, welches mit den Steuerungen und der Datenbank kommuniziert wie SQL4Automation oder
OPC-Router von Inray (als z.B. OPC-UA-Client).

Welche Ideen hätten ihr denn das ganze zu realisieren?

Schonmal vorab vielen Dank für eure Unterstützung
chriwin

 

[DeltaMikeAir]

Wie wäre es mit der Siemens eigenen Lösung?

Siemens Handbuch

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier noch ein Beispielprojekt:
https://support.industry.siemens.co...-s7-1500-an-eine-sql-datenbank?dti=0&lc=de-DE

 

[chriwin]

Wie wäre es mit der Siemens eigenen Lösung?

Die Lösung von Siemens habe ich mir schon angeschaut. Jedoch steht in der Doku, dass der Baustein ""LSql_Microsoft" der die Verbindung mit dem Datenbank-Server realisiert pro SQL-Server nur einmal aufrufbar ist. Die maximale Zeichenanzahl pro Befehl ist mit 255 auch ziemlich wenig um damit ernsthaft größere Datenmengen zu versenden.

 

[M74]

Hallo chriwin,

die Lösung mit SQL4automation ist elegant, weil Du damit direkt SQL-Befehle aus der SPS senden kannst. Das Framework ist über mehrere Verbindungen und Baustein-Instanzen skalierbar. Und den Vorteil von ereignisbasierten Einträgen aus der Datenbank hast Du schon erwähnt - das ist wesentlich effizienter, als wenn Du von aussen über eine Software pollst...

Ein Lösungsansatz wäre zudem, wenn Du die Ereignisse in eine Queue schreibst mit allen allen erforderlichen Informationen inkl. Zeitstempel. Somit kannst Du auch Logging-Informationen ausgeben (Mehrere Ereignisse im gleichen Task) - Du musst einfach die Buffer-Grösse so dimensionieren, dass dieser nicht voll läuft. Der nachgeschaltete Task, welcher die Daten in die Datenbank schreibt kann dann mehrere Ereignisse in einem Telegramm in die Datenbank schreiben, indem z.B. mehrere Stored Procedures hintereinander aufgerufen werden (EXEC spStore @a=1, @b=1.1;EXEC spStore @a=1, @b=1.1;...)
Wir haben dieses Prinzip bereits für Messmaschinen und Prüfeinrichtungen eingesetzt...

Und nicht zu vergessen mit SQL4automation ist es genau so einfach, (standardisierte) Daten von der Datenbank in die Steuerung zu bringen --> Einfach entsprechende SQL-Befehle verwenden

Viel Erfolg!

 

[chriwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo chriwin,

die Lösung mit SQL4automation ist elegant, weil Du damit direkt SQL-Befehle aus der SPS senden kannst. Das Framework ist über mehrere Verbindungen und Baustein-Instanzen skalierbar. Und den Vorteil von ereignisbasierten Einträgen aus der Datenbank hast Du schon erwähnt - das ist wesentlich effizienter, als wenn Du von aussen über eine Software pollst...

Ein Lösungsansatz wäre zudem, wenn Du die Ereignisse in eine Queue schreibst mit allen allen erforderlichen Informationen inkl. Zeitstempel. Somit kannst Du auch Logging-Informationen ausgeben (Mehrere Ereignisse im gleichen Task) - Du musst einfach die Buffer-Grösse so dimensionieren, dass dieser nicht voll läuft. Der nachgeschaltete Task, welcher die Daten in die Datenbank schreibt kann dann mehrere Ereignisse in einem Telegramm in die Datenbank schreiben, indem z.B. mehrere Stored Procedures hintereinander aufgerufen werden (EXEC spStore @a=1, @b=1.1;EXEC spStore @a=1, @b=1.1;...)
Wir haben dieses Prinzip bereits für Messmaschinen und Prüfeinrichtungen eingesetzt...

Und nicht zu vergessen mit SQL4automation ist es genau so einfach, (standardisierte) Daten von der Datenbank in die Steuerung zu bringen --> Einfach entsprechende SQL-Befehle verwenden

Viel Erfolg!

Danke für die Infos

Aber was ist denn der Vorteil von SQL4automation gegenüber der direkten Verbindungung zur Datenbank wie bei PDSql Library?
Oder anders gefragt: Warum nutz SQL4automation einen Connector wenn es auch ohne geht?

Das Ergebnis ist ja am Ende identisch: Bei beiden Ansätzen schicke ich der Datenbank ein SQL-Telegramm.

 

[M74]

Du hast Recht, sowohl bei SQL4automation als auch bei PDSql werden SQL-Kommandos übertragen - insofern ist das Funktionsprinzip der beiden
Produkte identisch (Die SPS schickt einen SQL-Befehl zur Datenbank und erhält eine Antwort zurück...)

Es ist richtig, dass SQL4automation einen Connector (Windows oder Linux Dienst) verwendet. Dies mag auf den ersten Blick als komplizierter erscheinen, bietet aber zusätzliche Vorteile: Stell Dir vor, Du hast ein Anlagen-Netzwerk, Deine Datenbank ist aber irgendwo im Rechenzentrum. Mit diesem Ansatz besteht die Möglichkeit, dass Du einen "Gateway-Rechner" mit 2 Netzwerkkarten installierst und dort den Connector installierst. Dieser nimmt die Telegramme von der SPS entgegen und leitet diese ins RZ weiter.

Ich habe mit PDSql installiert, aber nicht damit gearbeitet. Was mir hier auffällt ist, dass sowohl für das Query als auch für die Antworten (fixe) Datenstrukuren mit Strings definiert sind. Wenn Du nun eine Tabelle mit Anzahl Zeilen * Anzahl Spalten * StringLänge aufspannst, wird entsprechend Speicher beanspruchst. Die StringLänge musst Du so wählen, dass die längsten Nutzdaten nicht abgeschnitten werden. Entsprechend wird speicher verbraucht. Da musst du eben aufpassen, dass nichts abgeschnitten wird, sonst hast Du einen Kommunikationsfehler, weil das SQL-Kommando nicht gültig ist.
Bei SQL4automation werden sowohl das Query-Telegramm als auch die Antworten direkt auf einem Buffer bearbeitet und diese Nachteile der Strings entfallen. Der in der SPS-Welt immer noch relativ spärliche resp. teure Speicher wird somit möglichst optimal genutzt.

Weitere Vorteile von SQL4automation erleben wir in der grossen Offenheit: Es lassen sich alle Datenbanken mit ODBC-Schnittstelle ansprechen und auch die Bausteine sind für verschiedenste Hersteller bereits verfügbar, (Siemens, CODESYS, BECKHOFF, Stäubli und Kuka-Roboter, etc.)

Ich hoffe, Dir mit diesen Infos zu helfen.
(Und nebenbei, ich weiss von einem Kollegen, der eine Gratis-Lizenz für seine Diplomarbeit erhalten hat...)

 

[Rainer Hönle]

Wenn es eine Applikation sein darf, die z. B. auf dem PC mit dem MS SQL-Server läuft, wäre unter Umständen auch unser ACCON-EasyLog eine Option.

 

[chriwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich habe die SPS-Datenbankverbindung mit SQL4automation ausprobiert.
Jedoch reicht die Performance bei weitem nicht aus.

Hintergrund:
Bis zu 420 Datenbankeinträge sollten pro Sekunde allein durch die Zustandswechsel erfasst und gesendet werden. Dazu kommt ein Teil des Prozessabbildes (ganz grob überschlagen bis zu 100 kByte pro Sekunde).

Ich habe auf der SPS die Zeit gemessen, die benötigt wird die 420 Insert-Befehle (mittels gespeicherter Prozedur die jeweils 4 Insert-Befehle ausführt).
Die beträgt ca. 153 ms. Also alleine das Senden der Zustandswechsel benötigt 1/6 der Zeit. Die Daten zum Prozessabbild würden das ganze also komplett sprengen.
Gibt es da eine Möglichkeit das ganze merklich performanter zu übertragen?

 

[DeltaMikeAir]

(ganz grob überschlagen bis zu 100 kByte pro Sekunde)

Da wird wohl auch die CPU eine begrenzende Größe sein, bei 100kb/s

 

[NBerger]

Das wären dann 8.847.360.000 Byte in 24h. Also grob 8,4 GB

Und was soll die Anlage nebenbei noch tun? (wofür war sie eigendlich gedacht?

Big Data ist ja toll aber sowas halte ich für (mal nett) Unsinn.

 

[chriwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und was soll die Anlage nebenbei noch tun? (wofür war sie eigendlich gedacht?

Die SPSen steuern Anlagenbereiche von Fertigungsstraßen Intralogistik, Pressen etc.

Die Firme in der ich bin plant, baut und montiert diese Fertigungsanlagen und nimmt sie in Betrieb. Diese Anlagen sind jeweils Einzelstücke.

Das ganze Konzept hat das Ziel bei den Inbetriebnahmen (oder während der normalen Produktion) zu helfen Fehler zu finden, indem automatisch Zustandswechsel von Schrittketten und Variablen gespeichert werden.
Deswegen war die Idee einen Teil des Prozessabbildes zyklisch zu erfassen und im Nachgang dann den Verlauf der Variablen über die Speicheradresse zu erhalten.

 

[DeltaMikeAir]

Das ganze Konzept hat das Ziel bei den Inbetriebnahmen (oder während der normalen Produktion) zu helfen Fehler zu finden, indem automatisch Zustandswechsel von Schrittketten und Variablen gespeichert werden.
Deswegen war die Idee einen Teil des Prozessabbildes zyklisch zu erfassen und im Nachgang dann den Verlauf der Variablen über die Speicheradresse zu erhalten.

Also ich beschäftige mich seit > 15 Jahren mit Fehlersuchen an SPS-Steuerungen oder im Schaltschrank, an verschiedensten Anlagen
wie auch Produktionslinien, Logistiganlagen, Abfüllanlagen, Palettieranlagen, Kuka Robotern usw.
( 'Natürlich auch während der IBN, die mache ich ja auch selber )

Die von dir genannte Idee wäre für mich die schwierigste Lösung um einen Fehler zu finden. Dafür gibt es so viele ( einfache )
Möglichkeiten...

Vor allem bedenke, wenn deine Anlage irgendwann am Ende der Inbetriebnahme läuft und du nimmst dann diesen Speicher- TransferSQLPart wieder aus der SPS raus, dann wird sich deine SPS anders verhalten als vorher ( alleine schon aufgrund der Zykluszeitänderung ).

Es gibt übrigens Tools, um bei Inbetriebnahmen Daten selbst festgelegter Variablen zu loggen und diese auch mit einer Kamera
zu synchronisieren. Da kann man auch Ereignisse triggern....

Nur mal so als Beispiel, ich habe es noch nie gebraucht aber ist bei kniffligen Angelegenheiten sicher nicht schlecht.
https://www.autem.de/produkte/sps-analyzer-pro-6/

 

[martinsomatic]

Moin,

ich habe die SPS-Datenbankverbindung mit SQL4automation ausprobiert.
Jedoch reicht die Performance bei weitem nicht aus.

Hintergrund:
Bis zu 420 Datenbankeinträge sollten pro Sekunde allein durch die Zustandswechsel erfasst und gesendet werden. Dazu kommt ein Teil des Prozessabbildes (ganz grob überschlagen bis zu 100 kByte pro Sekunde).

Ich habe auf der SPS die Zeit gemessen, die benötigt wird die 420 Insert-Befehle (mittels gespeicherter Prozedur die jeweils 4 Insert-Befehle ausführt).
Die beträgt ca. 153 ms. Also alleine das Senden der Zustandswechsel benötigt 1/6 der Zeit. Die Daten zum Prozessabbild würden das ganze also komplett sprengen.
Gibt es da eine Möglichkeit das ganze merklich performanter zu übertragen?

Hallo chriwin,

ich versuche gerade selber mithilfe des Beispielprojektes eine umsetzten für mein aktuelles Projekt. Kurze Befehle sind ja kein Problem aber das mit den gespeicherten Prozeduren finde ich einfach nicht. Wo kann ich die Prozedur erstellen im TIA? Und wie genau sieht das jetzt aus wenn ich in eine Table mit sehr vielen Spalten habe und ich mit einmal mehrere Werte schreiben will wo ich mit 254 Zeichen nicht auskomme?

Gruß Martin

 

[chriwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo chriwin,

ich versuche gerade selber mithilfe des Beispielprojektes eine umsetzten für mein aktuelles Projekt. Kurze Befehle sind ja kein Problem aber das mit den gespeicherten Prozeduren finde ich einfach nicht. Wo kann ich die Prozedur erstellen im TIA? Und wie genau sieht das jetzt aus wenn ich in eine Table mit sehr vielen Spalten habe und ich mit einmal mehrere Werte schreiben will wo ich mit 254 Zeichen nicht auskomme?

Gruß Martin

Also die Prozedur musst du in der Datenbank erstellen. In der SPS wird die Prozedur wie ein normaler Insert-Befehl ausgeführt. Siehe Post von M74. Wenn dir die 254 Zeichen nicht reichen musst du so etwas wie SQL4Automation oder eine Bibliothek von anderen Drittherstellern benutzen (oder selber programmieren).
Mit SQL4Autmation z.B. wird die maximale Zeichenlänge durch den Sende- und Empfangsbuffer begrenzt. Den kannst du aber theoretisch beliebig ändern.

 

[sps_hubert]

@chriwin
bei den o.g. Anforderungen, sollte auf eine einfache performante Lösung hingesteuert werden. Wenn ich es richtig verstanden habe, soll der Datenlogger bzw. die Datenpumpe in die Datenbank zusätzlich zu dem eigentlichen Programm auf der SPS laufen. Meist ist hier eine zweite Ethernetschnittstelle als Netztrennung zur Datenbank nötig.
Direkt aus der SPS in eine SQL Datenbank geht am Schnellsten. Pro SQL Anweisung sind 10ms inkl. Antwort möglich. Die SPS und der SQL Server muss natürlich auch entsprechend schnell sein. Bei der Auswahl von den zu speichernden Daten kann sehr viel gespart werden. Vorher überlegen und sortieren und dann nur das wichtige in die Datenbank. Ich kann nicht sagen was später gebraucht wird und speichere daher erstmal alles, ist keine Lösung. Möglicherweise muss das Ziel nochmal überdaxcht werden. Wenn die Zustände von 200 Schrittketten gespeichert werden sollen: 200 mal 16bit Integer geht mit einer SQL Anweisung, eine weitere SQL Anweisung wäre 200 Byte = 1600 Digitale Eingänge. Es ist fast schneller wegzuschreiben als die Baugruppen und das Profinet es ranschaffen können. Daher bei der Hardware nicht anfangen zu sparen, denn wer viel Daten schnell speichern will, sollte gute Grundlagen legen.
Zum Vergleich mit OPC UA sind 100ms schon gut, wäre aber eine einfache Lösung zumal die 1500er SPS dies an Board hat. Ach so die OPC Lizenz nicht vergessen zu kaufen ;-). Mit einem Gateway dazwischen kann es nicht schneller sein als direkt. Oder bin ich da nur falsch informiert?
Grüße sps_hubert