What Modbus Is
Modbus is a simple register-oriented industrial protocol used to exchange coils, discrete inputs, and 16-bit register values between clients and servers. Its core value is simplicity: if the register map is accurate and the transport is known, the protocol is straightforward to move between devices, gateways, and supervisory systems.
That same simplicity also explains most failures. Modbus problems are usually not deep protocol mysteries. They are addressing mistakes, register-type mistakes, serial-parameter mistakes, or data-representation mistakes such as word order.
See QuickServer for Modbus protocol conversion options
For Chipkin-specific troubleshooting and field diagnostics, use the Modbus Troubleshooting Guide, the Modbus Addressing & Register Reference, and the Modbus Data Types & Byte Order Reference.
History
Modbus was introduced by Modicon in 1979 for PLC and controller communications. Its longevity comes from one practical fact: many devices can expose useful telemetry and command points with only a small set of function codes and a vendor register map. The protocol remained relevant because it stayed openly published and easy for vendors, integrators, and gateway platforms to implement.
That is why Modbus still appears everywhere from generators and chillers to meters, UPS systems, VFDs, environmental monitors, and protocol gateways.
Core Concepts
Every Modbus job depends on four foundations:
- Register type: coils, discrete inputs, input registers, or holding registers.
- Addressing convention: reference-style numbering versus zero-based offsets, plus the right Slave ID or Unit ID.
- Transport: Modbus RTU or Modbus TCP.
- Data representation: data type, scaling, and word order.
If one of those four assumptions is wrong, the integration can look healthy while still returning the wrong data.
Modbus-Specific Information
Modbus is intentionally small compared with object-oriented building protocols. That small surface area is a strength, but it also means the protocol depends heavily on documentation discipline and consistent interpretation.
Standard Data Model
| Data Type | Access | Typical Use | Practical Risk |
|---|---|---|---|
| Coils | Read/write | Commands, enables, start-stop bits | Easy to confuse with discrete inputs when the register map is poorly labeled |
| Discrete inputs | Read-only | Status contacts and digital states | Often mistaken for coils by teams that only look at the point name |
| Input registers | Read-only | Measurements, sensor values, counters | Common place to find scaled analog values that look wrong if data type is assumed incorrectly |
| Holding registers | Read/write | Setpoints, configuration, writable values | Most common table in field work, but also the most common source of off-by-one mistakes |
For deeper data-family coverage, use Modbus Coils, Modbus Discrete Inputs, Modbus Input Registers, and Modbus Holding Registers.
Common Public Function Codes
| Function Code | Typical Use | Why It Matters |
|---|---|---|
01 Read Coils | Read writable bit points | Common for enable states and relay outputs |
02 Read Discrete Inputs | Read status bits | Used for dry-contact style status values |
03 Read Holding Registers | Read analog and writable register data | Most common read path in real integrations |
04 Read Input Registers | Read read-only analog values | Common for meters, drives, and power devices |
05 and 06 Write Single Coil/Register | Single-point writes | Useful for simple command or setpoint tests during commissioning |
15 and 16 Write Multiple Coils/Registers | Block writes | Important when controllers expect batched writes rather than point-by-point updates |
23 Read/Write Multiple Registers | Combined read and write transaction | Shows up on more capable devices and gateways |
43/14 Read Device Identification | Identify vendor and model information | Helpful when a device partially documents its register map or gateway identity |
For deeper request-behavior coverage, use Modbus Function Codes and Modbus Register Map.
Framing, Limits, and Design Tradeoffs
Modbus uses a simple application PDU made from function code plus data. On serial links that PDU is wrapped with address and CRC fields, and on Modbus TCP it is wrapped with an MBAP header and port 502 transport. That simplicity is why packet captures are usually readable and why gateway troubleshooting is often faster than with more layered protocols.
The tradeoff is that Modbus does not natively describe point meaning, units, or engineering context. There is no universal discovery model for a register map, classic serial deployments still top out at 247 addressed devices on one segment, and polling remains the normal data-exchange pattern. In practice, that means the register map is part of the protocol, not optional paperwork.
That is also why Modbus commissioning depends so heavily on register-map quality, function-code discipline, and the right word-order interpretation for multi-register values.
Common Variants
| Variant | Where It Fits | Why It Matters |
|---|---|---|
| Modbus RTU | Serial RS-485 field trunks | Common for meters, drives, UPS systems, and legacy controllers |
| Modbus TCP | Ethernet and IP-connected devices | Common for PLCs, power devices, and gateway-facing integrations |
| Modbus ASCII | Legacy serial installs | Less common, but still relevant on older equipment and service ports |
How To Get The Points List
Modbus is usually not discoverable in the way BACnet is. In most jobs, the points list must come from documentation rather than from live browse alone.
Preferred sources, in order:
- Vendor register map or protocol manual
- Device integration guide or engineering submittal
- Existing PLC, SCADA, or gateway configuration already proven onsite
- A known-good validation pass with CAS Modbus Scanner
Use a scanner to validate the map, not to invent one from scratch.
[!CAUTION] If the customer does not have the register map, the real blocker is missing documentation, not missing software.
Devices that Support Modbus
QuickServer is Chipkin’s primary gateway for exposing non-Modbus systems as Modbus-facing points and for translating Modbus data into BACnet, MQTT, SNMP, and other targets.
Modbus RTU: ABB ACS880, AERMEC ANKi, ASCO 7000 UPS, Azonix BG300, Dwyer DigiHelic, Eaton UPS, E-Mon Class 3200, GE EPM6000, Liebert CRAC, Piller frequency converter, Sierra ATMF8000-NH
Modbus TCP: Condair humidifier, CORDEX CXC HP, Honeywell steam controller, Honeywell liquid level controller, Horner X4 PLC, ifm AL1342, Megatron chemical monitor, Modicon PLC, Sunbird P-IQ, Swegon Dual ERV Controller tblz366
Common Integration Targets
- BACnet for supervisory BMS visibility and protocol conversion
- SNMP for infrastructure and DCIM telemetry workflows
- MQTT for broker-based telemetry and cloud publishing
Tools & Diagnostics
| Tool | Type | Description |
|---|---|---|
| CAS Modbus Scanner | Scanner | Validate registers, data types, and live values before revising a gateway config |
| CAS Modbus RTU Parser | Parser | Decode raw RTU frames, CRC behavior, and function-code traffic |
| Wireshark | Packet analyzer | Best first tool for Modbus TCP capture and MBAP validation |
| QuickServer | Gateway and diagnostics platform | Convert Modbus data to BACnet, MQTT, SNMP, and 220+ other protocols while exposing diagnostics that separate source-side health from target-side presentation |
Frequently Asked Questions
What is the difference between Modbus RTU and Modbus TCP?
Modbus RTU runs over serial RS-485 with CRC-based framing. Modbus TCP runs over Ethernet and wraps the same data model inside a TCP session.
What is the most common Modbus integration error?
Off-by-one addressing is still the most common failure. Many manuals show 40001-style references while tools and gateways often expect zero-based offsets.
Why do 32-bit values look wrong even when communication works?
That is usually a data-type or word-order mismatch rather than a transport failure.
Do all Modbus devices use holding registers?
No. Devices may use coils, discrete inputs, input registers, or holding registers. The vendor map is authoritative.
What should I collect before a Modbus project starts?
At minimum: the register map, transport type, serial or TCP settings, device model, firmware revision, and one known-good engineering value.
Reference Documents
- Modbus specifications and implementation guides for the current official document set
- Modbus Application Protocol Specification V1.1b3 for the core data model and public function codes
- Modbus Serial Line Protocol and Implementation Guide V1.02 for RTU framing, timing, and serial-line rules
- Modbus Messaging on TCP/IP Implementation Guide V1.0b for MBAP header behavior and gateway-oriented TCP details
- Modbus Security Protocol for TLS-based security extensions used in newer deployments
Related Pages
- Modbus RTU
- Modbus TCP
- Modbus Word Order
- Modbus Function Codes
- Modbus Slave ID and Unit ID
- Modbus Register Map
- Modbus Coils
- Modbus Discrete Inputs
- Modbus Input Registers
- Modbus Holding Registers
- Modbus Troubleshooting Guide
- Modbus Addressing & Register Reference
- Modbus Data Types & Byte Order Reference
