Serial communication problems

On a serial line, the receiver drops any frame whose CRC or LRC doesn’t match and sends no response. Most serial problems therefore look like a single Timeout on the client. Narrow the cause down with the server’s diagnostics counters and both sides’ trace.

No response at all

Check in this order and stop at the first cause you find:

1. Port: did connect succeed? A port held by another program fails with Unable to acquire exclusive lock on serial port.
2. Transmission mode: are both sides RTU, or both ASCII?
3. Speed and character format: do baud, parity and stop_bits match the device? PDComm can’t use an 8N1 device, so switch the device to 8E1 or 8N2.
4. Address: does the request’s unit match the device’s address? A device with another address stays silent.
5. Wiring: on RS-232, transmit and receive cross exactly once; on RS-485, check D0/D1 polarity, termination and the common line. Make sure no RS-232 adapter is wired straight to an RS-485 port.
6. Device settings applied: after changing the device’s communication settings, did you save them and restart its communication module if needed?
7. Device state: a device in listen-only mode answers nothing. Recover it with diagnostics sub-function 1 (Restart Communications Option), which gets no response either.

Use trace to see what actually went over the line:

What trace shows	Meaning
tx without any rx	The request went out and nothing came back. Check wiring, address and device power.
rx dropped as rx_discarded	A reply from another address or corrupted bytes. Check the address and parity.
rx with garbled bytes	The speed or character format doesn’t match.

CRC and LRC errors

The receiver got a frame whose CRC (RTU) or LRC (ASCII) doesn’t match.

• Server side: it drops the frame and doesn’t answer. communication_errors in diagnostics increases, and the event log records a communication error event.
• Client side: a corrupted response fails with Protocol(Checksum) or Timeout. If the corrupted byte is the address, the client treats the reply as another device’s and drops it, so you see Timeout.

Common causes are noise, termination or biasing problems, long cables, and speed or parity mismatches. For intermittent errors, check cables and grounding first.

You can reproduce this with virtual serial ports: corrupting one character as in RTU and ASCII communication gives the client a Timeout and the server a communication_errors count of 1.

To check raw bytes yourself, feed them to fault:

{"action":"fault","transport":"rtu","bytes":"01030000000AC5CC"}

{"ok":true,"result":{"errors":["Checksum"],"frames":[],"source":"synthetic"}}

ASCII mode errors

Error from fault or a response	Cause
Encoding	A character that isn’t a hex digit, or a lowercase hex digit (a–f). ASCII mode accepts uppercase only.
Checksum	The LRC doesn’t match.
Timing	The gap between characters exceeded ascii_timeout_ms (1000 ms by default).
Length	The content between : and CR LF is too short.

If a device changed its end character with function 08/03, PDComm uses the new character from the reply onwards.

RTU character timing

The specification requires at least t3.5 of silence between frames and no more than t1.5 between characters inside a frame. On a multidrop RS-485 bus, every server delimits frames by t3.5 silence and answers only requests for its own address. A broadcast write to address 0 is applied by every server, and none replies.

Gaps you see on a PC are the result of batching by the USB adapter and driver, not the actual gaps on the line. To check character timing on the line, use an oscilloscope or a serial analyzer. You can test the decoder’s gap rules with the gap_us argument of fault (see Observe addresses and frames).

Broadcasts and silence

Situation	Result	Check
Write to unit 0	no_response is normal.	Read from each device to confirm the write.
Read from unit 0	InvalidConfig	Broadcasts are for writes only.
Device in listen-only mode	Timeout	Send the restart request, then confirm with a read.
Address with no device	Timeout	Check the device address.

After a broadcast, the client waits turnaround_ms before the next request. Increase it when a slow device is on the bus.

Virtual serial ports

• On macOS, PDComm doesn’t set a speed on pseudo terminals, so they run at the virtual link’s speed.
• When the virtual link ends (terminal closed or stop), the ports disappear and later requests fail.

Still stuck

Follow Diagnose failures and report them: collect both sides’ trace, the server’s diagnostics, the diagnostic log, and the device model, adapter and wiring, then contact support.