A Modbus ASCII frame with a wrong LRC is dropped with no reply. Convert values to hex first, compute the LRC over those bytes, then ASCII-encode the frame. A read-back of a parameter set to 9.95 confirms the data format before the first write.
A drive that skips Modbus ASCII commands with no reply, no error and no write is discarding the frame at the checksum. In ASCII mode the LRC is the two's complement of the 8-bit sum of the frame's bytes, and it has to be computed over the hex byte values, after conversion and before the frame is ASCII-encoded. Sum the ASCII character codes instead, or let the leading colon into the sum, and the drive drops the frame silently. This article gives the symptom pattern, the conversion order that fixes it, one frame worked through by hand, and the read-back test that pins down the data format before your first write.
Symptoms and what each points to
When a link misbehaves, the reply pattern tells you which layer to open. Match what you see against this list:
- Silence on every frame, port settings verified. The LRC covers the wrong bytes. The two usual versions: the sum ran over the ASCII character codes, or the leading colon entered the sum.
- Silence on one frame, the others fine. A wrong field in that frame: an unconverted decimal value, or a register number the drive does not have.
- A reply that reads as garbage. The receive path still holds ASCII characters. They need conversion to hex before the program compares anything.
- Value written but off by a factor of 10 or 100. Data format and scaling. The framing is fine.
- A short error reply comes back. The checksum arrived intact and the drive understood the frame; the register address or the value inside it is the problem.
Silence has one cause outside the frame itself: a slave that dropped off the link while the master keeps polling. The recovery side is covered in make a Modbus master reconnect after a slave outage. An RTU link fails with its own pattern of no replies and address errors, covered in Modbus RTU master no reply and address errors.
The conversion order that fixes it
Keep the sequence fixed:
- Convert each decimal value to hex. In the PLC program that is the BIN instruction: 200 decimal becomes C8 hex.
- Assemble the frame bytes: address, function code, register, data.
- Compute the LRC over those byte values.
- ASCII-encode the whole frame, two characters per byte, and send it with the leading colon and the CR LF.
The Modbus specification defines the LRC as the two's complement of the 8-bit sum of the bytes from the address field through the last data byte. The colon and the CR LF stay out of the sum. In ASCII mode every field travels as printable characters, two hex characters per byte, and the address field alone is two characters, with slave addresses 1 through 247.
If the value you are writing is a floating-point number, the register packing follows its own rules; convert a CODESYS REAL into two Modbus WORD registers walks one case.
Example: one write frame, three LRC results
Write 200 decimal to holding register 3 at slave 1, function 06, write single register.
Bytes: 01 06 00 03 00 C8. The value went through BIN first: 200 decimal is C8 hex.
Correct LRC. Sum the bytes: 1 + 6 + 0 + 3 + 0 + 200 = 210 decimal, D2 hex. Two's complement: 256 − 210 = 46 decimal, 2E hex. Frame: :0106000300C82E, then CR LF.
Wrong LRC one, ASCII codes summed. The 12 characters before the checksum carry ASCII codes (digits 0 through 9 sit at 30 to 39 hex, letters from 41 hex up). Their 8-bit total wraps to 65 hex, 101 decimal, which yields an LRC of 9B. The frame still shows the right address and data, and the drive drops it all the same.
Wrong LRC two, colon included. The colon is 3A hex, 58 decimal: 210 + 58 = 268, which wraps to 12 decimal, 0C hex, and the LRC computes to F4. Dropped as well.
Both wrong frames survive any visual check, because the address and data fields are correct. Only a hand recomputation over the byte values exposes them.
Decode the reply with ATH
The drive answers in the same ASCII form, so the receive path mirrors the transmit path. Strip the colon and the CR LF, run ATH, then check the reply's LRC with the same sum as above. ATH is documented as ASCII to Hex: it converts a table of ASCII values to a specified table of HEX values. Once the reply is in hex, the program can compare and scale it. Pair ATH on receive with BIN on transmit so both directions of the link go through explicit, inspectable conversions.
Learn the data format with a read-back
Before the first write, learn how the drive stores numbers. Read the acceleration parameter, change it manually at the drive to 9.95, and read it again. The bytes that come back give you the scale:
- Read-back 995: two implied decimal places. Write 9.95 as 995, which is 03E3 hex (3 × 256 + 227).
- Read-back 9950: three implied decimal places; multiply by 1000.
- Read-back 10: no decimals in that register, so 9.95 will round and the format has to come from the manual.
The parameter addresses come from the drive manual. The motor parameter group summary and the Modbus appendix of the drive's own manual list the register for each parameter; get them from the drive manufacturer or its distributor.
A scale mismatch reads back as zeros or shifted digits, the same failure family as a Modbus TCP analog value that reads 0.
One safety note: a write to the acceleration register changes how the motor starts and stops, so make the first writes with the machine at rest and clear.
Recommendation
Recommendation: Fix the order, then prove the format. Convert decimal to hex with BIN first, compute the LRC over the hex byte values, then ASCII-encode the frame. If frames still draw no reply with verified port settings, recompute one frame's LRC by hand before touching baud rate, addressing or wiring. Run the 9.95 read-back before the first write so the scaling is known, and keep ATH on the receive path so both directions stay inspectable.
Questions
Does this fix apply to Modbus RTU frames as well?
No. RTU sends raw bytes and closes each frame with a two-byte CRC, so there is no LRC to compute and no hex-to-character encoding step. A silent RTU link points at wiring, slave address or timing first. The decimal to hex, LRC, then character encoding order in this article applies only when the link runs in ASCII mode.
What comes back when the LRC is correct but the register is wrong?
An exception reply. The drive echoes the function code with 80 hex added, followed by an exception code; a register it does not recognize returns code 02, illegal data address. That reply is the useful signal: a correct checksum with a bad register produces a visible exception, while a wrong LRC produces silence, so the two failures never look alike on the wire.
How do I verify a reply's LRC by hand?
Add the byte values from the address pair through the last data byte, keep the 8-bit total, subtract it from 256, and compare the result with the reply's final two characters. For the reply to the example write, the arithmetic is the same as on the transmit side. A match means the frame arrived intact, so any wrong number left in the value is a scaling or format issue.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.