Ablaufsteuerung mit OPC in CoDeSys

derhendrik

Level-1
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS-Forum

Zurzeit arbeite ich immer noch an einem Uniprojekt, bei dem es darum geht, eine Fertigungsanlage zu steuern. Diese besteht aus einzelnen Modulen, welche jeweils durch z.B. eine SPS (verschiedene Hersteller!) oder einen Microcontroller oder sogar Matlab (also richtig auf Windows 7) gesteuert werden.

Das Überwachen, Starten, Visualisieren etc. will ich gerne mit dem OPC DA Standard und einem entsprechendem Client auf einer zentralen Einheit umsetzen. Dabei soll zusätzlich auch die Ablaufsteuerung davon übernommen werden, diese ist relativ simpel (Modul A fertig, jetzt starte Modul B, etc)

Ist es möglich, dass man diese Ablaufsteuerung in CoDeSys auf der Control Win Soft-SPS umsetzt? Also im Klartext ist es dann ja wirklich Client-Tätigkeit, da die Soft-SPS sowohl die OPC items lesen, auswerten, und schreiben muss.

Leider bin ich mit meinem Latein bald am Ende, das einzige was ich gefunden habe, war dieser Post von 2006:
http://www.sps-forum.de/hochsprachen-opc/7651-codesys-opc-client.html

PS: Lese zurzeit viele Papers zum Beispiel zu "Real-time control with OPC" und so Zeug, worin wird das denn bitte alles programmiert? Alles in C?

Würde mich unheimlich über einen Tip freuen, wie ich das Problem angehen soll.
Falls ihr dazu mehr Informationen braucht, lasst es mich wissen!

Mittlerweile bin ich soweit, dass ich das alles einfach mit Python machen möchte, da es dort gute Bibliotheken und Dokumentation gibt.
Das fehlt bei OPC leider fast vollständig. Nach meiner anfänglichen Euphorie bezüglich OPC steh ich der ganzen Sache nun etwas kritischer gegenüber =)
Wichtige Lektion, die ich aber gelernt habe: "Open" ist nicht gleich "Free"

Gruß,

Hendrik
 
Hallo Hendrik,

der OPC ist ja dazu da, eine standardisierte Schnittstelle zu bieten.
Den sehe ich da aber eher bei der Visualisierung im Spiel. Denn diese setzen immer auf OPC auf (sofern sie nicht vom gleichen Hersteller ist und direkt kommuniziert).

Ich persönlich würde mir einen Bus aussuchen, den alle in Frage kommenden Hersteller ohne großen Aufwand unterstützen. Umgebungsbedingungen spielen da natürlich auch rein. Da gibt es ja einige:
- CAN
- Profibus
- ASi
- Seriell (RS485 / RS422 / RS232) z.B. Modbus
- Ethernet (z. B. auch Modbus TCP oder Profinet)

Über diesen Bus würde ich dann alle Steuerungen verbinden und eine Standardschnittstelle (als Benutzerdefinierten Datentypen z.B. der dann im DB oder im Variablenbereich abgelegt werden kann) definieren.
Dann hast Du ohne einen Man-In-the-Middle eine Kommunikation untereinander - auch relativ schnell.
Die Zentrale kannst Du dann gestalten, wie Du es willst. Kann dann auch ein PC sein mit einer Soft-SPS.

Die Visualisierungsdaten kann man dann entweder zentral abrufen - mußt die dann aber auch natürlich zentral sammeln (Fällt der zentrale Knoten aus, ist auch die Visu platt) - oder Du sammelst die dann von jedem Modul ein. Dann können einzelne Module ausfallen, aber die funktionierenden können eventuell weiterarbeiten.
Das wiederum kannst Du dann über OPC machen.

Hoffe, das hilft erst einmal weiter.

Gruß
JS

PS: "Open" heißt nur, daß die Spezifikationen offengelegt sind. Heißt aber nicht, daß es auch zu allem eine Community gibt, die das "frei" programmiert. Die Hersteller lassen sich die Entwicklung natürlich bezahlen.
Wenn Du OPC-Server zum Testen suchst, kannst Du mal bei Matrikon gucken. Da kannst Du die meisten als Student kostenfrei nutzen - ohne Einschränkungen. Aus eigener Erfahrung muß ich sagen, daß die Leute von Matrikon sogar Studenten recht gut Supporten, wenn man konkrete Fragen hat.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Erstmal vielen Dank für deine ausführliche Antwort!

Sowas habe ich schon fast befürchtet, dass OPC in der eigentlichen Ablaufsteuerung nicht viel zu suchen hat ...

Zurzeit scheint Modbus TCP eine gute Möglichkeit zu sein, da ich eine funktionierende Arduino-Bibliothek dazu gefunden habe und es sich auch mit Matlab verwenden lässt. Da bedingt durch die Matlabsteuerung sowieso ein PC läuft und es keine harten Echtzeitanforderungen gibt, werde ich wohl eine SoftSPS nutzen. Diese soll dann hoffentlich auch alle relevanten Variablen als OPC items zur Verfügung stellen (die Codesys win control kommt ja beispielsweise auch mit einem OPC Server), um später mit einer HMI-Software auf sie zugreifen zu können. Ab da besteht dann ja wieder relativ viel Gestaltungsspielraum.

Ich finde, dass sich das in der Theorie schonmal ganz plausibel anhört. Hoffentlich lässt sich dies auch in der Praxis so umsetzen.

Danke nochmals! Freue mich natürlich immer über einen Input, wie man solche Systeme anders gestalten kann.

Hendrik
 
Zurück
Oben