Modbus Register schreiben
Ich versuche gerade, einen Schrittmotor-Controller via ModbusRTU anzusprechen. Das Lesen von Read-Only Registern funktioniert schonmal. Beim Schreiben von Konfigurationsdaten habe ich aber noch Probleme.
Der Regler unterstützt die Funktionen:
Read Holding Registers 3 (03h)
Write Single Register 6 (06h)
Write Multiple Registers 16 (10h)
Mask Write Register 22 (16h)
Read/Write Multiple Registers 23 (17h)
Der RevPi kann offenbar kein "Read/Write Multiple Register", sondern nur "WRITE_MULTIPLE_REGISTERS". Demnach kann ich nicht sehen, ob die gesendeten Werte korrekt übernommen wurden? Oder muss ich dafür die gleiche Adresse 2x ansprechen, einmal mit "Write_Multiple_Register" und danach per "Read_Holding_Register"?
Mit freundlichen Grüßen
Thorsten Ostermann
Der Regler unterstützt die Funktionen:
Read Holding Registers 3 (03h)
Write Single Register 6 (06h)
Write Multiple Registers 16 (10h)
Mask Write Register 22 (16h)
Read/Write Multiple Registers 23 (17h)
Der RevPi kann offenbar kein "Read/Write Multiple Register", sondern nur "WRITE_MULTIPLE_REGISTERS". Demnach kann ich nicht sehen, ob die gesendeten Werte korrekt übernommen wurden? Oder muss ich dafür die gleiche Adresse 2x ansprechen, einmal mit "Write_Multiple_Register" und danach per "Read_Holding_Register"?
Mit freundlichen Grüßen
Thorsten Ostermann
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
Ich habe jetzt mal ein "Write Multiple Registers (0x10)" in die Konfiguarion aufgenommen. Ich kann die zugeordnete Variable "AnalogOut0" mit PiTest beschreiben, sehe aber keinen Effekt am Ausgang.
Wenn ich mir die Kommunikation auf dem Bus ansehe, sendet der RevPi zyklisch "4C 10 A5 1E 00 01 02 00 00 39 B7". Das entspricht einem Write an den Slave 76(dez) auf Adresse 42270, 1 Register, 2 Bytes. Aber Value ist "0x 00 00"? Ich habe extra mal auf das analoge Signal getriggert. um zu sehen ob der Ausgang wenigstens kurz auf den per PiTest gesetzten Wert von 2000(dez) , also 2V geht. Aber da passiert nichts. Warum sendet der RevPi nicht dauerhaft den zuletzt per PiTest gesetzten Wert?
Mit freundlichen Grüßen
Thorsten Ostermann
Wenn ich mir die Kommunikation auf dem Bus ansehe, sendet der RevPi zyklisch "4C 10 A5 1E 00 01 02 00 00 39 B7". Das entspricht einem Write an den Slave 76(dez) auf Adresse 42270, 1 Register, 2 Bytes. Aber Value ist "0x 00 00"? Ich habe extra mal auf das analoge Signal getriggert. um zu sehen ob der Ausgang wenigstens kurz auf den per PiTest gesetzten Wert von 2000(dez) , also 2V geht. Aber da passiert nichts. Warum sendet der RevPi nicht dauerhaft den zuletzt per PiTest gesetzten Wert?
Mit freundlichen Grüßen
Thorsten Ostermann
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
- crismancich
- KUNBUS
- Posts: 40
- Joined: 05 Jan 2021, 11:25
- Location: Hamburg
- Contact:
Hallo Thorsten,
deine Beobachtung deckt sich mit unserer Doku. Read/Write wird vom Master offensichtlich nicht unterstützt:
https://revolutionpi.de/tutorials/modbu ... verwenden/
Wir haben das aufgenommen und an den zuständigen Product Owner weitergeleitet. In dieser Form erhalten die Product Owner Feedback aus dem Feld und entscheiden darüber, welche Features in die Roadmap aufgenommen werden.
deine Beobachtung deckt sich mit unserer Doku. Read/Write wird vom Master offensichtlich nicht unterstützt:
https://revolutionpi.de/tutorials/modbu ... verwenden/
Wir haben das aufgenommen und an den zuständigen Product Owner weitergeleitet. In dieser Form erhalten die Product Owner Feedback aus dem Feld und entscheiden darüber, welche Features in die Roadmap aufgenommen werden.
Viele Grüße / Kind regards / Quapla’ / 此致敬意
Boris Crismancich
Boris Crismancich
Hallo Boris,
Mein letzter Beitrag bezieht sich auf meinen Test mit "WRITE_MULTIPLE_REGISTERS". Das sollte laut Doku unterstützt werden, funktioniert aber offenbar nicht oder nicht so wie ich es erwarten würde. Der Slave kann das, aber der RevPi als Master sendet die Nutzdaten nicht raus?!
Mit freundlichen Grüßen
Thorsten Ostermann
Mein letzter Beitrag bezieht sich auf meinen Test mit "WRITE_MULTIPLE_REGISTERS". Das sollte laut Doku unterstützt werden, funktioniert aber offenbar nicht oder nicht so wie ich es erwarten würde. Der Slave kann das, aber der RevPi als Master sendet die Nutzdaten nicht raus?!
Mit freundlichen Grüßen
Thorsten Ostermann
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
Hallo Thorsten,
ich habe das hier gerade mal nachgestellt und kann mit dem FC WRITE_MULTIPLE_REGISTERS Daten übertragen. Um dein Problem genauer zu analysieren bräuchte ich bitte folgende Dinge von deinem Aufbau:
- Log des Modbus Masters (journalctl -u pimodbus-master > dein_modbus_master.log)
- Screenshot deiner Extended Attributes im Pictory
Gruß Nicolai
ich habe das hier gerade mal nachgestellt und kann mit dem FC WRITE_MULTIPLE_REGISTERS Daten übertragen. Um dein Problem genauer zu analysieren bräuchte ich bitte folgende Dinge von deinem Aufbau:
- Log des Modbus Masters (journalctl -u pimodbus-master > dein_modbus_master.log)
- Screenshot deiner Extended Attributes im Pictory
Gruß Nicolai
Hallo Nicolai,
mal vom frisch gebooteten Pi. Schreibversuch über piTest:
dann noch über den RevPiCommander. Kein Signal am Ausgang messbar. Lesen der Eingangswerte funktioniert ohne Probleme.
Mit freundlichen Grüßen
Thorsten Ostermann
mal vom frisch gebooteten Pi. Schreibversuch über piTest:
Code: Select all
Last login: Wed Jan 26 16:03:46 2022 from 192.168.47.149
pi@RevPi66210:~ $ piTest -w AnalogOut0,2500
Write value 2500 dez (=09c4 hex) to offset 205.
Mit freundlichen Grüßen
Thorsten Ostermann
- Attachments
-
- mein_modbus_master.zip
- (382 Bytes) Downloaded 673 times
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
Das Problem scheint durch das letzte Software-Update behoben zu sein. Ich kann jetzt sowohl einzelne als auch mehrere Register schreiben (Modbus-Kommandos 0x06 bzw. 0x10). Die Schreibzugriffe per piTest werden dann auch im RevPiModIO SPS-Monitor angezeigt und kommen richtig im Slave an. Ich werde das jetzt mal mit einem größeren Satz an Variablen mit höherer Updaterate testen.
Mit freundlichen Grüßen
Thorsten Ostermann
Mit freundlichen Grüßen
Thorsten Ostermann
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
Hallo Thorsten,
danke für dein Feedback. Ich bin leider noch nicht dazu gekommen, deinen Aufbau hier nachzustellen. Es freut mich daher zu hören, dass mit unserer aktuellen Software die Probleme behoben sind.
Gruß Nicolai
danke für dein Feedback. Ich bin leider noch nicht dazu gekommen, deinen Aufbau hier nachzustellen. Es freut mich daher zu hören, dass mit unserer aktuellen Software die Probleme behoben sind.
Gruß Nicolai
Hallo Nicolai,
ich muss leider zurückrudern. Alle Versuche, den Satz an übertragenen Variablen zu erhöhen sind bisher fehlgeschlagen. Ich bin inzwischen wieder auf je 3 Register zum Lesen und Schreiben zurück gegangen, aber selbst da meldet der Slave immer wieder Fehler.
Bei einem etwas komplexeren Setup ist mir ein merkwürdiges Verhalten vom Master aufgefallen, was zu Kollisionen auf dem Bus führt. Irgendwas scheint da in der State-Machine nicht zu stimmen?! Der Master wartet nach einem Kommando nicht lange genug auf die Antwort vom Slave, sondern schickt schon nach ca. 600µs das nächste Kommando hinterher. Hier mal ein paar Screenshots vom aufgezeichneten Datentransfer.
Ich hatte vorher versucht, verschiedene Registerzugriffe mit verschiedenen Zykluszeiten zu machen, um den Bus nicht unnötig zu belasten. Dabei ist mir das das erste Mal aufgefallen. Aber auch wenn ich gleiche Refresh-Zeiten konfiguriere, lässt sich das beobachten.
ich muss leider zurückrudern. Alle Versuche, den Satz an übertragenen Variablen zu erhöhen sind bisher fehlgeschlagen. Ich bin inzwischen wieder auf je 3 Register zum Lesen und Schreiben zurück gegangen, aber selbst da meldet der Slave immer wieder Fehler.
Bei einem etwas komplexeren Setup ist mir ein merkwürdiges Verhalten vom Master aufgefallen, was zu Kollisionen auf dem Bus führt. Irgendwas scheint da in der State-Machine nicht zu stimmen?! Der Master wartet nach einem Kommando nicht lange genug auf die Antwort vom Slave, sondern schickt schon nach ca. 600µs das nächste Kommando hinterher. Hier mal ein paar Screenshots vom aufgezeichneten Datentransfer.
Ich hatte vorher versucht, verschiedene Registerzugriffe mit verschiedenen Zykluszeiten zu machen, um den Bus nicht unnötig zu belasten. Dabei ist mir das das erste Mal aufgefallen. Aber auch wenn ich gleiche Refresh-Zeiten konfiguriere, lässt sich das beobachten.
- Attachments
-
- Schreibzugriff (0x10) und Slave-Antwort auf Lesezugriff (0x03) kollidieren
- scope_66.png (36.21 KiB) Viewed 19246 times
-
- Lesezugriff (0x03)
- scope_65.png (32 KiB) Viewed 19246 times
-
- Gesamtansicht
- scope_64.png (33.24 KiB) Viewed 19246 times
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!
Die Screenshots erscheinen leider in der falschen Reihenfolge. Ganz unten ist die Gesamtansicht. Ich konnte sogar Extremfälle beobachten, wo der nächste Master-Request und die Antwort vom Slave auf den vorherigen Request kollidiert sind. Gemäß Modbus-Spec sollte der Master eigentlich bis zu einem definierten Timeout warten, bevor er den nächsten Request sendet. Wo wird dieser Timeout beim RevPi Modbus Master konfiguriert?
Hier noch die Konfiguration der Zugriffe in PiCtory. Für die Fehlersuche wäre es schön, wenn man einzelne Zeilen über eine Checkbox deaktivieren könnte. Ich habe mir damit geholfen, eine unbelegte Slave-ID einzutragen und das Action-Intervall sehr hoch zu setzen. Aber ab und zu wird da ja trotzdem ein Paket rausgeschickt.
Mit freundlichen Grüßen
Thorsten Ostermann
Hier noch die Konfiguration der Zugriffe in PiCtory. Für die Fehlersuche wäre es schön, wenn man einzelne Zeilen über eine Checkbox deaktivieren könnte. Ich habe mir damit geholfen, eine unbelegte Slave-ID einzutragen und das Action-Intervall sehr hoch zu setzen. Aber ab und zu wird da ja trotzdem ein Paket rausgeschickt.
Mit freundlichen Grüßen
Thorsten Ostermann
- Attachments
-
- 2022-02-05 18_50_31-PiCtory - 2.0.4.png (160.6 KiB) Viewed 19246 times
--
https://www.mechapro.de - Wir bewegen Ihre Ideen!
https://www.mechapro.de - Wir bewegen Ihre Ideen!