When the platform has no points, you cannot conclude that the device has failed. A more reliable approach is to listen on the bus in the field and split the problem into three layers: whether there are frames, whether the frame format is correct, and whether a frame, once it has arrived, was parsed correctly. In equipment networking projects, Tongwei Smart recommends putting communication status, device online state, and exception events into the operations records of the gateway and the platform, so that “whether there is data” and “whether the data can be used” can be tracked separately.
The listening device only receives and does not become a second master
You can use a USB-to-RS-485 adapter that supports listening, or a serial analyser. The listening end should be a high-impedance input that only receives and does not transmit, so that it does not become a second master and contend for the bus. Wire it in parallel on A and B. Whether to connect the signal reference, and whether isolation is required, is set by the device manual and the site safety plan. Do not connect another controller that transmits on its own directly onto the bus to act as a listener.
Serial parameters must match the master
Baud rate, data bits, parity, and stop bits must be the same as the master. Modbus RTU is commonly 8N1, and it may also be 8E1 or another combination. It cannot be fixed as one setting. The listening tool should display the raw data in hexadecimal and keep timestamps, so that requests and responses can be matched.
Narrow the scope by request, response, and checksum
Take Modbus RTU as an example. You need to look at the slave address, function code, register address, data length, and CRC together. You can follow the symptoms below.
- No master request at all: check the master program, gateway serial configuration, polling tasks, communication enable, and upper-layer logic first.
- There is a request and no slave response: go on to slave power, address, A/B polarity, serial parameters, and protocol functions.
- The data changes often and CRC errors are numerous: check reversed A/B, interference, termination, grounding, baud rate, and cabling first.
- The frame is complete but the address is wrong: check the device address.
- The format is correct but the value is wrong: then check the register table, address offset, data type, and byte order.
When a correct response is already on the line, then check the gateway and the platform
If listening shows that the device has already returned frames as expected, and the platform still has no points, the cause can no longer be put on the field wiring. At that point check the gateway protocol template, serial channel, device model, point-table mapping, data type, scaling factor, timestamp, and uplink path. What the listening tool sees is the raw frame on the line. What the platform shows is the parsed result. Protocol adaptation and data modelling sit in between.
No response to a broadcast is not necessarily a fault
The Modbus broadcast address is usually used for write operations. Several slaves can receive it, but a slave generally does not return a response. If you capture a broadcast request and see no response, first confirm whether that is the behaviour the protocol specifies. When a broadcast write involves a control action, also confirm the permissions, the scope, and the fallback method.
The evidence has to be reproducible
Do not keep only a screenshot of the data. At a minimum, record the device model, serial parameters, wiring location, test time, master request, slave response, and the conditions under which the exception appeared. An engineering judgment needs these records. It does not rely on one chance recovery.
Common questions
- If the platform has no data, can that be judged a device fault?
- No. First confirm whether there is a master request on the bus, whether the slave responds, and whether the checksum passes. When a correct frame is already on the line, the problem is more likely in gateway parsing or the platform point table.
- Why, while listening, must you not connect another device that transmits on its own?
- A second master on the bus disrupts the existing polling. The listening end should only receive and not transmit.