# OPC vs. S7-Kommunikationstreiber



## Ludolf (2 März 2010)

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 (2 März 2010)

> 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 (2 März 2010)

Ludolf schrieb:


> 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 (2 März 2010)

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 (2 März 2010)

Ludolf schrieb:


> 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.



Ludolf schrieb:


> 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.



Ludolf schrieb:


> 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 (2 März 2010)

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 (2 März 2010)

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 (2 März 2010)

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


----------



## Rainer Hönle (3 März 2010)

Ludolf schrieb:


> 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 (3 März 2010)

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 (3 März 2010)

Ludolf schrieb:


> 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 (3 März 2010)

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


----------



## Gerhard Bäurle (3 März 2010)

Ludolf schrieb:


> 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äte*un*abhä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 (3 März 2010)

Gerhard Bäurle schrieb:


> 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 (3 März 2010)

Ludolf schrieb:


> 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


----------

