OPC vs. S7-Kommunikationstreiber

[Ludolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, ich hab folgendes Problem. Und zwar soll ich eine Anlagenvisualisierung in C#.net programmieren und muss damit auf eine S7 zugreifen können. Jetzt muss ich mich zwischen der Lösung mit einem OPC-Server und einer Bibliothek wie die von traeger, deltalogic etc. entscheiden. Welche Argumente sprechen für einen OPC-Server und welche für die Bibliothekslösung?
-z.B. wie sieht das aus mit der Geschwindigkeit?
-welche Lösung ist prinzipiell einfacher zu implementieren?
-gibt es bei der Bibliothekslösung auch Events und Alarme?
-wie ist das Variablenmanagement?
-usw.

 

[pvbrowser]

> Und zwar soll ich eine Anlagenvisualisierung in C#.net programmieren und > muss damit auf eine S7 zugreifen können.
Warum bei Adam und Eva neu anfangen ?
Du könntest z.B. unseren http://pvbrowser.org als Basis nehmen.

> Jetzt muss ich mich zwischen der Lösung mit einem OPC-Server und einer > Bibliothek wie die von traeger, deltalogic etc. entscheiden.

> z.B. wie sieht das aus mit der Geschwindigkeit?
OPC ist immer langsamer, weil der OPC Server auf seiner Seite über so eine Bibliothekslösung mit der SPS kommuniziert. OPC kommt also zusätzlich ins Spiel.

> welche Lösung ist prinzipiell einfacher zu implementieren?
Im Prinzip ähnlich.

> gibt es bei der Bibliothekslösung auch Events und Alarme?
Bei der Bibliothekslösung kannst Du SPS Variablen (Datenbausteine, I/O, ...) lesen bzw. schreiben.

> wie ist das Variablenmanagement?
Du musst die Variablen in Deinem SPS Projekt den Datenbausteinen zuordnen.

PS: Zur Kommunikation mit Siemens SPS solltest Du Dir die freie Lösung
http://libnodave.sourceforge.net/ ansehen. Dazu gibt es hier im Forum viele Beiträge.

 

[Gerhard Bäurle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, ich hab folgendes Problem. Und zwar soll ich eine Anlagenvisualisierung in C#.net programmieren und muss damit auf eine S7 zugreifen können. Jetzt muss ich mich zwischen der Lösung mit einem OPC-Server und einer Bibliothek wie die von traeger, deltalogic etc. entscheiden. Welche Argumente sprechen für einen OPC-Server und welche für die Bibliothekslösung?

Hallo,

proprietärer Gerätetreiber:

Wenn Du mit geräteabhängigen Treibern arbeitest,
musst Du das Kommunikationsprotokoll jedes einzelnen
Gerätes in Deine Applikation einbauen.

Für Siemens-Steuerungen gibt es die Protokolle in Form
Bibliotheken wie Prodave (Siemens), libnodave (Open
Source) oder comDrv, Aglink usw. von anderen Herstellern.

Nachteil: nicht universell, jedes neue Gerät benötigt
zusätzlichen Aufwand.

OPC:
OPC-Server dienen als einheitliche Schnitt-
stelle zunm Prozess und sind für verschiedenste
Hardware lieferbar. Man muss den nur Client einmal
selbst entwickeln, kommen weitere Geräte dazu, muss nur
der passenden OPC-Server installiert und parametriert
werden. OPC-Server werden normalerweise von den
Geräteherstellern angeboten, für die Siemens-SPSen
gibt es Alternativen von Inat, Softing und anderen.


Vorteil OPC:
universell einsetzbar unabhängig von der (SPS)-Hardware
Die OPC-Technologie hat auch den Vorteil, dass sie
in alle größeren Visualisierungssysteme enthalten
ist (als OPC-Client).

Nachteil OPC:
OPC-Technik ist eher aufwendig zu konfigurieren,
besonders wenn Client und Server auf verschiedenen
Rechnern laufen und man kann doch auch mal auf ein
Gerät treffen, für das es (noch) keinen OPC-server gibt.

Infos zu OPC allgemein:

http://de.wikipedia.org/wiki/OLE_for_Process_Control

http://www.opcfoundation.org/

 

[Ludolf]

Besten Dank für eure schnellen Antworten. Okay ich weiß jetzt das die Bibliotheksvariante schneller ist und das beide Möglichkeiten ungefähr gleich kompliziert sind. Aber wie sieht das mit den Alarms und Events aus. Ich weiß, dass ein OPC-Server solche Ereignisse ähnlich wie DataChanged auslöst -kann das eine Bibliothek auch??? Und wie manage ich die symbolischen Namen der Variablen bei der Bibliothekslösung?

 

[Gerhard Bäurle]

Besten Dank für eure schnellen Antworten. Okay ich weiß jetzt das die Bibliotheksvariante schneller ist ...

In der Theorie schon, je nach Implementierung das aber marginal.

Aber wie sieht das mit den Alarms und Events aus. Ich weiß, dass ein OPC-Server solche Ereignisse ähnlich wie DataChanged auslöst -kann das eine Bibliothek auch???

Alarm und Events ist eine OPC-Spezifikation, die m. W. nur die
Kommunikation zwischen OPC-Server und OPC-Client betrifft.

Mit einer Bibliothek müsstest Du das selbst realisieren.

Und wie manage ich die symbolischen Namen der Variablen bei der Bibliothekslösung?

Dazu können die OPC-Server teilweise die Daten aus dem Projektier-
ungswerkzeug lesen und deshalb mit den Symbolen arbeiten. Die
SPS selbst kennt ja (zumindest bei Siemens) die Symbole nicht.

Wenn Du mit einer Bibliothek die symbolisch auf Daten zugreifen
möchtest, benötigst Du in Deiner Applikation eine Symboltabelle
(woher auch immer), der Zugriff auf die SPS-Operanden erfolgt
(bei Siemens) immer über die absolute Adresse.

 

[Ludolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also für mich, als relativen Neuling auf diesem Gebiet, hört sich das alles relativ Pro OPC-Server an. Eine letzte Frage: Welche Vorteile besitzt denn dann überhaupt die Bibliothekslösung?

 

[Rainer Hönle]

Alarme (bausteinbezogene Meldungen) und Scans (symbolbezogene Meldungen), wie sie z.B. bei WinCC flexible o.ä. zum Einsatz kommen, sind in der Version 4.4 von ACCON-AGLink enthalten. Diese wird nächste Woche freigegeben.
Der Zugriff auf die Symbole und die Datenbausteinstrukturen eines STEP7-Projektes ist mit ACCON-AGLink ebenfalls möglich.
Zu ACCON-AGLink gehört ein .net-Wrapper und umfangreiche Beispielprogramme

ACCON-AGLink unterstützt dabei ohne Programmänderung
die S7-200, S7-1200, S7-300, S7-400, S7-400H über MPI, PPI, PROFIBUS, TCP/IP
die S5 über AS511 und TCP/IP
Geräte mit RK-512 bzw. 3964(R)-Protokoll
und demnächst auch CoDeSys-Steuerungen.

 

[Ludolf]

Und wo sind jetzt die Vorteile gegenüber OPC???

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wo sind jetzt die Vorteile gegenüber OPC???

U.a. dass dessen Nachteile (s.o.) nicht vorhanden sind ;-)

- Einarbeitung einfacher
- Bietet speziell bei der S7 wesentlich mehr Möglichkeiten als jeder OPC-Server (Alarm, Scan, Archivdaten, unterstützt projektierte Verbindungen für BSend/BReceive, Routing, ...)
- Zugriff auf die Sinumerik
- Wahrscheinlich schneller ;-)
- Keine DCOM-Konfiguration
- Unterstützt eine Vielzahl an Geräten, für die mehrere OPC-Server erforderlich wären

 

[Ludolf]

Okay, ich erweitere jetzt mal meine Aufgabenstellung. Und zwar soll meine Visualisierungssoftware, je nachdem auf welcher Anlage Sie gerade im Betrieb ist, in der Lage sein mit einer Soft-SPS von Beckhoff oder mit einer Siemens S7 zu kommunizieren. Wie stell ich das am besten an, so dass ich nicht den kompletten Code zweimal schreiben muss? Gibt es irgendwelche Treiber oder OPC-Server, die eine Kommunikation zu beiden Geräten mit der selben Syntax erlauben???

 

[Gerhard Bäurle]

Gibt es irgendwelche Treiber oder OPC-Server, die eine Kommunikation zu beiden Geräten mit der selben Syntax erlauben???

Entsprechend dem Sinn von OPC gibt es geräteabhängige OPC-Server
normalerweise vom Komponentenhersteller (also einen von/für Beckhoff
und einen von Siemens für S7).

Den Client, der mit allen OPC-Servern verbunden ist, schreibst Du selbst,
z. B. mit

http://www.dopc.kassl.de/dotnet.shtml

Zumindest für die S7 gibt es auch alternative Anbieter für den
OPC-Server, bei Beckhoff weiß ich das nicht.

 

[Ludolf]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sind die Schreib- /Lesebefehle etc. denn für alle OPC-Server dieselben?

 

[Gerhard Bäurle]

Sind die Schreib- /Lesebefehle etc. denn für alle OPC-Server dieselben?

Im Prinzip ja.

Mitte der 90er ist OPC gestartet, um sich als geräteunabhängige
Geräte-Schnittstelle zu etablieren - für einen einheitlichen Zugriff
auf Prozessdaten.

Siehe auch http://de.wikipedia.org/wiki/OLE_for_Process_Control

Hintergrund: Ohne standardisierte Schnittstelle müsste jede Visu-
software eine Unmenge von Treibern für verschiedenste Komponenten
haben.

Lösung: Jede Visualisierung bekommt einen OPC-Client und jede
Komponenten ihren OPC-Server. Der Datenaustausch erfolgt über
die standardisierte OPC-Schnittstelle.

Wenn Du Dich bei der Entwicklung Deines Clients also an den
Standard hälst, kannst Du auf jeden OPC-Server zugreifen (der
sich an den Standard hält, aber davon kann man ausgehen).

 

[Ludolf]

Lösung: Jede Visualisierung bekommt einen OPC-Client und jede
Komponenten ihren OPC-Server. Der Datenaustausch erfolgt über
die standardisierte OPC-Schnittstelle.

Ich versteh jetzt glaub ich was falsch. Ich dachte immer meine Visualisierung wäre mein OPC-Client, da diese ja Daten anfordert bzw. auch schreibt. Oder gibt es noch eine extra separate Softwarekomponente?:
SPS<=>OPC-Server<=>(OPC-Client<=>Visualisierung)

 

[Gerhard Bäurle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich versteh jetzt glaub ich was falsch. Ich dachte immer meine Visualisierung wäre mein OPC-Client, da diese ja Daten anfordert bzw. auch schreibt.

Es sind verschiedene Anwendung mit OPC-Client-Funktionalität vorstellbar:

• Bedienung/Visualisierung
• Protokollierung von Produktionsdaten
• Erfassung statistischer Daten
• Anbindung an ERP zwecks Auftragssteuerung

Visualisierung ist nicht die einzige Anwendungsmöglichkeit, wenn vielleicht auch
die Häufigste