Modbus über USB-Seriell-Schnittstelle

Ich kann mit den Screenshots nichts anfangen. Ich würd mal schaun was auf der seriellen Schnittstelle kommuniziert wird, entweder mit zusätzlichen seriell/USB konvertern oder einem Logikanalysator oder Digital-Oszilloskop mit passender Logikanalysator-Option. Da sieht man auch obs beim Timing Probleme gibt und was wirklich auf der Leitung ist, alles andere ist herumstochern.

Unter Linux funktioniert modbus mit FT232 und CH340 mit pymodbus auch mit 2mbit ohne Probleme, denke nicht dass es da mit "zivilen" Baudraten unter Windows Probleme geben kann. (Edit: mit einem STM32 als Gegenstelle, k.a. ob da die ESP32 Libs Probleme machen)

Ich schließe mich dem an. Schau erstmal mit einem Logic Analyzer auf der seriellen Schnittstelle, was da tatsächlich übertragen wird. Notfalls nimmst Du eine echte serielle Schnittstellenkarte, die über PCIe angebunden ist und damit auch die Timings exakt einhalten kann.

In diesem Modbus-Standard

https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

steht auch:

The format ( 11 bits ) for each byte in RTU mode is : Coding System: 8–bit binary Bits per Byte:

• 1 start bit
• 8 data bits, least significant bit sent first
• 1 bit for parity completion
• 1 stop bit

Even parity is required, other modes ( odd parity, no parity ) may also be used. In order to ensure a maximum compatibility with other products, it is recommended to support also No parity mode. The default parity mode must be even parity. Remark: the use of no parity requires 2 stop bits.

fchk

Frank K. schrieb:

The format ( 11 bits ) for each byte in RTU mode is : Coding System: 8–bit binary Bits per Byte:

• 1 start bit
• 8 data bits, least significant bit sent first
• 1 bit for parity completion
• 1 stop bit

Even parity is required, other modes ( odd parity, no parity ) may also be used. In order to ensure a maximum compatibility with other products, it is recommended to support also No parity mode. The default parity mode must be even parity. Remark: the use of no parity requires 2 stop bits.

fchk

Es war das Paritätsbit. Eben aktiviert...geht :-)

Etwas seltsam ist ja schon, das der UART des ESP32 das, was der Host dann in unpassendem Format gesendet hat, trotzdem akzeptiert hat. Aus dem Grund habe ich auch in Richtung "grundlegende Kommunikationsparameter überhaupt nicht gesucht"...

Frank, vielen herzlichen Dank für die Lösung meines Problems!

Klaus L. schrieb:

Etwas seltsam ist ja schon, das der UART des ESP32 das, was der Host dann in unpassendem Format gesendet hat, trotzdem akzeptiert hat.

Die meisten UARTs akzeptieren Daten auch mit falscher Parity, sie setzen nur ein entsprechendes Fehlerflag. Wenn man das nicht auswertet ... bekommt man davon auch nichts mit.