Das "Modbus TCP" sagt erst einmal nur grob in welche Richtung es geht.
Die zugehörige Norm ist die komplette Information. Du meist warscheinlich Norm
IEC 61158
igus D1 Handbuch standardsiert nach CiA 309:
Die Kommunikation mittels Modbus TCP ist als Gateway implementiert und dient lediglich als Telegramm Übertragung. Grundlage ist CiA 309 "Access from other networks" Teil 1 "General principles and services" und Teil 2 "Modbus/TCP mapping“
Ich wäre froh bereits früher auf diese Aussage gestoßen sein, habe mir selbst stundenlang die Zähne ausgebissen wieso normale Modbus TCP Kommunikation mir eigentlich eine sinnvollen Daten ausgibt -> da ich normalerweise nicht gerne die fertigen Blöcke der Hersteller verwende.
In diesem Falle habe ich mir selbst noch einen Block darüber geschrieben der mir die ganzen nötigen Variablen ansteuert.
Du findest alles, zwar schwierig aber doch, im Handbuch heraus, aber hier noch eine kurze Zusammenfassung:
Prinzipiell die ganz große Problematik! Es kann teilweise, nach meinen Messungen, bis zu 250ms dauern das Befehle über die Schnittstelle angenommen und verarbeitet wurden. Kann bei sehr vielen Fehlerfällen zu großer Verwirrung führen.
Dadurch muss das SWITCH_ACTIVE z.B. deutlich früher gesetzt werden als der START Befehl, ansonsten wird der einfach ignoriert.
Die IPs, HW_IDs und CON_IDs sollten klar sein.
ENABLE startet die Kommunikation -> muss für die Quittierung rückgesetzt werden, ansonsten funktioniert diese nicht.
SWITCH_ACTIVE, schaltet dein Modus in "Lageregelung" (nenne ich mal so).
OPM_SET kannst du im Handbuch finden, aber die wichtigsten:
(Modenr.: 1=Jog u. Auto(Position-Controlled); 3=Jog u. Auto(Speed-Controlled); 6=Ref-Drive(with position from fieldbus))
PP_RELATIV -> wenn TRUE dann relativ positionieren
PP_POS -> Zielposition, darauf auf die Webserver-Konfig für Vorschub usw. achten (m.M. nach komischerweise standardmäßig mm/100)
PPPV_VEL -> Zielgeschwindigkeit (für Richtungswechsel im Jog-Modus dementsprechend einen negativen Wert angeben)
PPPV_ACC -> Ich habe für mich ACC von DCC getrennt, ist standardmäßig nur ein Parameter (Beschleunigung, Entschleunigung)
START -> Muss TRUE sein egal ob Positionierung, Referenzfahrt oder Jog-Modus
STOP -> Dementsprechend zu START invertiert)
ERROR_RESET -> Quittiert die Fehler am D1
Die restlichen Variablen sollten als Status relativ klar sein was sie zu bedeuten haben.
Zusätzlich darauf achten DI7 muss unbedingt verkabelt werden, ist für die Freigabe zuständig und kann nicht anders übergeben werden.
Unbedingt die Einschaltreihenfolge, gibt ein eigenes Kapitel dafür im Handbuch, beachten.
Und dann der Überclue bei dem ganzen:
Wenn du eine Referenzfahrt auf negativen/positiven Endschalter durchführen möchtest und keine Absolutwertgeberjustage, dann benötigst du zusätzlich noch eine "Nullpunkt-Geschwindigkeit" und "Nullpunkt-Beschleunigung", die darfst du natürlich bei deaktivierter Freigabe und deaktivierter Modbus Kommunikation in der Kategorie "Fahrprofile" am Webserver direkt in der Hex-Tabelle eingeben bzw. gibt es daneben die Dez-Eingabe. Könnte man sich in der Vorlage zusätzlich ausprogrammieren, ist jedoch den Aufwand kaum Wert.
Alleine dafür hätte ich schon jemanden an den Kragen hüpfen können.
Ansonsten steht dein Achse beim referenzieren, fehlerlos.
Im gesamten muss ich mich sehr kritisch der Low-Cost-Automation gegenüber äußern, für verdrahtete, einfache Anwendungsbeispiele absolut super, aber für komplexere Aufgaben mit Schnittstellen absolut fehl am Platz. Hat bis jetzt nur Zeit, Nerven und Geld gekostet.
