Modbus über USB-Seriell-Schnittstelle

[Klaus L. (keyel80)]

Liebes Forum,

ich versuche mich an der Implementierung eines Modbus-Slaves auf Basis 
des ESP32, der über einen USB->TTL-UART Wandler mit dem Windows 11 
verbunden ist. Mein Ziel ist es, im Rahmen einer Lehrveranstaltung eine 
Platine mit diversen Sensoren und Aktoren von einer Codesys Software-SPS 
anzusprechen.

Ein Test mit dem Radzio! Modbus Master Simulator 
(RMMS)(https://en.radzio.dxp.pl/modbus-master-simulator/) lief (na ja, 
nach den üblichen Fehlerkorrekturen) einwandfrei.

Die Tests mit Modpoll (https://www.modbusdriver.com/modpoll.html) und 
dem CODESYS Control Win V3 x64 endeten mit Fehlermeldungen "CRC Error" 
oder "Timeout".

Um den Datenverkehr auf der Schnittstelle besser analysieren und 
vergleichen zu könnten, installierte ich den 
https://www.serial-port-monitor.org und präsentiere Euch Screenshots der 
Logs.

Im Detail zum RMMS-Test: So soll es sein :-) Es fällt auf, dass der RMMS 
im Vergleich sehr wenige Log-Einträge erzeugt. Insbesondere sind die 
ganzen IRP_MJ_DEVICE_CONTROL-Aufrufe nicht zu finden.

Im Detail zu modpoll-Test: Master-Log Eintrag 78/79 zeigt den Request, 
der gemäß Slave-Log korrekt erkannt und mit 01 02 01 00 a1 88 
beantwortet wird. Gemäß Master-Log Eintrag 85 und 89 kommt aber etwas 
gänzlich anderes an und wird deshalb auch nicht akzeptiert.

Im Detail zum CODESYS-Test: In Zeilen 574/575 erkennt man den Request. 
Eine Response ist nicht zu sehen

Übrigens, die erste: Ich habe zunächst einen CH340-Wandler verwendet, 
testweise auf den neuesten Treiber des Herstellers aktualisiert und dann 
auch einen FT232-Wandler verwendet. Die Situation blieb gleich.

Übrigens die zweite: Ich habe testweise Verzögerungen von 100ms und von 
500ms vor dem Rücksenden eingebaut. Beides brachte nichts.

Vermutlich ist der RMMS einfach weniger "scharf", was 
Timing-Anforderungen angeht? Möglicherweise kommen die Treiber für den 
USB-UART-Wandler durch die vielen IOCTL-Aufrufe durcheinander und 
"verschlucken" Daten? Ist dem so? Was kann man tun?

(edit 1: Das Projekt habe ich hier veröffentlicht: 
https://github.com/klaus-liebler/labathome/tree/master/labathome_firmware_modbus 
. Die notwendigen components, insbesondere meine modbus lib finden sich 
hier: https://github.com/klaus-liebler/espidf-components .)

Viele Grüße und Danke im Voraus!

Klaus

[Robert M. (r_mu)]

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)

[Frank K. (fchk)]

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

[Klaus L. (keyel80)]

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!

[Harald K. (kirnbichler)]

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.