Grundsatzfrage zu iO-Link

[wayne5de]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Nein, die landen nicht auf dem Master. Die IODD ist nur für die grafische Oberfläche moneo.
Somit kann/weiß moneo (grafische Oberfläche) , wie die Daten vom Sensor zu interpretieren sind und auch wie man ihn parametrieren kann.

 

[wayne5de]

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.

Ja, das ist so ungefähr richtig...

 

[Holzmichl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die IODD wird nur für "grafische Oberflächen" benötigt. In der Steuerung kann man die IODD nicht verwenden!

Soweit ich weiß, kann das Siemens in den Siemens IO-Link Mastern von ET200SP und ET200Eco per PCT.
Man liest in PCT (Port Configuration Tool) die IODD ein. Das wandelt dann die Infos in eine "Siemens-Config-Datei" für die HW-Konfig um und lädt die Infos in die HW-Konfig der CPU.
War mir genau deshalb zu starr und konnte ich in der HW-Konfig nicht gescheit Dokumentieren oder mit Kommentaren versehen, dass man da in ein paar Jahren noch durchblickt. Deshalb Port auf z.B. 32Byte IN/OUT eingestellt, per Move-Befehl im Block rangiert und in der UDT sauber kommentiert.

In den Siemens Mastern kann man dafür in der HW-Konfig einen Haken setzen für "Konfiguration ohne PCT".

 

[blackpeat]

Soweit ich weiß, kann das Siemens in den Siemens IO-Link Mastern von ET200SP und ET200Eco per PCT.
Man liest in PCT (Port Configuration Tool) die IODD ein. Das wandelt dann die Infos in eine "Siemens-Config-Datei" für die HW-Konfig um und lädt die Infos in die HW-Konfig der CPU.
War mir genau deshalb zu starr und konnte ich in der HW-Konfig nicht gescheit Dokumentieren oder mit Kommentaren versehen, dass man da in ein paar Jahren noch durchblickt. Deshalb Port auf z.B. 32Byte IN/OUT eingestellt, per Move-Befehl im Block rangiert und in der UDT sauber kommentiert.

In den Siemens Mastern kann man dafür in der HW-Konfig einen Haken setzen für "Konfiguration ohne PCT".

Die Info hat mir noch gefehlt, ob die Idee mit der reinen SPS Lösung auch mit Siemens klappt. Werde ich dann demnächst nochmal testen.

 

[AUDSUPERUSER]

IO-Link kann ja viel mehr als nur den Verdrahtungsaufwand zu reduzieren.

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


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 meinst Du jetzt aber nicht ernst, oder?

 

[Matzeh]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht noch was ganz Intressantes zu der Sache Edition 2 der Smart Sensor Profile. Erste Berührungskontakte schon gehabt Bei Messensoren. Es Wird die Skalierung direkt mitgeschickt. Verarbeitung findet im Beckhoff Standard Baustein(oder ensprechender Siemens Bibliotheksbausten) statt. Funktioniert bis jetzt gut.

Edition 2 der Smart-Sensor-Profile – Auf den gemeinsamen IO-Link-Nenner kommen

Edition 2 der Smart Sensor Profiles ermöglicht eine bessere Steuerung verschiedener Komponenten, so dass IO-Link-Sensoren schneller und flexibler als je zuvor integriert werden können ...

www.pepperl-fuchs.com

Edit:

Das meinst Du jetzt aber nicht ernst, oder?

Das hab ich glaub unbewusst mit meinem Link teils beantwortet

 

[evelkneevel]

Vielleicht noch was ganz Intressantes zu der Sache Edition 2 der Smart Sensor Profile. Erste Berührungskontakte schon gehabt Bei Messensoren. Es Wird die Skalierung direkt mitgeschickt. Verarbeitung findet im Beckhoff Standard Baustein(oder ensprechender Siemens Bibliotheksbausten) statt. Funktioniert bis jetzt gut.

Edition 2 der Smart-Sensor-Profile – Auf den gemeinsamen IO-Link-Nenner kommen

Edition 2 der Smart Sensor Profiles ermöglicht eine bessere Steuerung verschiedener Komponenten, so dass IO-Link-Sensoren schneller und flexibler als je zuvor integriert werden können ...

www.pepperl-fuchs.com

Edit:

Das hab ich glaub unbewusst mit meinem Link teils beantwortet

Das mit der Edition 2 hört sich genau nach dem an, was ich mir auch vorstellen würde.
Dann muss dafür nur noch Siemens ausm Quark kommen.

 

[Matzeh]

Das mit der Edition 2 hört sich genau nach dem an, was ich mir auch vorstellen würde.
Dann muss dafür nur noch Siemens ausm Quark kommen.

Softwaretechnisch sind sie da schon mit dabei ob sie eigene Sensoren haben

https://cache.industry.siemens.com/dl/files/016/109766016/att_982680/v1/109766016_IO-Link_Profiles_DOC_V1_0_de.pdf

 

[AUDSUPERUSER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das SmartSensorProfil V2 beschreibt nur die Übertragung der Prozessdaten und die Standardparameter, die ein Gerät enthalten muss.
Gerätespezifische Parameter, Vendor und Device-ID, Diagnose, das ist alles nicht genormt.

Solange man nur die Prozessdaten nutzt, kann man tauschen.
Aber keine Parametrierung
Kein Datastorage
Keine Diagnose.

--> VDMA ist dabei, eine erweiterte Vereinheitlichung zu machen. Dass wird aber noch einige Sommer dauern :-(

 

[blackpeat]

Das SmartSensorProfil V2 beschreibt nur die Übertragung der Prozessdaten und die Standardparameter, die ein Gerät enthalten muss.
Gerätespezifische Parameter, Vendor und Device-ID, Diagnose, das ist alles nicht genormt.

Solange man nur die Prozessdaten nutzt, kann man tauschen.
Aber keine Parametrierung
Kein Datastorage
Keine Diagnose.

--> VDMA ist dabei, eine erweiterte Vereinheitlichung zu machen. Dass wird aber noch einige Sommer dauern :-(

Parametrierung ist da ein Grund warum wir IO Link gerade implementieren bzw. das alles vorbereiten.

 

[MFreiberger]

Parametrierung ist da ein Grund warum wir IO Link gerade implementieren bzw. das alles vorbereiten.

Ich glaube, dass sich das nur rechnet, wenn ihr viele Sensoren parametrieren müsst. Die Einschränkungen (passende IODD, Sensorik nicht einfach austauschbar) sind für digitale Sensoren m.E. zu groß. Zudem werden weitere Softwaretools benötigt.

Also bei vielen einzustellenden Analogsensoren sehe ich den Mehrwert. Sonst aktuell eher nicht.

Gruß
MFreiberger

 

[olliew]

Zuviel Werbung?
-> Hier kostenlos registrieren

So pauschal beantworten lässt sich das nicht. Da sind Maschinenbauer, Maschine, eingesetzte Sensoren, anderes Zeugs mit 'IO-Link Potential' (Ja, es gibt neben Sensorik auch andere IO-Link Devices ) dann doch zu verschieden.

Es gibt ein paar coole Dingen die mit IO-Link machbar sind, es gibt aber auch das eine oder andere das nicht geht.

Für den einen mag es zum Beispiel schon entscheidend sein das ein IO-Link Device 'identifiziert' werden kann, Hersteller, Typ, Bestellnummer, Seriennummer, Hardware + Firmware Version, ohne das Fotos gemacht werden müssen.

Parametrieren kann in der SPS gemacht werden, ein Datensatz kann aber auch mittels DataStorage im IO-Link Master abgelegt werden. Was aber eher nicht geht (oder schwierig) ist ein Sensor von X durch ein Sensor von Y zu ersetzen.

Bei ein Tausch nach 10+ Jahre, bringt IO-Link die Möglichkeit mit das ein neueres Device (vom gleichen Hersteller), das alte Device ersetzt durch Übernahme der DeviceID mitsamt Parametern.

 

[van]

Parametrierung ist da ein Grund warum wir IO Link gerade implementieren bzw. das alles vorbereiten.

Was möchtest du in deinem Sensor Parametern?

Beispiel Druckschalter
Früher: Schaltpunkte müssen am Sensor in kryptischen Menüs eingestellt werden.

IoLink: Sensor liefert direkt den Druck an die Sps. Am HMI werden dann die Grenzwerte eingestellt und in der Sps ausgewertet. Der Sensor wird dadurch eigentlich dümmer.

 

[DeltaMikeAir]

Früher: Schaltpunkte müssen am Sensor in kryptischen Menüs eingestellt werden.

Früher gab es auch rein mechanisch einstellbare Schalter ( Scala ) oder voreingestellte Druckschalter.

 

[blackpeat]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was möchtest du in deinem Sensor Parametern?

Beispiel Druckschalter
Früher: Schaltpunkte müssen am Sensor in kryptischen Menüs eingestellt werden.

IoLink: Sensor liefert direkt den Druck an die Sps. Am HMI werden dann die Grenzwerte eingestellt und in der Sps ausgewertet. Der Sensor wird dadurch eigentlich dümmer.

Es werden Sensoren in der Safety ausgewertet und da Analog und Digitalwert verglichen der Schaltausgang vom Sensor soll aber aus der SW veränderbar sein damit falsche Einstellungen vermieden werden und man im Nachhinein den Schaltwert noch ändern kann ohne an jeden Sensor hin gehen zu müssen.

 

[van]

Ok in Verbindung mit Safety ist das dann schon etwas speziell…

Und die ganz alten Schalter kenne ich auch noch. Die hatten auch noch keine kryptischen Menüs die man ohne Bedienungsanleitung nicht versteht.

 

[maxder2te]

Also ich gehe 1:1 konform mit dem Ansatz von Holzmichl und ich setze es genau so ein.

Im Prinzip habe ich 3 Anwendungsszenarien:

1. Analogwertersatz
Bei allen messenden Sensoren die man früher typisch analog eingelesen hat (Druck, Füllstand, Durchfluss, Distanz) und wo das Einstellen der Schaltpunkte oder Analogwertskalierung ein großer Aufwand ist, werden die Sensoren heute einfach mit Werkseinstellung betrieben und liefern direkt Messwerte.
Bei messenen Sensoren wo zumindest Schaltpunkte einzustellen sind die man sonst digital verarbeitet hat (z.B. Niveauüberwachung Hydrauliktank) geht auch der Weg in diese Richtung, die Sensoren per IO-Link anzubieten und die Schaltpunkt in der Software zu definieren.

2. Feldbusersatz
Ich habe immer wieder Anwendungen, wo die IO-Link Ausführung des Sensors die kompakte und günstigste ist. Typisch sind das Drehgeber, Seilzuggeber, Messlineale wie das Balluff BTL, Neigunssensoren usw.

Das Lesen und Beschreiben von Parametern wird nur bei Sensoren benutzt, die eine gewisse Sicherheitsfunktion besitzen. Da wird typisch ein Digitalausgang des Sensors per Hardware wo eingebunden und die Schaltfunktion des Sensors per IO-Link Parameterabfrage auf Manipulation überwacht.

Ich hatte auch schon eine Anwendung, wo bei 8 identischen Maschinen je 44 Durchflussmesser kopfüber eingebaut waren und ich ein kleines Stück Software gebaut hab im die Anzeige zu drehen.

Das mit der Parametersicherung hat bei meinen ersten Gehversuchen 2017 nur sehr unzuverlässig funktioniert (Balluff, Murrelektronik), ich schalt das immer aus.
Auch IODD sind nur ein Notfallmittel um das PD-Mapping herauszufinden wenn die Dokumentation schlecht ist - PCT oder ähnliche Tools benutze ich nicht.

Im Hinblick auf ein Asset-Management möchte ich zukünftig die "I&M 0" Daten der Devices auslesen und für externe Systeme bereit stellen.

Aktuell kommen fast nur Siemens-Master zum Einsatz, ich parametriere i.d.R. 32 Byte In/OUT pro Kanal, lege das als generischen UDT auf die EA-Adressen und verende Decoder FCs für die jeweiligen Sensoren.

Im Hinblick auf Kompatibilität in 10 Jahren haben sich Balluff und IFM als sehr stabile Partner erwiesen.

Was ich nie tun würde ist schaltende Sensoren ohne Einstellmöglickeiten (z.B. Inis) per IO-Link anzubieten, denn der Mehrwert ist nicht vorhanden (Type und Seriennummer auslesen können ist zwar nett aber mehr auch nicht).

 

[TK_AT]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi, ich würde hier mal den Thread aufgreifen Zwecks der IO-Link Thematik. Und zwar haben wir in unserer neuen Automatisierung nur IO-Link verbaut. Ein Safety-Modul verschluckt sich manchmal und bringt diverse Fehler. Es lässt sich zurücksetzen, wenn man die Spannung wegnimmt.

Einmal hat das aber auch nicht mehr geholfen. Da es immer dasselbe Modul ist, habe ich einfach 2 Stück gegeneinander ausgetauscht. Dann kam die Steuerung aber komplett durcheinander und am HMI wurden alle möglichen Fehler zu den Modulen angezeigt. Es lag vermutlich an der anderen Belegung der Ein-und Ausgänge

Ich habe mich grob etwas dazu belesen (habe jetzt vor mich mehr mit IO-Link zu beschäftigen. Hatten wir vorher nie) und habe, wie oben bereits erwähnt wurde, gelesen, dass sich die Module beim Anschließen an die Kommunikation eigentlich selbst parametrieren. Würde es denn funktionieren, wenn man ein neues anschließt?

 

[olliew]

Safety lässt sich so pauschal nicht/nie beantworten.

Was genau ist denn dein Safety-Modul? IO-Link Safety? Und was meinst du mit verschlucken?

 

[TK_AT]

Ja, ein Profisafe IO-Link Modul zur Abfrage von Sicherheitseinrichtungen. Genau der Typ IFM Al200S

Und was meinst du mit verschlucken?

Ihm hat irgendwas nicht gepasst. Auf dem Modul hat man verschiedene Diagnoselampen. In Abhängig von Lampenkombination, Farbe und Leuchtzustand kann man aus der Anleitung den Fehler raussuchen. Hatte ich auch gemacht, aber habe es ehrlich gesagt wieder vergessen, weil es dann wieder funktioniert hat.

Aber nevermind: Meine Grundfrage, auch Allgemein, ob man die Safety Module Im Falle eines defekts o.ä. einfach tauschen kann.