OPC-Client für .NET ?

[drfunfrock]

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]

Hallo Hr. Doktor,

Schau mal HIER DA:
http://www.metadynamics.com/opcclien...rochure_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]

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]

Hallo Hr. Doktor,

Schau mal HIER DA:
http://www.metadynamics.com/opcclien...rochure_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.

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]

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]

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/
Gruss
Question_mark

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]

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

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]

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]

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.