Hallo,
via einfaches Terminal (HTerm) versuche ich gerade ein Modbus (Serial)
zu lesen. Die Daten sind aber, egal was für Einstellung, praktisch nicht
lesbar.
Gibt es Terminals (open source) die solche Modbus Daten gleich
dekodieren können?
Via Google Suche nichts gescheites gefunden (ca. 40min gesucht)...
Danke
Hallo epika,
Modbus RTU ist nicht als human readable konzipiert. Modbus ASCII wäre da
die Alternative.
Welche Hardware / Software verwendest du für den Sniffer? Es gibt
verschiedene Libraries, die die Modbus-Kommunikation machen und auch
entsprechende Ausgaben machen können. Du kannst dir auch ein einfaches
Skript schreiben, das dir die empfangenen Bytes als Hexadezimal-Werte
anzeigt. Dann kannst du die Daten interpretieren anhand der
Modbus-Spezifikation. Da Modbus so schön einfach ist geht das.
Viele Grüße
Elektrix
Hallo,
ich weiss nicht ob die Daten die kommen RTU oder ASCII sind.
Ich habe zwei Leitungen die ich sniffe (wohl RX und TX). Dies mit einem
einfachen CH340 also Serial to USB (COM) Wandler (also 2 Stück je für RX
und TX, und diese am RX vom Wandler angeschlossen).
Die Bautrate ist 115200, das weiss ich. Ich erhalte ja die Daten und
kann diese abspeichern, aber das dekodieren habe ich keine Ahnung wie.
Arbeite mit Windows.
Danke
epika schrieb:> Ich habe zwei Leitungen die ich sniffe (wohl RX und TX). Dies mit einem> einfachen CH340 also Serial to USB (COM) Wandler (also 2 Stück je für RX> und TX, und diese am RX vom Wandler angeschlossen).
Modbus RTU/ASCII wird in den meisten Fällen mit einer
RS-485-Schnittstelle im Halbduplex verwendet. Die Varianten mit
Vollduplex oder RS-232 sind hingegen eher selten anzutreffen.
Falls es sich jedoch um eine "normale" RS-485 handelt, benötigst Du
natürlich auf jeden Fall entsprechende Leitungstreiber. "Normale"
USB-Seriell-Wandler haben jedoch keine geeigneten Leitungstreiber. Und
man benötigt zum Mitlauschen auch nicht zwei separate Wandler, sondern
nur einen.
Es gibt Unmengen an Software, um Modbus mitzuschneiden und zu
dekodieren. Wenn Du stattdessen einfach mit einem normalen
Terminalprogramm mitschneidest, fehlen die für die Paketerkennung
wichtigen Pausen.
https://www.eltima.com/products/serial-port-monitor/
Hallo, es ist ziemlich sicher via RS232. Es ist die Schnittstelle zum
Phaserunner, bzw. um den Phaserunner zu programmieren via PC-Software.
Dieser hat 4 Anschlüsse, 5V, GND, und eben RX und TX.
Ich habe Seriell Wandler, weil der Phaserunner Daten zum PC schicken
kann, und umgekehrt PC Daten zum Phaserunner. Ich muss beide Daten
sniffen.
Mit dem Serial-port-monitor bin ich gerade dran, aber komme auf keine
gescheiten Daten. Liegt es in demfall an meine Serial Wandler?
Ist schon eine Weile her das ich es gebraucht habe, aber probier mal
das hier:
https://www.simplymodbus.ca/download.htm
Damit konnte man die Register direkt lesen/schreiben.
Olaf
hmm ok danke, muss ich dann ausprobieren. Aber wenn selbst der Serial
Port Monitor von eltima nichts gescheites auswerten kann, frage ich mich
ob meine Serial zu USB Wandler da was falsches messen... oder ob man da
anders sniffen müsste?
Mit einem einfach Terminal, werden einfach immer wieder 6 Byte Pakete
empfangen.
Die Daten sehen irgendwie so aus, egal ob Parity oder 2 Stopbit, ändert
nicht viel:
T a d K„'õ Y s @ (ÿûÿü ABE5Q ‘
P<ÿæ [;T a d ¸K„'õ \ s @ (ÿûÿü ?AE5V ‘P<ÿî
ˆsT a d ¸Ky'õ _ s @ (ÿûÿü ABD5Q ”
P<ÿæ (ÀT a d ¸K~'ø \ s @ 'ÿýÿü @CC5Q ”
P<ÿ÷ BT a d ¾K&'ø Y s @ 'ÿûÿþ ABC5Q ‘
P<ÿ÷ }MT a d ¾K~'õ \ p @ 'ÿûÿü ACC5K ”
P<ÿî -]T a d ¸Ky'ø _ p @ (ÿûÿþ @BC5K ‘þ
P<ÿæ "T a d ³K~'õ \ v @ (ÿýÿü ABD5Q ‘
P<ÿî ÎXT a d ³Ky!'î \ p @ 'ÿûÿú
@BD5Q ‘
Wenn du ein Oszi hast häng es doch mal dran. Dann siehst du ob die
Spannungen stimmen, welche Baudrate du hast und wieviele Bytes
tatsächlich kommen.
Viele Grüße
Elektrix
Im Handbuch zum Phaserunner steht u.a.:
"The communication standard uses a 5V TTL level serial bus, and Grin
producesa 3m long TTL->USB adapter cable so that you can connect with
the USB port of a standard computer. This is the same communication
cable used with the Cycle Analyst and Satiator products. You can also
use 3rd party USB->Serial cables, such as FTDI’s part number
TTL-232R-5V-AJ."
https://ebikes.ca/product-info/grin-products/phaserunner.html#UserManual
Das ist dann also weder RS-485 noch RS-232, sondern eine
UART-Schnittstelle mit 5V-Pegeln. Also dürfen auf dem entsprechenden
Adapter gar keine Leitungstreiber vorhanden sind, da sie (neben der
Pegelanpassung) auch noch eine Invertierung durchführen.
Um mit einem normalen Modbus-Analysator arbeiten zu können, wird auch
nur ein einziger Pegelwandler benötigt, an dessen RX-Eingang das
geeignet veroderte Signal beider Leitungen angelegt wird. Da der
Ruhepegel hig bzw. 5V beträgt, muss also ein AND-Gatter verwendet
werden. Ggf. tun es auch zwei Dioden und ein Pull-Up-Widerstand.
Friedrich L. schrieb:> Wenn es der Phaserunner ist, den ich gefunden habe, warum nimmst> du> nicht die Herstellersoftware?>> https://ebikes.ca/product-info/grin-products/phaserunner.html>> Viele Grüße>> Elektrix
Weil ich die Daten die der Phaserunner liefert nicht mit dem PC, sondern
auch mit einem Mikrocontroller auslesen möchte.
Andreas S. schrieb:> sondern eine> UART-Schnittstelle mit 5V-Pegeln. Also dürfen auf dem entsprechenden> Adapter gar keine Leitungstreiber vorhanden sind, da sie (neben der> Pegelanpassung) auch noch eine Invertierung durchführen.>> Um mit einem normalen Modbus-Analysator arbeiten zu können, wird auch> nur ein einziger Pegelwandler benötigt, an dessen RX-Eingang das> geeignet veroderte Signal beider Leitungen angelegt wird. Da der> Ruhepegel hig bzw. 5V beträgt, muss also ein AND-Gatter verwendet> werden. Ggf. tun es auch zwei Dioden und ein Pull-Up-Widerstand.
Also der Phaserunner hat eine RX und TX-Leitung - falls man die beim
Modbus so nennen darf??. Ich habe schon an beiden Leitung via CH340
Serial to USB versucht die Kommunikation zu entziffern. D.h. ich
schliesse die RX oder TX-Leitung des Phaserunner direkt am RX-Eingang
des CH340 an (auf 5V Pegel eingestellt). Ist das falsch?
Im Anhang mal die Daten die ich per HTerm empfange.
Ich weiss halt immer noch nicht ob mit oder ohne Parity, d.h. ob 1 oder
2 Stopbit etc.
Ja warscheinlich muss jetzt noch ein Oszi oder Datenlogger dran :-/ ...
nicht gedacht, dass der Modbus so kompliziert kodiert ist....
Die oben erwähnten Tools liefern mir alle keine brauchbaren Daten.
epika schrieb:> Ja warscheinlich muss jetzt noch ein Oszi oder Datenlogger dran :-/ ...> nicht gedacht, dass der Modbus so kompliziert kodiert ist....
Modbus ist überhaupt nicht kompliziert kodiert, sondern extrem einfach.
Allerdings muss man natürlich die verwendeten Register bzw. "Coils"
kennen.
Du hast aber vermutlich noch Probleme mit der physikalischen Ebene.
Harald schrieb:> Wireshark sollte auch direkt MODBUS dekodieren können, auch von> serieller Schnittstelle.
Modbus TCP glaub ich dir sofort.
Aber wie erkennen die denn bei RTU den Start des Frames aus einem
Stream? Bei einer festen Framelänge könnte man über die CRC validieren.
Soweit ich weiß ist Modbus bei manchen Funktionen recht flexibel in der
Framelänge. Und soweit ich weiß steht keine Länge im Frame.
Andreas S. schrieb:> Du hast aber vermutlich noch Probleme mit der physikalischen Ebene.
bevor ich die physikalische Ebene untersuche...
Was ich weiss:
Es ist ein Modbus RTU und 115200 Baudrate und der Phaserunner liefert
zwei Datenleitungen (zusätzlich 5V und GND) um dann via USB Wandler zur
PC-Software zu kommunizieren.
Ist es falsch am RX-Eingang eines CH340 Serial-USB Wandler (5V Pegel),
eine der Phaserunner Datenleitung anzuschliessen?
N. M. schrieb:> Aber wie erkennen die denn bei RTU den Start des Frames aus einem> Stream? Bei einer festen Framelänge könnte man über die CRC validieren.> Soweit ich weiß ist Modbus bei manchen Funktionen recht flexibel in der> Framelänge. Und soweit ich weiß steht keine Länge im Frame.
Gute Frage, hatte es nur gegoogelt, ob Wireshark auch seriell kann.
Weiter habe ich das nicht verfolgt.
epika schrieb:> Im Anhang mal die Daten die ich per HTerm empfange.
Daten als JPEG-Bild hat schon eine gewisse Qualität :-(
Ein Rechtsklick auf das "Received Data"-Fenster von HTerm erlaubt dir
den Export der Daten in diversen Darstellungsarten. Da muss man nicht
zur Screen Shot Krücke greifen und das auch noch als JPG-"Photo"
abspeichern.
Schorsch X. schrieb:> Üblicherweise sind dir Pausen die Trenner am Modbus.
Genau so ist es.
Auch wenn heutige PCs etliche GHz an Taktfrequenz haben, kann es aber
trotzdem passieren, dass eine einfache Anwendung entweder beim Empfang
eine Lücke übersieht oder beim Senden kurz schlafen gelegt wird. Die
"üblichen" UARTs bzw. USB-Seriell-Wandler bieten nämlich keine
Lückenerkennung in Hardware an, im Gegensatz zu z.B. einigen USARTs in
STM32-Microcontrollern.
Besonders schwierig zu findende Fehler treten übrigens dann auf, wenn
Geräte zu schnell antworten, d.h. direkt nach Erhalt eines Kommandos vom
Master. Spezifikationskonforme andere Geräte halten dann nämlich ggf.
beides als ein Paket, stellen dann eine fehlerhafte Prüfsumme fest und
setzen dann ein Alarm-Flag. In einem unserer aktuellen Projekte haben
wir genau solch eine Kombination. Leider kann man bei dem zu schnellen
Gerät keine Verzögerung konfigurieren, aber wenigstens bei dem anderen
Gerät die Erkennung auch kürzerer Pausen konfigurieren. Und der dritte
Gerätetyp basiert auf einer von mir entwickelten Firmware, so dass ich
dort selbst einen Workaround einbauen kann.
Hallo epika,
wie kommst du eigentlich darauf, dass das Kommunikationsprotokoll Modbus
RTU ist?
Wenn du einen Mikrocontroller zum Sniffen nimmst kannst dir mal die
diversen Modbus-Libraries für den Arduino anschauen.
Viele Grüße
Elektrix
Harald schrieb:> Gute Frage, hatte es nur gegoogelt, ob Wireshark auch seriell kann.> Weiter habe ich das nicht verfolgt.
Seriell ist nicht das Problem. Wireshark hat auch Pipes. Da kann man
alles rein schieben was man möchte. Von jeder Schnittstelle die man
möchte. Das Problem sehe ich eher dass man eben die Lücken im Frame
nicht erkennen kann. Also Start/Stop des Frames. Für einen uC kein
Problem. Für ein Betriebssystem schon. Und um sinnvoll innerhalb eines
Streams den Frame zu finden braucht man meiner Meinung nach eine feste
Länge oder eine dynamische Längenangabe innerhalb des Frames. Beides am
besten mit CRC.
Wolfgang schrieb:> Daten als JPEG-Bild hat schon eine gewisse Qualität
Ja das lässt bei mir auch die Lust gegen Null sinken.
N. M. schrieb:> Wolfgang schrieb:>> Daten als JPEG-Bild hat schon eine gewisse Qualität>> Ja das lässt bei mir auch die Lust gegen Null sinken.
sorry, jetzt im Anhang die HEX-Werte ..TXRX_1.log von der ersten
Datenleitung,
und ..TXRX_2.log von der zweiten Datenleitung. Die vielen Nullen
dazwischen werden wohl die erwähnten Pausen sein? Aber ich kann damit
leider trotzdem nicht viel anfangen. Müsste mich da mal einarbeiten.
Und muss dann noch später mit dem Oszi oder Datenlogger herausfinden ob
jetzt 2 oder 1 Stopbit bzw. ob mit oder ohne Parity-Bit...
vielen Dank
Friedrich L. schrieb:> wie kommst du eigentlich darauf, dass das Kommunikationsprotokoll Modbus> RTU ist?
ebikes.ca hat mir geschrieben, dass es ein serial Modbus ist, aber
aufgrund einer Lizenzvereinbarung dürfen sie keine weiteren Infos
weitergeben.
Im endless-sphere Forum, siehe Link unten, ist die Rede von RTU.
https://endless-sphere.com/forums/viewtopic.php?t=101055
Für Modbus verwende ich gerne qModMaster, kann RTU und TCP schreiben,
lesen und sniffen. Leider werden Float Werte nicht dekodiert, aber man
sieht zumindest die HEX Werte.
Christian K. schrieb:> Für Modbus verwende ich gerne qModMaster, kann RTU und TCP> schreiben,> lesen und sniffen. Leider werden Float Werte nicht dekodiert, aber man> sieht zumindest die HEX Werte.
ok danke, scheint ein gutes Program zu sein, ohne Begrenzungen.
Aber irgendwas scheint mir faul an meinem System, egal welche
COM-Einstellung, die Daten sind immer falsch, siehe Anhang.
Am Wochenende habe ich evtl. die Möglichkeit mit dem Oszi oder
Datenlogger zu messen...