OPC

Noel Moeller schrieb:

Und was nun?

Gruß Dieter

"Dieter Wiedmann" schrieb

mehr!

Noel Moeller schrieb:

Troll dich.

Noel Moeller schrieb:

Es gibt in D mindestens einen Anbieter, der für OPC Programmodule anbietet. Genau kann ich das jetzt nicht sagen, weil ich das Thema für mich weitgehend zu den Akten gelegt habe.

Wir haben seinerzeit entsprechende Bibliotheken eingekauft und in Delphi einiges in der Richtung programmiert.

Die Quelle finde ich jetzt nicht, aber hier gibt es anscheinend etwas:

Hat im Prinzip funktioniert, war aber irgendwie Murks. Vorteil ist, wenn du ein Gerät einkaufst, für das es einen OPC-Server gibt, dann kannst du mit einiger Sicherheit davon ausgehen, dass du dort Daten auslesen kannst. Ob der OPC-Server auch im Netzwerk funktioniert, und ob er die Daten liefert, die du benötigst, ist wohl Glückssache. Performance ist auch eher bescheiden.

Der Hammer war, (noch zu Windows 2000 Zeiten), dass nach einem Update des Internet-Explorers DCOM nicht mehr funktionierte, was bei einem meiner Kunden zum Ausfall diverser OPC-Anwendungen führte.

Wenn es darum geht, irgendwo per Software auf OPC-Daten zuzugreifen, ist das soweit schon ok. aber nicht als Basis für eigenen Automatisierungskonzepte, Datenerfassung in Industriebetrieben, Produktionsdatenerfassung etc.

Gruß

Stefan DF9BI

"Stefan" schrieb

Neuerdings gibt es ja OPC-UA, welches über Sockets und XML kommuniziert und nicht mehr über AktiveX/DCOM usw.

so schlecht?

Es gibt prof. Client-SW, die nur über das Zeug funktionieren?!?! Da leben einige Firmen davon...

Schlecht eigentlich nicht, nur du kannst dich nicht darauf verlassen, dass alle Server auch tatsächlich das machen, was sie sollen.

Das ist wohl eher ein grundsätzliches Problem. Jeder sucht nach einer Standardlösung und jedes Grüppchen definiert einen eigenen Standard für die Kommunikation zwischen Automatisierungsgeräten. Es gibt sogar eine spezielle Norm für Automatisierungskomponenten, die in der Landwirtschaft eingesetzt werden.

Als eine von vielen Schnittstellen ist OPC keine schlechte Lösung. Wenn du eine Maschine mit OPC-Schnittstelle kaufst, kannst du wohl davon ausgehen, dass du an die Daten ran kommst, aber ob das auch im Netzwerk funktioniert, und mit der erforderlichen Performance, und ob das alles wirlich so einfach ist, ist dann noch die Frage...

Dass das jetzt nicht mehr mit DCOM läuft ist ja ganz nett, nur was machst du mit alten Maschinen, die noch das alte System haben?

Mein Eindruck ist, dass viele sogenannte "Standard-Schnittstellen" die Sache nur unnötig kompliziert machen.

Was man eigentlich braucht, ist eine unkomplizierte und gut dokumentierte Schnittstelle zur jeweiligen Anlage.

Gruß

Stefan DF9BI

"Stefan" schrieb

Gut dokumentiert sollte das sowieso sein, auch bei Verwendung genormter Schnittstellen, aber ohne Normung, wäre der Arbeitsaufwand wieder enorm hoch.

Joern Bock schrieb:

Würde ich nicht sagen. Wenn es ein klar definiertes einfaches Protokoll gibt, ist das oft einfacher als die Implementierung irgendwelcher unnötig komplizierten Industriestandards.

Übel ist auch, wenn es keine öffentliche Doku zu den Standards gibt und man nur Treiber kaufen kann. Manchmal hat man den Eindruck, man ist der erste, der das Produkt gekauft hat und ärgert sich mit Treibern anderer Leute rum.

Da ist es mir schon erheblich angenehmer, wenn ich mich nur mit meinen eigenen Schnittstellen rumschlagen muss.

Beispiel SPS. Da gibt es Ethernet-Interface für z.B. Siemens SPSe, mit denen per TCP/IP auf S7-Steuerungen zugegriffen werden kann. Anstatt, dass man dort nun einfach per Socket-Kommunikation Daten abfragen kann, muss man einen Treiber verwenden, der eigentlich immer irgendwelche undurchschaubaren Probleme bereitet.

Gruß

Stefan DF9BI