mit OPC Daten auf MSSQL Datenbank schreiben

[Arcon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo miteinander,

ich besitze eine 300er SPS mit Ethernet - Anbindung und zusätzlich einen INAT OPC-Server .. jetzt bin ich bereits soweit .. dass ich im OPC-Server die Verbindung zur SPS aufgebaut habe .. und bspw. bestimmte Merker auslesen kann .. jedoch möchte ich es gerne so hinbekommen .. dass die Datenbank die Werte zyklisch vom OPC-Server abfragt .. muss ich das mit einer Programmiersprache , wie z.b. Delphi oder VBA lösen oder kann ich das direkt in der datenbank aktivieren ?

 

[Rainer Hönle]

Die Datenbank wird nicht beim Server nachfragen, sie ist ja kein OPC-Client. Da muss schon eine Applikation her, die den OPC-Server frägt und die Werte in die Datenbank schreibt.

 

[Arcon]

Zuviel Werbung?
-> Hier kostenlos registrieren

...

Also könnte man es für den Anfang so machen, dass ich in einer Zelle in Excel folgendes reinschreibe -> =Servername|Verbindung!Variable
anschließend in vba ein script schreibe, was mir ständig diese eine zelle auf eine veränderung kontrolliert .. und sobald eine veränderung stattgefunden hat .. soll mir der wert in die datenbank geschrieben werden ... wäre das sinnig ?

 

[Rainer Hönle]

Manche OPC-Server liefern ActiveX-Client-Controls mit. Wenn Inat das auch tut, dann ist das Lesen sicher einfach. Wahrscheinlich kann man mit VBA auch in eine SQL-Datenbank schreiben. Ich kann allerdings nicht sagen wie. Excel verwende ich nur als Tabellenkalkulation. Zum Programmieren nehme ich eine "normale" Programmiersprache.
Sollen die Werte jetzt zyklisch oder bei Änderung geschrieben werden? Welche Datenmenge steckt dahinter? Was ist das eigentliche Ziel? Was soll mit den Daten in der SQL-Datenbank gemacht werden?

 

[Arcon]

ich habe mir bereits die aktuelle delphi version gekauft .. jedoch muss sie vom admin nur noch installiert werden ... und das geschieht erst am freitag .. bis dahin wollte ich etwas in excenl rumspielen und austesten .. um am freitag gleich durchzustarten

die werte sollen nur bei datenänderung geschrieben werden .. dabei handelt es sich um ca. 50 werte, die ständig auf änderung kontrolliert werden müssen .. anschließend möchte ich die werte bei änderung in die datenbank kopieren .. und dann möchte ich mit einem front-end auf die daten in der datenbank zugreifen .. also wie so eine art auswertungs-tool ..

kennst du dich den mit delphi soweit aus, dass das machbar wäre ?
was ich mich frage .. das tool .. was die abfrage ständig kontrolliert .. muss ja immer online sein .. also wäre es das beste wenn ich das aufm server installier und dort die werte ständig abfragt .. oder wie kann man sich das vorstellen , wie das funktioniert .. ich will ja nicht ständig selber triggern .. !?!

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit Delphi ist dies auf jeden Fall machbar. Außerdem sind hier im Forum einige, die sich mit Delphi und OPC hervorragend auskennen. Hilfe solltest du also in jedem Fall bekommen wenn du mal Fragen hast (wenn auch nicht von mir).

 

[Question_mark]

Alles geht ..

Hallo,

Außerdem sind hier im Forum einige, die sich mit Delphi und OPC hervorragend auskennen

Du hast mich jetzt richtig aufgeweckt. Hier war ja nicht nur OPC gefragt, sondern auch die entsprechende Kommunikation von SPS über PC zum MS SQL Server. Mit Delphi kann man diese doch verschiedenen Techniken recht komfortabel verbinden.
Also OPC (oder auch gerne Deltalogics AGLink) zur Anbindung an die SPS, und dann nehme ich bevorzugt zur Anbindung von Delphi an Datenbanksysteme die Komponenten von DevArt. Für den MS SQL Server zB. hier den Link :

http://www.devart.com/sdac/

Kostet zwar ein paar Euronen, funktioniert aber zuverlässig und stabil, also absolut industrietauglich auch nach mehreren Jahren 24/7 Betrieb ...

Gruß

Question_mark

 

[rudl]

Hast du dir schon mal überlegt von der SPS direkt in die Datenbank zu schreiben? Dann brauchst du kein Programm das ständig pollt, sondern die SPS bestimmt wann sie welche Daten in die Datenbank schreiben will...

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Just my 2 cents

Hallo,

Hast du dir schon mal überlegt von der SPS direkt in die Datenbank zu schreiben?

Das ist im Prinzip zwar möglich, und wenn ich mich recht erinnere hat schon mal jemand das hier im Forum vorgestellt. Aber ob das wirklich praktikabel ist ? Nicht jeder SPS-Programmierer kann auch SQL-Abfragen gegen eine Datenbank programmieren. Und wenn doch, spätestens bei einem verschachtelten "Inner Join" wird er im Wikipedia nachschlagen, wie man dicke Seile knüpft und Deckenhaken stabil eindübelt. Und der Funktionsumfang wird mit Sicherheit auch beschränkt sein. Ob das Ding Trigger empfangen kann, Stored Procdures mit Parameterübergabe handeln kann usw.

Außerdem gibt es so viele verschiedene Dialekte von SQL, nahezu jeder Hersteller von Datenbanken kocht da sein eigenes Süppchen. Was auf Oracle funktioniert, muss nicht unbedingt auf einem MS SQL Server oder auf einer AS400 funktionieren.

Dann brauchst du kein Programm das ständig pollt, sondern die SPS bestimmt wann sie welche Daten in die Datenbank schreiben will...

Also das Pollen besorgt der OPC-Server und nur wenn sich Daten ändern feuert der mir einen Event. Ansonsten legt sich meine Applikation im Idle Status zur Ruhe.

Und wer bestimmt, wenn die Datenbank zB. neue Auftragsdaten in eine SPS schreiben will ?

Also die direkte Verbindung SPS <--> Datenbank ist (jedenfalls zur Zeit) noch recht unflexibel und eingeschränkt.

Gruß

Question_mark

 

[Jochen Kühner]

Auch mal was...

Kannst ja auch mal meinen LibNoDave Protokoller ansehen.

http://jochensserver.dyndns.org/wordpress/?page_id=9

Der kann zwar keine Daten vom OPC lesen, aber direkt Daten aus einer SPS in eine Datenbank schreiben.

 

[Question_mark]

Da bleiben noch einige Fragen offen

Hallo,

Der kann zwar keine Daten vom OPC lesen, aber direkt Daten aus einer SPS in eine Datenbank schreiben.

Und vice versa auch ?
Kann der Trigger von der DB empfangen ?
Stored Procedures mit Parameterübergabe an die DB anstoßen ?
SQL Abfragen mit Parametern gegen die DB absetzen ?
Was ist mit komplexen, verschachtelten Abfragen über mehrere Tabellen ?
Kann man damit von der S7 Tabellen und Felder in der DB erstellen ?
Was ist mit dem H1 Protokoll ?
Was ist mit H1 über TCP ?
RK 512 Protokoll ?

Also für meinen Geschmack werden da zu viele Fragezeichen offenbleiben.
Aber ich habe mir das jetzt nicht alles angesehen, aber eine Verständnisfrage stellt sich mir doch : Wie ich aus dem Namen "LibNoDave Protokoller" ableite, ist wohl die LibNoDave von Zottel die Grundlage für die Kommunikation zur SPS. Und auf welchem Gerät ist der LibNoDave Protokoller und Zottels Library installiert ? Vielleicht solltest Du den Protokoller mal etwas näher hier im Forum beschreiben. Die Webseite, auf Die Du im obigen Beitrag verlinkt hast ist nicht sehr informativ, da hab ich meistens schon keine Lust mehr, noch weiter zu blättern. Nimm dies aber bitte nicht als Kritik, sondern nur als Hinweis auf.

Gruß

Question_mark

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,



Und vice versa auch ?
Kann der Trigger von der DB empfangen ?
Stored Procedures mit Parameterübergabe an die DB anstoßen ?
SQL Abfragen mit Parametern gegen die DB absetzen ?
Was ist mit komplexen, verschachtelten Abfragen über mehrere Tabellen ?
Kann man damit von der S7 Tabellen und Felder in der DB erstellen ?
Was ist mit dem H1 Protokoll ?
Was ist mit H1 über TCP ?
RK 512 Protokoll ?

Also für meinen Geschmack werden da zu viele Fragezeichen offenbleiben.
Aber ich habe mir das jetzt nicht alles angesehen, aber eine Verständnisfrage stellt sich mir doch : Wie ich aus dem Namen "LibNoDave Protokoller" ableite, ist wohl die LibNoDave von Zottel die Grundlage für die Kommunikation zur SPS. Und auf welchem Gerät ist der LibNoDave Protokoller und Zottels Library installiert ? Vielleicht solltest Du den Protokoller mal etwas näher hier im Forum beschreiben. Die Webseite, auf Die Du im obigen Beitrag verlinkt hast ist nicht sehr informativ, da hab ich meistens schon keine Lust mehr, noch weiter zu blättern. Nimm dies aber bitte nicht als Kritik, sondern nur als Hinweis auf.

Gruß

Question_mark

Hab mal was geschrieben:

http://www.sps-forum.de/showthread.php?t=35901

 

[Question_mark]

Eine Frage noch

Hallo,

Und auf welchem Gerät ist der LibNoDave Protokoller und Zottels Library installiert

Diese Frage ist noch offen ...
Ist das etwa ein PC ?

Gruß

Question_mark

 

[Jochen Kühner]

Hallo,



Diese Frage ist noch offen ...
Ist das etwa ein PC ?

Gruß

Question_mark

Zufrieden? ;-)

 

[rudl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist im Prinzip zwar möglich, und wenn ich mich recht erinnere hat schon mal jemand das hier im Forum vorgestellt. Aber ob das wirklich praktikabel ist ? Nicht jeder SPS-Programmierer kann auch SQL-Abfragen gegen eine Datenbank programmieren. Und wenn doch, spätestens bei einem verschachtelten "Inner Join" wird er im Wikipedia nachschlagen, wie man dicke Seile knüpft und Deckenhaken stabil eindübelt. Und der Funktionsumfang wird mit Sicherheit auch beschränkt sein. Ob das Ding Trigger empfangen kann, Stored Procdures mit Parameterübergabe handeln kann usw.
Question_mark

Schon klar, dass nicht jeder der SPS programmiert auch Datenbankspezialist ist. Bevor man aber selber eine Applikation in Delphi oder VB entwickelt, (Dafür muss man ja auch Hochsprachen programmieren können) ist es sicher einfacher ein fertiges und getestes Programm einzusetzen. Ausserdem können wirklich Stored Procedures mit Variablenübergabe ausgeführt werden. Die Stored Procedure kann vom Datenbankadministrator erstellt werden. Der Vorteil ist einfach, dass die SPS direkten Zugriff auf die Datenbank hat und kein zusätzlicher Datenhandler benötigt wird. Dies wirkt sich positiv auf die Flexibilität und je nach Datenmenge auf die Performance aus. Bei einer Programmänderung muss nur die Datenbank und das SPS Programm angepasst werden und nicht noch zusätzlich ein Datenhandler.

Außerdem gibt es so viele verschiedene Dialekte von SQL, nahezu jeder Hersteller von Datenbanken kocht da sein eigenes Süppchen. Was auf Oracle funktioniert, muss nicht unbedingt auf einem MS SQL Server oder auf einer AS400 funktionieren.
Question_mark

Der Standardsyntax ist überall gleich und nach ISO ANSI standardisiert. Weiterführende Befehle können verschieden sein. (Etwa mit der IEC 61131 zu vergleichen) Diese Unterschiede sind jedoch marginal und können einfach angepasst werden. Zum Beispiel Stored Procedures werden in den einen Sprachen mit Call, in den anderen mit Execute aufgerufen.

Und wer bestimmt, wenn die Datenbank zB. neue Auftragsdaten in eine SPS schreiben will ?
Question_mark

Das Konzept wird eigentlich auf den Kopf gestellt. Die SPS holt sich die Daten und nicht die Datenbank schreibt die Daten in die SPS. Schlussendlich meldet zum Beispiel eine Leit-SPS ein Typwechsel an die anderen SPS / Roboter. Dies kann über ein DIO oder Profibus geschehen. Natürlich können auch alle DIO über die Datenbank ausgetauscht werden, was aber nicht unbedingt zu empfehlen ist.

Also die direkte Verbindung SPS <--> Datenbank ist (jedenfalls zur Zeit) noch recht unflexibel und eingeschränkt.
Question_mark

Wenn ich es mit den herkömmlichen Lösungen vergleiche ist es die Flexibelste.

 

[Dr. OPC]

Obwohl es spanned ist wie diese Diskussion langsam in andere Lösungsvorschläge "abdriftet", nochmal die Kurzform:

Ursprüngliche Aufgabe: S7-300 mit Inat OPC Server schon vorhanden, 50 Datenpunkte bei Änderung in Datenbank schreiben.

Zwischenschritt: Excel (als OPC Client) gibt es schon und funktioniert auch, Werte werden bei Änderung in Tabelle abgefüllt.

Lösung: OPC-Client mit Delfi (wurde dafür extra gekauft) selber schreiben, Werte werden bei Änderung vom OPC Server an diesen Client gemeldet. Der Client nimmt die Werte aus dem DataChangeCallback und ruft die entsprechende ODBC oder ADO Funktion der Datenbank auf. Hinweis: hier muss "entkoppelt" werden da sich die Daten schneller ändern können als sie in die Datenbank geschrieben werden können, also sollte nicht direkt aus dem Callback die Datenbank gerufen werden!

Vorteil: funktioniert mit allen SPSen (für die es einen OPC Server gibt) und mit allen Datenbanken (für die es eine ODBC Schnittstelle gibt). Kann konfigurierbar implementiert werden (z.B. Liste mit OPC Variablen und Liste mit Ziel-Feldnamen oder natürlich mit GUI) und ist somit nicht nur flexibel sondern auch wiederverwendbar und ohne weitere Programmierung anpassbar. Würde auch mit zwei oder mehr OPC Servern als Datenquelle funktionieren (ohne dort SQL-Statements in den SPSen implementieren zu müssen)

Alternativ: Derartige Software gibt es natürlich auch schon als fertige Produkte z.B. DataLogger (Softwaretoolbox) und viele andere, aber es sollte ja eigener Hirnschmalz anstelle von Euros investiert werden.

 

[Jochen Kühner]

Obwohl es spanned ist wie diese Diskussion langsam in andere Lösungsvorschläge "abdriftet", nochmal die Kurzform:

Ursprüngliche Aufgabe: S7-300 mit Inat OPC Server schon vorhanden, 50 Datenpunkte bei Änderung in Datenbank schreiben.

Zwischenschritt: Excel (als OPC Client) gibt es schon und funktioniert auch, Werte werden bei Änderung in Tabelle abgefüllt.

Lösung: OPC-Client mit Delfi (wurde dafür extra gekauft) selber schreiben, Werte werden bei Änderung vom OPC Server an diesen Client gemeldet. Der Client nimmt die Werte aus dem DataChangeCallback und ruft die entsprechende ODBC oder ADO Funktion der Datenbank auf. Hinweis: hier muss "entkoppelt" werden da sich die Daten schneller ändern können als sie in die Datenbank geschrieben werden können, also sollte nicht direkt aus dem Callback die Datenbank gerufen werden!

Vorteil: funktioniert mit allen SPSen (für die es einen OPC Server gibt) und mit allen Datenbanken (für die es eine ODBC Schnittstelle gibt). Kann konfigurierbar implementiert werden (z.B. Liste mit OPC Variablen und Liste mit Ziel-Feldnamen oder natürlich mit GUI) und ist somit nicht nur flexibel sondern auch wiederverwendbar und ohne weitere Programmierung anpassbar. Würde auch mit zwei oder mehr OPC Servern als Datenquelle funktionieren (ohne dort SQL-Statements in den SPSen implementieren zu müssen)

Alternativ: Derartige Software gibt es natürlich auch schon als fertige Produkte z.B. DataLogger (Softwaretoolbox) und viele andere, aber es sollte ja eigener Hirnschmalz anstelle von Euros investiert werden.

Uhhh, danke für den Tip, habe bei meinem Protokoller bei einer Testprotokollierung an eine Anlage Probleme mit dem Durchsatz bekommen, aber nie die Datenbank als möglichen Flaschenhals in betracht gezogen. Wer wohl das schreiben in die Datenbank auch azyklisch implementieren, mal sehen ob's dann geht... (sind um die 40-60 Telegramme pro Sekunde mit je 100 Byte)

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Immer noch keine vernünftige Antwort bekommen

Hallo,

(ohne dort SQL-Statements in den SPSen implementieren zu müssen)

Eigentlich versuche ich immer noch herauszufinden, ob die Lösungen von Jochen Kühner bzw. von rudl wirklich auf SQL-Statements in der SPS beruhen und direkt von der SPS auf die Datenbank connecten oder doch einen PC als Gateway verwenden.

Ich zitiere mich ausnahmsweise mal selber :

Diese Frage ist noch offen ...
Ist das etwa ein PC ?

Und erhalte eine sehr merkwürdige Antwort :

Zufrieden?

Da bei Jochen Kühner aber in diesem Zusammenhang immer LibNoDave genannt wird, nehme ich mal an, es gibt keine "direkte" Verbindung zwischen SPS und Datenbank, sondern es hängt immer noch ein PC dazwischen !

Das Konzept wird eigentlich auf den Kopf gestellt. Die SPS holt sich die Daten und nicht die Datenbank schreibt die Daten in die SPS.

Das nenne ich dann mal wirklich flexibel, hust ...

Diese Unterschiede sind jedoch marginal und können einfach angepasst werden.

*ROFL*

Da haben wir also ein Trio (Jochen Kühner, rudl und SQL4automation), in dem jeder von einer "direkten" Verbindung zwischen SPS und Datenbank spricht.

Ich frage doch einfach nur nach, wie direkt denn die Verbindung zwischen SPS und Datenbank ist, oder ob da doch vielleicht doch noch so ein kleiner PC dazwischenhängt ...

Gruß

Question_mark

 

[Question_mark]

Flaschenhals ist nicht die DB

Hallo,

aber nie die Datenbank als möglichen Flaschenhals in betracht gezogen.

Die Datenbank ist nicht der Flaschenhals, die lacht sich schlapp über die paar Bytes. Der Flaschenhals ist ganz einfach der Umweg über die ODBC Treiber von Windows, da werden die Daten durch die Treiber von Windows geschleust. Und manchmal ist Windows auch mit anderen Sachen beschäftigt.

Gruß

Question_mark

 

[Question_mark]

Ach, was sind wir heute wieder kontrovers

Hallo,

Schon klar, dass nicht jeder der SPS programmiert auch Datenbankspezialist ist. ....... Bei einer Programmänderung muss nur die Datenbank und das SPS Programm angepasst werden

Also je ein Programmierer für SPS und Datenbank erforderlich. Wir beide haben eben unterschiedliche Auffassungen von Flexiblität. Und ich fürchte mal, die werden auch in der Zukunft nicht wirklich ausgeräumt werden

Gruß

Question_mark