Modbus ASCII lesen — jede LRC geprüft.
Im ASCII-Modus reist jedes Modbus-Byte als zwei Hex-Zeichen, eingerahmt von Doppelpunkt und CR LF. Trace liest die serielle Leitung, findet jedes Telegramm an diesen Begrenzern, prüft die LRC und zeigt Adresse und Function-Code im Klartext.
Kein Mailprogramm eingerichtet? Schreib direkt an support@trace-analyzer.net.
Der Zugang ist derzeit kostenlos und wird auf Anfrage freigeschaltet.
- ✓ LRC geprüft
- ✓ Rahmen von : bis CR LF
- ✓ Function-Codes im Klartext
- ✓ Fehlerhafte Telegramme bleiben sichtbar
Von der Leitung zum Telegramm.
Eine Anfrage an Slave 1, die Antwort mit zwei Registern — und dieselbe Anfrage noch einmal mit beschädigter LRC.
Das dritte Telegramm endet auf FB statt FA. Trace behält es in der Liste und markiert es als FrameError. Anders als bei Modbus RTU spielt das Timing keine Rolle: die Begrenzer allein bestimmen das Telegramm. Gekürzt dargestellt.
Modbus ASCII, ohne Zeichen zu zählen.
Rahmen ohne Timing
Jedes Telegramm beginnt mit einem Doppelpunkt und endet mit CR LF. Trace rahmt an diesen Zeichen — unabhängig vom USB-Adapter und seinen Zeitstempeln.
LRC bei jedem Telegramm
Die LRC wird über die dekodierten Bytes berechnet, nicht über die Hex-Zeichen, und mit der übertragenen verglichen. Ein falsches Telegramm wird markiert, nicht verworfen.
Eine Definition, die du anpasst
Die Modbus-ASCII-Definition ist eine offene TrIML-Datei. Register-Belegungen oder herstellerspezifische Function-Codes ergänzt du selbst — ohne Code.
- SucheVolltextsuche über alle Telegramme, auch im laufenden Strom.
- AufnahmeRohbytes und fertige Interpretation in einer .msf-Datei.
- Mehrere PortsMehrere Schnittstellen in einer Sitzung, auf einer gemeinsamen Zeitachse.
- Aus der FerneProbe an der Anlage, Auswertung im Browser — ohne eingehenden Port.
Was noch fehlt.
Damit du nicht erst beim Ausprobieren merkst, wo die Grenzen liegen:
- Keine Felder je Function-Code. Startadresse, Anzahl und Registerwerte erscheinen als Hex-Block im Feld Data. Die Aufteilung kannst du in der Definition selbst ergänzen.
- Exception-Antworten (Function-Code mit gesetztem Bit 0x80) werden noch nicht gesondert hervorgehoben.
- Eine Definition je Port. Laufen RTU und ASCII auf derselben Leitung, schaltet Trace nicht selbst um — du wählst die Definition für den Port.
- Kein Modbus TCP. Trace liest serielle Leitungen, keinen Netzwerkverkehr.
Die LRC über dekodierte Bytes.
Die LRC sichert die Bytes hinter den Hex-Zeichen. In TrIML ist das ein Attribut: encoding="ascii-hex" an der Berechnung.
<const type="byte" value="0x3A" name=":" /> <ascii-byte name="Address" /> <ascii-byte name="Function" valuedescriptor="modbus-func" /> <!-- Data: hex pairs up to the LRC --> <calc name="LrcCalc" type="LRC" encoding="ascii-hex" from="1" to="-1" resultType="byte" /> <const ref="LrcCalc" validate="true" type="ascii-byte" name="LRC" />
Häufige Fragen
Was unterscheidet Modbus ASCII von Modbus RTU?
Gleiche Function-Codes, anderer Rahmen: ASCII sendet jedes Byte als zwei Hex-Zeichen zwischen Doppelpunkt und CR LF und sichert das Telegramm mit einer LRC. RTU sendet rohe Bytes, trennt Telegramme durch Pausen und nutzt eine CRC16. ASCII braucht doppelt so viele Zeichen, verträgt aber Pausen innerhalb eines Telegramms.
Stört Trace den Busverkehr?
Nein. Trace hört nur zu und sendet selbst keine Anfragen. Am RS485-Bus wird ein USB-RS485-Wandler parallel an A und B angeschlossen.
Modbus ASCII mit Trace ausprobieren.
Schreib kurz, woran du misst. Der Zugang wird dann freigeschaltet — und was dir fehlt, fließt direkt in die Entwicklung ein.
Kein Mailprogramm eingerichtet? Schreib direkt an support@trace-analyzer.net.