TIA IO-Link Events vom Master und Devices sinnvoll auswerten. Erfahrung?

[dealer125]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

in meiner Firma setzen wir zum erstmal IO-Link ein.
Bisher ausschließlich Siemens z.B. ET200SP eingesetzten wollen nun auf IFM oder Turck Master wechseln. Erproben nun die Möglichkeiten und Einsatz von Sensorik und Aktorik an diesen Mastern.

Nun werden ja die Fehler als Events übermittelt entweder vom Master direkt oder vom Device über den Master.

Wer hat damit denn schon Erfahrung gesammelt und kann gegeben falls ein vorgehen empfehlen um gezielt die Störung/Events von einem Device zu erhalten, damit diese Später in einer Visualisierung entsprechenden in Klartext ausgegeben werden können?

Habe dafür bisher nur den Baustein IO_LINK_DEVICE von Siemens gefunden, aber komfortabel erscheint mir dieser im ersten Moment nicht.
Wir setzen TIA Portal V15.1U2 und eine 1500 SPS.

Danke schon mal im Voraus.

 

[Draco Malfoy]

Japp also das Thema ist mitnichten trivial, sollte aber generell in Angriff genommen werden. Ich bin gerade dabei, eine IO-Link Library für einen definierten Anwendungsfall zu schreiben.

In Kürze, folgendes:

- Nicht jeder Master schickt dieselben Events;
- Nicht jeder Master (auch die Siemens Master nicht alle - nur die "besseren", also zum Beispiel 6ES7 148-6JD00-0AB0) transponiert die IO-Link Alarme in die Profinet-Alarmebene;
- Auf Subslot-Ebene können Ziehen / Stecken Alarme generiert werden, auch da tut es nicht jeder Master;

Folglich, sind die Bausteine, die du für einen bestimmten Master schreibst, mit anderen ggf. nicht kompatibel.

Ansonsten, um eine vollumfängliche Diagnose bereitzustellen, müsste man die üblichen Profinet-Mechanismen bemühen:

IF OB86_WIEDERKEHR_MIT_WARTUNG OR
    OB82_GEGANGEN_ABER_NICHT_ALLE OR
    OB70_REDU_WIEDERKEHR_VERLUST THEN

   Req_800C_Datensatz_Lesen := TRUE;

END_IF;

Und natürlich die Alarme aus dem OB82 sammeln. Aber da gibts natürlich wieder verschiedene.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie Draco schreibt, ist das Hauptproblem die fehlende Standardisierung sowohl von Mastern als auch von Sensoren / Aktoren.
Es gibt wohl Bestrebungen zur Vereinheitlichung in Form von Geräteprofilen.
Aus meiner Sicht macht es aktuell am meisten Sinn die Zustands- und Fehlerkennungen in den zyklischen Prozessdaten zu verwenden.
Die Profinet-Diagnose ist ein gutes Beispiel von "Gut gemeint ist das Gegenteil von gut gemacht".
Wir nutzen setzen mittlerweile viel IO-Link ein. Aber immer nur die reinen Prozessdaten.
"Erweiterte Features" wie Konfiguration, Backup / Restore über IO-Link nutzen wir nicht.
So funktioniert auch Master- und Sensortausch ohne viel Theater.
Ist zwar nicht im Sinne des Erfinders ... Aber pragmatisch und funktioniert

Gruß
Blockmove

 

[Draco Malfoy]

Wie Draco schreibt, ist das Hauptproblem die fehlende Standardisierung sowohl von Mastern als auch von Sensoren / Aktoren.
Es gibt wohl Bestrebungen zur Vereinheitlichung in Form von Geräteprofilen.
Aus meiner Sicht macht es aktuell am meisten Sinn die Zustands- und Fehlerkennungen in den zyklischen Prozessdaten zu verwenden.
Die Profinet-Diagnose ist ein gutes Beispiel von "Gut gemeint ist das Gegenteil von gut gemacht".
Wir nutzen setzen mittlerweile viel IO-Link ein. Aber immer nur die reinen Prozessdaten.
"Erweiterte Features" wie Konfiguration, Backup / Restore über IO-Link nutzen wir nicht.
So funktioniert auch Master- und Sensortausch ohne viel Theater.
Ist zwar nicht im Sinne des Erfinders ... Aber pragmatisch und funktioniert

Gruß
Blockmove

Ich meine, der Punkt ist doch einfach der.

Wer nutzt schon die Funktionalitäten des PROFINET-Systems überhupt vollumfänglich aus ? Hast du schon mal eine Anlage gesehen, wo tatsächlich alle OB86-, 85-, 83-, 82- Aufrufe zu aller Feldharware ausgewertet werden, wo die Diagnosealarme gesammt und visualisiert werden ?

Lt. Spezifikation werden die IO-Link Alarme auf die Profinet-Diagnosealarme abgebildet, so als Ziel- und Sollzustand.

Also muss man mindestens einen insoweit modularen Bibliotheksaufbau haben, daß man zu jedem "Kanalbaustein", der die zyklischen und azyklischen Daten verwaltet, einen MOD-Baustein hat, der die Diagnose macht. Wobei man in derselben Weise auch nicht-IO-Link-fähige Module mitnehmen und diagnostizieren könnte, wie zum Beispiel RFID-Geräte oder Antriebe. Für PCS7 hat Siemens eigene Bibliotheken zum IO-Link, funktionieren aber nach demselben Muster.

 

[Blockmove]

Ich meine, der Punkt ist doch einfach der.

Wer nutzt schon die Funktionalitäten des PROFINET-Systems überhupt vollumfänglich aus ? Hast du schon mal eine Anlage gesehen, wo tatsächlich alle OB86-, 85-, 83-, 82- Aufrufe zu aller Feldharware ausgewertet werden, wo die Diagnosealarme gesammt und visualisiert werden ?

Ich kenn keine aus meinem Umfeld.
Und der Grund ist auch ganz einfach ... Komplexität / Kosten / Nutzen.

 

[BigBen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aus meiner Sicht macht es aktuell am meisten Sinn die Zustands- und Fehlerkennungen in den zyklischen Prozessdaten zu verwenden.
Die Profinet-Diagnose ist ein gutes Beispiel von "Gut gemeint ist das Gegenteil von gut gemacht".
Wir nutzen setzen mittlerweile viel IO-Link ein. Aber immer nur die reinen Prozessdaten.
"Erweiterte Features" wie Konfiguration, Backup / Restore über IO-Link nutzen wir nicht.

Ich würde tatsächlich auch gerne die zyklischen Prozessdaten für eine Fehleranalyse nutzen, um dann für den Anwender erkennbar zu machen, dass azyklisch die Diagnosedaten aus dem IO-Link-Device geholt werden können. Z.B. Manche Geräte z.B. von ifm senden direkt den Gerätestatus mit, das macht es dann ja einfach. Andere Geräte, auch von ifm, senden reine Prozessdaten. Wie leitet man daraus mögliche Fehlerzustände ab? Macht Ihr das dann mit dem PQI-Byte?

MfG BigBen

 

[Blockmove]

Ich würde tatsächlich auch gerne die zyklischen Prozessdaten für eine Fehleranalyse nutzen, um dann für den Anwender erkennbar zu machen, dass azyklisch die Diagnosedaten aus dem IO-Link-Device geholt werden können. Z.B. Manche Geräte z.B. von ifm senden direkt den Gerätestatus mit, das macht es dann ja einfach. Andere Geräte, auch von ifm, senden reine Prozessdaten. Wie leitet man daraus mögliche Fehlerzustände ab? Macht Ihr das dann mit dem PQI-Byte?

MfG BigBen

Ganz pragmatisch, je nachdem was der Sensor in seinen Prozessdaten halt liefert.
Außerdem weiß man ja meist in welchen Rahmen ein Messwert sinnvoll ist.
Letztlich ist es doch auch nix anderes als mit ganz normalen Analogwerten. Wenn du ein 0-10V Signal hast, dann ist die Diagnose auch beschränkt.
Entgegen der ganzen Werbeversprechen und Präsentationen ist IO-Link einfach noch ne große Baustelle.
Wir nutzen IO-Link breitflächig, investieren aber nicht viel Zeit und Energie in die "Zusatz"-Features.