Read Modbus ASCII — with every LRC checked.
In ASCII mode every Modbus byte travels as two hex characters, framed by a colon and CR LF. Trace reads the serial line, finds each telegram by those delimiters, verifies the LRC and shows address and function code in plain text.
No mail app set up? Write directly to support@trace-analyzer.net.
Access is currently free and granted on request.
- ✓ LRC verified
- ✓ Framing from : to CR LF
- ✓ Function codes in plain text
- ✓ Faulty telegrams stay visible
From the wire to the telegram.
A request to slave 1, the response with two registers — and the request again with a corrupted LRC.
The third telegram ends in FB instead of FA. Trace keeps it in the list and marks it as FrameError. Unlike Modbus RTU, no timing is involved: the delimiters alone mark the telegram. Shown abridged.
Modbus ASCII without counting characters.
Framing that needs no timing
Each telegram starts with a colon and ends with CR LF. Trace frames by these characters — independent of the USB adapter and its timestamps.
LRC on every telegram
The LRC is computed over the decoded bytes, not the hex characters, and compared with the transmitted one. A wrong telegram is marked, not dropped.
A definition you can adapt
The Modbus ASCII definition is an open TrIML file. You add register layouts or vendor-specific function codes yourself — without code.
- SearchFull-text search across all telegrams, even in the live stream.
- RecordingRaw bytes and the finished interpretation in one .msf file.
- Multiple portsSeveral interfaces in one session, on a shared timeline.
- RemoteProbe at the machine, analysis in the browser — no inbound port.
What is still missing.
So you don't have to find the limits by trying:
- No per-function-code fields. Start address, quantity and register values appear as a hex block in the Data field. You can add the split to the definition yourself.
- Exception responses (function code with bit 0x80 set) are not highlighted separately yet.
- One definition per port. If RTU and ASCII run on the same line, Trace does not switch automatically — you choose the definition for the port.
- No Modbus TCP. Trace reads serial lines, not network traffic.
The LRC over decoded bytes.
The LRC covers the bytes behind the hex characters. In TrIML that is one attribute: encoding="ascii-hex" on the calculation.
<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" />
Frequently asked questions
What is the difference between Modbus ASCII and Modbus RTU?
Same function codes, different framing: ASCII sends every byte as two hex characters between a colon and CR LF and protects the telegram with an LRC. RTU sends raw bytes, separates telegrams by silence and uses a CRC16. ASCII needs twice the characters but tolerates pauses within a telegram.
Does Trace interfere with bus traffic?
No. Trace only listens and never sends requests itself. On an RS485 bus, a USB-to-RS485 converter is connected in parallel to A and B.
Try Modbus ASCII with Trace.
Tell us briefly what you are measuring. We will enable your access — and whatever you find missing goes straight into development.
No mail app set up? Write directly to support@trace-analyzer.net.