# OPC welche Lib



## citybreaker (7 Mai 2010)

Hallo!

Ich habe die Aufgabe Daten aus einem OPC Server auszulesen und soll
dazu einen Client programmieren. Ich habe schon einiges gegoogelt und informationen gefunden, aber das was ich suche war noch nicht dabei.

Welche Information ich nicht gefunden habe, welche Library man am besten benutzt und wo ich diese dann her bekomme.

Die Programmiersprache ist mir erst mal egal, ob VisualBasic, C++, C# oder Delphi ist erst mal zweitrangig.

Vielen dank schon mal im vorraus für eure Hilfe.


----------



## Nitrozin (10 Mai 2010)

Hi,

für den Client brauchst du die OPCDAAUTO.DLL.
Das Interface ist gut dokumentiert und du findest eine Menge Beispiele dazu im Netz.
Es gab schon Beitäge hier im Forum.
http://sps-forum.de/showthread.php?t=22512

Gruß Nitro


----------



## citybreaker (11 Mai 2010)

Ok dankeschön. Die Lib konnt ich nun herunterladen. Beim einbinden
in C# kommts allerdings zu ner Fehlermeldung das es sich Dabei um keine gültige Assembly oder Com Komponente handelt.

Für welche Programmiersprachen ist die Lib geeignet? Hab da leider auch
durch googlen und in der Forensuche keine Informationen zu finden können.


----------



## Dr. OPC (11 Mai 2010)

Die Automation Dll wird für das Automation Interface benötigt. Der OPC Server ist nichts anderes als eine COM Komponente (nach der Definition von MS) mit einem sogenanten Dual Interface. Es kann damit direkt mit C++ verwendet werden (unmanaged Code) das ist auch der effektivste Weg und liefert die größte Performance. 

Um mit Visual Basic oder Delfi gegen die COM Komponenten zu programmieren benötigt man die Automation DLL, diese setzt das Custom Interface in das Automation Interface um. Es handelt sich hierbei also um einen Wrapper, den Automation-Wrapper.

Für C# ist das alles noch einmal schwieriger, denn hier wird von managed gegen unmanaged Code programmiert. Dafür wird eine COM-Interop Komponente benötigt. Diese RCW und eine .NET API gibt es von der OPC Foundation.

Mein Tip: Programmiere in C++ dann a) lernst du was dabei und b) das Ergebnis ist performanter und c) du kannst auch knifflige Probleme lösen, Speicher, Verbindungsabbrüche, Timeouts,... wenn du die ATL verwendest ist es nicht mal schwierig und das Studio hat verschiedene Wizzards die dir helfen (obwohl du dann wieder nicht so viel lernt als wenn du es selber machst ;-)


----------



## citybreaker (11 Mai 2010)

Ok danke dir. Dann werd ich das ganze mit C++ machen.


----------



## Question_mark (11 Mai 2010)

*Dokterchen, darf ich mal korrigieren*

Hallo,



			
				Dr. OPC schrieb:
			
		

> Es [das Automation Interface] kann damit direkt mit C++ verwendet werden



Doktorchen darf ich da mal etwas korrigieren. Das Automation Interface ist für die Programmierung mit Visual Basic bestimmt, da VB nicht mit COM Interfaces umgehen kann und daher diese Performance fressende Krücke als Wrapper braucht.



			
				Dr. OPC schrieb:
			
		

> Um mit Visual Basic oder Delfi gegen die COM Komponenten zu programmieren benötigt man die Automation DLL, diese setzt das Custom Interface in das Automation Interface um.



Auch das ist nicht richtig. In Delphi kann ich direkt (also wie auch in C++) gegen das Custom Interface programmieren, irgendwie hast Du da die Programmiersprachen durcheinandergewürfelt.

Gruß

Question_mark


----------



## Dr. OPC (14 Mai 2010)

Sorry, das ist tatsächlich etwas misverständlich rüber gekommen.

Es [gemeint ist das DualInterface] ist zunächst mal eine Kombination aus Custom und Dispatch Interface. Das IDual wird direkt verwendet von sagen wir mal Sprachen, die Pointer beherrschen (vtable Zugriff auf Methoden), also C++ und Delfi (da hast du recht) und einige andere. Das DualInterface ist schneller (early binding), unterstützt im Unterschied zum "echten" Custom aber nur Automationtypen (von Dispatch "geerbt"). Es [immer noch das DualInterface] enthält zusätzlich das IDispatch Interface, dieses wird von allen Sprachen mit sagen wir mal einem Interpreteransatz verwendet z.B. VisualBasic, Scripting und anderen. Hier gibt es nur die Automation Datentypen. Zum Zugriff wird dabei ein Wrapper verwendet, der üblicherweise eine DLL ist und den Zugriff kapselt, der Zugriff ist langsamer (late binding). OPC Server sind COM Server und haben fast alle (zumindest die, die ich kenne) das Dual Interface.

Ich hoffe nun ist es klarer. Vermutlich nicht. Ich versuche es nochmal einfach.

1) "classic" OPC Server sind COM Server (also COM Objekte)
2) Sie haben ein DualInterface (ein Dispatch und ein auf Automationtypen reduziertes Custom Interface)
3) Direkter Zugriff über COM map, vtable nur mit Sprachen die diese Pointer beherrschen (Toolsupport schlecht ausser mit ATL, schnell)
4) Indirekter Zugriff über Wrapper DLL für Interpretersprachen (guter Toolsupport, langsam)


----------



## Ralle (14 Mai 2010)

Ich würde Folgendes empfehlen, wenn ihr ein wenig Geld erübrigen könnt: http://www.kassl.de/opc/index.shtml

Kostet wirklich nicht die Welt, funktioniert aber sehr gut!


----------



## david.ka (17 Mai 2010)

Hallo,

ich benutze diese Bibliothek.
http://www.codeproject.com/KB/COM/opcdotnet.aspx

Einige Projekte laufen schon seit Jahren fehlerfrei damit.
Programmiersprache: C#

Grüße
David


----------



## citybreaker (18 Mai 2010)

Danke schonmal. Werde mir die verschiedenen Sachen die ihr gepostet habt
in nächster Zeit mal genauer angucken und gucken was für mich am besten
geeignet ist.

Mit Rückfragen sind zu rechnen. ​


----------

