drfunfrock
Level-1
- Beiträge
- 934
- Reaktionspunkte
- 72
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.denn ich verwende DASS und kann das nur empfehlen!
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.
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
Wie lang hast du Zeit und wieviel willst du mitarbeiten?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.
nee, die Anwendung ist sicher nicht kritisch, aber was ist mit VB.Net, das ist der kritische Punkt.die Anwendung ist in dem Sinne nicht kritisch
Ähemm, Du bist uns aber weit voraus !!!Ein Linux (Pseudo)-OPC(nicht DCOM!)-Client oder -Server
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.die "richtigen" Pakete über´s Netz zu schicken. Wie er die intern erzeugt, ist egal.
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 : 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.
Question_mark schrieb:Hallo doc,
nee, die Anwendung ist sicher nicht kritisch, aber was ist mit VB.Net, das ist der kritische Punkt.die Anwendung ist in dem Sinne nicht kritisch
Ich hatte zwar nicht nach OPC gefragt, aber das mit dem Mitarbeiten kann man sich überlegen.Zottel schrieb:Wie lang hast du Zeit und wieviel willst du mitarbeiten?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.
Warst du es, der auch schon im Forum nach OPC für Linux gefragt hat?
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.
Ralle schrieb:Eine Anwendung, die beim Kunden dauernd abschmiert ist immer kritisch, die gehen dir dann ständig auf die Ei...
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 glaube, auf der Seite hat sich seit 2001 nichts mehr getan, der Projektstatus ist auch nicht klar angegeben (Status 1-6 ???).Ich habe etwas gefunden http://freedce.sourceforge.net/
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.dass Beckhoff von DCOM abrät
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).drfunfrock schrieb:Ich habe etwas gefunden http://freedce.sourceforge.net/
Zottel 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).drfunfrock schrieb:Ich habe etwas gefunden http://freedce.sourceforge.net/
@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.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?