Daten aus SQL-Server mit SIMATIC S7 auslesen

[aurel]

Hallo zusammen,

habe folgenden Sachverhalt zu lösen:

In unserer Fertigung sind für jedes Produkt Kenndaten zur Fertigung auf einem SQL-Server abgelegt.

Wir haben jetzt eine neue Anlage dazu bekommen, die eine S7-CPU in einem SIEMENS IndustriePC (Microbox) besitzt, über welche die Anlage gesteuert wird. Die Microbox besitzt eine Profibusschnittstelle, zwei Ethernet-Anschlüsse (TCP/IP-Protokoll vorhanden) und ihre Betriebssystemoberfläche ist Windows XP.

Beim Anlegen von Spannung an die Microbox fährt also eine ganz normale Windowsoberfläche hoch und die CPU lädt sich dann direkt nach Start...die Ein- und Ausgänge der CPU werden über eine ET200 Baugruppe dargestellt, die über Profibus angeschlossen ist.

Ich soll jetzt eine Verbindung zwischen dem SQL-Server und der S7-CPU herstellen, um Kenndaten zur Fertigung auszulesen, die LEIDER nicht mehr aus den Datenbausteinen der S7-CPU gelesen werden sollen, sondern zentral verwaltet werden sollen.

Habe noch nie etwas mit einem SQL-Server zu tun gehabt und weiß nicht, wie ich eine Kommunikation zwischen S7-CPU und dem SQL-Server aufbauen kann.

Um die S7-CPU mit der Windowsoberfläche kommunizieren zu lassen, muss ich den OPC-Server benutzen, oder? Könnt ihr mir Beispiele bzw. Links zu Beispielen aufzeigen, wie man eine solche Kommunikation (Austausch von Bytes?) herstellen kann.

Wie sieht dann die weiter Verbindung des OPC-Servers zum SQL-Server aus? Wie kann man sich das Vorstellen? Was braucht man alles für Software dafür und wie kann man das einstellen bzw. projektieren?

Bitte helft mir.

MfG Aurel

[Garog]

Schau mal hier da gab es schonmal so ein Thema

http://www.spsforum.com/showthread.php?t=11250

Ist eigentlich eine sehr einfache Geschichte das ganze

Wenn du Flexible dazwischen einsetzt habe ich da noch ein FAQ welches ich noch in den Lesezeichen hatte.
Da geht das ganze über ein Script.
FAQ 26283062

[Rainer Hönle]

Es braucht nicht zwingend einen OPC-Server, es genügt auch eine Kommunikationsbibliothek wie libnodave oder unser ACCON-AGLink. Es benötigt aber immer eine Applikation, die die Daten von der SPS liest und in eine SQL-Datenbank schreibt.
Um welchen SQL-Server handelt es sich? Wie ist die SQL-Datenbank aufgebaut? Wie sollen die Daten den einzelnen Feldern zugeordnet werden? Oder soll der DB als Binärhaufen archiviert werden? Wann und wie soll das abspeichern getriggert werden?

[JesperMP]

Das mit dem VBS Skript finde ich ein bisschen gefährlich.
Ich bin gerade zurück von ein Job in Japan, wo ich auch mit ein SQL Datenbank Daten austauschen musste.
Zuerst habe ich es mittels VBS gelöst. Es wahr sehr erfolgreich, ganze 99.99% stabil. Leider scheiterte das Skript jeder 10-20 Tage. Es gab Skript-überlauf fehler, ohne das es ordentliche fehlermeldungen erscheinte. Dies obwohl ich es mit das Err Objekt programmiert hatte.
Meine Kunde konnte dies nicht akzeptieren.

Letzendlich habe ich FactorySQL von www.inductiveautomation.com eingesetzt. Bis jetzt lauft es ohne Probleme.
Ich kann diese Produkt empfehlen. Es kostet 2000 USD für ein lizenz ohne Tags-einschränkungen.

[vierlagig]

Es braucht nicht zwingend einen OPC-Server, es genügt auch eine Kommunikationsbibliothek wie libnodave oder unser ACCON-AGLink. Es benötigt aber immer eine Applikation, die die Daten von der SPS liest und in eine SQL-Datenbank schreibt.
Um welchen SQL-Server handelt es sich? Wie ist die SQL-Datenbank aufgebaut? Wie sollen die Daten den einzelnen Feldern zugeordnet werden? Oder soll der DB als Binärhaufen archiviert werden? Wann und wie soll das abspeichern getriggert werden?

falsche richtung rainer. von der datenbank in die cpu und aglink läuft wohl nicht auf der cpu ... aber der trigger ist ein gutes stichwort - also eine anwendung mit z.b. aglink, die auf einen trigger von der cpu wartet und dann die daten aus der datenbank in die cpu schreibt ... direktes lesen mit der cpu aus irgendeiner applikation dürfte mangels kommunikationsbibliothek in der CPU wohl nicht zu realisieren sein - lass mich hier aber gern vom gegenteil überzeugen

[Rainer Hönle]

falsche richtung rainer. von der datenbank in die cpu und aglink läuft wohl nicht auf der cpu ... aber der trigger ist ein gutes stichwort - also eine anwendung mit z.b. aglink, die auf einen trigger von der cpu wartet und dann die daten aus der datenbank in die cpu schreibt ... direktes lesen mit der cpu aus irgendeiner applikation dürfte mangels kommunikationsbibliothek in der CPU wohl nicht zu realisieren sein - lass mich hier aber gern vom gegenteil überzeugen

Ob falsche Richtung weiss ich nicht. Es ist ein PC mit Windows XP vorhanden auf dem irgendein SQL-Server läuft. Die SPS (ich gehe von einer Soft-SPS aus) läuft ebenfalls auf diesem PC. Jetzt sollen produktionsrelevante Daten der SPS mit dem SQL-Server archiviert werden. Soweit jetzt einmal das, was ich vermute. Das Schreiben direkt aus der SPS in eine SQL-Datenbank ist nicht möglich. Was bleibt sonst noch? Eine reine TCP-Verbindung über die dann irgendwelche Daten geschickt werden die dann im SQL-Server landen. OK, auch hierfür benötige ich eine Applikation, denn von alleine wird das nichts. Somit kann ich doch gleich die Daten (oder zuerst einen Trigger) abfragen und dann archvieren. Diese Lösung ist gängig und oft im Einsatz. Wenn die SPS alles steuern soll, alos komplett ohne Polling, dann bietet ACCON-AGLink dafür BReceive an. Die SPS schickt die Daten mittels BSend und der PC kann diese dann verarbeiten, archvieren, ....
Aber die Erläuterung von aurel ist nicht ganz eindeutig. Deshalb auch meine Spekulationen.

Nachtrag nach nochmaligem Lesen: SPS fordert mittels BSend die gewünschten Daten an, der PC liest diese aus der Datenbank schreibt diese dann in die SPS (BSend, direktes Schreiben, ....)

[vierlagig]

Ob falsche Richtung weiss ich nicht. Es ist ein PC mit Windows XP vorhanden auf dem irgendein SQL-Server läuft. Die SPS (ich gehe von einer Soft-SPS aus) läuft ebenfalls auf diesem PC. Jetzt sollen produktionsrelevante Daten der SPS mit dem SQL-Server archiviert werden. Soweit jetzt einmal das, was ich vermute.

also ich verstehe es so, dass die rezeptdaten aus der datenbank in die steuerung sollen. keine archivierung - vielleicht könnte man es mit dearchivierung beschreiben.

der nachtrag trifft es da schon eher:

Nachtrag nach nochmaligem Lesen: SPS fordert mittels BSend die gewünschten Daten an, der PC liest diese aus der Datenbank schreibt diese dann in die SPS (BSend, direktes Schreiben, ....)