- Beiträge
- 6.344
- Reaktionspunkte
- 1.541
-> Hier kostenlos registrieren
Wenn beim DIP eines anderen Herstellers On/Off anders rum war, hat Siemens den mit Absicht um 180° gedreht bestückt, damit die Elektriker keinen Unterschied merken ...
Erfahrung mit IO-Link
- Ersteller holgermaik
- Erstellt am
-> Hier kostenlos registrieren
Cassandra
Level-2
- Beiträge
- 438
- Reaktionspunkte
- 294
Zum Glück hören sich deine Anmerkungen 100% positiv an! *ROFL*
- Beiträge
- 11.613
- Reaktionspunkte
- 3.873
-> Hier kostenlos registrieren
Stimmt
Mich nerven letztlich einfach nur Kleinigkeiten an der Umsetzung.
Wenn du die IOL-Fachleute im Haus hast, dann erzählen sie fast immer als erstes:
- Wir können Cloud
- Wir haben 2 Netzwerkanschlüsse (1 für die Steuerung einer für die Cloud)
- Die Konfiguration geht mit jedem Standardbrowser
- ...
Also mal hier die Frage in die Runde:
Wer von euch bindet IOL-Master an die Steuerung UND an die Cloud an?
Nutzt das wirklich jemand produktiv an mehreren Anlage / Maschinen?
Hat eine(r) von euch wirklich ein 2. Netzwerk in der Anlage (nicht nur zum Schaltschrank) nur für die Cloudanbindung?
Wenn die Experten mit der Browserbedienung kommen, dann dürfen sie das immer gerne auf einem Siemens TP1500 zeigen.
Führt meist zu recht ratlosen Gesichtern
Besonders wenn man dann eine IODD hochladen muß.
Am liebsten sind mir dann noch die Hersteller, die Konfiguration von Geräten per NFC oder Bluetooth bringen.
Wir haben im Konzern IPhone und diese sind IT-managed.
Selbst wenn es eine IOS-App gibt, ist da erstmal nix mit schnell mal installieren
Man merkt einfach, dass die Produktentwicklung in vielen Firmen zu IT-lastig ist.
Man entwicklet Features, ohne auf die Bedürfnisse der "wirklichen" Kunden einzugehen. :twisted:
So um es nun doch noch positiv klingen zu lassen:
Wir setzen IOL sind einigen Jahren ein und haben keinerlei Probleme im Betrieb damit.
Schönen Sonntag
Gruß
Blockmove
Chräshe
Level-2
- Beiträge
- 886
- Reaktionspunkte
- 289
Hallo Blockmove,
ich setze kein IO-Link ein und hab damit auch kein Problem.
Mit dem Konzept „So einfach wie möglich und so komplex wie nötig“, bin ich bisher ganz gut gefahren.
Gruß
Chräshe
PS: Doch, im Betrieb sind einige IO-Link-Sensoren im Einsatz.
Allerdings werden nur die Normsignale konventionell verwendet.
Das sehe ich als einen der größten Vorteile von IO-Link…
OP
holgermaik
Level-3
- Beiträge
- 1.361
- Reaktionspunkte
- 336
Hallo an alle
ich möchte mich erstmal für die vielen Meinungen bedanken.
Über die Sicherung der Master Config hatte ich bis jetzt so noch gar nicht nachgedacht.
Ich werde es erstmal wie Blockmove halten und den Sensor ohne Config betreiben.
Holger
ich möchte mich erstmal für die vielen Meinungen bedanken.
Über die Sicherung der Master Config hatte ich bis jetzt so noch gar nicht nachgedacht.
Ich werde es erstmal wie Blockmove halten und den Sensor ohne Config betreiben.
Holger
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
-> Hier kostenlos registrieren
Stimmt
Mich nerven letztlich einfach nur Kleinigkeiten an der Umsetzung.
Wenn du die IOL-Fachleute im Haus hast, dann erzählen sie fast immer als erstes:
- Wir können Cloud
- Wir haben 2 Netzwerkanschlüsse (1 für die Steuerung einer für die Cloud)
- Die Konfiguration geht mit jedem Standardbrowser
- ...
Also mal hier die Frage in die Runde:
Wer von euch bindet IOL-Master an die Steuerung UND an die Cloud an?
Nutzt das wirklich jemand produktiv an mehreren Anlage / Maschinen?
Hat eine(r) von euch wirklich ein 2. Netzwerk in der Anlage (nicht nur zum Schaltschrank) nur für die Cloudanbindung?
Wenn die Experten mit der Browserbedienung kommen, dann dürfen sie das immer gerne auf einem Siemens TP1500 zeigen.
Führt meist zu recht ratlosen Gesichtern
Besonders wenn man dann eine IODD hochladen muß.
Am liebsten sind mir dann noch die Hersteller, die Konfiguration von Geräten per NFC oder Bluetooth bringen.
Wir haben im Konzern IPhone und diese sind IT-managed.
Selbst wenn es eine IOS-App gibt, ist da erstmal nix mit schnell mal installieren
Man merkt einfach, dass die Produktentwicklung in vielen Firmen zu IT-lastig ist.
Man entwicklet Features, ohne auf die Bedürfnisse der "wirklichen" Kunden einzugehen. :twisted:
So um es nun doch noch positiv klingen zu lassen:
Wir setzen IOL sind einigen Jahren ein und haben keinerlei Probleme im Betrieb damit.
Schönen Sonntag
Gruß
Blockmove
Wir tun das.
Wir holen über den Y-Weg bei ifm Mastern, die Daten, die wir in der Datenbank haben wollen, und werten sie dort aus.
Großer Vorteil ist: An der SPS vorbei.
MFreiberger
Level-3
- Beiträge
- 2.869
- Reaktionspunkte
- 760
Moin AUDSUPERUSER,
Warum ist das ein Vorteil? Frage einfach interessehalber.
VG
MFreiberger
Warum ist das ein Vorteil? Frage einfach interessehalber.
VG
MFreiberger
- Beiträge
- 11.613
- Reaktionspunkte
- 3.873
Das "Y" macht aber nur Sinn, wenn ich in der SPS und in der DB unterschiedliche Werte auslesen will.
Beispiel Distanzmesser:
SPS bekommt den Entfernungswert
DB die Betriebsdauer
Bei der Vernetzung kommt dann bei den meisten "Y"-IOL-Mastern, die ich kenne, das Problem, dass sie keine 4 Netzwerkports haben, sondern nur 2.
Im Normalbetrieb kann ich beide für Profinet nutzen, Im Y-Betrieb sind die 2 Ports den unterschiedlichen Netzen zugeordnet.
Nutze ich also Y, dann wird die Vernetzung aufwendiger und somit teurer.
Kann sein dass das bei IFM anders ist.
Aber das wird ja in Zukunft bei TSN alles besser ... Wenn's denn noch jemand beherrscht
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
-> Hier kostenlos registrieren
Das "Y" macht aber nur Sinn, wenn ich in der SPS und in der DB unterschiedliche Werte auslesen will.
Beispiel Distanzmesser:
SPS bekommt den Entfernungswert
DB die Betriebsdauer
Bei der Vernetzung kommt dann bei den meisten "Y"-IOL-Mastern, die ich kenne, das Problem, dass sie keine 4 Netzwerkports haben, sondern nur 2.
Im Normalbetrieb kann ich beide für Profinet nutzen, Im Y-Betrieb sind die 2 Ports den unterschiedlichen Netzen zugeordnet.
Nutze ich also Y, dann wird die Vernetzung aufwendiger und somit teurer.
Kann sein dass das bei IFM anders ist.
Aber das wird ja in Zukunft bei TSN alles besser ... Wenn's denn noch jemand beherrscht
Die Master haben zwei Ports für Feldbus und einen für Ethernet.
Ja, es ist richtig, mehr Verkabelungsaufwand.
Aber dafür hat man beides sauber getrennt und IT und Automatisierung streiten nicht
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
Der IT-ler nervt nicht jedes Mal den SPS Programmierer, wenn er einen Wert braucht.
Er kann über JSON auf den Master zugreifen, und sich die Werte holen.
Er könnte auch schreiben, sofern der SPSler das im Master freigibt
- Beiträge
- 11.613
- Reaktionspunkte
- 3.873
Der IT-ler nervt nicht jedes Mal den SPS Programmierer, wenn er einen Wert braucht.
Er kann über JSON auf den Master zugreifen, und sich die Werte holen.
Er könnte auch schreiben, sofern der SPSler das im Master freigibt
Der ITler muss letztlich trotzdem nerven. Ihm fehlt nämlich das Prozess-KnowHow.
Irgend jemand muss dem ITler mitteilen welche Werte er vom welchem Master auslesen muss und wie er sie bewerten muss.
Der Elektrokonstrukteur ist immer mit im Boot.
Und nach der Einführungsphase ist es doch so, dass der SPSler zumeist auch noch Condition-Monitoring-Systeme auch noch betreut.
Wir nutzen als Protokoll OPC UA auf der Steuerung.
Das bietet dem ITler die selben Vorteile wie JSON.
Das Zeitalter von "Lies mal im DB204 das DW12 aus" sind vorbei.
Gruß
Blockmove
- Beiträge
- 6.344
- Reaktionspunkte
- 1.541
-> Hier kostenlos registrieren
Weiss er das denn?
Welche Werte er auslesen muss? Na gut. Wie er sie bewerten muss? Keinesfalls.
Eben drum!
- Beiträge
- 11.613
- Reaktionspunkte
- 3.873
Naja es gibt ITler und ITler
Im I4.0 Umfeld gibt es auch viele Quereinsteiger in der IT.
Da passen manchmal die alten Vorurteile nicht mehr.
Mit den Kollegen, die die Technik umsetzen hab ich auch selten Probleme.
Wenn dann ist's der tolle Vertrieb.
Wenn dir ein Senior Consultant mit Bachelor of Arts (also Geisteswissenschaften) erzählt, dass die schwäbischen Anlagenbauer in 5 Jahren weg vom Markt sind weil sie das Potential von cloudbasierten SPSen mit 5G nicht erkennen, dann fahr ich schon mal aus meiner Haut.
- Beiträge
- 6.344
- Reaktionspunkte
- 1.541
Na klar, Dieter, es gibt so'ne und es gibt solche.
Aber noch sind SPS- und Hochsprachen-Basierte mit Zusammenwachsen beschäftigt und es werden ständig Neue nachwachsen, um sich auch an den Kollisionen dieser Welten zu beteiligen!
Aber noch sind SPS- und Hochsprachen-Basierte mit Zusammenwachsen beschäftigt und es werden ständig Neue nachwachsen, um sich auch an den Kollisionen dieser Welten zu beteiligen!
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
-> Hier kostenlos registrieren
Sorry, wenn ich Dir wiederspreche, aber unser ITler hat das fast ganz alleine gemacht.
Du hast ja meinen Kontakt.
Wenn Du Dir das mal live anschauen möchtest, einfach melden.
- Beiträge
- 11.613
- Reaktionspunkte
- 3.873
Wird zwar langsam offtopic, aber mal die Frage:
Was hat der der ITler fast ganz alleine gemacht?
Bei uns gibt es nur sehr wenige IT-Anwendungen im IoT-Umfeld wo ich einen wirtschaftlichen Vorteil im Y-Link sehe.
Beispiel wäre vielleicht Energie- und Luftverbrauch und evtl. vorbeugende Wartung an Werkzeugen.
Gruß
Blockmove
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
Werte eingesammelt und ausgewertet.
So wie Du schreibst, z.B. Energiedatenerfassung.
Klar, die Sensoren hat jemand eingebaut und angeschlossen.
Für die Signalerfassung und Auswertung wurde kein Automatisierer gebraucht.
Wie gesagt, komm und schau es Dir an
So wie Du schreibst, z.B. Energiedatenerfassung.
Klar, die Sensoren hat jemand eingebaut und angeschlossen.
Für die Signalerfassung und Auswertung wurde kein Automatisierer gebraucht.
Wie gesagt, komm und schau es Dir an
AUDSUPERUSER
Level-3
- Beiträge
- 2.001
- Reaktionspunkte
- 847
-> Hier kostenlos registrieren
https://youtu.be/0V9jxKl1c6w
Hier hat auch jemand Erfahrung mit IO-Link gemacht.
Dank IO-Link gibt es Bier
Hier hat auch jemand Erfahrung mit IO-Link gemacht.
Dank IO-Link gibt es Bier
Draco Malfoy
Level-1
- Beiträge
- 1.168
- Reaktionspunkte
- 82
Es ist alles sehr theoretisch.
1) Der Messwert ist stabil, erscheint allerdings zeitlich versetzt und und mit ungewisser Refresh-Rate, wenn du ihn azyklisch abholst.
2) Der Verschmtzungsgrad wird nur kommen, wenn diese Erkennung Richtig konfiguriert ist.
3) Welchel bei einem Defekt erst ab Version 1.1, oder nur mit einem erheblichen Programmieraufwand realisierbar.
4) Diagnose - mein Gott, 90% der User sind nicht einmal in der Lage, die von der Fa. Siemens bereitgestellten hardwarebasierten Diagnosemöglichkeiten der Baugruppen vollumfänglich auszunutzen, weil kein Mensch weiß, was Diagnose-, Kommen-/Gehen, Ziehen- / Stecken usw. Alarme sind und wie man deren Informationen richtig verarbeitet.
Jetzt kommt, um die Situation vollends durcheinander zu bringen und einen handelsüblichen 55€/h Baustellen-Programmierer-Inbetriebnehmer endgültig aus der Bahn zu werfen, noch das IO-Link. Die Probleme, die damit verbunden sind, und allesamt einen hohen Programmieraufwand erfordern, sind alle alles andere als trivial.
1) Die azyklischen Zugriffe auf den Master erfordern IO-Link Treiber, die gerätespezifisch sind. Ich kann also keine IO-Link fähigen SCHMALZ Vacuum-Ejektoren mit einem Treiber für IO-Link fähige Laserlichtschranken betreiben.
2) An einem Master können durchaus mehrere IO-Link Geräte angeschlossen sein, aber der Master kann trotzdem nur einen azyklischen Auftrag zur selben Zeit verarbeiten. Es muss also eine funktionsfähige Backplane implementiert sein, die sozusagen das Routung und Management der azyklischen Aufträge je Masterbaugruppe übernimmt.
3) Neben den azyklischen Status- und Read-Aufträgen gibt es noch Niederschreiben von Konfigurationsdaten. Das Lesen-/Schreiben dieser Daten muss auch im Treiber integriert sein.
4) Bei großen Mengen an IO-fähigen Geräten kommt eine standardmäßige CPU an ihre Grenzen, da deren Ressourcen für azyklische Kommunikation ebenfalls nicht unbegrenzt sind. Auch diese Ressourcen müssen dann aktiv gemanagt und von einer entsprechenden Routine dynamisch zugeteilt werden.
Ich habe für einen simplen Anwendungsfall mit IO-Linkt fähigen Saugern einen Treiber- und Schnittstellenbaustein mit ca. 2000 Zeilen in SCL geschrieben. Er belegt einen Auftragszähler, tauscht die Daten mit dem Gerät aus, und inkrementiert anschließend den Counter, um anderen IO-Link fähigen Geräten am selben Master den Datenaustausch zu ermöglichen. Daneben findet noch Diagnose der Masterbaugruppe statt und es werden Statusmeldungen zum Gerät und zum Kommunikationsstatus in diesem Baustein generiert.
Und jetzt stelle man sich einmal einen AWL-Programmierer vor, der das alles umsetzten soll. Ich glaube, ich gehe dann besser gleich Vodka trinken, bevor ich mir dieses Schauspiel antue.
Zuletzt bearbeitet:
- Beiträge
- 15.416
- Reaktionspunkte
- 4.044
Da hat du schon Recht, aber...
Man muß hier auch mal Aufwand und Nutzen betrachten.
Möglicherweise reicht es auch aus den Fehler zu melden (Hier eben, dass der Sauger nicht saugt, also kein Teil hält).
Denn auch wenn du den Fehler ganz genau aus den Meldungen und Zuständen des Masters herausbekommst, wird am Ende entweder der Sauger, das Kabel oder der Master ausgetauscht. Denn auch deine genauen Meldungen müssen vom Nutzer erst einmal interpretiert werden.
Wir Alle kenne doch die Aussagen alá:
User: Die rote Lampe leuchtet!
Ich: Wie lautet die Fehlermeldung?
User: Weiß ich nicht, hab ich weggedrückt und nicht gelesen!
Ich: Geh nochmal hin.
User: Ooooch ist so viel Text, kann ich mir nicht merken!
Ich: Ok, schreib auf, am Besten die Nummer, den Rest such ich mir selbst!
