Grundsatzfrage zu iO-Link

evelkneevel

Level-2
Beiträge
38
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

ich habe mal eine Grundsätzliche Frage zu iO-Link. Wir, als kleiner Maschinenbauer, überlegen aktuell in wie weit wir iO-Link in unsere Anlagen einbauen wollen/müssen.
Aktuell haben wir noch gar nichts in die Richtung eingebaut. Bei der Steuerungstechnik setzen wir komplett (SPS, FUs, IOs) auf Siemens und dabei werden wir auch bleiben. In der alten Firma haben wir in der Instandhaltung und für Retrofits schon viel mit iO-Link gemacht. Aber da war man halt immer direkt an der Maschine, wenn irgendwas war. Ich frage auch lieber hier nach, weil die Vertreter und Verkäufer einem ja alles verkaufen.
Grundsätzlich finde ich iO-Link auch ne gute Sache.
Das Problem sehe ich allerdings in der Instandhaltung, wenn nach 10 Jahren, die Anlage beim Kunden einen Sensordefekt erleidet und genau der Sensor nicht mehr lieferbar ist. Da ich ja das Rumgehampel mit den ganzen TIA Versionen schon einige Zeit mitmache, weiß ich nicht, ob das so geil wird, wenn man die Hardware nochmal ändern muss nach so einer langen Zeit. Alle "normalen" Inis kann man ja einfach gegen irgendwas adäquates austauschen, aber bei iO-Link hab ich da halt meine Bedenken.
Bei den iO-Link Mastern von z.B. IFM sieht man in der SPS ja nur das oder die EA-Bytes, aber nicht den Ini. Bei den Siemens Mastern (für die ET200SP) mit dem PCT sieht man ja wirklich den Ini, bzw. ändern sich ja die Adressen, wenn sich die EA-Bytes vom Sensor ändern. Wir würde auch nicht jeden Digitalen Ini auf iO-Link umbauen, aber ggf. den ganzen Analog Kram (Druck, Durchfluss, Positionen usw.).
Habt ihr in der Hinsicht schon Erfahrungen gesammelt? Also nicht nur für die IBN, sondern wirklich im Bereich Instandhaltung, wenn mal ein Sensor nicht mehr genauso lieferbar ist. Oder sind meine Bedenken unbegründet? Oder gibt es Einstellungsmöglichkeit in den iO-Link Mastern, damit man problemlos die Inis einfach durchtauschen kann?

Gruß,
Dome
 
Zuviel Werbung?
-> Hier kostenlos registrieren
IO-Link kann ja viel mehr als nur den Verdrahtungsaufwand zu reduzieren.

Die Frage ist, ob ihr diese Funktionen benötigt/anbieten wollt?

wenn mal ein Sensor nicht mehr genauso lieferbar ist. Oder sind meine Bedenken unbegründet? Oder gibt es Einstellungsmöglichkeit in den iO-Link Mastern, damit man problemlos die Inis einfach durchtauschen kann?
Der IO-Link Master speichert sich die Konfiguration für einen Port, wird dort nun ein Sensor getauscht und durch einen typgleichen ersetzt, wird die Konfiguration direkt auf den Sensor übertragen.

Da IO-Link ein offener Standard ist, kannst du einen IO-Link-fähigen typgleichen Sensor eines Herstellers deiner Wahl verwenden.
 
Moin,

das Thema IO-Link beschäftigt uns auch.

Der IO-Link Master speichert sich die Konfiguration für einen Port, wird dort nun ein Sensor getauscht und durch einen typgleichen ersetzt, wird die Konfiguration direkt auf den Sensor übertragen.

Da IO-Link ein offener Standard ist, kannst du einen IO-Link-fähigen typgleichen Sensor eines Herstellers deiner Wahl verwenden.
Was ist denn typgleich? Woran erkennt man das?
Ich habe im Prinzip die gleichen Bedenken, wie @evelkneevel : Was passiert nach ~10Jahren? Sollte man auf "Spezialtypen" verzichten? Wie ist das mit Safety?
Alles, was konfiguriert werden muss, ist aus Instandhaltersicht schwieriger zu handeln. Und wenn es nur darum geht, dass der "einfache" Elektriker sagt: "Das ist mit Software ... das pack ich nicht an."
Das ist zwar ein bisschen dumm und kurz gedacht, aber in Zeiten des Fachkräfte- oder Kräftemangels ein Thema, das man bedenken sollte.

VG
MFreiberger
 
Der IO-Link Master speichert sich die Konfiguration für einen Port, wird dort nun ein Sensor getauscht und durch einen typgleichen ersetzt, wird die Konfiguration direkt auf den Sensor übertragen.

Da IO-Link ein offener Standard ist, kannst du einen IO-Link-fähigen typgleichen Sensor eines Herstellers deiner Wahl verwenden.
Das ist ein Grund warum wir nicht die Backup & Restore Funktion nutzen wollen sonder alles aus dem SPS Programm einstellen wollen. Das wir bei unseren Serienmaschinen verschieden Sensoren einbauen können.

Es kann nämlich nicht einfach ein Sensor von einem anderen Hersteller eingebaut werden, die sind über Vendor und Device ID fest.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dem IO-Link Master ist es egal ob du einen Drehzahlsensor in NPN Ausführung von ifm (MX5017) oder einem anderen Hersteller nimmst.
Sollte es den MX5017 mal nicht mehr geben sondern einen MX6017, der aber typgleich ist, kannst du einfach den anschliessen.

Da IO-Link ein offener Standard ist, muss eben jede IO-Link-fähige Baugruppe den Planungsrichtlinien entsprechen.

 
Das ist ein Grund warum wir nicht die Backup & Restore Funktion nutzen wollen sonder alles aus dem SPS Programm einstellen wollen. Das wir bei unseren Serienmaschinen verschieden Sensoren einbauen können.

Es kann nämlich nicht einfach ein Sensor von einem anderen Hersteller eingebaut werden, die sind über Vendor und Device ID fest.
IO-Link gibt dir aber die Möglichkeit genau das zu tun, ohne das Projekt aufmachen zu müssen.
Wenn eure Philosophie dafür eine andere ist, kann IO-Link nichts dafür
 
Mal eine Frage, wo seht ihr denn bei euch den Mehrwert? Welche Zusatzfunktionen würdet ihr gerne nutzen oder geht es eher um Verkabelungsaufwände?

Der Verkabelungaufwand reduziert sich eigentlich überhaupt nicht. Wir haben aktuell einen Drucksensor, der auch die Temperatur, über iO-Link, ausgeben KÖNNTE. Benötigt wird das nur bedingt bzw. gar nicht.
Man muss aber jetzt nicht den Status quo beurteilen, sondern auch mal ein paar Jahre weiter denken.

IO-Link gibt dir aber die Möglichkeit genau das zu tun, ohne das Projekt aufmachen zu müssen.
Wenn eure Philosophie dafür eine andere ist, kann IO-Link nichts dafür

Was ist denn dafür nötig damit das so funktioniert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Verkabelungaufwand reduziert sich eigentlich überhaupt nicht. Wir haben aktuell einen Drucksensor, der auch die Temperatur, über iO-Link, ausgeben KÖNNTE. Benötigt wird das nur bedingt bzw. gar nicht.
Dann lasst es doch einfach sein. Weniger kann auch mehr sein.
 
Dem IO-Link Master ist es egal ob du einen Drehzahlsensor in NPN Ausführung von ifm (MX5017) oder einem anderen Hersteller nimmst.
Sollte es den MX5017 mal nicht mehr geben sondern einen MX6017, der aber typgleich ist, kannst du einfach den anschliessen.

Da IO-Link ein offener Standard ist, muss eben jede IO-Link-fähige Baugruppe den Planungsrichtlinien entsprechen.

Werde ich mich mal einlesen vielleicht hab ich was überlesen.
IO-Link gibt dir aber die Möglichkeit genau das zu tun, ohne das Projekt aufmachen zu müssen.
Wenn eure Philosophie dafür eine andere ist, kann IO-Link nichts dafür

IFM hat uns zumindest erzählt das wenn Backup und Restore genutzt werden sollen kann ich nicht am gleichen Eingang einen Festo oder IFM einsetzten. Sondern muss bei einem bleiben wo Vendor und DeviceID gleich sind ob das auch in Zukunft möglich ist ist schwer abzuschätzen deswegen war unser Plan das über die SPS zu händeln da kann ich mehrere Sensorenhersteller an einem Kanal unterstützten je nachdem was gerade lieferbar ist.
 
Werde ich mich mal einlesen vielleicht hab ich was überlesen.


IFM hat uns zumindest erzählt das wenn Backup und Restore genutzt werden sollen kann ich nicht am gleichen Eingang einen Festo oder IFM einsetzten. Sondern muss bei einem bleiben wo Vendor und DeviceID gleich sind ob das auch in Zukunft möglich ist ist schwer abzuschätzen deswegen war unser Plan das über die SPS zu händeln da kann ich mehrere Sensorenhersteller an einem Kanal unterstützten je nachdem was gerade lieferbar ist.
Vielleicht kommt es hier noch auf die Portklasse an (Class A/Clas B) bzw die Version der IODD Datei.. eventuell reicht es nach einem Tausch auch schon aus die IODD Datei nachzupflegen.

Screenshot 2024-03-06 110716.png

Ist definitiv aber weniger Aufwand, als alle Eventualitäten auf der Steuerungstechnik Vorzuhalten.

Hier mal noch der IODD Finder: https://ioddfinder.io-link.com/

Kann auch sein, das hierzu zB von ifm eine kostenpflichtige Version von moneo fällig ist etc..

Systembeschreibungen:

IO-Link: https://io-link.com/share/Downloads/At-a-glance/IO-Link_Systembeschreibung_dt_2018.pdf
P+F: https://files.pepperl-fuchs.com/webcat/navi/productInfo/doct/tdoct6495a_ger.pdf?v=28-FEB-23
ifm: https://www.ifm.com/download/files/...lg V1/$file/IO-Link Handout DE_allg V1.7.pdf/

Trends IO-Link: https://www.ifm.com/de/de/shared/technologien/io-link/systemueberblick/trends
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir benutzen mittlerweile viel Technik mit IO-Link. Speziell für Analoge Sensoren, Absolutwertgeber, für IO-Module oder seit Neuestem für die DC-Sicherungen von ifm.
Wir haben es bis jetzt immer so gehändelt, dass keine IODD in den IO-Link-Master gepackt wurde, sondern die Bytes nach Schnittstelle angelegt wurden. Dann interessieren einen irgendwelche IDs eigentlich nicht.
Zusätzlich wird möglichst darauf verzichtet die Einstellungen des Sensors zu verändern und mit der Standard-Konfig auszukommen.
Da hier meistens ein bereits im Sensor normierter Wert übertragen wird, entsteht auch kein wirklicher Nachteil.

Die Schnittstelle zum SPS-Programm ist dann ein Struct oder UDT, welches auf der SPS-Seite den Sensor abbildet oder in einem FC einliest und die Daten in einen DB schreibt.

Meine Meinung hierzu:
speziell ifm ist so stark auf den Zug mit IO-Link aufgesprungen, dass die Nachfolgemodelle kompatibel gestaltet werden um die eigenen Kunden zufrieden zu stellen.
Siemens tanzt auf vielen Hochzeiten, scheint aber bei den IO-Link-Mastern aktuell das schlüssigste Konzept zu haben und auch längerfristig möglichst Ersatzteilkompatibel zu bleiben.
Festo hat mit den Absolutwertgebern in den Zylindernuten für den internen Magnet einen echten Mehrwert geschaffen, was Sie selbst auch wissen.

Von Safety über IO-Link halte ich aktuell Abstand. Da wird auch mir zu viel in Kombination fixiert, sodass man in ein paar Jahren wirklich Probleme bekommen kann.
 
Naja die Frage war aber nicht, was jetzt schon alles geht oder was für ne IBN am schönsten und einfachsten ist, sondern was in 10 Jahren bei einem Defekt ist.
Die Lösung von @Holzmichl hört sich da schon brauchbarer -für uns als Maschinenbauer und auch für den Kunden- an.
 
Von Safety über IO-Link halte ich aktuell Abstand. Da wird auch mir zu viel in Kombination fixiert, sodass man in ein paar Jahren wirklich Probleme bekommen kann.
Da hab ich mich auch mal etwas einlesen müssen.. da wird noch viel mit harten festegelegten Dingen gearbeitet, auch bei Safety over WiFi Themen.. ist zwar möglich, aber eingeschränkt. (zB sichere Türschalter-Elemente gibt es mit drahtloser Funktion)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht kommt es hier noch auf die Portklasse an (Class A/Clas B) bzw die Version der IODD Datei.. eventuell reicht es nach einem Tausch auch schon aus die IODD Datei nachzupflegen.
Das stimmt so nicht, das hat nichts mit den Portklassen zu tun. Class B hat nur eine zusätzliche Stromversorgung.
Die IODD wird nur für "grafische Oberflächen" benötigt. In der Steuerung kann man die IODD nicht verwenden!
 
Dem IO-Link Master ist es egal ob du einen Drehzahlsensor in NPN Ausführung von ifm (MX5017) oder einem anderen Hersteller nimmst.
Sollte es den MX5017 mal nicht mehr geben sondern einen MX6017, der aber typgleich ist, kannst du einfach den anschliessen.

Da IO-Link ein offener Standard ist, muss eben jede IO-Link-fähige Baugruppe den Planungsrichtlinien entsprechen.


Typgleich ist nicht einfach. Da muss die Prozessdatenstruktur passen, die Einheit des Messwertes, usw...

Herstellerübergreifend wird gerade sowas entwickelt. D.h. z.B. wenn zukünftig ein Drucksensor dem Smartprofile 123 entspricht,
dann kann man herstellerübergreifen den Sensor tauschen. Dazu wird es auch eine spezielle Vendor und Device-ID geben...
 
Zuletzt bearbeitet:
Das stimmt so nicht, das hat nichts mit den Portklassen zu tun. Class B hat nur eine zusätzliche Stromversorgung.
Die IODD wird nur für "grafische Oberflächen" benötigt. In der Steuerung kann man die IODD nicht verwenden!
Wir reden ja auch hier nicht über Steuerungssysteme, dass die IODD Files für den IO Link Master sind geht ja aus der Thematik hier hervor
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir benutzen mittlerweile viel Technik mit IO-Link. Speziell für Analoge Sensoren, Absolutwertgeber, für IO-Module oder seit Neuestem für die DC-Sicherungen von ifm.
Wir haben es bis jetzt immer so gehändelt, dass keine IODD in den IO-Link-Master gepackt wurde, sondern die Bytes nach Schnittstelle angelegt wurden. Dann interessieren einen irgendwelche IDs eigentlich nicht.

In einen ifm IO-Link Master kann man auch noch keine IODD packen. Das kann nur der Balluff.

Wie gesagt, die Die IODD ist quasi nur für "grafische Oberflächen"...
 
In einen ifm IO-Link Master kann man auch noch keine IODD packen. Das kann nur der Balluff.

Wie gesagt, die Die IODD ist quasi nur für "grafische Oberflächen"...
Screenshot 2024-03-06 124733.png

Wenn ich doch aber zB über LR Device (ifm) IODDs herunterlade, müssen die ja irgendwo landen.. ich denke mal auf dem Master, da ich ja über LR Device meine Ports und somit auch IO-Link Slaves parametrieren kann.
 
Anhang anzeigen 76151

Wenn ich doch aber zB über LR Device (ifm) IODDs herunterlade, müssen die ja irgendwo landen.. ich denke mal auf dem Master, da ich ja über LR Device meine Ports und somit auch IO-Link Slaves parametrieren kann.
So wie ich das bei unserem Studeten mit dem IFM moneo vertanden habe holen sich die Softwaren nur einen Datenstrom und wandelt selber mit der IODD den Datenstrom in anzeigbare Daten um.
 
Zurück
Oben