IO-Link mittels IPC

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

wir sind gerade am überlegen wie man einen IO-Link Master an einen IPC anbindet.
Jetzt gibt es da ja verschiedene Optionen die einem ifm zB anbietet (MQTT / Modbus / Codesys Control).

Auf dem IPC ist ein Linux Derivat installiert (ich glaube Ubuntu).

Mit was habt ihr denn in der Konstellation gute Erfahrungen gemacht?

Danke soweit!

 

[Gerhard Bäurle]

@AUDSUPERUSER – hast Du eine Idee?

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Frage ist was willst du damit machen und mit welcher Art von Software willst darauf zugreifen UND wie willst du das Thema IO-Link Device Parametrierung angehen?

Ich hab mich damit auch vor knapp 2 Jahren beschäftigt und 3 Master mit MQTT und OPC evaluiert und die Idee aufgrund unserer Software, die das verwenden würde wieder verworfen.

Es gibt auch Master mit USB usw.

 

[Biiebs]

Wir haben gute Erfahrungen mit IO-Link + EtherCAT bei CODESYS-basierten Steuerungen gemacht. Lies sich auch problemlos integrieren. Wie immer, kocht auch jeder Hersteller "sein eigenes Süppchen" mit der API des IO-Link Masters, dieses Handling ist, je nach Steuerung, einfacher (durch vorhandene Bibliotheken) oder etwas komplexer (mehr Eigenimplementierung notwendig). Herstellerbezüglich habe ich hier schon gute Erfahrungen mit IFM oder Festo gemacht.

 

[maxder2te]

Wir haben gute Erfahrungen mit IO-Link + EtherCAT bei CODESYS-basierten Steuerungen gemacht.

Es geht dem TE wohl nicht darum ob IO-Link oder nicht und such nicht um die Anbindung an eine Steuerung.
Die Anbindung daran ist lediglich Arbeit, egal ob der IO-Link Master von Siemens, Balluff, Murrelektronik, IFM oder Pepperl & Fuchs heißt- das geht an einer Steuerung ratz-fatz.

@DCDCDC worum geht's bei der "IPC-Anbindung"?

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da es ja wohl darum geht von ein (windows?) PC aus, mit IO-Link Devices zu quatschen über ein IO-Link Master, sind die Möglichkeiten eher eingeschränkt.
Hersteller neutrale Implementierungen (MQTT, OPC, ...) sind ... sagen wir mal überschaubar.

 

[DCDCDC]

Ein Kollege hatte mich nur gefragt ob das möglich ist, ich glaube es ging um Taster/Sensoren.. kann ich aber am Montag noch mal genau nachhaken.

Wir hab eine kleine Maschine an der ein UR Roboter ein bisschen Material hin und her transportiert.. der IPC war bisher eigentlich nur als UI-Schnittstelle verwendet, da läuft halt Grafana und der andere Kram drauf..

Jetzt soll dort eben noch ein bisschen nachgerüstet werden und da kommt dann die Frage auf wie ich an einem IPC auf dem Linux läuft mit IO-Link umgehen kann.

Codesys Control ist mir da ins Auge gesprungen

CODESYS Control for Linux SL

CODESYS Control Linux SL is an IEC 61131-3-compliant SoftPLC for PC-based industrial controllers running on Linux with soft real-time properties.

store.codesys.com

Würde aber bedeuten, dass noch mal zusätzlich in eine Lizenz investiert werden muss.

MQTT wäre auch komplett in Ordnung, wir haben dafür eigene interne Wrapper für Python, müsste ich nur die Hardware auch dazu bekommen, Daten an den Broker zu senden.. der muss halt auch aufgesetzt sein auf dem IPC dann wahrscheinlich?

 

[maxder2te]

Ein Kollege hatte mich nur gefragt ob das möglich ist, ich glaube es ging um Taster/Sensoren.. kann ich aber am Montag noch mal genau nachhaken.

Wir hab eine kleine Maschine an der ein UR Roboter ein bisschen Material hin und her transportiert.. der IPC war bisher eigentlich nur als UI-Schnittstelle verwendet, da läuft halt Grafana und der andere Kram drauf..

Jetzt soll dort eben noch ein bisschen nachgerüstet werden und da kommt dann die Frage auf wie ich an einem IPC auf dem Linux läuft mit IO-Link umgehen kann.

Codesys Control ist mir da ins Auge gesprungen

CODESYS Control for Linux SL

CODESYS Control Linux SL is an IEC 61131-3-compliant SoftPLC for PC-based industrial controllers running on Linux with soft real-time properties.

store.codesys.com

Würde aber bedeuten, dass noch mal zusätzlich in eine Lizenz investiert werden muss.

MQTT wäre auch komplett in Ordnung, wir haben dafür eigene interne Wrapper für Python, müsste ich nur die Hardware auch dazu bekommen, Daten an den Broker zu senden.. der muss halt auch aufgesetzt sein auf dem IPC dann wahrscheinlich?

Ok, es handelt sich also um eine reine Einzellösung.
Prinzipiell ist sowohl CoDeSys als auch MQTT eine brauchbare Lösung dafür. Die MQTT-fähigen sind halt tatsächlich sehr dünn gestreut und außerdem eher teuer.

Ich hab 2022 mal einige Master evaluiert. Der Wunsch seitens unserer Server-Leute war, darüber Smartlights von Werma anzubinden. Am Tisch hatte ich Geräte von Pepperl&Fuchs, IFM und Murrelektronik. Ich hab sie eher in Hinblick auf OPC-UA untersucht.

Die Geräte von Pepperl&Fuchs und Murrelektronik waren ok, die kann man beide Standalone betreiben. Bei IFM bin ich schon beim IP-Adressen vergeben gescheitert und außerdem haben die nicht so ins Konzept gepasst, da die eher für den Betrieb Profinet + IIoT konzipiert sind - außerdem werden sie recht heiß. Preislich ist das Ganze zudem so angesiedelt, dass diese Master mehr gekostet haben als eine 1212C + IO-Link Master und für die S7-1200 haben wir Standard-Treiber am Server laufen. Für uns hats also nicht gepasst.
Da du eine Einzellösung baust fällt jetzt der Preis für einen IO-Link Master weniger ins Gewicht, die CoDeSys Lizenz wohl auch nicht - für dich ist wohl eher interessant was für die Implementierung einfach geht. Vom Faktor unkompliziert her ist da das Murrelektronik Modul 54620 mein Favorit.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mal kurz verglichen..

Murr IMPACT67 Pro PN DIO8 IOL8 M12L 4P - ca 550€
- kein MQTT Subscribe, aber REST und OpcUa (wäre auch eine beidseitige Kommunikation über OpcUa möglich?), Profinet Modul .. EthernetIP Modul ist Murr 54631
ifm AL1350 - ca 320€ .. anscheinend auch kein MQTT Subscribe, aber REST.. + komplette Dokumentation + Beispiele wie REST/MQTT zu nutzen sind, einstellbar über den Webserver LR Device usw.

 

[maxder2te]

Ich habe mal kurz verglichen..

Murr IMPACT67 Pro PN DIO8 IOL8 M12L 4P - ca 550€
- kein MQTT Subscribe, aber REST und OpcUa (wäre auch eine beidseitige Kommunikation über OpcUa möglich?), Profinet Modul .. EthernetIP Modul ist Murr 54631

Ja, und das Lesen und Schreiben von IO-Link Device-Parametern geht mittels ISDU-Methoden hab ich aber nur mit UAExpert durchgetestet. Hab mir dazu von Murrelektronik Module geborgt.

ifm AL1350 - ca 320€ .. anscheinend auch kein MQTT Subscribe, aber REST.. + komplette Dokumentation + Beispiele wie REST/MQTT zu nutzen sind, einstellbar über den Webserver LR Device usw.

Ok. das mit dem MQTT-Subscribe habe ich mir echt nicht angesehen.

Wie gesagt, wenn du eine Einzellösung suchst macht der Preisunterschied der beiden Module echt keinen Unterschied, außer du hast jemanden den du zum Stundensatz < 10€ einsetzt.

 

[DCDCDC]

Ich darfs wohl selbst machen

da wir kein wirtschaftliches Unternehmen sind, muss ich eh schauen was noch an Geldern auf dem Projekt vorhanden ist.. und dann muss ich die 230€ Differenz zwischen den beiden Produkten dem Controlling erklären.

Das mit OpcUa wäre noch ein gutes Argument für den Murr, ISDU sagt mir aktuell nichts, da müsste ich mich noch mal einlesen in die Thematik.

Aktuell gehts für mich nur darum Lösungen zu suchen, da wir hier nachrüsten fällt es mir leichter das mit "günstigeren" Lösungen durchzuboxen als mit teureren.

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

Muss es denn IP65/67 sein? Bei der Preisfindung die Verkabelung nicht vergessen, sind schnell ein paar € die zusammenkommen.

 

[DCDCDC]

Ich glaube nicht, dass 65/67 zwingend ist.. aber da wir an dem Ding auch aktuell mechanisch alles umbauen kann ich das nicht ganz sagen.. bin da nicht mit involviert.

 

[AUDSUPERUSER]

Jesses Gott
Wieder gefährliches Halbwissen unterwegs.

Falls das Thema noch aktuell ist, gerne per PN

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Falls das Thema noch aktuell ist, gerne per PN