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
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.