trigger zur wertabfrage / OPC

[Arcon]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo miteinander,

ich besitze einen Inat Opc server.. eine SPS anlage mit einer 300er CPU und ethernetanbindung .. und eine ms sql datenbank express edition ..
ich möchte es realisieren, dass wenn ein wert in der sps anlage verändert wird .. wir gehen mal von nem merker aus .. dass der inat opc server aller 250 ms diesen wert auf änderung abfragt .. sollte der wert sich ändern .. muss es eine funktion gegen .. die diesen wert in die dafür vorgesehene tabelle der datenbank schreibt ...

ich habe es bereits so realisiert .. dass mir der aktuelle wert der sps-anlage in verbindung mit dem opc server .. in eine excel-tabelle geschrieben wird .. jedoch möchte ich nun, dass entweder der wert weiter in die datenbank übertragen wird .. bzw. der wert direkt vom opc server in die datenbank übertragen wird ...

und da hab ich ein verständnis problem ... wie realisiere ich das .. ? ich bräuchte doch sowas wie nen trigger .. der in der datenbank integriert is .. und ständig auf den opc server zugreift .. und auf eine änderung prüft .. ? liege ich da falsch ?

habt ihr irgendwelche inspirationen ?

danke für die hilfe !

gruß martin

 

[Rainer Hönle]

Die Datenbank macht von sich aus gar nichts. Das muss normalerweise ein OPC-Client machen, der die Daten vom OPC-Server liest und dan in die Datenbank schreibt. Hatte dies aber bereits in dem anderen Thread geschrieben.
Ein Trigger in der Datenbank bezieht sich auf Änderung der gespeicherten Daten, also die sich bereits in der Datenbank befinden. Zur Vertiefung des grundsätzlichen Verständnisses der verwendeten Datenbank empfehle ich dieses Buch .... Zum Thema OPC können andere entsprechende Buchtipps abgeben.

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da "der andere Thread" offensichtlich nicht auf das ursprüngliche Problem zurückkommen will und dem Themenstarter nicht wirklich weiter geholfen wird, versuche ich es hier.

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. Hier wird Excel mit VBA oder einem ActiveX Control verwendet (das den eigentlichen OPC Client darstellt) und die Werte bei Änderung bekommt und in Excel-Zellen rein schreibt.

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 in 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. ini-File mit Liste von 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, oder die SPS überhaupt anfassen 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.

Also ja du liegst falsch. Du brauchst keinen Trigger in der Datenbank. Der OPC Client (den du schreiben musst/willst) bekommt die Daten bei Änderung geliefert (er wird vom Server gerufen - Callback) und die Daten musst du nehmen und in die Datenbank-Felder schreiben in die sie hineingehören. Deine Software "verbindet" also zwei Standards, OPC auf der einen und ODBC (oder für welche Datenbankschnittstelle du dich entscheidest) auf der anderen Seite und "kopiert" Daten hin und her. Es muss also so etwas wie eine "Verknüpfungsliste" geben in der Quell-Datenpunkte zu Zielfeldern der DB zugeordnet sind. Das alleine ist erstmal nicht so schwierig, kniffeliger wird es wenn du Fehlerszenarien beherrschen musst, was wenn die Datenbankverbindung weg ist? Wohin mit den Daten die trotzdem aus der SPS kommen? Was wenn die Verbindung zum OPC Server abbricht? Wie soll die selbsständig wieder aufgebaut werden? An welcher Stelle setzen die Daten wieder ein? All diese Fragen musst du sicher irgendwann für dich und deinen Anwendungsfall beantworten.

Aus meiner Sicht bist du aber gut beraten wenn du Standardschnittstellen einsetzt, hier wurden viele Probleme schon gelöst und es gibt auch massenhaft Beispiele wie man vorgehen sollte.

 

[Question_mark]

Noch ein paar Anmerkungen zum Thema

Hallo,

Also ja du liegst falsch. Du brauchst keinen Trigger in der Datenbank.

Also eher ein "Jein" von mir. Grundsätzlich kann man auch ohne Trigger von der Datenbank mit derselben Daten über einen PC mit der SPS austauschen. Wenn aber die Datenbank z.B. neue Auftragsdaten an eine Produktionslinie schicken will, kann es sinnvoller sein (anstelle von pollen des PC zur Datenbank), dass von der DB ein Trigger zum PC gesendet wird und der PC sich die neuen Auftragsdaten dann von der DB abholt. Man braucht es nicht unbedingt, aber man kann es (und sollte man auch) so machen.

Also bezogen auf die Applikation auf dem PC können durchaus beide Kommunikationspartner (also SPS und DB), Events bei Änderung von Daten feuern.

Der OPC Client (den du schreiben musst/willst)

Naja,es ist nicht gerade trivial, einen zuverlässig funktionierenden OPC-Client für den 24/7 Betrieb in der Industrie zu programmieren. Dazu ist schon ein erheblicher Zeitaufwand erforderlich. Da aber beim Fragesteller Delphi schon angeschafft worden ist, hier der von mir verwendete OPC-Client (den ich uneingeschränkt empfehlen kann) :

http://www.kassl.de/opc/delphi.shtml

Einfach Spitze, laufen in meinen Projekten schon seit Jahren ohne Probleme.

Und für die Anbindung von Delphi an verschiedene Datenbanken (MySQL, MS SQL, Oracle etc.) verwende ich das hier auch schon seit Jahren mit bestem Erfolg :

http://www.devart.com/dac.html

Ok, beide Teile sind kostenpflichtig, aber sind Ihr Geld immer Wert, absolut schnell und effizient. Man kann das auch selbst programmieren, aber bis man die Zuverlässigkeit und Funktionalität erzielt hat, erscheint Windows 2014

Dann kann man wieder von vorne anfangen ...

Deine Software "verbindet" also zwei Standards, OPC auf der einen und ODBC (oder für welche Datenbankschnittstelle du dich entscheidest) auf der anderen Seite und "kopiert" Daten hin und her.

Natürlich richtig. Aber ich will da mal noch ergänzen : Alleine die unterschiedlichen Datenformate von SPS und DB erfordern eine sorgfältige Anpassung durch die verbindende Applikation. So können alle an der Kommunikation beteiligten Komponenten (also SPS, Compiler auf dem PC und DB) durchaus den Datentyp "Integer" auf Ihre eigene Weise interpretieren. Ganz extrem zB. :

1) Integer der SPS : 16-Bit
2) Integer Delphi : 32-Bit
3) Integer DB : 64-Bit

Das betrifft natürlich auch Datentypen wie DateTime und noch eine Menge andere.

Das alleine ist erstmal nicht so schwierig, kniffeliger wird es wenn du Fehlerszenarien beherrschen musst, was wenn die Datenbankverbindung weg ist? Wohin mit den Daten die trotzdem aus der SPS kommen? Was wenn die Verbindung zum OPC Server abbricht? Wie soll die selbsständig wieder aufgebaut werden? An welcher Stelle setzen die Daten wieder ein? All diese Fragen musst du sicher irgendwann für dich und deinen Anwendungsfall beantworten.

Yeep, wie ich schon zuvor beschrieben habe : es ist nicht trivial. Man kann zwar etwas zusammenhacken, das es funktioniert. Aber es muss eben über Jahre ohne Probleme funktionieren, und dazu braucht man schon ein wenig Erfahrung.

bist du aber gut beraten wenn du Standardschnittstellen einsetzt

Dem kann ich ohne Einschränkung zustimmen, und da der Fragesteller Delphi verwendet, habe ich (siehe oben) mal ein paar Vorschläge gemacht.

Gruß

Question_mark

 

[Rainer Hönle]

1) Integer der SPS : 16-Bit
2) Integer Delphi : 32-Bit
3) Integer DB : 64-Bit

Bei MSSQL hat ein int 32 Bit, ein bigint 64 Bit.

 

[Dr. OPC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Na schön das wir uns einig sind.

Bei dem Trigger hast du Recht, das würde die "Gegenrichtung" betreffen. Also wenn "Rezeptdaten" aus der Datenbank in die SPS geschrieben werden dann ist so ein Trigger natürlich sinnvoll. Aber das Verständnis-Problem des Fragestellers hatte ich so verstanden dass "Daten zum Archivieren" von der SPS in die Datenbank geschrieben werden sollen. Für diese "Vorwärtsrichtung" benötigt man keinen Trigger in der DB. Also im Prinzip genauso wie in seinem Excel-Beispiel das er ja schom am Laufen hat.

Die Datentypkonvertierung ist sicher solange kein Problem solange immer in den "größeren" Typ geschrieben wird. Aber da muss man natürlich aufpassen, da hast du recht und eventuell ein paar Variants konvertieren (bzw. den OPC Server das machen lassen). Solange es keine komplexen Typen sind ist das aber gut beherrschbar. Leider ist das auf Seite der Datenbanken nicht so "verlässlich" spezifiziert und je nach Herrsteller (und manchmal sogar nach Version ein und des selben Herrstellers) immer etwas anders. Bei OPC ist das sicher "verlässlicher", vor allem wenn man "zertifizierte" OPC Server einsetzt, kann man sich (zumindest darauf) recht gut verlassen.

Zum Fehlerhandling und zur Stabilisierung im 24/7 Betrieb dürfte klar sein das hier der größte Aufwand besteht und die "Qualität" einer Software sichtbar wird. Da kann man noch entscheiden ob der Anwendungsfall es erfordert z.B. einmal am Tag anstarten, Knopf drücken und Daten archivieren ist sicher nicht so kritisch als wenn die Kerntemperatur von Brennstäben im Atomkraftwerk protokoliert werden soll.

Wie du richtig sagst, kommt man vielleicht an einen Punkt an dem der Einsatz von fertigen (und getesteten) Bibliotheken sinnvoll ist, um sich diese Arbeit nicht selber machen zu müssen, oder man kauft gleich ein fertiges Software Produkt und probiert, ob es den Ansprüchen genügt.