The Industrial Raspberry Pi Forum

Hallo,

nachdem mein System wieder läuft, versuche ich nun Modbus zum laufen zu bekommen.

Meine Hardware scheint richtig angeschlossen zu sein, da ich mit modpoll auf dem Core korrekte Messwerte bekomme:
liefert: Nun versuche ich das ganze in Pictory ModbusRTU Master einzustellen:
device_path /dev/ttyUSB0
baud_rate 19200
parity None
data_bits 8
stop_bits 1

In Extended Data:
Slave Addr. 33
Function Code READ_HOLDING_REGISTERS
Register Addr. 1
Quantity of Registers 1
Action Interval (ms) 1000
Device Value Input_Word_1

Wenn ich jetzt aber versuche etwas zu lesen: kommt: Warum ist der Wert 0 und nicht 430??? Und was sagt der Fehlercode 255??

Hallo ghx,
danke für die ausführliche Schilderung des Fehlerbildes. Das ist klasse und hilft, das Problem zu verstehen. Ich finde Deine Vorgehensweise spitze, denn Du hast erst einmal gezeigt, dass Modbus ohne den Weg über das Prozessabbild funktioniert. Jetzt, beim Versuch, den RevPi Way zu nutzen und über das Prozessabbild zu kommunizieren, tun sich die Probleme auf. Also ran ans Troubleshooting und in die Mitte der Sache!

Das Statusregister, das Du ausgelesen hast, ist auch hier der Schlüssel:
Was bedeutet der Wert 255 im Register "Modbus_Master_Status"? Der Wert ist gleich 0xFF und steht unter anderem hier:
https://revolutionpi.com/en/tutorials/m ... -verwenden

Möglicherweise wurde das Problem durch den parallelen Zugriff sowohl über den Userspace via "Modpoll" als auch vom Service, der das Prozessabbild befüllt, verursacht.

Die RS485-Schnittstelle hier kann meiner Meinung nach nur von einem Prozess geöffnet werden, zumindest für Schreibzugriffe - es kann nur einen geben

a) Stoppe alle Userspace Prozesse, die auf die RS485-Schnittstelle zugreifen, entweder durch einen "sudo reboot" oder anderweitig.
b) Führe einen Reset des PiControl Prozesses durch, "piTest -x".
c) Teste Deine Befehle nochmals - hat sich der Wert im Register "Modbus_Master_Status" verändert? Ggf. schreibe eine 1 in das Register "Master_Status_Reset" und lese den Wert nochmals aus.

Vielleicht löst sich das Ganze damit auf.

Hallo Dirk,

Das Statusregister, das Du ausgelesen hast, ist auch hier der Schlüssel:
Was bedeutet der Wert 255 im Register "Modbus_Master_Status"? Der Wert ist gleich 0xFF und steht unter anderem hier:

Aber 0x11 ist doch was anderes als 0xFF Oder hab ich da was falsch verstanden?
Als alter C-Programmierer dachte ich, das richtig auseinanderhalten zu können.

ein piTest -x hat gestern nix gebracht. Der Fehler blieb erhalten.

Nach einem sudo reboot liefert mir piTest folgendes: Mag sein, dass es mit modpoll irgendwie kollidiert war. Jetzt jungfräulich und ohne Fehler. Aber immer noch kein Messwert!

... danach modpoll liefert Messwert.

ein piTest nach dem modpoll blieb auch fehlerfrei. Aber auch ohne Werte.

Nach dem 3. piTest -X kommen jetzt auch Werte zurück. Vorerst stabil.
Kann da irgendetwas mit dem Timing nicht stimmen? Hat evtl modpoll ein anderes Timing wie der Modbus-Master?

Neues Update:
Nach einigen Stunden blieb der Messwert hängen. Keine Updates mehr
nach einem piTest -x: der Messwert 0 und das 0xff verstehe ich, da plötzlich der USB-Modbus nicht mehr ttyUSB0 sonder ttyUSB1 heißt.

Teil 2:
Nach einem reboot lief es wieder. Ich hab die Vermutung, der USB-Modbus hat einen Schlag...

Hallo ghx,
dann wurde USB wurde neu enumeriert, eventuell war die Verbindung wackelig
Ok, da habe ich wohl 0x11 mit 0xFF verwechselt - sorry, das schaue ich mir nochmals an, vollkommen richtig bemerkt Allerdings hast du die 0xFF ja dann doch erhalten. Das ist halt der Kern der Sache, wenn das Gerät "fehlt" kommt es zu diesem Fehlercode.

• Wie sieht dein Aufbau aus und welche Umgebungen gibt es?
• UDEV Regeln ermöglichen konstante Pfade bei USB Enumerierung:
• Revolution Pi Questions And Answers | Is there a way to ensure that the USB devices are always represented with the same device file names?