Modbus problems arrive as “it doesn’t read”. The checklist’s job is converting that sentence into one of five precise failures.
The taxonomy
Timeouts (no response at all): wiring/physical layer (see the RS-485 rules), wrong slave address, wrong serial settings (baud/parity — one parity mismatch produces exactly this), or on TCP: IP/port/firewall. Exception responses — the slave answered with a complaint, and the code tells you which: 01 illegal function (device does not support what you asked — check function code 03 vs 04 confusion, the classic), 02 illegal address (your map is off — often the ±1 convention), 03 illegal value (write rejected), 04/06 device-side trouble. Exceptions are progress: the link works, the request is wrong.
Wrong values with healthy comms: byte/word order (a plausible-but-absurd float like 5.7e-41 is the signature), scaling conventions (value ×10 registers), or signed/unsigned misreads (65535 where −1 was meant). Intermittent CRC/frame errors: physical layer again, or two masters on one RTU bus — the forbidden configuration that half-works just long enough to ship. Slow data: polling architecture, not the protocol — measure the cycle, count the jobs.
Tools
A USB-RS485 dongle plus any Modbus scanner isolates PLC-vs-device in five minutes: if the laptop reads the meter, the problem lives in your program’s job table; if not, it lives on the wire or in the meter. On TCP, Wireshark shows the conversation verbatim — request/response pairs with exception codes in plain sight.
FAQ
Device works with the laptop, not with the PLC — now what? Diff the two conversations: function code, address base, timing. The scanner defaults often differ from your blocks in exactly the register-convention ways above.
Can I have two masters on RS-485 Modbus? No. Gateways or a single owning PLC that serves others — pick an architecture, not a collision schedule.
Zone Otomasyon resolves most Modbus callouts in the first visit — the checklist is why. Field diagnostics.