TIA Direkt aus Steuerung (S7-1500er) in SQL Datenbank schreiben

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum,
bin als in meinem Beruf schon länger stiller mitleser und habe auch schon viel lernen können. Leider geht mir diese Thread noch nicht weit genug, also hier meine erste Frage.

Ausgangssituation:
War die letzten Jahre als Automatisierungstechniker bei einem Industrie Dienstleister unterwegs und habe doch vieles mit S7 gemacht, war aber meistens auf APROL unterwegs.
Nun habe ich Job gewechselt und bin nun der einzige Automatisierer bei einem Industrie Unternehmen. Wie es der Zufall so will, bin ich eigentlich als Aprol Techniker eingestellt, soll aber nun Daten mit einer S7-1500 in eine SQL DAtenbank schreiben.

Ich habe das Siemens Projekt wie beschrieben angelegt und die Verbindungsparameter eingetragen. Jedoch bekomme ich als Status der Verbindung den Fehlercode 16#8602 und 16#80C5 retour. Laut Beschreibung des Bausteins TCON bedeutet der Code 80C5, das die Verbindung vom Server verweigert und/oder aktiv abgebaut wurde.

Da ich mich auf SQL Server eigentlich NICHT auskenne, bleibt mir leider nur das Vertrauen in die Siemens Anleitung. Hier nochmal der Link:
https://support.industry.siemens.co...-s7-1500-an-eine-sql-datenbank?dti=0&lc=de-AT

Gibt es sonst noch wesentliche Einstellungen an der SPS und am SQL Express Server welche in dem Dokument nicht angeführt sind?

Zum besseren Verständniss noch der Hardware Aufbau:
Laptop mit VM Workstation 16, da läuft eine Win10 VM mit allen wichtigen Siemens Programmen und auch dem SQL Express Server.
Sie CPU (aktuell eine S7-1214 V4.4 weil die S7-1512SP noch nicht lieferbar ist) ist direkt über einen USB-Ethernet Adapter in die VM verbunden.

Danke schon mal fürs lesen und hoffentlich werd ich hier geholfen :)
Grüße Klaus
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen und vielen Dank für den Link.
In der Siemens Beschreibung wurde der Port nur für eine IP freigeschalten und nicht bei IPAll.
TCON arbeitet jetzt ohne Fehler, dafür hackt der Trcv jetzt...
Werde mal mithilfe von Wireshark suchen wo der nächste Fehler liegt
 
Hallo,
ich fürchte dass ich wohl trotzdem noch ein wenig Input brauchen werden...

Mein aktueller Stand bei dem Projekt ist folgender:
Die SPS und der SQL Server wurden wie in dem Siemens Dokument konfiguriert.
Wenn ich nun die Verbindung zum Server herstellen möchte dann passiert folgendes:

Laut Wireshark sendet der SQL Server die tds REsponse dass der Anmeldeversuch erfolgreich war. Ausserdem sendet er auch die Info zurück welche Datenbank angewählt wurde, welcher benutzer eingeloggt ist und die Sprache.
Soweit denke ich dass mit dem Server alles in Ordnung ist.
Auf der Siemens Seite sieht es allerdings weniger gut aus...
Hier bekomme ich vom Baustein Trcv den Fehlercode 16#8088 retour. Laut Beschreibung passen die Parameter LEN und DATA nicht zusammen.
Also habe ich mal in den LSqlMicrosoft Baustein reingesehen und festgestellt dass bei beiden Parametern die selbe DAtenstruktur angegeben ist?!
Wie kann es dann sein dass die Empfangslänge nicht mit der Sendelänge übereinstimmt?:confused:

Steh gerade komplett am Schlauch...
 
Nachtrag:
Der letzte Satz meines vorherigen Post war schwachsinn... Der Parameter "LEN" des Trcv = 0 und Adhoc ist = TRUE. Am Ausgang "RCVD_LEN" ist eine udt angegeben.

Anscheinend scheitert das ganze Vorhaben schon an der Anmeldung.
Laut Wireshark meldet sich die S7 korrekt am SQL Server an, dieser antwortet dann mit einer TDS Response welche insgesamt 554 Bytes groß ist. Davon sind 499 Bytes Nutzdaten im Tabular Data Stream.
Die Angehängte UDT ist groß genug um diese Daten zu empfangen, es passiert aber nicht. Der Parameter "RCVD_LEN" bleibt immer 0 mit Fehlercode 16#8088.

Vielleicht kann ja der Kollege @sps_hubert ja noch was beitragen. Anscheinend hat die Verbindung hier geklappt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo amo111,
Die Verbindung zur MS SQL Datenbank geht in mehreren Schritten zu prüfen. Jeder Schritt bedingt mehr richtige Einstellungen. Also bis zu welchem Schritt funktioniert es?
Zum Testen empfehle ich Dir eine funktionierenden Client. z.B. HeidiSQL_11.1_Portable
1. Direkt auf dem Server starten (Typ: Microsoft SQL Server (TCP/IP, Library: SQLOLEDB, HostnameVomServer, Anhaken Benutzer+Passwort)
2. Das gleiche von einem anderen PC aus (im gleichen LAN wie der Server)
3. Die gleichen Anmeldedaten in die SPS eintragen

Immer schön mit dem Wireshark ab Schritt 2 "mithören". Bei der MS SQL Installation: "Gemischter Modus muss aktiviert" werden, beachten, sonst kann sich kein externer Client am Server anmelden!

Viel Spaß beim Testen!
 
Hallo und danke für die Antwort!

Habe die letzten Tage noch getestet und kann folgendes berichten.
Die S7 meldet sich erfolgreich am SQL Server an und kann auch ein einmaliges SQL Statement ausführen. In meinem Fall ein Wert und der dazugehörige Zeitstempel.
Durch den Fehler des Baustein Trcv bleibt der Baustein "SqlMicrosoft" allerdings in einem undefiniertem Zustand hängen. Für eine zweite Anwrisung muss die Verbindung neu initialisiert werden.

Meine Hoffnung ist dass es an der verwendeten S7-1214 v4.4 liegt. Ich fürchte zwar nicht aber die Hoffnung stirbt zuletzt. Am 8. Februar soll dann die 1512sp geliefert werden.
Wenn es dann noch immer nicht klappt muss ich mir was anderes ausdenken, die Deadlime rückt immer näher...

Grüße Klaus
 
Zuletzt bearbeitet:
Hallo amo111,
schade, wenn es nicht funktioniert. Ich habe dieses Projekt "109779336_SQL_S7_1500_CODE_V20" TIA 16 mit einer SQL Express Datenbank laufen. Ich benutze eine 1511er CPU. O.g. Baustein läuft im Original Code und die Trcv hängt sich nicht auf. Alle 10s schreibt die SPS in die SQL DB. Falls ich Zeit finde, werde ich es mal der 1214er testen. Läuft es mit der 1512sp CPU?
Christian
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

das Schreiben in die SQL Datenbank scheint deutlich leichter zu sein als ein Select. Select wurde von Siemens erst mit der V2.0 in 11/2020 implementiert.

Laut Siemens Doku soll die Kommunikation via Wireshark aufgezeichnet werden, um die Anwort auf eine Select-Abfrage richtig zuordnen zu können.

Wieso ist das notwendig und wovon ist das abhängig?? Ändert sich dieser Wert je nach Select-Abfrage oder verwendeter Datenbank, kann ich somit in der SPS nur immer genau jene Select Statements triggern, deren Antwortstruktur (ColumnMetaData) ich zuvor via Wireshark ermittelt habe??

Nutzt das jemand im Produktiveinsatz?

Gruß Maik
 
Hallo,
nachdem ich heute endlich mal wieder die Zeit gefunden habe mich mit dem Problem zu beschäftigen, habe ich heute folgende Erkenntniss zu berichten.
Da die bestellte 1512SP endlich geliefert wurde, konnte ich den Baustein nun mit der korrekten Hardware testen. Am Anfang mussten noch ein paar Hausgemachte Probleme eliminiert werden (Der Feind sitzt ja bekanntlich vorm Bildschirm :rolleyes:) doch dann klappte alles wie beschrieben.
Momentan schreibe ich ein paar Blinkttakte, bei Wertänderung, mit Zeitstempel in verschiedene Datenbanken auf meinen SQL Express Server.

Der Tag und Monat im Zeitstempel musste noch ausgedreht werden aber das hat ja SPS hubert bereits erwähnt. DANKE dafür!!!
Desweiteren musste ich erst noch herausfinden dass der output Pin "busy" relativ Sinnlos ist weil dieser dauerhaft TRUE ist. Das liegt am Trcv der permanent wartet das Daten empfangen werden.
Ich werte nun den Pin "busy" des Tcon aus, und nutze ihn um weitere Aufträge zu triggern. Somit kann ich alle xx Millisekunden einen neuen Auftrag schreiben.

Danke nochmal an alle Antworten hier!

@maik10
Darüber habe ich mich auch gewundert. Da mein Vorhaben allerdings keine select Statements erfordert, brauche ich das zum Glück jedoch nicht.
 
Es gibt in der Tat verschiedene Schwierigkeitslevel bei der Kommunikation von SPS zur SQL Datenbank. Ich freue mich mit @amo111 , daß es läuft.
Level 1: Connect und Login
Level 2: SPS schreibt (@amo111 Falls es bei Dir wichtig ist: Prüfst Du die Antwort OK beim INSERT, mein SPS Baustein macht es)
Level 3: SPS liest, bekommt eine variable Antwort auf SELECT
Ja, das Level 3 hat die meiste Entwicklungszeit gekostet. Falls Du nur einen Wert immer aus der selben Tabelle brauchst, kannst Du natürlich abkürzen. Jedoch ist dann immer mal wieder ein Programmierer nötig, da es eben nicht variabel ist.
Bei mir laufen alle 3 Level mit den MYSQL TYPE SHORT, LONG, LONGLONG, DATETIME.
Christian
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin, hat denn jemand die Sache mit einer 1200er schon hinbekommen. Ich hänge dort in sps_hubert´s Level3 ;) .Ich habe da Verbindung und kann in die Datenbank schreiben jedoch bekomme ich kein Antworttelegramm obwohl ich auf dem SQL Serverrechner in Wireshark sehe das eins geschrieben wird.

Gruß der Micha
 
Servus, hier nochmal ein Vorschlag(HDBASE) für eine weitere Möglichkeit der Datenübertragung in diverse Formate zum erschwinglichen Preis.
 
erledigt, mit der Version 2.1. Den Parameter len von TRCV auf 8191 und Adhoc auf true. Den Datentyp "typeUseSpecificData.data" im Datenbaustein SQLReceive.data direkt mit Array of Byte 0 ...8191 geändert . Dann in den Eingangsparametern von LSql_Microsoft bei data "typeUseSpecificData.data" mit Array of Byte 0 ...8191 ausgetauscht. So klappt es mit der 1212er sich zu verbinden , Werte zu ändern und selectanfragen durchzuführen. Die Rohdaten bei select müssen natürlich noch aufgearbeitet werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt in der Tat verschiedene Schwierigkeitslevel bei der Kommunikation von SPS zur SQL Datenbank. Ich freue mich mit @amo111 , daß es läuft.
Level 1: Connect und Login
Level 2: SPS schreibt (@amo111 Falls es bei Dir wichtig ist: Prüfst Du die Antwort OK beim INSERT, mein SPS Baustein macht es)
Level 3: SPS liest, bekommt eine variable Antwort auf SELECT
Ja, das Level 3 hat die meiste Entwicklungszeit gekostet. Falls Du nur einen Wert immer aus der selben Tabelle brauchst, kannst Du natürlich abkürzen. Jedoch ist dann immer mal wieder ein Programmierer nötig, da es eben nicht variabel ist.
Bei mir laufen alle 3 Level mit den MYSQL TYPE SHORT, LONG, LONGLONG, DATETIME.
Christian
Hallo,

ich "kämpfe" jetzt auch schon seit einiger Zeit mit der Verbindung einer S7-1500 mit einer MS-SQL-Server-DB.
Die Levels 1 & 2 habe ich mit Erfolg erreicht.
Der Level 3 bereitet mir allerdings Kopfzerbrechen..
Die Token-Row-Antworttelegrame des SQL-Servers beginnen jeweils mit einem $D1-Zeichen, das man im Empfangs-DB zwar als Byte deklarieren kann, aber das folgende Byte des Datensatzes dann nicht im DB angezeigt wird, vermutlich weil die nächst folgende Deklaration an einer Wortgrenze beginnt...
Haben Sie das so hinbekommen, dass die einzelnen Antwortzeilen jeweils in eine S7-Deklaration "passen", oder ein großes Bytearray aufgemacht, um anschließend "manuell" die einzelnen Daten des Antworttelegrammes zusammen zu stellen?
Ich hoffe, dass Siemens das Beispielprojekt an der Stelle noch ausbaut. Die Verbindung von S7 und Datenbank birgt aus meiner Sicht schon eine Menge an nützlichem Potential!
 
Hallo,

ich "kämpfe" jetzt auch schon seit einiger Zeit mit der Verbindung einer S7-1500 mit einer MS-SQL-Server-DB.
Die Levels 1 & 2 habe ich mit Erfolg erreicht.
Der Level 3 bereitet mir allerdings Kopfzerbrechen..
Die Token-Row-Antworttelegrame des SQL-Servers beginnen jeweils mit einem $D1-Zeichen, das man im Empfangs-DB zwar als Byte deklarieren kann, aber das folgende Byte des Datensatzes dann nicht im DB angezeigt wird, vermutlich weil die nächst folgende Deklaration an einer Wortgrenze beginnt...
Haben Sie das so hinbekommen, dass die einzelnen Antwortzeilen jeweils in eine S7-Deklaration "passen", oder ein großes Bytearray aufgemacht, um anschließend "manuell" die einzelnen Daten des Antworttelegrammes zusammen zu stellen?
Ich hoffe, dass Siemens das Beispielprojekt an der Stelle noch ausbaut. Die Verbindung von S7 und Datenbank birgt aus meiner Sicht schon eine Menge an nützlichem Potential!
Hallo
"Die Verbindung von S7 und Datenbank birgt aus meiner Sicht schon eine Menge an nützlichem Potential!" - das sehe ich auch so - aber es sollte doch nicht so kompliziert sein, oder?!
Wir haben all die bekannten Probleme mit der direkten Integration in einem Steuerungssystem umgangen (ist nicht nur bei Siemens so...). Wir nutzen stattdessen SQL4automation - das funktioniert einfach. Nur als Tipp bevor du aufhörst zu kämpfen.... 🤷‍♂️
 
Hallo
"Die Verbindung von S7 und Datenbank birgt aus meiner Sicht schon eine Menge an nützlichem Potential!" - das sehe ich auch so - aber es sollte doch nicht so kompliziert sein, oder?!
Wir haben all die bekannten Probleme mit der direkten Integration in einem Steuerungssystem umgangen (ist nicht nur bei Siemens so...). Wir nutzen stattdessen SQL4automation - das funktioniert einfach. Nur als Tipp bevor du aufhörst zu kämpfen.... 🤷‍♂️
Hallo rrabit,
danke für den Hinweis.
Ich habe ähnliche Anwendungen unter Ausnutzung eines "Umweges" über einen PC auch schon realisiert.
In diesem Fall möchte ich, da es sich um eine kleine Maschine handelt, gerne einen direkten Zugriff auf eine Datenbank einrichten.
Das Schreiben funktioniert auch bereits einwandfrei. Beim Lesen scheitere ich zur Zeit "nur" an der fehlenden Möglichkeit die ankommenden Daten in einem DB zu deklarieren, da es anscheinend nicht möglich ist, Datenbereiche lückenlos über verschiedene Datentypen hinweg zu deklarieren.

Da das Thema doch eigentlich brennend interessant ist, wunder ich mich, dass offensichtlich wenige Kollegen solche Projekte durchgeführt haben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo @erkoausbe ,
das Schreiben in eine DB ist wirklich einfacher. Beim Lesen "Level 3" habe ich über eine Zwischenfunktion die Daten in die SPS kopiert. So kann ich verschiedene Datentypen lesen. Und es ist beliebig erweiterbar. Es gibt auch die Möglichkeit bei wechselnden Datentypen, jedoch in der SPS programmierten, automatisch den richtigen Datentyp zu ermitteln. Also die Daten von 3 Zeilen mit 3 Spalten landen bei mir in einer INT Variable. Suchst Du so etwas? Na, dann hat das Kämpfen doch ein Ende ;-)
Christian
 
Hallo @erkoausbe ,
das Schreiben in eine DB ist wirklich einfacher. Beim Lesen "Level 3" habe ich über eine Zwischenfunktion die Daten in die SPS kopiert. So kann ich verschiedene Datentypen lesen. Und es ist beliebig erweiterbar. Es gibt auch die Möglichkeit bei wechselnden Datentypen, jedoch in der SPS programmierten, automatisch den richtigen Datentyp zu ermitteln. Also die Daten von 3 Zeilen mit 3 Spalten landen bei mir in einer INT Variable. Suchst Du so etwas? Na, dann hat das Kämpfen doch ein Ende ;-)
Christian
Guten Morgen,

ich habe meine Beobachtungen inzwischen an die Siemenskollegen, die die Anwendungsbeispiele betreuen gemeldet und sogar eine Rückfrage dazu erhalten. Ich hoffe dass das Beispiel vielleicht noch in diese Richtung erweitert wird!?

Mein eigenes Projekt habe ich leider zurückstellen müssen. Denke aber, dass ich den folgenden Weg zur Auswertung des Antworttelegrammes gehen werde / muss..:
Ich deklariere ein großes Bytearray für das komplette Antworttelegramm des SQL-Servers und "zerlege" das dann anschließend manuell in die von mir erwarteten SPS-Variablen.

Die Möglichkeit den richtigen Datentyp automatisch zu ermitteln ist sehr interessant.
Bei mir besteht die SQL-Serverantwort aus INT-, REAL- und Stringvariablen.
Ist es möglich das mit Deinem Programm automatisch zuzuordnen?
 
Hallo @erkoausbe
die ServerAnwort mit bis zu 10 INT habe ich schon in der SPS fertig. Da es ein Array ist, kann es leicht erweitert werden. Analog dazu muss dann REAL und STRING (hoffentlich nicht zu lang und zu viele) Konversation erfolgen.
Falls interessiert, dann benötige ich die genaue SQL Serverversion, um es mal mit der 1511 zu testen.
Die Frage der automatischen Zuordnung: JA, das geht. Meine Funktionsblöcke geben DONE oder TRUE zurück. Es sollte ja nur ein Typ passen ;-)
 
Zurück
Oben