OPC-Client für .NET ?

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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Kurt schrieb:
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.

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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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/
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
 
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.
 
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 !!! :D
{oder%20
{was%20
{willst
Du}
uns}
damit}
sagen ???}
Naja, die Klammern gehen nicht ganz auf, sei nachsichtig :D
Gruss
Question_mark
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
Re: OPC Client

Question_mark schrieb:
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.

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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zottel schrieb:
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 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
 
Eine Anwendung, die beim Kunden dauernd abschmiert ist immer kritisch, die gehen dir dann ständig auf die Ei...
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
OPC-Client mit VB.NET

Hallo doc,
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
drfunfrock schrieb:
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.
 
Zottel schrieb:
drfunfrock schrieb:
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.

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
 
Zurück
Oben