Inkrementalgeber mit I/O-Link brauchbar auswerten

[CoffeeAddict2220]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich möchte eignentlich mal eure Meinung zu einer Situation, die ich gerade hier habe.
Vielleicht hat ja sogar jemand eine brauchbare Lösung.

Der IFM-Inkrementalgeber RB3100 wird normalerweise über eine Zählerkarte mit HSC-Technologieobjekt ausgewertet. Im Zuge einer Umrüstung auf IO-Link wurde getestet, den Geber direkt per IO-Link auszulesen, da er diese Funktion unterstützt.


Das Problem dabei: Der Geber zählt über IO-Link nur von 0 bis zur eingestellten Auflösung (standardmäßig 1024 Impulse) und springt nach jeder Umdrehung wieder auf 0 zurück. Eine Umkonfiguration auf einen größeren Zählbereich (z. B. Nutzung der vollen 2-Byte-Übertragung bis 65.535) ist laut IFM nicht möglich.


Für Anwendungen, bei denen Antriebe nach einem bestimmten Weg gestoppt werden sollen, ist dieses Verhalten unpraktisch. Eine softwareseitige Lösung, bei der der Sprung von 1024 auf 0 erkannt und Umdrehungen mitgezählt werden, empfinde ich als unsauber und fehleranfällig – insbesondere mit dem Risiko, den Überlauf zu übersehen.

Habt ihr da vielleicht eine andere "bessere" Idee oder Erfahrungen mit dieser Art der Auswertung?

 

[DeaD_EyE]

Theoretisch könnte man das mit Software lösen.
Der Überlauf/Unterlauf darf dann nur einmal in einem Zyklus vorkommen.

Vorzeichen bestimmen, indem das Signal für die Richtung ausgewertet wird. Da die Richtung bekannt ist, kann man den Unter-/Überlauf auswerten. Nach der Korrektur berechnet man die relative Position zum letzten Zyklus und addiert diese dann zur absoluten Position (Merker oder DB).

 

[CoffeeAddict2220]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja genau das was auch in meinem Sinn, aber so 100 % zufrieden bin ich mit der Lösung nicht, da ist die Lösung mit dem HSC irgendwie, "sicherer"?
Der Drehgeber steuert den entscheidenen Teil unserer Anlagen und gibts da ein Problem mit nicht erkanntem Überlauf oder so, ist die Anlage nicht funktionsfähig. Vielleicht haben wir mal Luft um das ausgiebig zu testen.

 

[JSEngineering]

Die entscheidende Frage ist ja: Wie schnell zählt der bis 1024 hoch, wie viele Umdrehungen sind das, wie schnell dreht der Motor, wie schnell läuft die SPS --> kann der Überlauf in einem Zyklus, in einem Zyklus mehrfach oder ausschließlich innerhalb mehrerer Zyklen passieren?

Wenn Du sicherstellen kannst, daß der Überlauf mehr als 1 Zyklus benötigt, dann ist das eigentlich sicher auswertbar. Sofern der Überlauf pro Zyklus passieren kann, wird es schon eng. Dann kann man nicht mehr sicher feststellen, ob der Motor jetzt ganz langsam oder ganz schnell war.

Auch bei einer Counterkarte mußt Du den Überlauf handeln. Ob man das nun aber alle 100 Zyklen oder alle 5 Zyklen macht, ist eigentlich egal.

Wenn Du Befürchtung hast, daß Dein Task zu langsam dafür ist, mach einen schnelleren Task (oder Weckalarm, ja nachdem was für eine Steuerung Du hast), der ausschließlich den Zähler handhabt und das Ergebnis dann dem Haupt-Task zur Verfügung stellt.

 

[CoffeeAddict2220]

Naja in meinem Fall sind es 500ms pro Umdrehung, also eigentlich gut händelbar: Ich schaue nur gern so ein bisschen links und rechts, da es ja viele Lösungen für ein Problem geben kann. Dazu kommt, dass im Sondermaschinenbau ungewiss ist, wie schnell sich die Antriebe in Zukunft drehen oder wie schnell eine SPS arbeitet, da die Programme sehr stark variieren.

Z.B. dachte ich an irgendeine kompatible Bib mit einer coolen Funktion oder sowas wie den HSC nur für I/O-Link Encoder.

 

[DeaD_EyE]

Zuviel Werbung?
-> Hier kostenlos registrieren

SPS: 10 ms Zykluszeit -> 1 / 10e-3s * 60 => 6000 1/min

Bei 500ms pro Umdrehung: 1 / 500e-3s * 60 => 120 1/min
Sollte machbar sein.

 

[the_muck]

Ist es aber nicht so das der HSC immer den aktuellen Wert im Speicher hat. Bei IO Link + Überlaufberechnung stellt sich im Programm ja die Frage zu welchem Zeitpunkt die Daten aktualisiert und berechnet wurden. Also wird mein Positionier Fehler eventuell entsprechend größer?

 

[Blockmove]

Du weißt ja, was du an Genauigkeit brauchst. Dem entsprechend kannst du ja ein wenig mit der Zykluszeit, den Schwankungen der Zykluszeit und auch der IO-Link-Aktualisierungszeit herum rechnen. Dann siehst du ja, ob du überhaupt die gewünschte Genauigkeit erreichen kannst.

Alternativ würde ich mal bei Sick, P+F oder Kübler nach "richtigen" IO-Link Multiturngebern schauen.

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

IO-Link-Multiturn-Drehgeber

Absolute Positionsverfolgung auch im stromfreien Zustand und frei konfigurierbarer Auflösung

www.ifm.com

Ist dann preislich aber auch ne andere Nummer...

 

[Blockmove]

IO-Link-Multiturn-Drehgeber

Absolute Positionsverfolgung auch im stromfreien Zustand und frei konfigurierbarer Auflösung

www.ifm.com

Ist dann preislich aber auch ne andere Nummer...

Dafür kannst du unter Umständen auf Referenz- und / oder Endlagenschalter verzichten.

 

[Blockmove]

Noch ein Hinweis zu den Multiturn-Gebern:
Es gibt Varianten mit Batterien oder Akkus.
Die ganz einfachen sind nur Inkrementalgeber mit eingebauter "Zählelektronik".
Die können dir das Laune ganz schön versauen.
Ist die Batterie oder der Akku leer, dann musst du die Achse neu vermessen und unter Umständen auch den Geber neu parametrieren.
Bessere Modelle basieren auf Singleturngebern und zählen dann quasi die Umdrehungen selber und bilden so den Multiturn nach.
Manche haben zusätzlich EEprom zum Zwischenspeichern der Umdrehungen bei Batterieausfall. Solange der Antrieb dann nicht um mehr als eine Umdrehung verdreht wird, passiert nichts.
Dann gibt's auch noch "richtige" Multiturngeber. Aber da muss auch der Verfahrweg der Achse passen.

Wenn du wirklich auf Endlagenschalter verzichtest, dann nicht die Billigvariante verwenden.
Nimmst du die mittlere Variante, dann sind Motoren mit Bremse zu empfehlen. Dann kann keiner im spannungslosen Zustand drehen.

 

[the_muck]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja stimmt, wie schnelle sind denn dieser Geber dann. Ich hab da kein Fuß im Thema. Bei Ethercat mal was von 1ms für 8 Antriebe gelesen. Also 0,125ms?

 

[Blockmove]

Ja stimmt, wie schnelle sind denn dieser Geber dann. Ich hab da kein Fuß im Thema. Bei Ethercat mal was von 1ms für 8 Antriebe gelesen. Also 0,125ms?

Da musst du bei IFM nachfragen.
IO-Link arbeitet mit 38,4 kBit/s. Wenn nur der Geber am Master hängt, wirst du wohl (geschätzt) alle 4-6ms einen Positionswert bekommen.

 

[DeaD_EyE]

Da das Gerät unabhängig seine Werte aktualisiert und im Speicher ablegt, kann z.B. passieren, dass der alte Wert gelesen wird, obwohl der neue Wert schon vorhanden sind. Wenn man z.B. nur alle 6 ms Werte abholen kann, können sich die Werte in der Zwischenzeit geändert haben und dann zu Fehlern führen. Im Endeffekt ist die IOLink-Lösung technisch gesehen schlechter, da sie ungenauer sein kann. Dass die Kommunikationsanbindung selbst das Nadelöhr ist, hatte ich gar nicht auf dem Schirm.

Mit den HSC-Zählern habe ich noch nicht so viel gemacht, kann mir aber vorstellen, dass ein Interrupt bei einem Unter-/Überlauf möglich ist.

 

[CoffeeAddict2220]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben bei einer Anlage aktuell eine Zykluszeit von 1,2 bis 2 ms und im Trace habe ich über I/O-Link jeden Zyklus eine aktualisierte Position des Drehgebers erhalten.

 

[Blockmove]

@DeaD_EyE
Das Thema hast du überall im Zusammenhang mit Zyklus- und Reaktionszeiten.
Bei den HSC-Karten kannst du div. Interrupts einstellen. Vorallem kannst du einen Sollwert vorgeben und kannst dann darauf basierend Reaktionen vorgeben.

 

[Blockmove]

Wir haben bei einer Anlage aktuell eine Zykluszeit von 1,2 bis 2 ms und im Trace habe ich über I/O-Link jeden Zyklus eine aktualisierte Position des Drehgebers erhalten.

Hätte ich nicht erwartet. Ist das normales IO-Link mit den 38,4 kBit/s?
Es gibt auch ein „High-Speed“-IO-Link.

 

[CoffeeAddict2220]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt meine ich 3 verschiedene COM Modi bei I/O-Link, COM1 mit 4,8kBit/s; COM2 mit 38,4kBit/s und COM3 mit 230,4kBit/s. Unsere Master von Murr (IMPACT67 PRO) sind fähig alle 3 zu verwenden. Damit erhalten wir solch schnelle Inputs.

 

[CoffeeAddict2220]

Da das Gerät unabhängig seine Werte aktualisiert und im Speicher ablegt, kann z.B. passieren, dass der alte Wert gelesen wird, obwohl der neue Wert schon vorhanden sind. Wenn man z.B. nur alle 6 ms Werte abholen kann, können sich die Werte in der Zwischenzeit geändert haben und dann zu Fehlern führen. Im Endeffekt ist die IOLink-Lösung technisch gesehen schlechter, da sie ungenauer sein kann. Dass die Kommunikationsanbindung selbst das Nadelöhr ist, hatte ich gar nicht auf dem Schirm.

Mit den HSC-Zählern habe ich noch nicht so viel gemacht, kann mir aber vorstellen, dass ein Interrupt bei einem Unter-/Überlauf möglich ist.

Technisch schlechter ist schon sehr plumb gesagt. Es hat seine Vor- und Nachteile. Da wir vor kurzem unsere Anlagen mit 80% aller digitalen eingänge und Ausgänge, sowie Signallampe auf I/O-Link umgerüstet haben, ersparen wir uns einen gewaltigen Verdrahtungsaufwand von sonst 14polige Sensorkabeln von "normalen" Sensor-Aktor-Boxen. Und wie schon gesagt mit einer Übrtragungsrate von bis zu 230kBit/s erhält man in unter 2ms die aktuellen Zustände der Boxen.

 

[Blockmove]

Schlechter ist so ein System in den seltensten Fällen. Meist überwiegen die Vorteile.
Egal ob nun normale E/A mit Impact67 oder auch Impact67 in Verbindung mit IO-Link.
Man muss sich halt vor der Einführung Gedanken machen und einfach die Anwendungsfälle anschauen.
Normale M12-Sensor-Aktor-Boxen machen zumindest in der heutigen Zeit nur noch selten Sinn.