# OPC-Client für .NET ?



## drfunfrock (12 Oktober 2004)

Hat jemand Erfahrung mit einem OPC-Client-Interface für .NET ? Ich kenne mich da überhaupt nicht aus. Ich möchte das Data-Binding für VB benutzen.


Doc Funfrock


----------



## Kurt (12 Oktober 2004)

Hallo Hr. Doktor,

Schau mal HIER DA:
http://www.metadynamics.com/opcclientxnet_brochure_p1.htm
Das sollte dir das Leben sehr erleichtern.

Ich kenn mich damit nicht aus, denn ich verwende DASS und kann das nur empfehlen! 
Funktioniert aber mit der Einheitsbrei Programmierumgebung nicht.

Kurt

_Bevor ich jetzt zerissen werde, Begründung:
Einheitsbrei... 
Server, Betriebsystem, Officepaket, Zubehör, Programmiertool vom selben Hersteller = Tod der Vielfalt = Tod des Wettbewerbes = Tod der Weiterentwicklung/Innovation._


----------



## Question_mark (12 Oktober 2004)

*OPC Client*

Hallo Kurt,


> denn ich verwende DASS und kann das nur empfehlen!


genau, DASS habe ich auch verwendet und das funzt super. Es gibt eben auch Sachen, die leider unbekannt und deshalb verkannt sind, eben ausserhalb des Einheitsbreis Entwicklungsumgebung. Aber die funktionieren halt sogar unter M$ Windoof jahrelang und problemlos.
Die Clients für DA 1.0, DA 2.0, AE 1.1 und HDA 1.0 habe ich mir dann allerdings selber schon vorher als Komponenten für diese Programmierumgebung geschrieben, spart einiges an Lizenzkosten.
In diesem Sinne,
Gruss
Question_mark


----------



## drfunfrock (12 Oktober 2004)

Kurt schrieb:
			
		

> Hallo Hr. Doktor,
> 
> Schau mal HIER DA:
> http://www.metadynamics.com/opcclientxnet_brochure_p1.htm
> ...



Ja, du hast im Grunde recht, nur bekomme ich kein Geld für Alternativen, weil ... VB kennt man eben. VB .NET ist ja auch schon ein Fortschritt. Am liebsten hätte ich mir eine schöne Linux-Lösung gewünscht, aber das wird noch die nächsten 20 Jahre ein Traum bleiben.

Ach ja, dein Tip ist nicht übel...


Doc Funfrock


----------



## Question_mark (12 Oktober 2004)

*OPC Client*

Hallo doc,
also eine industrielle Anwendung in VB.Net schreiben, davon würde ich lieber die nächsten 20 Jahre nur träumen und die Finger davon lassen.
Aber um mal was konstruktives beizutragen, hier ein Link, wo evtl. Fragen kompetent beantwortet werden :
http://www.opcfoundation.org/forum/
Manchmal trifft man mich dort auch, allerdings unter einem anderem Nick.
Gruss
Question_mark


----------



## drfunfrock (12 Oktober 2004)

*Re: OPC Client*



			
				Question_mark schrieb:
			
		

> Hallo doc,
> also eine industrielle Anwendung in VB.Net schreiben, davon würde ich lieber die nächsten 20 Jahre nur träumen und die Finger davon lassen.
> Aber um mal was konstruktives beizutragen, hier ein Link, wo evtl. Fragen kompetent beantwortet werden :
> http://www.opcfoundation.org/forum/
> ...



Nun die Anwendung ist in dem Sinne nicht kritisch, als dass sie "nur" den Zustand der Anlage auf dem Schirm darstellt und zum einstellen wichtiger Betriebsparameter beim Start dient. Bisher läuft diese Anwendung mit VB6 und einem OCX-Controll als Client. Es kann also nicht schlechter werden. Delphi ist zwar besser, aber hier gänzlich unbekannt. Die Vorbehalte sind gross. Ehrlich gesagt ich habe auch keine Lust eine Diskussion im Betrieb um eine gute Software zu führen. Nachdem die SPS neu ist, ist der Wille zu weiteren Veränderungen nicht gerade stark.

Wir arbeiten hier mit  Beckhoff TwinCat und ich bin schon am überlegen, ob wir nicht am ADS-Interface aufsetzen, weil Beckhoff, dass mit seinem OPC-Server auch macht. Eigentlich will ich aber nur ein paar Komponenten die direkt an die SPS per OPC/ADS über eine Connect-Class gekoppelt werden, ohne dass wir hier grossartig Code schreiben müssen.

Doc Funfrock


----------



## Zottel (12 Oktober 2004)

drfunfrock schrieb:
			
		

> ...am liebsten hätte ich mir eine schöne Linux-Lösung gewünscht, aber das wird noch die nächsten 20 Jahre ein Traum bleiben.


Wie lang hast du Zeit und wieviel willst du mitarbeiten?
Warst du es, der auch schon im Forum nach OPC für Linux gefragt hat?
Ich habe da noch so eine Idee:
Ich möchte nicht den Overhead von COM und DCOM unter Linux nachbilden. OPC nutzt DCOM und legt ja schon fest, welche Objekte es braucht oder welche Objekteigenschaften die von OPC definierten Objekte haben.
Ein Linux (Pseudo)-OPC(nicht DCOM!)-Client oder -Server bräuchte ja nichts weiter zu tun, als die "richtigen" Pakete über´s Netz zu schicken. Wie er die intern erzeugt, ist egal.


----------



## Question_mark (12 Oktober 2004)

*OPC Client*

Hallo doc,


> die Anwendung ist in dem Sinne nicht kritisch


nee, die Anwendung ist sicher nicht kritisch, aber was ist mit VB.Net, das ist der kritische Punkt.
@Zottel


> Ein Linux (Pseudo)-OPC(nicht DCOM!)-Client oder -Server


Ähemm, Du bist uns aber weit voraus !!!   
{oder%20
{was%20
{willst
Du}
uns}
damit}
sagen ???}
Naja, die Klammern gehen nicht ganz auf, sei nachsichtig   
Gruss
Question_mark


----------



## Question_mark (12 Oktober 2004)

Hallo Zottel,
ne ich hab schon verstanden :


> die "richtigen" Pakete über´s Netz zu schicken. Wie er die intern erzeugt, ist egal.


Aber : Nein, erstmal muss der Transfer auf dem eigenen PC realisiert werden, also "COM". Danach der Transfer über PC's im Netzwerk, also "DCOM". Bei Transfer der Pakete über "COM" bleibt erstmal alles dem OS (hier nun mal nur M$) überlassen. Damit ist der Sack zu.
Danach können wir uns über die "richtigen" Pakete über's Netz unterhalten.
Gruss
Question_mark


----------



## Zottel (12 Oktober 2004)

> Aber : Nein, erstmal muss der Transfer auf dem eigenen PC realisiert werden, also "COM". Danach der Transfer über PC's im Netzwerk, also "DCOM".
> Bei Transfer der Pakete über "COM" bleibt erstmal alles dem OS (hier nun mal nur M$) überlassen. Damit ist der Sack zu.
> Danach können wir uns über die "richtigen" Pakete über's Netz unterhalten.


Die "richtigen" Pakete kann der PC auch an sich selbst schicken. Dafür kennt Linux das "loop back interface" lo, damit kannman so ziemlich jede Client-Server-Kommunikation auf einem Rechner Abbilden.
Aber mir geht es gar nicht um COM und DCOM.
Die können eine Menge. Ein Objekt kann ein ganzes EXCEl-sheet sein, samt eingebetteten (OLE-)Objekten. OPC nutzt nur einen kleinen Teil davon.
Das folgende kann im Detail ziemlich weit neben der Realität liegen, aber im Prinzip sagt der OPC-Client: 
"Server, liste mir die Objekte auf."
Der Server sagt:
"Nr:1 typ:integer Bezeichnung:Merkerwort_1 Wert: 17"
...
"Nr:22 typ:integer Bezeichnung:Merkerwort_22 Wert: 177"
oder:
"Nr:1 typ:array of integer Bezeichnung:Merkerworte Wert(1,2,3,17,...177)"

Das alles natürlich binär verschlüsselt. (D)COM übermittelt
Aktualparameter für einen Funktionsaufruf im anderen Programm oder auf dem anderen Rechner. Das Umkodieren in eine gemeinsame Schreibweise und das Anhängen von Metainformationen (wieviele Bytes, die 4 Bytes sind float oder longint) heißt im COM-Jargon "Marshalling". Statt das bei jedem übertragenen Wert nach den Regeln zu generieren, würde der Pseudo-OPC-Server in eine Muster-Bytefolge für ein "marshalled float" den richtigen Wert reinkopieren und das Ergebnis an das Paket anhängen.
Von Objekte, Methoden, Marshalling und remote procedure calls muß er dazu nix wissen.


----------



## drfunfrock (13 Oktober 2004)

*Re: OPC Client*



			
				Question_mark schrieb:
			
		

> Hallo doc,
> 
> 
> > die Anwendung ist in dem Sinne nicht kritisch
> ...



Warum? Schlimmer als mit VB6 kann es doch nicht sein oder? Hast du da Erfahrungen? Die Anwendung glücklicherweise erfüllt nur unkritische Aufgaben  und läuft nicht auf dem Soft-SPS-PC. Jedenfalls läuft die SPS auch ohne OPC-Client-Anwendung. 

Doc Funfrock


----------



## drfunfrock (13 Oktober 2004)

Zottel schrieb:
			
		

> drfunfrock schrieb:
> 
> 
> 
> ...


Ich hatte zwar nicht nach OPC gefragt, aber das mit dem Mitarbeiten kann man sich überlegen.



			
				Zottel schrieb:
			
		

> Ich habe da noch so eine Idee:
> Ich möchte nicht den Overhead von COM und DCOM unter Linux nachbilden. OPC nutzt DCOM und legt ja schon fest, welche Objekte es braucht oder welche Objekteigenschaften die von OPC definierten Objekte haben.
> Ein Linux (Pseudo)-OPC(nicht DCOM!)-Client oder -Server bräuchte ja nichts weiter zu tun, als die "richtigen" Pakete über´s Netz zu schicken. Wie er die intern erzeugt, ist egal.



Da gibt es schon etwas  www.opcconnect.com  und zwar einen OPC-Server der auf Linux läuft. Nur der Beckhoff-OPC-Server läuft nicht auf dem PC  mit TwinCat, sondern bezieht seine Daten über das Beckhoff-eigene Protokoll ADS, welches im übrigen von der Schnittstellenseite gut dokumentiert ist. Der Hintergrund ist der, dass Beckhoff von DCOM abrät. Da ich keine Ahnung von der Stabilität von DCOM habe, glaube ich das erst einmal. Eine Linux-Lösung ist daher  nur dann für mich zu realisieren, wenn ich den OPC-Server mit auf den PC für die Soft-SPS installiere. Eigentlich müsste man für Linux nur einen DCOM-Aufruf implementieren. So etwas müsste es doch geben, oder?

Übrigens unser Kunde hat hier seinen Linux-PC stehen, der Nummerkreise verwaltet und die Testelektronik steuert und das alles mit Perl. Dieser PC mit Debian ist wunderbar stabil, auch wenn das Konzept mir nicht in den Kram passt, weil es wieder ein Gerät ist, dass ausfallen kann und ein Kunde die Konntrolle über etwas hat.

Doc Funfrock


----------



## Ralle (13 Oktober 2004)

Eine Anwendung, die beim Kunden dauernd abschmiert ist immer kritisch, die gehen dir dann ständig auf die Ei...


----------



## drfunfrock (13 Oktober 2004)

Ralle schrieb:
			
		

> Eine Anwendung, die beim Kunden dauernd abschmiert ist immer kritisch, die gehen dir dann ständig auf die Ei...



Jepp, nur von welcher weiss du das im vorraus? Ob Windows, Unix oder sonst etwas überall finden sich Programme, die nicht laufen. Und oft weisst du noch nicht  einmal, an wem es liegt.


Doc Funfrock


----------



## drfunfrock (13 Oktober 2004)

Zottel schrieb:
			
		

> Aber : Nein, erstmal muss der Transfer auf dem eigenen PC realisiert werden, also "COM". Danach der Transfer über PC's im Netzwerk, also "DCOM".
> Bei Transfer der Pakete über "COM" bleibt erstmal alles dem OS (hier nun mal nur M$) überlassen. Damit ist der Sack zu.
> Danach können wir uns über die "richtigen" Pakete über's Netz unterhalten.




Ich habe etwas gefunden http://freedce.sourceforge.net/

Doc Funfrock


----------



## Question_mark (13 Oktober 2004)

*OPC-Client mit VB.NET*

Hallo doc,


> Ich habe etwas gefunden http://freedce.sourceforge.net/


Ich glaube, auf der Seite hat sich seit 2001 nichts mehr getan, der Projektstatus ist auch nicht klar angegeben (Status 1-6 ???).
Hast Du das schon ausprobiert oder ist das auch nur so ein Projekt, dass von 2-4 Leuten voller Enthusiasmus angefangen wird und dann im Laufe der Jahre im Alpha-Status dahinvegetiert und nie beerdigt wird ?
Wenn das wirklicht funzt, dann fehlt ja nur noch der OPC-Proxy, der sollte sich doch in ein paar Jahren zum stable-release entwickeln lassen.  :wink: 
Gruss
Question_mark


----------



## Anonymous (13 Oktober 2004)

*OPC Client in VB.NET*

Hallo doc,


> dass Beckhoff von DCOM abrät


Der Grund dafür liegt nicht in der Stabilität von DCOM, sondern darin, dass die Sicherheitseinstellungen des M$ Windoof oft die Kommunikation über DCOM verhindern. Der noob ist manchmal bei den Einstellungen etwas überfordert, dann funktioniert halt eine Kommunikation über DCOM nicht. Man findet halt eine überproportionale Anzahl von Beiträgen mit Problemen bei OPC-Verbindungen im OPC-Forum, alle haben Probleme mit den Windoof Sicherheitseinstellungen. Sind die einmal richtig eingestellt, laufen die DCOM-Verbindungen jahrelang ohne Probleme.
Ich habe das so geregelt, dass mein OPC-Client im Anlauf die Sicherheitsregeln per Programm selber setzt. Hat eigentlich alle DCOM-Probleme gelöst.   :wink: 
Gruss
Question_mark


----------



## Question_mark (13 Oktober 2004)

*OPC Client mit VB.NET*

Hallo doc,
das vorige posting (als Gast) war von mir, das Forum hat mich mal wieder rausgeschmissen, altes Problem, aber immer noch nicht gelöst  :twisted:  :twisted:  :twisted: 
Gruss
Question_mark


----------



## Zottel (13 Oktober 2004)

drfunfrock schrieb:
			
		

> Ich habe etwas gefunden http://freedce.sourceforge.net/


Ja, kenne ich auch, habe ich (vor ca. 20 Monaten) runtergeladen. Zunächst mal haben sie eine DCOM- (oder COM-?) Unterverzeichnis, aber genau dessen Inhalt lies sich nicht übersetzen (habe vergessen warum, aber es war nicht in 1-2 Abenden hinzubekommen).
@question-mark: Ich habe auch ab und zu nachgeschaut, aber schon länger nicht mehr. Vielleicht sollte man einen der Entwickler ansprechen. Mancher ist vielleicht frustriert, weil er mehr Resonanz für seine Ideen erwartet hätte. Kenne ich aus eigener Erfahrung.

@dr-funfrock: Wenn du Beckhoff über ADS anbinden willst, ich habe dafür funktionsfähigen (aber etwas unreifen) C-Code für Linux, der eigentlich auch mal als eigenes Projekt auf sourceforge erscheinen sollte.


----------



## drfunfrock (13 Oktober 2004)

Zottel schrieb:
			
		

> drfunfrock schrieb:
> 
> 
> 
> ...



Ich denke die Zielgruppe ist auch ziemlich klein. Wer sich mit so etwas beschäftigt, der muss schon ziemlich abgedreht sein. 8) Ich freue mich schon auf so eine Arbeit   :twisted: 



> @dr-funfrock: Wenn du Beckhoff über ADS anbinden willst, ich habe dafür funktionsfähigen (aber etwas unreifen) C-Code für Linux, der eigentlich auch mal als eigenes Projekt auf sourceforge erscheinen sollte.



Ich wäre sehr daran interessiert. Ich werde es in der Firma leider nicht noch nicht einsetzen können. Aber wer weiss, mal schauen was sich machen lässt. Im Prinzip ist der Bedarf da.


Doc Funfrock


----------



## Zottel (13 Oktober 2004)

drfunfrock schrieb:
			
		

> Ich wäre sehr daran interessiert. Ich werde es in der Firma leider nicht noch nicht einsetzen können. Aber wer weiss, mal schauen was sich machen lässt. Im Prinzip ist der Bedarf da.


Ich häng´ dir hier mal das Archiv von dem Arbeitsverzeichnis dran. Ich hab es an einer Stelle in der Firma im Einsatz (Rechner fragt Meßwerte von einem BC9000 ab.). 
Den Code habe ich geschrieben, als es mir stank, daß ich bei Verwendung von Modbus TCP mit ganz wenigen von Modbus ansprechbaren Speicherstellen auskommen sollte. 
Ich weiß im Moment aber nicht, ob ich noch später noch wesentliche Fehler ausgebügelt habe. Die Prgramme enthalten hart kodierte IP- und AMS-Adressen.
Wennn du Schwierigkeiten hast, melde dich halt.


----------



## drfunfrock (14 Oktober 2004)

*Re: OPC-Client mit VB.NET*



			
				Question_mark schrieb:
			
		

> Hallo doc,
> 
> 
> > Ich habe etwas gefunden http://freedce.sourceforge.net/
> ...



Ich habe es nicht probiert. Ich habe nach einer Eingebung nur dir richtigen Stichworte zum Suchen gehabt.  Aber selbst wenn es Alpha ist, dann könnte die Struktur einem weiterhelfen.


Doc Funfrock

Doc Funfrock


----------



## drfunfrock (14 Oktober 2004)

Zottel schrieb:
			
		

> drfunfrock schrieb:
> 
> 
> 
> ...



Danke!

Doc Funfrock


----------



## seeba (25 Juli 2005)

Hallo,
ich habe ein VB.NET Programm enwickelt, das in MySQL schreibt und Änderungen liest und auf den OPC zurückschreibt. Bei Interesse bitte: mail@sebastian-narz.de oder besser s.narz@narz.net
Lässt sich bestimmt was machen   

Gruß Sebastian


----------



## Josef (29 September 2005)

Zottel schrieb:
			
		

> ... samt eingebetteten (OLE-)Objekten...



Hallo Mitglieder,

OPC steht für "OLE for proces control"
kann aber nicht herausfinden für was "OLE" steht.
Es ist das Komponentenmodell der Fa. Microsoft
aber die genaue Bedeutung der Abkürzung fehlt mir noch.

mfg
Josef


----------



## Zottel (29 September 2005)

*O*ject *L*inking and *E*mbedding.
Der neuere "MS-Speak" ist COM=Common Object Model.
Wenn die Objekte über mehrere Rechner verteilt werden, DCOM = Distributed COM


----------

