applikation zur kommunikation - cache.industry.siemens.com · opc-kommunikation über das...

Applikation zur Kommunikation

OPC-Kommunikation über das SEND/RECEIVE-Protokoll mit einem Visual Basic .NET OPC-Client

Erweiterung

Gewährleistung, Haftung und Support

OPC mit SEND/RECEIVE-Protokoll, Beitrags-ID: 21523291

V1.0 02.05.05 2/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Gewährleistung, Haftung und Support

Für die in diesem Dokument enthaltenen Informationen übernehmen wir keine Gewähr.

Unsere Haftung, gleich aus welchem Rechtsgrund, für durch die Verwen-dung der in diesem Dokument beschriebenen Beispiele, Hinweise, Pro-gramme, Projektierungs- und Leistungsdaten usw. verursachte Schäden ist ausgeschlossen, soweit nicht z.B. nach dem Produkthaftungsgesetz in Fäl-len des Vorsatzes, der grober Fahrlässigkeit, wegen der Verletzung des Lebens, des Körpers oder der Gesundheit, wegen einer Übernahme der Garantie für die Beschaffenheit einer Sache, wegen des arglistigen Ver-schweigens eines Mangels oder wegen Verletzung wesentlicher Vertrags-pflichten zwingend gehaftet wird. Der Schadensersatz wegen Verletzung wesentlicher Vertragspflichten ist jedoch auf den vertragstypischen, vorher-sehbaren Schaden begrenzt, soweit nicht Vorsatz oder grobe Fahrlässig-keit vorliegt oder wegen der Verletzung des Lebens, des Körpers oder der Gesundheit zwingend gehaftet wird. Eine Änderung der Beweislast zu Ih-rem Nachteil ist hiermit nicht verbunden.

Die Applikationsbeispiele sind unverbindlich und erheben keinen Anspruch auf Vollständigkeit hinsichtlich Konfiguration und Ausstattung sowie jegli-cher Eventualitäten. Sie stellen keine kundenspezifische Lösungen dar, sondern sollen lediglich Hilfestellung bieten bei typischen Aufgaben-stellungen. Sie sind für den sachgemäßen Betrieb der beschrieben Produk-te selbst verantwortlich. Diese Applikationsbeispiele entheben Sie nicht der Verpflichtung zu sicherem Umgang bei Anwendung, Installation, Betrieb und Wartung. Durch Nutzung dieses Applikationsbeispiels erkennen Sie an, dass Siemens über die oben beschriebene Haftungsregelung hinaus nicht für etwaige Schäden haftbar gemacht werden kann. Wir behalten uns das Recht vor, Änderungen an diesem Applikationsbeispiel jederzeit ohne Ankündigung durchzuführen. Bei Abweichungen zwischen den Vorschlä-gen in diesem Applikationsbeispiel und anderen Siemens Publikationen, wie z.B. Katalogen, hat der Inhalt der anderen Dokumentation Vorrang.

Copyright© 2005 Siemens A&D. Weitergabe oder Vervielfältigung die-ser Applikationsbeispiele oder Auszüge daraus sind nicht gestattet, soweit nicht ausdrücklich von Siemens A&D zugestanden. Bei Fragen zu diesem Beitrag wenden Sie sich bitte über folgende E-Mail-Adresse an uns:

mailto:[email protected]

mailto:[email protected]

Vorwort


V1.0 02.05.05 3/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Vorwort

Ziel der Applikation Diese Beispielapplikation behandelt den Einsatz des SEND/RECEIVE-Protokolls mit dem SIMATIC NET OPC-Server. Dabei erfolgt die Kom-munikation des OPC-Servers mit der Steuerung über die Block- und Vari-ablendienste des SEND/RECEIVE -Protokolls.

Es wird demonstriert, wie ein auf individuelle Bedürfnisse zugeschnittener OPC-Client in der Programmiersprache Visual Basic .NET programmiert wird. Auch wird die Projektierung der PC-Station zur Verwendung des SI-MATIC NET OPC-Servers mit dem SEND/RECEIVE-Protokoll und Industri-al Ethernet erläutert. Damit können strukturierte Daten über die OPC-Schnittstelle übertragen werden.

Kerninhalte dieser Applikation Folgende Kernpunkte werden in dieser Applikation behandelt:

• Programmtechnischer Umgang mit den Kommunikationsdiensten des SEND/RECEIVE-Protokolls:

– Blockdienste (AG_SEND / AG_RECEIVE)

– Variablen-Dienste (FETCH / WRITE)

um größere Datenmengen zwischen PC und gemischten Automatisie-rungssystemen (z.B. SIMATIC S5 und SIMATICT S7) austauschen zu können.

• Projektierung des SEND/RECEIVE-Protokolls bei Verwendung von In-dustrial Ethernet

• Erstellung eines OPC-Clients mit graphischer Oberfläche

• Demonstration des Umgangs mit der Data Access Schnittstelle des OPC-Servers über das Custom Interface und Einbindung in das .NET-Framework mit dem OPC DA RC-Wrapper

• Aufzeigen des Vorgehens zur Implementierung eines aufgesetzten Quittierungsmechanismus (aufgesetztes Ebene 7-Protokoll)

Vorwort


V1.0 02.05.05 4/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Aufbau des Dokuments Die Dokumentation der vorliegenden Applikation ist in drei Dokumente ge-gliedert:

• Einführung

• Erweiterung

• Demonstration Zusätzlich ist der STEP7-Code und der Visual Basic .NET-Code verfügbar.

Das erste, vorliegende Dokument, die Erweiterung, ist für Personen ge-dacht, die sich einen schnellen Überblick verschaffen wollen.

Teil Beschreibung Einführung Applikationsbeschreibung und Funktionsprinzipien

Hier erfahren Sie alles, um sich einen Überblick zu verschaffen. Sie lernen die verwendeten Kompo-nenten (Standard Hard- und Softwarekomponen-ten, sowie die eigens erstellte Anwender Software) kennen.

Erweiterung Funktionsprinzipien im Detail und Programm-strukturen

Hier wird auf die detaillierten Funktionsabläufe der beteiligten Hard- und Softwarekomponenten, die Lösungsstrukturen und wo sinnvoll auf die konkrete Implementierung dieser Applikation eingegangen. Sie benötigen diesen Teil, wenn Sie das Zusam-menspiel der Lösungskomponenten kennen lernen wollen, um diese z.B. als Basis für eigene Entwick-lungen zu verwenden.

Demonstration Aufbau, Projektierung und Bedienung der Applikation

Dieser Teil führt Sie Schritt für Schritt durch den Aufbau, wichtige Projektierungsschritte, Inbetrieb-nahme und Bedienung der Applikation.

Als weitere Komponente ist noch der S7-Programmcode verfügbar.

Teil Beschreibung

S7-Programmcode Der S7-Programmcode beinhaltet den Code und eine Bedienoberfläche, die auch als Vorführsystem geeignet ist.

Visual Basic .NET Code Beinhaltet die Programmdateien des OPC-Clients und das Visual Studio .NET Projekt.

Referenz zum Automation and Drives Service & Support Dieser Beitrag stammt aus dem Internet Applikationsportal des Automation and Drives Service & Support. Durch den folgenden Link gelangen Sie di-rekt zur Downloadseite dieses Dokuments.

http://support.automation.siemens.com/WW/view/de/21523291


Vorwort


V1.0 02.05.05 5/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Inhaltsverzeichnis

Inhaltsverzeichnis......................................................................................................... 5

Einleitung ...................................................................................................................... 7

1 vorliegendes Dokument ................................................................................. 7

Funktionsprinzipien und Programmstrukturen ......................................................... 8

2 Generelle Funktionsmechanismen ............................................................... 8 2.1 OPC DA Interface (OPC Data Access)............................................................. 8 2.1.1 Allgemein .......................................................................................................... 9 2.1.2 OPC-Server .................................................................................................... 10 2.1.3 OPC-Client...................................................................................................... 10 2.1.4 Die Rolle von Variablen .................................................................................. 11 2.1.5 Die Datenquelle Cache und Device................................................................ 12 2.1.6 Synchrone Lese- / Schreibaufträge ................................................................ 13 2.1.7 Asynchrone Lese- / Schreibaufträge .............................................................. 13 2.1.8 Variablen beobachten (DataChange-Mechanismus) ...................................... 14 2.1.9 Aktive und Passive Items................................................................................ 15 2.2 Prinzipielles Anwendungsmodell der OPC DA Schnittstelle in dieser

Applikation.................................................................................................. 16 2.3 Das Klassenmodell von OPC Data Access .................................................... 17 2.4 Kommunikationsformen zwischen OPC und SIMATIC NET........................... 19 2.4.1 Block- und Variablendienste ........................................................................... 19 2.4.2 Blockdienste ................................................................................................... 21 2.4.3 Abbildung von Datenpuffern auf OPC-Variablen ............................................ 22 2.4.4 Anwendung der blockorientierten Dienste ...................................................... 22 2.4.5 Variablendienste ............................................................................................. 23 2.5 Einbinden von COM Komponenten in die .NET-Umgebung........................... 25

3 Funktionsmechanismen dieser Applikation .............................................. 29 3.1 Datentransferdienste zwischen OPC-Client und Steuerung........................... 29 3.1.1 Variablendienste ............................................................................................. 29 3.1.2 Blockorientierte Dienste.................................................................................. 30 3.2 Identifikation und Verschaltung der Prozessvariablen.................................... 30 3.3 Ablauf- und Datenflussdiagramme dieser Applikation .................................... 34 3.3.1 Datenfluss zwischen Oberfläche und Steuerung............................................ 34 3.3.2 Gruppenzuordnung und Zustand der Items in der Applikation ....................... 35 3.4 Klassendiagramme der Applikation ................................................................ 37 3.4.1 Überblick......................................................................................................... 37 3.4.2 Die Klasse MainForm ..................................................................................... 38 3.4.3 Die Klasse BlockServices ............................................................................... 39 3.4.4 Die Klasse VariableServices........................................................................... 40 3.4.5 Fehlerhandling in der Applikation ................................................................... 40

Vorwort


V1.0 02.05.05 6/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

4 Erläuterungen zum OPC-Client ................................................................... 42 4.1 Strukturen im OPC-Client ............................................................................... 42 4.2 Anbindung an den OPC-Server ...................................................................... 43 4.3 Blockorientierte Dienste.................................................................................. 44 4.3.1 Grundlegende Variablen zur Anbindung an den OPC-Server ........................ 44 4.3.2 Anlegen von OPC-Gruppen............................................................................ 45 4.3.3 OPC-Items ...................................................................................................... 46 4.3.4 Callback Interface anmelden .......................................................................... 48 4.3.5 Daten von einer PLC mittels AG_SEND/AG_RECV empfangen.................... 49 4.3.6 Daten zu einer PLC mittels AG_SEND/AG_RECV senden............................ 52 4.4 Variablendienste ............................................................................................. 55 4.4.1 Beispiel: Synchron schreiben ......................................................................... 55 4.4.2 Beispiel: Asynchron lesen............................................................................... 56

5 Erläuterungen zum S7-Programm............................................................... 58 5.1 Grundstrukturen.............................................................................................. 58 5.2 Ablauf des Programms ................................................................................... 60 5.3 Aufruf der Send- / Receive - Bausteine (FC 5 / FC 6) .................................... 62 5.3.1 AG_SEND (FC 5) ........................................................................................... 62 5.3.2 AG_RECV (FC 6) ........................................................................................... 62

6 Modifikationen zum Beispielprogramm...................................................... 63 6.1 Veränderungen im STEP 7-Programm........................................................... 63 6.2 Veränderungen an der Visual Basic .NET Applikation.................................... 64

Anhang und Literaturhinweise .................................................................................. 65

7 Glossar (optional) ......................................................................................... 65

8 Literaturhinweise .......................................................................................... 67 8.1 Literaturangaben............................................................................................. 67 8.2 Internet-Link-Angaben .................................................................................... 67

Einleitung

vorliegendes Dokument

OPC mit SEND/RECEIVE-Protokoll, 21523291

V1.0 02.05.05 7/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Einleitung

1 vorliegendes Dokument

Dieses Dokument ist die Erweiterung des Dokumentes OPC-Kommunika-tion über das SEND/RECEIVE-Protokoll mit einem Visual Basic .NET OPC-Client – Einführung.

Die Einführung beschreibt den grundlegenden Aufbau der Applikation und sollte daher vor dem vorliegenden Dokument, der Erweiterung, gelesen werden.

In diesem Dokument finden Sie weiter- und tiefergehende Informationen zur Applikation als in der Einführung. Es ist aber kein Handbuchersatz.

Funktionsprinzipien und Programmstrukturen

Generelle Funktionsmechanismen


V1.0 02.05.05 8/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft


Inhalt Hier wird auf die detaillierten Funktionsabläufe der beteiligten Hard- und Softwarekomponenten, die Lösungsstrukturen und wo sinnvoll auf die kon-krete Implementierung dieser Applikation eingegangen.

2 Generelle Funktionsmechanismen

Hier erfahren Sie… welche generellen Funktionsmechanismen gelten. Hier wird in erster Linie auf OPC und die Funktionsmechanismen mit .NET eingegangen.

2.1 OPC DA Interface (OPC Data Access)

OPC spezifiziert verschiedene Dienste zum Zugriff auf Informationen am Fertigungsprozess wie Variablen, Alarme und Archivdaten. Die erste und zugleich wichtigste Spezifikation für den Variablenzugriff ist die OPC Data Access Interface Spezifikation. In dieser werden einheitliche und hersteller-unabhängige Dienste für Prozessanschlüsse definiert. Als Prozessan-schlüsse werden in diesem Zusammenhang Schnittstellen zu speicherpro-grammierbaren Steuerungen (SPS), Feldbussystemen oder anderer Hard-ware in der Feldebene der Automatisierungstechnik bezeichnet.

Übersicht Die folgende Abbildung soll verdeutlichen, dass eine Prozessarchitektur sehr komplex werden kann und bis in die Unternehmensleitebene verbun-den ist. Damit ist ersichtlich, dass einheitliche Schnittstellen bei der Vielzahl von Baugruppen in der Feldebene sinnvoll sind und Kosten sparen können.




V1.0 02.05.05 9/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Abbildung 2-1

2.1.1 Allgemein

Um eine möglichst große Unabhängigkeit zwischen der Prozessanbindung und der eigentlichen Anwendung zu erreichen, wird die Prozessanbindung durch eine eigenständige Anwendung realisiert, die als OPC-Server be-zeichnet wird. Eine Anwendung, die auf Daten eines solchen OPC-Servers zugreifen will, wird als OPC-Client bezeichnet.

OPC-Server und OPC-Clients können auf verschiedenen Rechnern ausge-führt werden. So kann der OPC-Server zum Beispiel auf einem Prozessleit-rechner bereitgestellt werden. Die Clients könnten zur Prozessvisualisie-rung dienen oder zur Erfassung der Prozessdaten in einer Büroapplikation wie zum Beispiel Microsoft Excel.

Die Kommunikation zwischen Server und Client erfolgt über Industrial Ethernet und die Prozess-Hardware ist über herstellerspezifische Treiber an den Server angebunden. Die Kommunikation zwischen OPC-Server und OPC-Clients wird über die Dienste von OLE abgewickelt.




V1.0 02.05.05 10/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Übersicht Abbildung 2-2

2.1.2 OPC-Server

Ein OPC-Server für den Datenzugriff (Data Access), bildet die Verbindung zwischen der OPC Schnittstelle und einer oder mehrerer Datenquellen.

Damit stellt er die zentrale Kommunikationseinheit zwischen einem OPC-Client und der jeweiligen Steuerung dar.

Die Anbindung des OPC-Servers an die jeweilige Steuerung erfolgt über die implementierten Kommunikationsprotokolle.

Der OPC-Server setzt typischerweise auf spezielle Treiber auf, welche die Schnittstelle zur Prozess-Hardware bilden. Der Server stellt den Applikatio-nen eine OPC-Schnittstelle zur Verfügung, die auf COM/DCOM-Mechanismen aufsetzt. Die Applikationen, die den Dienst des OPC-Servers nutzen, werden als OPC-Clients bezeichnet.

2.1.3 OPC-Client

Indem im Client COM-Referenzen auf die jeweiligen Schnittstellen erzeugt werden, wird dem OPC-Server mitgeteilt, dass ein Client Zugriff auf be-stimmte Variablen der projektierten Steuerung erwünscht.

Weitere über die Group(s)-Schnittstelle „IOPCGroupStateMgt“ verfügbare Schnittstellen erlauben lesende und schreibende Zugriffe auf diese Variab-len. Folgende Zugriffe sind dabei möglich:




V1.0 02.05.05 11/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

• Synchron lesen / schreiben

• Asynchron lesen / schreiben

• Beobachten von Variablen

Hinweis Synchrone Lese- bzw. Schreibaufträge blockieren die weitere Ausführung des OPC-Clients. Bei asynchronen Lese- bzw. Schreibaufträgen bleibt der OPC-Client be-dienbar („responsive“), d.h. der Auftrag wird im Hintergrund ausgeführt.

Für weitere Informationen sei hier auf die OPC-Spezifikation bzw. das OPC - Manual verwiesen. \3\

2.1.4 Die Rolle von Variablen

Variablen müssen, um Prozesswerte zu erhalten, bei den Aufrufen der OPC-Schnittstelle angegeben werden. Durch die Angabe von Variablen kann der Client beim Server die benötigten Werte anfordern. Der Client muss jede gewünschte Variable beim Server anmelden, um festzulegen, welche Werte wann gelesen werden sollen. Variablen können sowohl syn-chron als auch asynchron gelesen und geschrieben werden.

Der Client kann die Beobachtung von Variablen auf den Server übertragen. Wenn sich der Wert einer Variablen ändert, schickt der Server dem Client eine entsprechende Nachricht.

Aufteilung der Variablen Die vom OPC-Server angebotenen Variablen lassen sich unterteilen in: Tabelle 2-1

Variable Beschreibung

Prozessvariablen Repräsentieren Mess- und Steuergrößen in einen Pro-zess, z.B. den Status von Ein-/Ausgabegeräten

Steuervariablen Die Verwendung dieser Variablen löst bestimmte Zu-satzdienste aus, z.B. die Übertragung von Passwörtern.

Informationsvariablen Diese Variablen werden vom Kommunikationssystem bereitgestellt und geben Auskunft über den Zustand von Verbindungen, Geräten usw.

Beispiele für Variablen Hier einige Beispiele für Variablen eines OPC Data Access-Servers:

• Steuerungsgrößen einer speicherprogrammierbaren Steuerung

• Daten eines Messdatenerfassungssystems

• Statusvariablen des Kommunikationssystems




V1.0 02.05.05 12/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.1.5 Die Datenquelle Cache und Device

Unterscheidung Es erfolgt eine Unterscheidung beim Lesen oder Schreiben von Werten zwischen zwei Auftragsarten:

• Cache.

• Device.

Device Auf das Device lesen bzw. schreiben bedeutet, dass der entsprechenden Lese- bzw. Schreibauftrag direkt an die Steuerung/Hardware weitergeleitet wird. Der Leseauftrag wird in der Protokollebene verarbeitet. Erst nach der Abarbeitung dort oder einem Fehler kommt die Funktion zum Client zurück.

Cache Der Cache ist ein Speicherbereich in dem OPC-Server in dem die Daten in ihrer konvertierten Form als Variant abgelegt werden. Der Zugriff auf die-sen Speicher hat nicht unbedingt einen Auftrag an die SPS zur Folge. Das heißt, die Daten sind dann nicht unbedingt aktuell.

Übersicht Abbildung 2-3

Hinweis Synchrone und asynchrone Leseaufträge können sowohl vom Cache als auch vom Device ausgeführt werden. Schreibaufträge erfolgen immer zum Device.




V1.0 02.05.05 13/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.1.6 Synchrone Lese- / Schreibaufträge

Synchron bedeutet, dass der Client einen Lese- oder Schreibauftrag an den Server richtet und erst, wenn dieser Auftrag vollständig abgearbeitet wurde, kommt dieser mit einer Meldung zurück. Wird aus der Hardware ge-lesen, bedeutet dies für synchrone Aufträge, dass der Auftrag erst bei ei-nem erfolgreich abgewickelten Auftrag an die Steuerung oder bei einem Fehler zum Client zurückkommt. Dies kann bei langsamer Kommunikation zu erheblichen Verzögerungen beim Client führen.

Vor- und Nachteile von synchronem Zugriffen Tabelle 2-2

Vorteile Nachteile

• einfache Programmierung • hoher Datendurchsatz, da nur ein

Prozesswechsel pro Auftrag zwi-schen OPC-Client und OPC-Server stattfindet.

• Die Anwendung wird so lange un-terbrochen, bis der synchrone Auf-trag verarbeitet ist. Erst wenn alle Daten gelesen sind, kann die An-wendung fortsetzen. Wenn die Funktion nicht in einem eigenen Thread aufgerufen wird, wird z.B. die Benutzeroberfläche einer inter-aktiven Anwendung während des Funktionsaufrufs blockiert.

2.1.7 Asynchrone Lese- / Schreibaufträge

Allgemeines Wird eine asynchrone Kommunikation aufgebaut, dann übergibt der Client einen Verbindungspunkt an den OPC-Server. Über diesen Verbindungs-punkt kann der OPC-Server jetzt asynchron Nachrichten an den OPC-Client schicken.

Ein asynchroner Auftrag kehrt nach der Registrierung im Server zum Client zurück. Die Abwicklung erfolgt nur noch in dem OPC-Server. Ist der Auftrag beendet, dann erhält der Client über den Verbindungspunkt die Daten und Informationen über Erfolg oder Misserfolg des entsprechenden Auftrages.

Auf die bisher beschriebene Weise stellt der OPC-Client jedes Mal eine An-frage an den OPC-Server, um den Wert einer Prozessvariablen zu erfah-ren.




V1.0 02.05.05 14/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Vor- und Nachteile von asynchronem Zugriffen Tabelle 2-3

Vorteile Nachteile

• die eigene Anwendung wird nur kurz unterbrochen, weil die eigent-liche Kommunikation parallel zu der Anwendung läuft.

• die Erstellung der Anwendung ist etwas komplexer. In der Anwen-dung muss ein Rückrufmechanis-mus implementiert sein, der zu je-dem Zeitpunkt das Ergebnis der Auftragsbearbeitung entgegen-nehmen kann. Windows-Programme verfügen standardmä-ßig über asynchrone Mechanis-men, damit sie auf Eingaben des Anwenders reagieren können.

• bei der Übergabe weniger Variab-len in einem Auftrag fällt eine grö-ßere Belastung durch die Prozess-übergänge beim Aufruf und beim Rückruf an. Es sind doppelt so vie-le wie bei synchronen Zugriffen.

Hinweis Um den OPC-Client während Lese-/Schreiboperationen bedienbar zu halten, muss die asynchrone Methode genutzt werden!!!

Synchrone Aufrufe blockieren den OPC-Client, was häufig dazu führt, dass der Anwender kein Feedback vom OPC-Client erhält und somit glaubt, der OPC-Client sei abgestürzt.

2.1.8 Variablen beobachten (DataChange-Mechanismus)

Beim Beobachten von Variablen prüft der OPC-Server fortlaufend, ob sich der Wert oder die Qualität von Variablen geändert hat.

Zu diesem Zweck fügt OPC-Client aktive OPC-Items einer Gruppe hinzu und aktiviert die Gruppe. Es werden dann alle aktiven OPC-Items in allen aktiven Gruppen beobachtet.

Hierzu stellt der OPC-Client die Funktion DataChange bereit. Der OPC-Server ruft diese Funktion auf, wenn eine Änderung der Werte stattgefun-den hat. Der OPC-Server übergibt dabei als Parameter von DataChange die geänderten Werte, Qualitäten und Zeitstempel der OPC-Items.

Der OPC-Client wird durch die Beobachtung der Variablen nicht belastet. Erst wenn eine Änderung erkannt wird, wird das Programm des Clients ausgeführt.

Damit der OPC-Client bei sich schnell ändernden Prozessvariablen nicht mit Änderungsmeldungen überlastet wird, können Sie über den gruppen-spezifischen Parameter UpdateRate vorgeben, mit welcher minimalen Rate er aufgerufen werden soll. (Siehe Abbildung 2-3).




V1.0 02.05.05 15/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Anwendungsbereich von Variablen beobachten Das Beobachten von Variablen ist die optimale Lösung, wenn ein Pro-gramm stets einen aktuellen Datenbestand des Prozesses oder eines Teils des Prozesses benötigt.

Hinweis Der Datendurchsatz wird bestimmt durch den Parameter UpdateRate der Gruppe und der in der Projektierung festgelegten Zykluszeit. Die Zyklus-zeit bestimmt die kleinstmögliche Aktualisierungsrate. Die Aktualisie-rungsrate sollte in ganzen Vielfachen der Zykluszeit angegeben werden.

Vor- und Nachteile vom Beobachten von Variablen Tabelle 2-4

Vorteile Nachteile

• die Anwendung wird nur benach-richtigt, wenn sich die Prozessda-ten geändert haben

• hoher Datendurchsatz, weil wenig Prozesswechsel stattfinden. Je nach Zusammensetzung der Item-Struktur ist eine gute Optimierung möglich.

• die Beobachtung der Variablen kann Item- und gruppenweise durch den Client ein- und ausge-schaltet werden

• die Reaktionszeit von der Ände-rung eines Wertes im Prozess bis zur Übergabe des neuen Wertes an den Client ist größer als die Ak-tualisierungsrate der Gruppe

• die Erstellung der Anwendung ist etwas komplexer, da die Anwen-dung einen asynchronen Teil zum Empfang von Werteänderungen benötigt. Windows-Programme verfügen standardmäßig über a-synchrone Mechanismen, damit sie auf Eingaben des Anwenders rea-gieren können

2.1.9 Aktive und Passive Items

Es ist möglich Gruppen oder Items aktiv oder passiv anzulegen.

Bei aktive Variablen wird der Cache des OPC-Servers aktualisiert. Es findet eine ständige Kommunikation mit dem Prozess statt. Diese Einstellung ist für das Empfangen von Callbacks für das entsprechende Item nötig.

Bei passiven Variablen ist nur eine Kommunikation vom Device möglich. Der Cache wird nicht aktualisiert. Sollen nur einzelne Variablen gezielt ab-gefragt werden, so ist es besser diese Items passiv anzulegen, da der Pro-zess nicht ständig abgefragt wird.




V1.0 02.05.05 16/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.2 Prinzipielles Anwendungsmodell der OPC DA Schnittstelle in dieser Applikation

Es wird nun kurz auf das Anwendungsmodell der OPC DA Schnittstelle eingegangen. Eine ausführliche Beschreibung des Objektmodells finden Sie in der OPC DA Spezifikation. Abbildung 2-4




V1.0 02.05.05 17/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.3 Das Klassenmodell von OPC Data Access

Allgemeines Das hierarchische Klassenmodell von Data Access hilft, beim Datenzugriff durch den Client, Zeitaufwand und inhaltliches Ergebnis den aktuellen An-forderungen einer Applikation anzupassen. Data Access unterscheidet drei Klassen:

• OPC-Server

• OPC-Group

• OPC-Item

Übersicht Nachfolgende Abbildung verdeutlicht die hierarchische Struktur des Klas-senmodells.

Nur zur Erzeugung eines Objekts der Klasse OPC-Server verwendet die Client-Applikation COM-Aufrufe des Betriebssystems. Die anderen Objekte werden durch entsprechende OPC-Methoden der Klasse OPC-Server oder untergeordneten Klassen erzeugt. Abbildung 2-5

Klasse OPC-Server An oberster Stelle steht die Klasse OPC-Server. Jeder OPC-Server gehört dieser Klasse an. Diese Klasse stellt den Zugangspunkt für alle weiteren Dienste des OPC Data Access Servers dar. Mit Hilfe klassenspezifischer Attribute und Methoden können Sie Informationen über Status, Version und (optional) den Namensraum der verfügbaren Prozessvariablen erhalten. Ein Objekt der Klasse OPC-Server verwaltet die Instanzen der untergeord-neten Klasse OPC-Group.




V1.0 02.05.05 18/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Klasse OPC-Group Mit der Klasse OPC-Group ist eine Einordnung und Strukturierung der vom OPC-Server genutzten Prozessvariablen möglich, da die Klasse OPC-Server Methoden besitzt mit denen ein Client Gruppenobjekte (Klasse OPC-Group) verwalten kann. Ein OPC-Client kann mehrere Objekte dieser Klasse gleichzeitig benutzen.

Mit Hilfe der Objekte von OPC-Group kann ein Client sinnvolle Einheiten von Prozessvariablen, die in OPC-Items gekapselt werden, bilden und mit diesen Operationen ausführen. So können beispielsweise alle Prozessvari-ablen einer Bildschirmseite eines Bedien- und Beobachtungssystems in ei-ner Gruppe zusammengefasst werden.

Die Klasse OPC-Group definiert Methoden, über die die Werte der Pro-zessvariablen gelesen und geschrieben werden können. Bei einigen Me-thoden können mehrere Variablen in einem Auftrag zusammengefasst und gleichzeitig übergeben werden. Man spricht von Mengenoperationen, da durch einen Aufruf einer Methode mehrere Objekte manipuliert werden können. Insbesondere bei der Benutzung eines OPC-Servers über das Netz ermöglichen diese Mengenoperationen eine hohe Ausführungsge-schwindigkeit, da durch sie die Anzahl der Prozesswechsel, die bei Aufruf von Methoden einer Softwarekomponente erfolgen, gering gehalten wer-den.

Klasse OPC-Item Objekte dieser Klasse repräsentieren die eigentlichen Prozessvariablen und ermöglichen gezielte Abfrage einzelner Daten. Prozessvariablen wer-den durch ein Element (Item) im Namensraum des OPC-Servers identifi-ziert und durch eine Item-ID gekennzeichnet. Hierbei ist eine 1-1, 1-n oder n-1-Beziehung zwischen Prozessvariablen und OPC-Item möglich. Die I-tem-ID wird vom Hersteller des Servers festgelegt und muss innerhalb des Namensraums des Servers eindeutig sein. Mit jedem Item sind folgende Eigenschaften verbunden: Tabelle 2-5

Eigenschaft Beschreibung

Wert Zuletzt erfasster Wert der Variable. Qualität Aussagekraft der Wertes. Wenn die Qualität gut ist, konnte der

Wert sicher ermittelt werden. Zeitstempel Zeitpunkt, an dem der aktuelle Wert der Variablen erstmalig

ermittelt wurde. Mit jeder zum Client gemeldeten Wertänderung wird auch der Zeitstempel aktualisiert. Ändert sich der Wert einer Variablen nicht, bleibt auch der Zeitstempel gleich.




V1.0 02.05.05 19/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Item-IDs Die Item-ID ist eine Zeichenfolge, die eine Prozessvariable eindeutig identi-fiziert. Sie gibt dem Server an, welche Prozessvariable dem OPC-Item zu-geordnet wird. Über das OPC-Item kann dann auf die Prozessvariable zu-gegriffen werden. Der OPC-Server von SIMATIC NET bildet die verschie-denen Kommunikationsdienste der Protokolle über OPC-Items ab, indem er Teile der Item-ID als Parameter für den Aufruf einer Kommunikationsfunkti-on verwendet.

Für den OPC-Server von Simatic NET gilt folgende Syntax für die Item IDs:

<Protokoll-ID>:[<Verbindungsbezeichnung>]<Variablenname> Tabelle 2-6

Parameter Beschreibung

Protokoll-ID Legt fest, welches Protokoll zu benutzen ist. Verbindungsbezeichnung Name der projektierten Verbindung, über die das

Gerät erreicht werden kann. Variablenname Bestimmt schließlich die zu benutzende Variable

des Geräts.

2.4 Kommunikationsformen zwischen OPC und SIMATIC NET

2.4.1 Block- und Variablendienste

Über die im OPC-Server projektierten Verbindungen (mit NetPro erstellt) werden mit Hilfe der jeweiligen Protokollbausteine die Werte der Variablen ausgelesen.

Hierbei ist zu beachten, dass es sich bei den Protokollbausteinen nicht um eine normierte Schnittstelle handelt, sondern um proprietäre Protokolle, die für die jeweils darunter liegende Steuerung implementiert sind.

Das Auslesen und Aktualisieren der Variablen kann auf zwei verschiedene Arten durchgeführt werden:




V1.0 02.05.05 20/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Über Variablendienste Tabelle 2-7

Abbildung Beschreibung Bei Variablendiensten werden die zu beobachten-den Variablen zyklisch vom OPC-Server abge-fragt. Der OPC-Server aktualisiert also aktiv die zu beobachtenden Prozessvariablen.

Über Blockdienste Tabelle 2-8

Abbildung Beschreibung Von Blockdiensten spricht man, wenn die zu beo-bachtenden Variablen programmgesteuert mittels größerer Datenblöcke zum OPC-Server übertra-gen werden. Dabei stößt das Steuerungsprogramm über Kom-munikationsbausteine die Übertragung der Vari-ablen an. Hier ist also die Steuerung der aktive Partner.




V1.0 02.05.05 21/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Hinweis In dieser Applikation werden beide Dienste vorgestellt. Blockdienste soll-ten für große Datenmengen verwendet werden. Variablendienste für Ein-zelabfragen.

Einen Vergleich zwischen Variablen- und Blockdiensten findet sich im Einführungs-Dokument dieser Applikation.

Unterstützte Dienste Bei blockorientierten Diensten werden die Inhalte eines Datenpuffers von einem Sender über das Kommunikationssystem an einen Empfänger ge-sendet.

Folgende Protokolle unterstützen blockorientierte Dienste:

• S7-Kommunikation (BSEND/BRCV)

• S5-Kompatible Kommunikation über Ethernet (SEND/RECEIVE)

• S5-Kompatible Kommunikation über PROFIBUS (SDA, SDN/Indication)

Hinweis Kennzeichnend für die blockorientierten Dienste ist, dass nur dann Daten übertragen werden, wenn der Sender den Übertragungsvorgang anstößt. Der Empfänger kann die Kommunikation nicht auslösen.

2.4.2 Blockdienste

Aktionen vom Sender beim Austausch von Datenpuffern • Stellt einen Sendepuffer mit den Inhalten zusammen.

• Sendet den Puffer auf einer Verbindung an einen Kommunikationspart-ner.

• Bekommt eine Quittung über das Ergebnis der Datenübertragung.

Aktionen vom Empfänger beim Austausch von Datenpuffern • Stellt einen Empfangspuffer für eine Verbindung bereit.

• Wird benachrichtigt, wenn ein Partner ihm ein Datenpuffer zusendet.

• Wertet die empfangen Daten aus.

Auswahlkriterien für Wahl des Kommunikationsdienstes Tabelle 2-9

Kriterium AG_SEND BSEND

S5-kompatible Kommunikation + + S7 Kommunikation - + Implizite Quittung - +




V1.0 02.05.05 22/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.4.3 Abbildung von Datenpuffern auf OPC-Variablen

Die OPC Data Access Schnittstelle kennt nur Prozessvariablen. Damit die Vorteile der blockorientierten Dienste auch mit OPC genutzt werden kön-nen, muss eine Abbildung auf OPC-Items erfolgen.

Unterschiede zwischen Sende- und Empfang-Items:

Sende-Item S7-Kommunikation: „BSEND“, S5-kompatible Kommunikation: „SEND“

• Ein OPC-Item repräsentiert einen Sendepuffer oder einen Teilbereich eines Sendepuffers.

• Wenn das OPC-Item geschrieben wird (synchron/asynchron), wird ein Schreibauftrag auf dem Netz ausgelöst.

• Werden mehrere Items, die einen Teilbereich eines Puffers repräsentie-ren, in einer Mengenoperation auf einmal geschrieben, so wird erst der gesamte Sendepuffer aus allen Teilbereichen gebildet und dann ge-sendet.

• Der Lesezugriff liefert die zuletzt gesendeten Daten aus dem Sendepuf-fer. Wurde noch nicht gesendet, ist das Item unter den genannten Um-ständen lesbar, hat aber die Qualität „BAD“.

Empfangs-Item S7-Kommunikation: „BRCV“, S5-kompatible Kommunikation: „RECEIVE“.

• Ein OPC-Item repräsentiert einen Empfangspuffer.

• Wenn das OPC-Item vom Gerät gelesen wird (synchron/asynchron), wird die Baugruppe empfangsbereit. Dieser Zustand bleibt so lange be-stehen, bis ein Datenpaket empfangen wurde oder der verbindungs-spezifische Timeout abgelaufen ist. Wenn kein Datenpaket während der Timeout-Zeit empfangen wurde, ist die Qualität des OPC-Items „BAD“.

• Wenn das OPC-Item beobachtet wird (Aktives Empfangs-Item in aktiver Gruppe), wird dauerhaft ein Empfangspuffer in der Kommunikations-baugruppe eingerichtet. Wird ein Datenpaket empfangen, so signalisiert der OnDataChange-Rückruf dies der Applikation - sofern sich die Daten von den zuvor empfangenen Daten unterscheiden.

2.4.4 Anwendung der blockorientierten Dienste

Handhabung von Sende- und Empfangs-Items:

Sende-Items Diese sollten nur beschrieben werden, das Lesen oder Beobachten der Sende-Items liefert nur die zuvor geschriebenen Daten.




V1.0 02.05.05 23/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Empfangs-Items Diese sollten beobachtet werden, d. h. das Empfangs-Item sollte als akti-ves Item in einer aktiven Gruppe vorhanden sein. Damit wird - unabhängig von der Implementierung einer Rückruf-Funktion - der Cache des OPC-Servers mit jedem Eintreffen eines Datenpakets aktualisiert.

Vorteile / Nachteile bei der Kommunikation mit den Blockdiensten des SEND/RECEIVE-Protokolls

Tabelle 2-10

Vorteile Nachteile

• Mit dem OPC-Server können grö-ßere Datenblöcke bis 64 Kbyte ü-bertragen werden.

• Keine Netzlast, da keine Daten-übertragung, wenn dies nicht vom Anwenderprogramm angestoßen wird (kein Polling).

• Bei Verwendung des OPC-Servers ist ein strukturierter Zugriff auf Da-tenblöcke möglich.

• Kommunikation mit S5- und S7-Geräten sowie PCs möglich.

• Empfänger kann die Datenübertra-gung nicht anstoßen. Er muss auf die Übermittlung von Daten durch den Sender warten.

• Die Daten müssen in einem Puffer liegen oder durch ein Anwender-programm im Partnergerät in einen Puffer kopiert werde

2.4.5 Variablendienste

Über die S5-kompatible Kommunikation auf Industrial Ethernet kann in ein-facher, symbolischer Weise auf Variablen eines S5- oder S7-Automatisierungssystems zugegriffen werden. Dazu werden die Dienste ”FETCH” und ”WRITE verwendet.

Bei Ausführung des Dienstes ”FETCH” wird ein Auftrag zum Partnergerät übermittelt, welcher als Quellparameter eine Angabe der geforderten Vari-ablen enthält. Der Empfänger des Auftrags wertet den Quellparameter aus und gibt mit der Bestätigung des Auftrags den aktuellen Inhalt der angefor-derten Variable zurück.

Mit einem Auftrag für den Dienst ”WRITE” wird neben dem Quellparameter auch der Wert übermittelt, den die Variable im Zielgerät annehmen soll. Der Empfänger wertet den Quellparameter aus und setzt die angegebene Vari-able entsprechend. Dann wird die Auftragsbestätigung zurückgesendet.

Variablen sind üblicherweise Ausschnitte eines S7- oder S5-Objekts ab ei-ner bestimmten Speicheradresse des Objekts, denen ein bestimmter Da-tentyp zugeordnet wird. Beispielsweise greift die Variable mit der Notation ”DB 5,B10” auf das Byte 10 des Datenbausteins 5 zu und stellt den Inhalt als Wort dar. Die Bildung von Feldvariablen - mehrere Elemente gleichen Typs in einer Variablen - ist ebenfalls möglich.




V1.0 02.05.05 24/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Als Objekte sind auf den meisten S5- und S7-Geräten verfügbar: • Datenbausteine

• Ein- /Ausgänge

• Peripherieein- und -ausgänge

• Merker

• Timer

• Zähler

• Systembereich

• Erweiterte Peripherie

Vorteile / Nachteile bei der Kommunikation mit den Variablendiensten Tabelle 2-11

Vorteile Nachteile

• Flexibler Zugriff • Automatische Optimierung durch

den OPC-Server möglich

• Geringer Datendurchsatz im Ver-gleich zu Blockdiensten bei SEND/RECEIVE.

• Zur Beobachtung von Variablen-änderungen muss zyklisch auf das Partnergerät zugegriffen werden.




V1.0 02.05.05 25/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

2.5 Einbinden von COM Komponenten in die .NET-Umgebung

Da COM Komponenten aus der Zeit vor dem .NET-Framework stammen, sind Anpassungen nötig um diese in .NET-Anwendung einbinden und nut-zen zu können.

Übersicht Nutzung einer COM Komponente in einer .NET-Anwendung/Komponente: Abbildung 2-6

WIN32 API

unm

anag

ed

Common Language RuntimeIL Intermediate Language

Base Classes WinForms WEBForms

VS.N

ET VB VC++ C# JScript …andere

CO

M-

Kom

ponente, z.B

. OP

C-Server

RCW-Wrapper

RCW und der Zusammenhang zur COM Komponente Damit eine für die bisherige Windows-Welt erstellte COM Komponente in eine .NET-Anwendung eingebaut werden kann, muss ein „Wrapper“, eine Art Hülle, erstellt werden, die alle Schnittstellendefinitionen für die .NET-Anwendung kapselt.

Dies ist notwendig, da die bisherigen Schnittstellendefinitionen, die sich in so genannten IDL-Dateien befinden, von .NET nicht mehr unterstützt wer-den. Dieser Wrapper wird auch als Runtime Callable Wrapper (RCW) be-zeichnet.

Bei COM Komponenten, die das Automation Interface anbieten, kann das Visual Studio diese Wrapper automatisch erstellen.

Für COM Komponenten, die das Custom-Interface zur Verfügung stellen, müssen solche Wrapper jedoch manuell erstellt werden.

Hinweis Die Unterschiede zwischen Automation und Custom Interface werden hier nicht weiter vertieft.




V1.0 02.05.05 26/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Speichermanagement bei Nutzung von COM Komponenten Da das Speichermanagement bei .NET-Anwendungen vom Garbage -Collector übernommen wird, COM Komponenten jedoch ein explizites Speichermanagement verlangen, muss hier auf folgende Dinge geachtet werden:

• Datenaustausch von .NET zu COM

• Datenaustausch von COM zu .NET

Datenaustausch von .NET zu COM In .NET sind alle Variablen Objekte. Da COM-Server im Allgemeinen nicht synchron mit den COM-Clients (in diesem ein .NET-RCW) laufen, sollten Übergabewerte vom Zugriff des Garbage Collectors geschützt werden („anpinnen“ von Objekten).

Datenaustausch von COM zu .NET COM Komponenten liefern Rückgabewerte in Form von COM-Zeigern. Da es im "managed code" von .NET-Clients keine solchen Pointer gibt, müs-sen die Rückgabewerte zunächst in .NET-Objekte gespeichert werden. Dies geschieht über den .NET-Datentyp „IntPtr“ und Methoden / Objekten der „System.Marshal“-Klassen.

RCW und OPC OPC-Komponenten bieten aufgrund der OPC-Spezifikation ein Custom In-terface an; für performante Anwendungen muss ein RCW manuell erstellt werden. Für den SIMATIC NET OPC-Server wird für die Data Access -Schnittstelle V2.05 ein RC Wrapper mitgeliefert, der nur noch in das jeweilige Visual Studio-Projekt integriert werden muss.

Wird hingegen das Automation Interface von OPC mit .NET genutzt, so wird der RCW automatisch vom Visual Studio .NET erstellt, sobald ein Verweis auf die OPC-Automation Schnittstelle in das .NET-Projekt einge-fügt wird. Durch die dadurch entstehende doppelte Kapselung des OPC Custom Interfaces, ist allerdings ein Leistungsabfall in Kauf zu nehmen.

Hinweis Diese Applikation behandelt die Nutzung des Custom Interfaces, da eine performante Anbindung im Focus der Anwendung steht.

Hinweis Der umgekehrte Anwendungsfall - die Nutzung einer .NET-Komponente

als COM Komponente - ist mit Hilfe eines COM Callable Wrappers (CCW) möglich. Im Rahmen dieses Dokuments wird jedoch nicht näher darauf eingegangen, da es zum Verständnis der Applikation nicht nötig ist.




V1.0 02.05.05 27/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Integration der SIMATIC NET OPC DA Schnittstelle in Visual Studio .NET Folgende Vorraussetzungen müssen erfüllt sein:

• SIMATIC NET V6.2 ist installiert

• Visual Studio .NET ist mit einer .NET-Windows-Anwendung gestartet

Einbau des .NET RCW Damit Sie auf die OPC DA Schnittstelle und die Funktionen der Datenkon-vertierungsbibliothek zugreifen können, müssen Sie in das Projekt eine Re-ferenz auf den OPC DA RCW und die DataConversion.dll erstellen.

Hinweis Die Notwendigkeit eines RCW und was man sich darunter vorstellen kann, ist in Kap. 0 erklärt.

Tabelle 2-12

Nr. Aktion Anmerkung 1 Klicken Sie im Projekt auf Verweis hin-

zufügen...

2 Klicken Sie im folgenden Dialog auf

Durchsuchen und wählen Sie die Dateien OpcRcw.Comn.dll, OpcRcw.Da.dll und DataConversion.dll aus, die sich in Ihrem Projektverzeichnis befinden soll-ten. Bestätigen Sie mit Öffnen und anschlie-ßend mit OK. Hinweis Die Dateien OpcRcw.Comn.dll und OpcRcw.Da.dll sind Bestandteil der SIMATIC NET Software und auch zu finden unter: <LW>:\...\Siemens\SIMATIC.NET\opc2\bin




V1.0 02.05.05 28/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3 Die RCW sowie die DataConversion-Bibliothek erscheinen nun unter den Ver-weisen und können in Ihrem .NET-Projekt genutzt werden.

Wie die jeweiligen OPC DA Schnittstellen nun genutzt werden müssen, er-fahren Sie in Kap. 4.


Funktionsmechanismen dieser Applikation


V1.0 02.05.05 29/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3 Funktionsmechanismen dieser Applikation

Hier erfahren Sie ... wie die Klassen im OPC-Client zusammenarbeiten und welche Aufgaben die wichtigsten Komponenten erfüllen sowie die Umsetzung der block- und variablen- orientierten Kommunikation.

Zunächst wird die logische Datenverbindung zwischen Steuerung und OPC-Client beschrieben. Hierbei werden die korrespondierenden Daten-strukturen in der Steuerung und im OPC-Client aufgeführt. Danach erfah-ren Sie mehr über den Datenfluss in der Applikation anhand von Daten-flussdiagrammen. Außerdem wird Ihnen hier die Struktur des OPC-Clients mit Hilfe von Klassendiagrammen erläutert.

3.1 Datentransferdienste zwischen OPC-Client und Steuerung

3.1.1 Variablendienste

Variablendienste ermöglichen den direkten Zugriff auf und die Beobachtung von Variablen im Automatisierungsgerät. Die Adressierung der Variablen erfolgt symbolisch. Zum direkten Lesezugriff auf Variablen überträgt der OPC-Server die gewünschte Adressinformation an die SPS und diese sen-det daraufhin die angeforderten Daten zurück. Bei einem Schreibzugriff ü-berträgt der OPC-Server die Adressinformation zusammen mit dem zu schreibenden Wert an das Partnergerät (SPS).

Syntax der Prozessvariablen für SEND/RECEIVE-Variablendienste SR:[<Verbindungsname>]<Bereich>{,}<Typ><Adresse>{,<Anzahl>}

Beispielhaft wird hier die Deklaration zweier Visual Basic .NET-Variablen genannt, die für den Write-Auftrag verwendet werden. Über die deklarierte Konstante wird auf die Prozessvariable verwiesen. SR steht als fester Aus-druck für das SEND/RECEIVE-Protokoll. In eckigen Klammern dahinter be-findet sich der Name der projektierten Verbindung. Dahinter wird jeweils auf ein Merkerbyte verwiesen, welches das Datenobjekt ist, das angesprochen werden soll.

Private Const m_RecvDoSendItemName As String = "SR:[Write]MB1,1"; Private Const m_RecvAckItemName As String = "SR:[Write]MB2,1";




V1.0 02.05.05 30/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3.1.2 Blockorientierte Dienste

Die blockorientierten Dienste ermöglichen eine programmgesteuerte Über-tragung größerer Datenblöcke. Diese Dienste werden auch als SEND/RECEIVE-Dienste bezeichnet. Die Übertragung mit dem OPC-Server wird durch Variablen realisiert:

• Variablen, die Datenblöcke empfangen.

• Variablen, die Datenblöcke senden.

Fest definierte Variablennamen Folgende Variablennamen sind für jede Verbindung fest definiert:

• RECEIVE

• SEND

Syntax der Prozessvariablen für blockorientierte Dienste Es gibt folgende Möglichkeiten:

SR:[<Verbindungsname>]receive{,<Typ><Adresse>{,<Anzahl>}} SR:[<Verbindungsname>]send{<n>}{,<Typ><Adresse>{,<Anzahl>}}

Beispielhaft wird nachfolgend die Deklarierung einer Variablen im Visual Basic .NET-Programm gezeigt, die Datenblöcke empfangen kann (receive). Es handelt sich um eine Byte-Adressierung.

Private Const m_SendAckItemName As String = SR:[PC=>S7]receive,B0,12";

3.2 Identifikation und Verschaltung der Prozessvariablen

Möchte ein Anwender einen OPC-Client selbst implementieren, so ist es unentbehrlich zu verstehen, wie Prozessvariablen bei OPC identifiziert werden. Weiterhin wird erklärt, wie die Variablen in der Beispielapplikation verschaltet sind.

Bedeutung von OPC-Server- und Client-Handles Damit die angelegten OPC-Items und OPC-Gruppen eineindeutig identifi-ziert werden können, muss jeder OPC-Client so genannte Handles verwal-ten (z.B. in Form von Membervariablen oder -arrays).

Dabei wird zwischen Client- und Server-Handles unterschieden. Dies ist notwendig, um auch bei mehreren OPC-Clients eine eindeutige Zuordnung zu erhalten (zwei OPC-Clients könnten identische Client-Handles besitzen). Dabei ist für den OPC-Client wichtig, wie er Daten beim OPC-Server anfor-dern will.




V1.0 02.05.05 31/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Client-Handles • werden vom OPC-Client beim Anlegen übergeben.

• dienen zur späteren Identifikation von OPC-Gruppen und -Items, falls die Aufrufrichtung OPC-Server OPC-Client ist (bei Callbacks nötig).

• sind nötig, wenn der OPC-Client sich für einen Callback am OPC-Server angemeldet hat. Dies bedeutet, dass er bei Wertänderung eines Items in einer Callbackfunktion benachrichtigt wird. In dieser Funktion kann er, anhand des Client-Handles, das zugehörige Item identifizieren.

Verwendung von Client-Handles in der Applikation Wird eine Nachricht vom OPC-Server zum OPC-Client gesendet, so muss der OPC-Client die Items mittels der Client-Handles identifizieren und zu-ordnen. Eine solche Verwendung entspricht dem Empfang von OPC-Ereignissen.

Bei asynchronen Schreib-/Leseaufrufen und bei „aktiven Gruppen / Items“ werden OPC-Callback-Methoden aufgerufen.

Hinweis Client-Handles sollen in der Regel mit Array-Indizes des zugehörigen Variablen im OPC-Client korrespondieren oder Steuerelemente in der Visualiseriungsoberfläche identifizieren.

Abbildung 3-1

Server-Handles: • werden vom OPC-Server nach dem Anlegen eines Objekts (Gruppe

oder Item) zurückgegeben.

• dienen zur späteren Identifikation von OPC-Gruppen und -Items, falls die Aufrufrichtung OPC-Client OPC-Server ist und werden für explizi-te Read und Write Aufrufe des OPC-Clients benötigt, egal ob diese synchron oder asynchron sind. Bei diesen Aufrufen gibt der Client die Server-Handles der Items mit, für die er einen Aufruf absetzen will. Im Server können anhand dieser übergebenen Server-Handles die zuge-hörigen Items identifiziert werden.




V1.0 02.05.05 32/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Verwendung von Server-Handles in der Applikation Bei einer Anforderung vom OPC-Client an den OPC-Server kann es sich um einen Schreib- oder Leseaufruf in synchroner als auch asynchroner Form handeln. In nachfolgender Abbildung wird veranschaulicht, welche Zuordnung von Variablen zwischen OPC-Client und OPC-Server besteht und in welcher Variable sich die entsprechenden Server-Handles im OPC-Client gemerkt werden. Abbildung 3-2

Verschaltung der Prozessvariablen mit den Visualisierungselementen Nachfolgende Abbildungen zeigen die Verschaltungen zwischen Variablen-tabelle und Oberfläche.

Verschaltung beim Empfangen Die Variablen Pressure, Temperature und Humidity im UDT 1 werden mit einem Header, der aus einer ID und einem Zeitstempel besteht als Byte-Array im DB20 abgelegt. Dieses Array wird nach einem RECEIVE in der Visual Basic .NET-Anwendung getrennt und in den Textfeldern entspre-chend angezeigt. Abbildung 3-3




V1.0 02.05.05 33/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Verschaltung beim Senden Die Variablen Name, ValveState und Voltage auf der Visual Basic .NET-Oberfläche können an die Steuerung blockorientiert gesendet werden. Abbildung 3-4

Vorgehen bei der Zeitmessung Um das Programm in der SPS möglichst einfach zu gestalten, wird die mitt-lere Übertragungszeit im PC-Programm ermittelt. Nachfolgend wird sche-matisch dargestellt, welche Zeit im Sende-/Empfangsauftrag bei den Block-diensten gemessen wird. Tabelle 3-1

Richtung Beschreibung S7=>PC Die Zeit t1 entspricht der gemessenen Zeit bei einem Schreibauf-

trag.

PC=>S7 Die Zeit t2 entspricht der gemessenen Zeit bei einem Leseauftrag.




V1.0 02.05.05 34/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3.3 Ablauf- und Datenflussdiagramme dieser Applikation

Im Folgenden wird das dynamische Modell dieser Applikation beschrieben. Es zeigt welche zeitlichen Abläufe stattfinden und wie sich die Applikation dabei verhält.

3.3.1 Datenfluss zwischen Oberfläche und Steuerung

Send-Verbindung Die Abbildung unten zeigt den Datenfluss, der bei einer Send-Verbindung abläuft. Abbildung 3-5

Erläuterung Tabelle 3-2

Nr. Aktion 1 Beim Drücken des „S7->PC“ Buttons wird das „DoSend“ Byte in der Steu-

erung auf „1“ gesetzt 2 Dies veranlasst den FC1 ein Telegramm zu erzeugen und im DB20 abzu-

legen. 3 Mittels AG_SEND wird das Datum dann zur Applikation geschickt. 4 Diese bestätigt den Erhalt des Datenpakets durch Setzen der Variable

„Ack_Send_Done“ auf „1“.




V1.0 02.05.05 35/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Receive-Verbindung Die Abbildung unten zeigt den Datenfluss, der bei einer Receive-Ver-bindung abläuft. Abbildung 3-6

Erläuterung Tabelle 3-3

Nr. Aktion 1 Beim Drücken des „PC->S7“ Buttons wird vom PC ein Telegramm mit den

obigen Daten erzeugt und an die Steuerung gesendet. 2 Diese empfängt das Datenpaket über den AG_RECV und legt es im DB30

ab. 3 Der FC2 entpackt das Telegramm in Header und Nutzdaten. 4 Anschließend sendet er über den AG_SEND den ausgepackten Header

wieder an die Applikation zurück, der als Quittung fungiert.

Hinweis Es ist auch möglich auf FETCH / WRITE zu verzichten und ausschließ-lich mit AG_SEND / AG_RECV zu arbeiten.

Hierbei ist allerdings ein höherer Programmieraufwand zu berücksichti-gen.

3.3.2 Gruppenzuordnung und Zustand der Items in der Applikation

Nachfolgend wird tabellarisch dargestellt, welche Items den Gruppen in welchem Zustand hinzugefügt wurden bzw. welcher Gruppenzustand vor-herrscht.




V1.0 02.05.05 36/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Blockdienste Bei den Blockdiensten werden 2 Gruppen angelegt:

• Gruppe ActiveGroupSR

• Gruppe PassiveGroupSR

Generell werden die Items entsprechend des Gruppenzustandes aktiv oder passiv angelegt.

Auflistung Tabelle 3-4

Item Gruppe Zustand Hinweis SR:[S7 => PC]receive,B0, +Adresse

ActiveGroupSR Aktiv

SR:[PC => S7]receive,B0, 12

ActiveGroupSR Aktiv

SR:[Write]MB1,1" PassiveGroupSR Passiv Flusssteuerung S7 PC

SR:[Write]MB2,1 PassiveGroupSR Passiv Quittung S7 PC

SR:[PC => S7]send,B0, +Adresse

PassiveGroupSR Passiv

Hinweis Adresse steht für den Beginn des ByteArrays, welches der Größe des Telegrammkopfes und dem empfangenen UDT-Größe gebildet wird.

Variablendienste Bei den Variablendiensten werden ebenfalls 2 Gruppen angelegt:

• Gruppe FetchGroup

• Gruppe WriteGroup

Es wird eine Gruppe für die Write-Variablen und eine Gruppe für die Read-Variablen angelegt. Beiden Gruppen sind passiv.

Auflistung Tabelle 3-5

Item Gruppe Zustand SR:[Fetch]MD200 FetchGroup Passiv SR:[Fetch]MD204 FetchGroup Passiv SR:[Fetch]MD208 FetchGroup Passiv SR:[Write]MD200 WriteGroup Passiv SR:[Write]MD204 WriteGroup Passiv SR:[Write]MD208 WriteGroup Passiv




V1.0 02.05.05 37/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3.4 Klassendiagramme der Applikation

Im folgenden Kapitel wird die statische Struktur der Applikation beschrie-ben. Sie zeigt, wie die Klassen der Visual Basic .NET-Applikation gestaltet sind und welche objektorientierte Strukturierung der Aufgabe vorgenom-men wurde.

3.4.1 Überblick

Klassendiagramm Die Abbildung unten verdeutlicht die Abhängigkeiten der Klassen unterein-ander.

Abbildung 3-7




V1.0 02.05.05 38/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Erläuterung des Klassendiagramms Wie zu erkennen ist, existiert eine Klasse MainForm, die die Interaktionen mit dem Benutzer auffängt und sie an die jeweils, für die Aktion zuständige Klasse weiterreicht.

Hierbei sind die spezialisierten Klassen zum einen BlockServices, die für die Verwaltung der blockorientierten Dienste zuständig ist und zum ande-ren die Klasse VariablenServices, die für die variablen orientierten Dienste zuständig ist. Zwischen der Klasse MainForm und den für die Dienste zu-ständigen Klassen besteht eine Forward- und Backward-Referenz.

3.4.2 Die Klasse MainForm

Aufgaben Die Aufgaben dieser Klasse sind:

• Verbinden mit dem SIMATIC NET OPC-Server

• Verbindungstrennung vom OPC-Server sofern eine Verbindung zum Server besteht.

• Initialisierung der Klassen BlockServices und VariableServices

• Entgegennahme der Eingabe- und Ausgabegrößen

• Form-Managment der graphischen Benutzeroberfläche, wie z.B. abfan-gen der Events bei Buttonklick, Aktivieren und Deaktivieren der Buttons, Anzeigen und Auslesen der Textboxes.

Wichtigste Methoden Tabelle 3-6

Methodenname Funktion btnConnect_Click Durch Klicken des Buttons „Connect“, wird diese Routine aufgeru-

fen. Nur möglich falls noch keine Verbindung hergestellt wurde. Herstellung der Verbindung zum SIMATIC NET OPC-Server. Initia-lisierung der Klassen BlockServices und VariableServices mit den benötigten Parametern aus der Verbindungsherstellung

btnDisconnect_Click Durch Klicken des Buttons Disconnect, wird diese Routine aufgeru-fen. Nur möglich nach erfolgreich hergestellter Verbindung. Beendigung des Servers und Trennung der Verbindung. Aufruf der Disconnect-Methode von den Klassen BlockServices und VariableServices, in denen Aufräumarbeiten getätigt werden.




V1.0 02.05.05 39/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3.4.3 Die Klasse BlockServices

Aufgaben Die Aufgabe dieser Klasse bestehen aus:

• OPC-Verbindungsmanagment (hinzufügen von Gruppe und Items)

• Senden und Empfangen mit Blockdiensten (synchrones Lesen, asyn-chrones Schreiben)

• Berechnen der Übertragungszeit

• Benutzung der Konvertierungs-dll (DataConversion.dll) zur Datenkon-vertierung zwischen S7- und PC-Datentypen.


Methodenname Funktion Connect Hinzufügen der Gruppen und Items. Anlegen des Callback-

objekts für die asynchronen Operationen. Disconnect Aufräumarbeiten bei Trennung vom Server. Abmelden des

Callbacks und Speicherfreigabe nicht mehr benötigter Objekte. ReceiveData Synchroner Leseauftrag mit Blockdiensten wird aufgerufen. ProcessReceivedData Aufruf einer DataConversion.dll-Methode zur Konvertierung

empfangener Daten in den entsprechenden Datentyp und Übergabe an MainForm zur Anzeige. Berechnung der Übertragungszeit.

ProcessSendDataReceipt Aufruf einer DataConversion.dll-Methode zur Umwandlung der zu sendenden Daten in ein Bytearray. Berechnung der Übertragungszeit.

SendData Methode zur Telegrammgenerierung wird aufgerufen und es erfolgt ein asynchroner Schreibauftrag an den OPC-Server (mittels Blockdiensten).

OnDataChange Callback-Funktion für die aktiven Items. Bei Werteänderung und Ablauf der Updaterate erfolgt ein Aufruf dieser Methode.




V1.0 02.05.05 40/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

3.4.4 Die Klasse VariableServices

Aufgaben Die Aufgaben dieser Klasse sind:

• OPC-Verbindungsmanagment (hinzufügen von Gruppe und Items)

• Senden und Empfangen mit Variablendiensten (asynchrones Lesen, synchrones Schreiben)


Methodenname Funktion Connect Hinzufügen der Gruppen und Items. Anlegen des Callback-Objekts und

Anmelden an den Callback für die asynchronen Operationen. Disconnect Aufräumarbeiten bei Trennung vom Server. Abmelden des Callbacks und

Speicherfreigabe nicht mehr benötigter Objekte. FetchData Asynchroner Leseaufruf mittels Variablendiensten OnFetchedData Callback-Methode für asynchronen Leseauftrag. Aufruf der entsprechen-

den Anzeigemethode in der Klasse MainForm WriteData Synchroner Schreibauftrag

3.4.5 Fehlerhandling in der Applikation

Allgemeines Das Fehlerhandling in dieser Applikation erfolgt mittels "unstructured ex-ception handling". In Visual Basic können auftretende Fehler mit der An-weisung „On Error Goto Sprungmarke“ zu einer Sprungmarke mit entspre-chenden Anweisungen im Fehlerfall delegiert werden. Mittels „On Error Re-sume Next“ kann bei auftretenden Fehler die Applikation sicherer gemacht werden.

So wird in dieser Applikation im Fehlerfall sicher gestellt, das nicht mehr benötigte Objekte freigegeben werden und eine weitere Bedienbarkeit der Applikation sichergestellt ist.

Eine weiter Möglichkeit des Fehlerhandlings ist das "structured exception handling". Dazu werden den Befehle "Try", "Catch" und "Finally" eingesetzt. Da diese Art des Fehlerhandlings in dieser Applikation nicht eingesetzt wird, soll diese hier nicht weiter betrachtet werden.

Beispiel Falls z.B. die Verbindungsherstellung zum SIMATIC NET OPC-Server aus bestimmten Gründen fehlschlägt, wird im Error Handler dafür gesorgt, dass der Button „Connect“ wieder aktiviert wird. So wird sichergestellt, das der Benutzer erneut einen Verbindungsaufbau initiieren kann.




V1.0 02.05.05 41/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Auslösen einer Exception Falls Fehler bei Aufträgen während der Kommunikation auftreten, z.B. beim Schreibauftrag, so wird eine Exception geworfen mit der entsprechenden Beschreibung als Parameter. Dies geschieht in Visual Basic mit dem Schlüsselwort „throw“: If Errors(0) <> 0 Then Throw New ApplicationException("Writing AckByte failed.") End If

Benutzung von Errorcodes Als Rückgabewerte der OPC-Funktionen können bestimmte Errorcodes (die der OPC-Spezifikation zu entnehmen sind) Aufschluss über den Status der Methode geben. So kann durch gezieltes Abfragen des Errorcodes eine Meldung an den Benutzer bei fehlschlagen des Aufrufs gegeben werden, bzw. eine anderweitige Reaktion der Applikation initiiert werden.


Erläuterungen zum OPC-Client


V1.0 02.05.05 42/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4 Erläuterungen zum OPC-Client

Hier erfahren Sie... Welche Strukturen im OPC-Client realisiert sind. Dabei wird vor allem auf das Anlegen von Gruppen und Items eingegangen.

Hinweis Für weitere Informationen sollten Sie auf den kommentierten Quellcode zurückgreifen.

4.1 Strukturen im OPC-Client

Im OPC-Client werden Klassen anstelle von Strukturen verwendet.

Soweit dies im Rahmen dieser Applikation sinnvoll erschien, wurden objekt-orientierte Methoden angewendet.

Die Klassendiagramme sowie die Aufgaben der wichtigsten Klassen sind bereits in Kap. 3.4 Klassendiagramme der Applikation erläutert.

Die Klasse MainForm stellt die Implementierung des Dialogs dar und wird gleichzeitig als zentraler Container für die anderen verwendeten Klassen genutzt. Da es sich bei der Instanziierung des OPC-Servers ebenfalls um eine zentrale Aufgabe handelt wird auch dies hier vorgenommen.

In der Klasse BlockServices wurde die AG_SEND/AG_RECEIVE Funktio-nalität gekapselt. Sie verwaltet eigene Gruppen, besitzt ein eigenes Call-back-Interface und kümmert sich um das Anlegen und Freigeben von Res-sourcen.

Das Gegenstück dazu ist die Klasse VariableServices. Sie implementiert die Variablendienste und verfügt ebenso wie die Klasse BlockServices über eigene Ressourcen.




V1.0 02.05.05 43/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.2 Anbindung an den OPC-Server

Die Anbindung an den OPC-Server erfolgt mit der Methode „btnCon-nect_Click“ des Dialogs „MainForm“:

Abbildung 4-1

OPC-Server starten




V1.0 02.05.05 44/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3 Blockorientierte Dienste

Die blockorientierten Dienste, sprich AG_SEND/AG_RECV, sind in der Klasse „BlockServices“ implementiert.

Die im folgenden dargestellten OPC-spezifischen Themen beziehen sich auf den Quellcode der Datei „BlockServices.vb“.

4.3.1 Grundlegende Variablen zur Anbindung an den OPC-Server

Die Klasse benötigt für die Anbindung an den OPC-Server folgende Werte:

Anbindung an den OPC-Server inkl. Gruppen Private m_Server As IOPCServer = Nothing Private m_ActiveGroupHandle As Integer = 0 Private m_PassiveGroupHandle As Integer = 0 Private m_ActiveGroup As IOPCGroupStateMgt = Nothing Private m_PassiveGroup As IOPCGroupStateMgt = Nothing Ferner sind für die Bereitstellung der Funktionalitäten folgende Variablen notwendig.

Merker für die Anbindung an die ConnectionPointContainer (so genannte Coo-kies)

Private m_ActiveGroupCallbackCookie As Integer = 0 Private m_PassiveGroupCallbackCookie As Integer = 0

Handles Tabelle 4-1

Handle Beschreibung Allgemein benutz-te Handles

Diese Handles werden sowohl für die Sende- wie auch für die Empfangsrichtung verwendet. Private Const m_AckItemClientHandle As Integer = 1 Private Const m_DataItemClientHandle As Integer = 2

Handles, die für den Empfang be-nutzt werden

Private Const m_DoSendItemClientHandle As Integer = 3 Private m_RecvDoSendItemServerHandle As Integer = 0 Private m_RecvAckItemServerHandle As Integer = 0 Private m_RecvDataItemServerHandle As Integer = 0

Handles, die für das Senden be-nutzt werden:

Private m_SendAckItemServerHandle As Integer = 0 Private m_SendDataItemServerHandle As Integer = 0




V1.0 02.05.05 45/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3.2 Anlegen von OPC-Gruppen

Codeauszug Das Anlegen der Gruppen wurde mit der Methode „Connect(...)“ gekapselt.

Abbildung 4-2

Erläuterung Der Codeauszug zeigt lediglich den Aufruf der OPC-Methode „AddGroup“.

Beachten Sie, dass die geforderte Aktualisierungsrate nicht der tatsächli-chen Aktualisierungsrate entsprechen muss. Diese wird mittels der Variable RevisedUpdateRate zurückgegeben.

Hinweis Einen Überblick über die verwendeten Gruppen und Items und ihren Zu-stand erhalten sie im Kapitel 3.3.2.




V1.0 02.05.05 46/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3.3 OPC-Items

Anlegen von OPC-Items Das Anlegen von Items wurde innerhalb der Methode „Connect“ gekapselt.

Im folgendem Codeabschnitt sieht man, wie Itemdefinitionen in Arrays an-gelegt werden und anschließend an die Methode „AddItems“ übergeben werden.

Abbildung 4-3

Eigenschaften von OPC-Items Für jedes Item müssen die folgenden Properties gesetzt werden: Tabelle 4-2

Property Verwendung szAccessPatch wird nicht verwendet szItemID z.B. „SR:[MyConnection]receive,B0,12” bActive wenn True, dann wird das Item aktiv angelegt hClient Client-Handle; kann frei vergeben werden vtRequestedDataType Datentyp der angefordert wird dwBlobSize wird nicht verwendet pBlob wird nicht verwendet

Item aktiv anlegen

Datentyp: Byte-Array

Itemname

Items hinzufügen




V1.0 02.05.05 47/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Auswerten des Fehler-Arrays In nachfolgendem Auszug wird dargestellt wie das Fehler-Array ausgewer-tet werden kann und welche Maßnahmen hinsichtlich der COM Interopera-bilität ergriffen werden müssen. Abbildung 4-4

Hinweise zur Nutzung des .NET Wrappers Die Tatsache, dass der .NET Wrapper nur eine dünne Schicht zwischen .NET und COM darstellt, erfordert einige Konvertierungsarbeit. So muss z.B. das Fehler-Array vom unverwalteten in den verwalteten Speicher von .NET kopiert werden.

Darüber hinaus ist auch ein Zugriff auf die Struktur OPCITEMRESULT nur durch kopieren der Daten möglich. Durch sie erhalten wir das vom Server zurückgegebene Server-Handle. Soll später ein aktiver Zugriff auf ein Item erfolgen, so muss für dieses das Server-Handle gemerkt werden. Soll ein Item lediglich beobachtet werden so ist das Server-Handle nicht von Nöten.

Die vom OPC-Server erzeugten Fehler- und Resultat-Arrays müssen vom Client wieder freigegeben werden. Dies erfolgt hier über FreeCoTaskMem. Den danach ungültigen Zeiger auf 0 zu setzen ist nicht Pflicht, es ist jedoch guter Programmierstil und erleichtert die Fehlersuche.

Umkopieren des Error-Arrays

Trat ein Fehler auf?

Zugriff auf un-managed Me-mory

Weiter im Array




V1.0 02.05.05 48/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3.4 Callback Interface anmelden

Codeauszug Das Anmelden des Callback Interfaces wurde innerhalb der Methode „Connect“ gekapselt.

Abbildung 4-5

Erläuterung Der Ablauf ist hier recht übersichtlich. Über das Interface „Connection-PointContainer“ einer OPC Gruppe kann der „ConnectionPoint“ für das I-OPCDatacallback Interface geholt werden. An diesem wird dann per „Advi-se-Aufruf“ das eigene IOPCDatacallback Interface angemeldet.

Um das eigene Callback Interface wieder vom Server zu trennen wird die Methode „Unadvise“ des ConnectionPoints benutzt.

Hinweis Die Methode Unadvise am ConnectionPoint muss beim Trennen (Dis-connect) vom Server aufgerufen werden, da sonst nicht alle Ressourcen frei gegeben werden.




V1.0 02.05.05 49/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3.5 Daten von einer PLC mittels AG_SEND/AG_RECV empfangen

Veranlassung der SPS zum Senden der Daten Um die Übertragung von der PLC in Richtung PC zu starten, schreibt der PC über die „Write“ Verbindung ein Byte, das „DoSend“-Byte. Sobald sich der Wert dieses Bytes von 0 auf 1 ändert beginnt die PLC zu übertragen (siehe Kapitel 5 Erläuterungen zum S7-Programm).

Codeauszug – Starten der Übertragung Abbildung 4-6

Schreiben des „DoSend“ Bytes mit dem Wert 1 Starten der

Performance-Messung

Auf Fehler prüfen




V1.0 02.05.05 50/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Erläuterung – Starten der Übertragung In obigem Codeabschnitt wird die Variable „m_RecvInProgress“ auf True gesetzt. Sie dient zur Feststellung ob die Anwendung auf Daten wartet oder nicht. Das ist deshalb von Vorteil, weil diese Funktion asynchron abgear-beitet wird. Die Daten, die hier angefordert werden, werden zu einem spä-teren Zeitpunkt über die Funktion „OnDataChange“ empfangen und in der Funktion „ProcessReceivedData“ verarbeitet.

Neben den eigentlichen Daten werden über OnDataChange auch Fehler-codes empfangen. Die Fehlercodes werden allerdings nur dann ausgewer-tet, wenn auch tatsächlich auf Daten gewartet wird. So ist zum Beispiel ei-ne Zeitüberschreitung nur dann relevant, wenn die Verbindung aktuell für die Übermittlung von Daten benötigt wird.

Codeauszug – Empfang der Daten im OPC-Client Zum Empfang der Daten von der PLC wurde zu Beginn eine aktive OPC Variable mit dem Namen "SR:[S7 => PC]receive,B0,xxx" angelegt. Der Platzhalter xxx steht hier für die Größe des Byte-Arrays.

Für dieses OPC-Item legt der SIMATIC NET OPC-Server einen Empfangs-puffer auf der Verbindung „S7 => PC“ an und meldet per OnDataChange sobald neue Daten eingetroffen sind.

In der Methode ProcessReceivedData wird nun das Byte-Array analysiert, die Daten in die von Visual Basic .NET benötigte Form konvertiert und an die Oberfläche weitergeleitet.

Abbildung 4-7

Der S7DataConverter hilft bei der Konvertie-rung der Daten

Berechnung der mittleren Performance, nur wenn Daten angekommen sind

1.Parameter: Byte-Array

2.Parameter: Beginn des Arrays bei gera-de Adresse (j/n)

3.Parameter: auto-matische Offset-Korrigierung an/aus




V1.0 02.05.05 51/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Erläuterung – Empfang der Daten im OPC-Client In obigen Codeausschnitt wird zunächst das empfangene Byte-Array (Va-lue) der Konvertierungs-dll übergeben. Hierbei muss angegeben werden, ob das Array bei einer geraden Adresse beginnt und ob gegebenenfalls ei-ne automatische Offset-Korrektur stattfinden soll. Anschließend werden die einzelnen Daten aus dem Byte-Array mit Hilfe der Methode „GetValue“ der Konvertierungs-dll entpackt und in die entsprechenden Variablen (DataTi-meStamp, Pressure, Temperature, Humidity) zerlegt.

Anschließend erfolgt, sofern Daten angekommen sind (m_RecvInProgress), die Berechnung der mittleren Performancezeit.

Abschließend werden die Daten an das MainForm-Objekt (m_Dialog) über-geben und dort zur Anzeige gebracht.

Codeauszug – Senden der Quittung Um der PLC anzuzeigen, dass die Daten erfolgreich übermittelt wurden und vom PC verarbeitet werden konnten wird ein Quittungs-Byte an die PLC gesendet. Dies wurde hier mittels eines asynchronen Schreibaufrufs auf der Write - Verbindung realisiert. Abbildung 4-8

Falls der Write-Aufruf fehlschlagen sollte, so wird eine Exception geworfen, mit der entsprechenden Fehlermeldung. Siehe Kapitel 3.4.5 Fehlerhandling in der Applikation.

IOPCAsyncIO2 Inter-face von der Gruppe holen.

Wert asynchron schreiben

Es kommen keine Daten an. Nun wird die Quittung gesen-det.




V1.0 02.05.05 52/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.3.6 Daten zu einer PLC mittels AG_SEND/AG_RECV senden

Senden von Daten an die SPS mit AG_SEND-OPC-Item Für das Senden der Daten an die PLC wurde zu Beginn ein passives OPC-Item mit dem Namen "SR:[PC => S7]send,B0,xxx“ angelegt. Der Platzhal-ter xxx steht dabei für die Größe des Byte-Arrays. Das Absenden der Daten wurde in der Methode SendData implementiert.

Codeauszug – Absenden der Daten Abbildung 4-9

Generieren des Telegramms, siehe Abbildung 4-10

Absenden der Da-ten mittels asyn-chronem Write




V1.0 02.05.05 53/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Erläuterung Sobald die Daten geschrieben wurden erhalten wir vom OPC-Server eine Quittung durch den Callback der Methode OnWriteComplete. Hier muss das Fehler-Array ausgewertet werden um Aufschluss über die Qualität der Übertragung zu erhalten.

Codeauszug – Telegramm-Generierung In nachfolgendem Codeauschnitt wird die Telegramm-Generierung genau-er verdeutlicht. Hierfür ist die Methode „GenerateTelegram“ der Klasse BlockServices verantwortlich. Abbildung 4-10

Byte-Array der ent-sprechenden Länge anlegen

S7DataConverter hilft bei der Daten-konvertierung




V1.0 02.05.05 54/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Codeauszug – Empfang der Quittung Nachdem die PLC die Daten erhalten und gespeichert hat sendet sie ein Bestätigungspaket an den PC. Dies erhalten wir über einen OnDataChange und werten es in der Methode ProcessSendDataReceipt aus.

Abbildung 4-11

Erläuterung – Empfang der Quittung Wie auch schon beim Empfangen der Daten von der SPS wird auch hier mit einem Flag gearbeitet. In diesem Fall heißt es „m_SendInProgress“. Es wird auf True gesetzt wenn Daten gesendet werden und auf False, wenn der Vorgang abgeschlossen ist.

Des weiteren wird ein Zähler namens „m_SendDurationCount“ verwendet, der die Anzahl an Zeitmessungen beinhaltet. Da die erste Übertragung von Daten unverhältnismäßig lange dauert im Vergleich zu allen folgenden, soll für diese keine Zeitmessung erfolgen. Deshalb wird dieser Zähler mit -1 ini-tialisiert.

Berechnung der mittle-ren Übertragungszeit.

Extrahieren des Zeitstempels




V1.0 02.05.05 55/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.4 Variablendienste

4.4.1 Beispiel: Synchron schreiben

Das synchrone Schreiben von OPC-Items wurde zum Beispiel in der Me-thode WriteData der Klasse „VariableServices“ implementiert.

Voraussetzung ist ein gestarteter OPC-Server, eine angelegte Gruppe und mindestens ein darin angelegtes OPC-Item.

Codeauszug Abbildung 4-12

Erläuterung Die OPC Funktion „Write“ erwartet ein Array mit Server-Handles sowie ei-nes mit den dazugehörenden zu schreibenden Werten.

Nach dem Aufruf von „Write“ wird das Fehler-Array umkopiert und das Ori-ginal im unmanaged Speicher freigegeben.

Aufruf der Write - Methode des OPC-SyncIO - Interfaces.

Fehlerhandling




V1.0 02.05.05 56/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

4.4.2 Beispiel: Asynchron lesen

Das asynchrone Lesen erfolgt über das OPC-IAsyncIO2-Interface. Dies kann folgendermaßen umgesetzt werden:

Codeauszug Zunächst werden die Werte asynchron aus der Steuerung gelesen: Abbildung 4-13

Erläuterung Wie bei allen Lese-/Schreib-Operationen müssen auch hier die ItemServer-Handles angegeben werden. Im obigen Fall werden diese über den Para-meter „ServerHandles“ übergeben.

In diesem Codebeispiel wird der Read-Methode als Transaktionsnummer (Parameter dwTransactionID) immer 1 übergeben. Das ist deshalb möglich, weil die Methode „FetchData“ die einzige Funktion ist, die den asynchronen Read benutzt. Gibt es mehrere Aufrufer so ist es ratsam für jeden Aufrufer bzw. jeden einzelnen Leseauftrag eine eindeutige Transaktionsnummer zu vergeben.

Aufruf der Read-Methode des OPC-AsyncIO2-Interfaces.

Fehlerhandling

Serverhandle Ar-ray aufbauen




V1.0 02.05.05 57/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Anzeigen der Werte Da es sich um einen asynchronen Aufruf handelte, werden die eigentlichen Werte erst in der Callback-Methode OnReadComplete dem OPC-Client übergeben.

Da es für alle Gruppen eine Callback-Methode gibt, muss nun nach den Gruppen, Client-Handles und Transaktionsnummern unterschieden wer-den, um die gelieferten Werte auch den Objekten und Aufrufen im OPC-Client zuordnen zu können (s. dazu Kap. 3.2).

Codeauszug – Anzeigen der Werte In folgendem Codefragement ist dieses Vorgehen stark vereinfacht darge-stellt. Das ist hier möglich, da es nur eine Funktion gibt die den asynchro-nen Read benutzt, und diese auch nicht parallel mehrfach ausgeführt wer-den kann.

Abbildung 4-14


Erläuterungen zum S7-Programm


V1.0 02.05.05 58/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

5 Erläuterungen zum S7-Programm

Hier erfahren Sie... die Funktionsweise des S7-Programms.

5.1 Grundstrukturen

Das Programm auf der Steuerung erzeugt und versendet auf Anforderung des OPC-Clients (DO_SEND) einen Datenblock. Gleichzeitig wartet es auf Daten, die vom PC übermittelt werden und bestätigt deren Erhalt durch zu-rücksenden des Telegramm-Headers (Quittung).

Es werden folgende Strukturen und Datenbausteine eingesetzt:

Struktur „Header“ (UDT 0) Abbildung 5-1

Struktur „Measured_Values“ (UDT 1): Die Struktur enthält simulierte Messwerte, die als Daten für die Kommuni-kation von der Steuerung zum PC (S7 => PC) dienen. Bei jeder Anforde-rung dieser Daten werden sie um einen bestimmten Wert inkrementiert um ständig wechselnde Werte zu simulieren. Abbildung 5-2




V1.0 02.05.05 59/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Struktur „Machine_Data“ (UDT 2): Simulierte Maschinendaten, die als Daten für die Kommunikation vom PC zur Steuerung (PC => S7) dienen. Abbildung 5-3

Datenbaustein „SND_DB“ (DB 20): Werden Daten von der Steuerung angefordert (DO_SEND), werden in die-sem Datenbaustein die zu übertragenden Werte zusammengesetzt und dann als Datenblock versendet. Abbildung 5-4

Datenbaustein „RCV_DB“ (DB 30): Abbildung 5-5

! Achtung

In diesen Datenbaustein wird der empfangene Datenblock abgelegt. Dieser DB muss mindestens so groß sein, wie das zu erwartende Datenpaket ( Einstellung des OPC - Sendepuffers und des RECV-Bausteins). Kann dieser Wert nicht direkt durch das Daten-Array erreicht werden müssen noch entsprechend viele „Dummy-Bytes“ eingefügt werden.




V1.0 02.05.05 60/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Datenbaustein „Data“ (DB 10): Durch die Funktion (FC 2) „Fractionize_Telegram“ werden die empfange-nen Werte aus dem Receive - Datenbaustein an die entsprechenden Stel-len kopiert. DB 10 steht hier als beispielhaftes Ziel. Es könnten genau so gut andere Datenbausteine oder Merkerbereiche verwendet werden. Abbildung 5-6

5.2 Ablauf des Programms

Die Abläufe innerhalb der Steuerung sind recht übersichtlich.

Übersicht Folgendes Diagramm veranschaulicht den Aufrufablauf: Abbildung 5-7




V1.0 02.05.05 61/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

Netzwerk 1 Der erste Teil des Programms (Netzwerk 1) versendet die Daten von der Steuerung zum PC. Tabelle 5-1

Nr. Aktion 1 Setzen des Do_Send-Bits per Write - Verbindung. 2 Das Setzen dieses Bits bewirkt ein Aufruf des Funktionsbausteins

„Built_Telegram“ (FC1), der den zu übertragenden Datenblock im Daten-baustein 20 zusammensetzt. Danach wird der Send-Baustein (FC 5) so oft durchlaufen, bis das Datenpaket übertragen wurde (Send_Done = 1).

3 Zum Schluss wird noch auf die Bestätigung vom PC gewartet (Ack_Bit), bevor wieder auf eine neue Sendeaufforderung gewartet wird.

Netzwerk 2 Der zweite Teil des Programms (Netzwerk 2) wartet auf Daten die vom PC übertragen werden. Tabelle 5-2

Nr. Aktion 1 Dazu wird der Receive - Baustein (FC 6) so lange durchlaufen, bis er per

NewDataReceive (NDR = 1) meldet, dass Daten empfangen wurden. 2 Daraufhin wird die Funktion „Fractionize_Telegram“ (FC 2) aufgerufen, die

den empfangenen Datenblock zerlegt. Als Beispiel werden dort die Daten aus den ersten drei Array-Elementen in einen anderen Datenbaustein (DB 10) kopiert.

3 Zum Schluss wird noch der Header des empfangen Datenpakets als Bes-tätigung an den PC zurückgesendet




V1.0 02.05.05 62/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

Fehl

er! U

nbek

annt

er N

ame

für D

okum

ent-

Eige

nsch

aft

5.3 Aufruf der Send- / Receive - Bausteine (FC 5 / FC 6)

Hier wird ein kurzer Abriss über die Schnittstelle der Bausteine FC 5 und FC 6 gegeben. Es wird beispielhaft ein Aufruf durchgeführt und die Funkti-on der Parameter beschrieben.

5.3.1 AG_SEND (FC 5)

Aufruf der Funktion FC 5 1=Baustein aktiv / 0 =Baustein inaktiv ID der Verbindung ( NetPro) Ladeadresse der Verbindung ( NetPro) Zu versendender Datenbaustein Länge des Datenpaketes (in Byte) Bestätigungswert für Senden der Daten Statusbit für Fehler beim Senden

Statuswert des Bausteins

Hinweis Eine genauere Beschreibung wie sich die Länge des Datenpakets ermit-teln lässt, findet sich in Kapitel 6.1.

5.3.2 AG_RECV (FC 6)

Aufruf der Funktion FC 6 ID der Verbindung ( NetPro) Ladeadresse der Verbindung ( NetPro) Datenbaustein für die empfangenen Daten Bestätigungswert für empfangene Daten Statusbit für Fehler beim Senden Statuswert des Bausteins Länge des empfangenen Datenpaketes (in Byte)


Modifikationen zum Beispielprogramm


V1.0 02.05.05 63/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

6 Modifikationen zum Beispielprogramm

Hier erfahren Sie... an welchen Stellen Sie Anpassungen im Visual Basic .NET- bzw. S7-Programm vornehmen müssen um die Datenblockgröße zu verändern.

6.1 Veränderungen im STEP 7-Programm

Allgemein In diesem Beispiel besteht der übertragene Datenblock aus dem Header (UDT0) und einem Array von selbst definierten Strukturen (UDT1 oder 2). Das bedeutet, dass sinnvoller weise die Länge des Datenblocks immer ei-nem vielfachen der UDT - Größe + Header entsprechen sollte.

Beispiel: Von der Steuerung soll ein Array mit 800 UDT1 übertragen werden. Die dafür einzustellende Datenblockgröße berechnet sich wie folgt:

Anzahl * UDT - Größe + Header 800 * 10 Byte + 10 Byte = 8010 Byte

S7 => PC Der Datenbaustein „SND_DB“ (DB 20) muss so groß angelegt werden, dass er alle zu versendenden Daten aufnehmen kann, die von der Funktion (FC 1) „Built_Telegram“ dort abgelegt werden. Und er muss mindestens so groß sein, wie der beim Send-Aufruf angegebene Datenbereich.

Beim Aufruf des Send-Bausteins (FC 5) muss unter „SEND“ und „LEN“ die Länge des Datenblocks in Byte angegeben werden:

PC => S7 Der Datenbaustein „RCV_DB“ (DB 30) muss mindestens so groß angelegt werden, dass er alle zu empfangenden Daten aufnehmen kann.

Beim Aufruf des Receive - Bausteins (FC 6) muss unter „RECV“ die Länge des Datenblocks in Byte angegeben werden:

Hinweis

Genau diese Größe muss auf Seite des PCs/PGs auch als Sende-Puffer des OPC-Servers konfiguriert sein. Wie Sie diese Einstellung vornehmen erfahren Sie im Dokument "Demonstration" dieser Applikation.


Modifikationen zum Beispielprogramm


V1.0 02.05.05 64/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

6.2 Veränderungen an der Visual Basic .NET Applikation

An dieser Stelle wird Ihnen erklärt, wo Sie Einstellungen im Quelltext der Applikation vornehmen müssen, damit diese richtig auf die Datenblockgrö-ße reagiert.

Codeausszug Der folgende Codeabschnitt befindet sich am Anfang der Quelldatei „BlockServices.vb“. In ihm werden Konstanten angelegt, welche die Daten-pakete in ihrer Größe und Beschaffenheit grob umreißen. Abbildung 6-1

Anpassungen Um die Anzahl der zu senden Nutzdaten zu verändern, passen Sie bitten die Variable „m_SendUdtCount“ an. Die Größe des gesendeten Daten-blocks berechnet sich nach: m_HeaderSize + m_SendUdtSize * m_SendUdtCount.

Entsprechend kann mit der Variablen „m_RecvUdtCount“ die Anzahl der zu empfangenden Datensätze angepasst werden.

! Achtung

Die Werte der Variablen m_HeaderSize, m_SendUdtSize und m_RecvUdtSize ergeben sich aus den in der Steuerung verwende-ten UDTs. Sie sollten daher nur dann geändert werden, falls es auf seiten der Steuerung zu einer Veränderung kommt!

Anhang und Literaturhinweise

Glossar (optional)


V1.0 02.05.05 65/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc


7 Glossar (optional)

COM Component Object Modell: Software-Modell zur Kommunikation zwischen Komponenten, das auf einer einheitlichen Schnittstelle aufsetzt; DCOM

DCOM Distributed Object Modell: Software-Modell zur Kommunikation über Rech-nergrenzen hinweg, welches auf COM aufsetzt.

Eventhandler Ein Eventhandler bearbeitet aufgetretene Ereignisse bzw. Windows-Nachrichten.

Exception Unter einer Exception versteht man eine Ausnahmesituation. Diese kann entweder vom Betriebssystem (z.B. Division by zero) oder vom Anwenderprogramm generiert werden.

Exception-Handler Ein Exception-Handler bearbeitet aufgetretene Ausnahmesituationen. Dies ist in der Regel ein gesichertes Fehlverhalten und/oder eine Nachricht an den Nutzer.

HRESULT Rückgabe-Datentyp von COM-Objekten.

IDL Interface Definition Language: Eine von Microsoft standardisierte Sprache zur Definition von Funktions- und Parameter-Schnittstellen.

OPC OLE for Process Control. Eine für den Automatisierungsbereich geschaffe-ne Standardisierung zur Prozesssteuerung. Gepflegt von der OPC - Foun-dation. Es sind mehrere Schnittstellen mit unterschiedlichem Aufgabenbe-reich vorhanden.

OPC-Client Ein Programm, das die Dienste eines OPC-Servers in Anspruch nimmt, in-dem es Anfragen an den Server mittels einer der vorhandenen OPC Schnittstellen stellt.


Glossar (optional)


V1.0 02.05.05 66/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

OPC DA OPC Data Access Schnittstelle. Die Schnittstelle ermöglicht das Beobach-ten und Verändern von Prozesswerten.

OPC-Server Ein Programm, das eine der OPC Schnittstellen zur Verfügung stellt und auf Anfragen eines OPC-Clients Antwortet.

Polling Englischer Begriff, mit dem das (meist zyklische) Abfragen bestimmter Werte oder Zustände gemeint ist.

RCW Runtime Callable Wrapper. Eine Hülle (siehe Wrapper), die eine Custom Schnittstelle für das .NET Framework kapselt. Durch den RCW werden äl-tere COM Schnittstellen für das .NET Framework zugänglich.

Sink-Interface Mit Hilfe des Sink-Interfaces können Nachrichten zwischen Komponenten gesendet werden. Das Sink-Interface setzt auf COM-Mechanismen auf.

Windows-Nachricht In den gängigen Microsoft Windows Betriebssystemen werden zur Mit-teilung von Ereignissen, z.B. das Paint-Ereignis, Nachrichten ausgetauscht.

Wrapper Als „Wrapper“ wird in der Regel ein Klassenverbund bezeichnet, der an-dere Klassenverbände zur Datenkonvertierung oder leichteren Verwendung kapselt. Er kann somit als „Hülle“ gesehen werden, der die „gewrappten“ Klassen umschließt und nach außen verbirgt.


Literaturhinweise


V1.0 02.05.05 67/67

Cop

yrig

ht ©

Sie

men

s A

G 2

005

All

right

s re

serv

ed

2152

3291

_OP

C_S

R_E

xten

sion

_DO

KU

_v10

_d.d

oc

8 Literaturhinweise

8.1 Literaturangaben

Diese Liste ist keinesfalls vollständig und spiegelt nur eine Auswahl an ge-eigneter Literatur wieder.

Tabelle 8-1

Themengebiet Titel /1/ STEP7 Automatisieren mit STEP7 in AWL und SCL

Hans Berger Publicis MCD Verlag ISBN 3-89578-113-4

/2/ .NET Inside C#, Tom Archer .NET Crashkurs, Clemens Vasters, Oellers, Javidi, Jung, Freiberger, DePetrillo Microsoft .NET Framework Programmierung, Jeffrey Richter

/3/ Handbuch zur Indus-triellen Kommunikation auf PG/PC mit SIMA-TIC NET.

SIMATIC NET – Industrielle Kommunikation mit PG/PC Band 1 Grundlagen Band 2 Schnittstellen Wird von SIMATIC NET installiert, siehe: Start SIMATIC Dokumentation Deutsch Im Produktsupport unter der Beitrags ID: 62044387

8.2 Internet-Link-Angaben

Diese Liste ist keinesfalls vollständig und spiegelt nur eine Auswahl an ge-eigneter Literatur wieder.

Themengebiet Titel \1\ Referenz auf

den Beitrag http://support.automation.siemens.com/WW/view/de/21523291

\2\ Siemens A&D Customer Sup-port

http://support.automation.siemens.com

\3\ OPC OPC DA 2.05a Specification unter http://www.opcfoundation.org/



http://support.automation.siemens.com/

http://www.opcfoundation.org/

applikation zur kommunikation - cache.industry.siemens.com · opc-kommunikation über das...

Documents