Modbus RTU Pre-Commissioning Checklist

Step-by-step checklist to verify RS-485 wiring, serial settings, and device connectivity before deploying a Modbus RTU configuration. Prevents the most common commissioning failures.

Categories:

Overview

Most Modbus RTU commissioning failures trace back to physical-layer or serial-parameter issues that could have been caught before deploying a gateway configuration. This checklist covers what to verify at the site before loading any QuickServer configuration.

Complete each section in order. If any step fails, resolve it before moving to the next.

Before You Go to Site

Collect this information from the customer before traveling — especially for remote locations:

#ItemWhy It Matters
1Modbus RTU serial settings (baud rate, parity, stop bits, data bits)Mismatched settings = zero communication
2Slave/Node ID(s) for each deviceDefault 247 is rarely correct
3Register map (manufacturer documentation)Configuration is blocked without it
4Register typeholding (4xxxx) or input (3xxxx) registers?Wrong type = timeouts on valid addresses
5Addressing conventionstandard (1-based), PDU (0-based), or page-based?#1 cause of wrong data reads
6Number of devices on the RS-485 busAffects polling and addressing
7Site contact — single person with on-site access and authorityAvoids fragmented communication

[!WARNING] For remote sites (>2 hours from technician): Provide the customer with this checklist and ask them to verify basic connectivity with a Modbus scanner tool before scheduling a site visit.

Step 1: Verify RS-485 Wiring

RS-485 wiring errors are the #1 physical-layer cause of Modbus RTU failure. Check these first — before touching any configuration.

  • A/B lines are correct — RS-485 is a differential pair. Reversed A/B lines produce zero communication with no error indication. Swap and re-test if in doubt.
  • Ground reference — connect the signal ground (GND) between devices if available. Missing ground reference causes intermittent errors on longer cable runs.
  • Cable length — RS-485 supports up to ~1200m (4000ft) at 9600 baud. Higher baud rates reduce maximum cable length.
  • Termination resistors — for cable runs over 30m (100ft) or high baud rates, verify 120Ω termination resistors are installed at both ends of the RS-485 bus.
  • No star/spur topology — RS-485 requires a daisy-chain (bus) topology. Star wiring causes signal reflections and intermittent timeouts.

[!TIP] Swap A and B wires and re-test. This resolves roughly half of “no communication” cases.

Step 2: Verify Serial Parameters

All devices on the same RS-485 bus must use identical serial settings. Verify these match between the gateway and every slave device:

ParameterCheck AgainstCommon Default
Baud RateManufacturer documentation9600 or 19200
Data BitsManufacturer documentation8
ParityManufacturer documentationNone or Even
Stop BitsManufacturer documentation1
  • All four parameters match between the gateway and the target device
  • Parameters match the manufacturer’s documented settings (not assumed defaults)
  • If using non-standard baud rates (e.g., 192000), confirm the gateway supports them

[!WARNING] Some controllers use baud rates like 192000 with 2 stop bits. Always verify against the manufacturer documentation rather than assuming standard values.

Step 3: Confirm Device Connectivity with a Scanner

Before deploying any gateway configuration, verify that the Modbus device is reachable using a standalone scanner tool. This isolates device/wiring issues from configuration issues.

Using CAS Modbus Scanner or ModScan:

  1. Connect your laptop directly to the RS-485 bus (using a USB-to-RS-485 adapter)
  2. Set the scanner to the serial parameters from Step 2
  3. Enter the device’s Slave ID
  4. Read a known register (pick one from the manufacturer register map)
  5. Verify the returned value is plausible

Interpreting results:

Scanner ResultMeaningNext Step
Valid data returnedDevice is reachable, wiring is goodProceed to Step 4
Timeout / no responseWiring, serial settings, or Slave ID issueGo back to Steps 1–2
Exception responseDevice is reachable but rejecting the requestCheck function code and register address
Garbled / CRC errorsBaud rate or parity mismatchRe-verify serial settings (Step 2)

[!NOTE] If the scanner can’t reach the device, the gateway won’t either. Don’t load the configuration until this step passes.

Step 4: Validate Register Addresses

With scanner connectivity confirmed, verify that the register addresses in your point list are correct:

  • Read 3–5 known registers and compare values to the device display or known state
  • Check for off-by-one — if values don’t match, try decrementing the address by 1 (see Modbus Addressing & Register Reference)
  • Verify register type — if holding registers (FC03) timeout, try input registers (FC04) for the same address
  • Test 32-bit values — if floats read as zeros or garbage, check byte order

Step 5: Capture a Baseline Diagnostic

Once the system is working:

  1. Generate a full diagnostic file from the gateway (minimum 300-second capture)
  2. Save it with the date — this is your “known good” baseline
  3. If issues appear later, capture another diagnostic and compare the two to identify what changed

This is especially important for remote sites where return visits are costly.

Step 6: Deploy the Gateway Configuration

Only after Steps 1–5 pass:

  1. Upload the QuickServer configuration file
  2. Verify that mapped points show correct values
  3. Confirm read/write operations work for any writable points
  4. Check BACnet (or other output protocol) objects reflect the expected Modbus values

Common Commissioning Failures

For a full symptom-based diagnostic guide, see the Modbus Troubleshooting Guide.

SymptomMost Likely CauseFix
Zero communicationRS-485 A/B wiring reversedSwap A and B wires
Zero communicationBaud rate mismatchVerify serial settings against manufacturer docs
Zero communicationWrong Slave IDVerify device ID (don’t assume default 247)
Timeouts after initial successIntermittent wiring issueRe-check connections, capture comparative diagnostics
Wrong data valuesRegister address off-by-oneDecrement address by 1
Wrong data valuesByte order mismatch (32-bit)Try word-swap (CDAB)
Exception response from deviceWrong function code or register typeTry FC03 vs FC04, or check if register is read-only
CRC errorsParity or stop bits mismatchMatch all serial parameters exactly
Works on some devices but not othersMixed Slave IDs or serial settingsVerify each device independently

Chipkin Tools

Need more help?

If this page does not resolve the issue, contact Chipkin support with the product model, protocol details, and any diagnostics you have already captured.

Open Chipkin Support