Sensors, PLCs, and Modbus Gateways: Define Roles Before You Connect
Updated: Oct 3
A sensor, a PLC, and a Modbus gateway can all appear on the same network diagram, but that does not mean they speak the same interface or share the same job. A sensor might connect to a PLC input; a PLC may expose selected values over Modbus; and a gateway may bridge a serial network to an IP connection. Each step needs to be confirmed for the equipment in the project.
Start by tracing one data point from its source to the system that will read it. This keeps wiring, control logic, protocol conversion, and remote access from being treated as one feature.
Trace One Value Through the System
Draw the path in order:
Sensor → input or communication interface → PLC logic/data point → Modbus client or server → gateway or network path → SCADA or monitoring application
The arrows can change with the equipment. Some sensors provide analog or discrete signals that terminate at a PLC input. Others expose data digitally. Check the sensor and PLC manuals for the actual interface, wiring, scaling, and update behavior; do not assume a sensor has a Modbus address simply because the PLC uses Modbus elsewhere.
Next, identify where the value is stored and how it becomes available to another system. The PLC may expose a configured data point through a Modbus server, or it may act as a client that reads another device. Confirm the role and data map in the PLC project and manual. A register map is a deliberate configuration, not an automatic mirror of every sensor input.
Identify the Modbus Variant and Roles
Modbus RTU and ASCII use serial framing. Modbus TCP carries Modbus application data over TCP/IP with an MBAP header. The variants share parts of the application data model, but their messages and connection settings differ. RS-485 is a common physical layer for serial Modbus; it does not by itself define the message format.
Link segment | Record before configuration |
|---|---|
Sensor to PLC | Electrical/digital interface, wiring, scaling, and which device supplies the value |
PLC to Modbus client | PLC role, RTU/ASCII/TCP variant, endpoint, serial settings or IP/port, and supported function codes |
Gateway to upstream application | Gateway mode, source and destination variants, client/server roles, device identifiers, and register mapping |
Do not assume that “Modbus compatible” settles these details. A device may support only some function codes or one variant. Refer to the Modbus Application Protocol Specification, the Serial Line Protocol guide, and the TCP/IP implementation guide for protocol framing. Use each device's manual for the features it actually implements.
Separate Routing, Serial Transport, and Protocol Conversion
An IP router forwards IP traffic between networks; RFC 1812 describes IPv4 router requirements. A serial server can transport serial bytes over an IP connection while leaving the Modbus serial message intact. A Modbus gateway can terminate one variant and generate requests in another, but the device must explicitly support the required mode and mapping.
The names “gateway” and “router” are not enough to establish behavior.
Check the product manual for the exact direction of conversion, the supported client/server roles, how device identifiers are handled, and whether data is passed through or polled and remapped. If those details are absent, treat the behavior as unverified and ask the vendor before designing around it.
Build a Point Map Before Polling
For each value, record the source and its interpretation before configuring an application:
Field | Example of what to record |
|---|---|
Source | Sensor tag and the PLC input or data point that represents it |
Protocol endpoint | Device model and firmware, client/server role, and RTU/ASCII/TCP variant |
Modbus request | Data group, function code, manual reference, and client address or offset convention |
Value interpretation | Data type, signedness, byte and word order, scale, and unit |
Access and timing | Read-only or writable permission, expected update behavior, and polling interval allowed by the device/application design |
Register labels such as 40001 are not guaranteed to be the exact numeric address a client should send. Check both the device manual and the client software's address convention.
Start with one documented read-only point. Compare the response with a known value and confirm the units and scaling before adding more registers or allowing writes. This helps separate a transport problem from an address or data-format problem.
Keep the Control and Monitoring Paths Clear
Decide which system is responsible for control and which one is collecting or presenting data. A monitoring gateway or remote platform should not be assumed to own the PLC's control function. Specify which traffic is permitted, who can write values, and what the system should do when the upstream connection is unavailable.
For remote monitoring, document the network boundary, approved peers, account permissions, and logging path. NIST's Guide to Operational Technology Security provides broader guidance for planning OT network segmentation, access, and monitoring. Apply the site's own security and change-control requirements to the actual topology.
Avoid adding cloud polling to a control path until the owner has defined its purpose, allowed access, and behavior during a network interruption. The desired update rate should come from the application and device documentation, not a generic example value.
Commission in a Small, Observable Sequence
Verify the sensor signal or digital interface at the PLC and confirm the value and unit in the PLC project.
Confirm the Modbus endpoint, variant, roles, address convention, and supported function code from the current manuals.
Read one known point without writes and compare the returned value with the PLC's local view.
Add points in small groups and monitor response time, timeouts, and device load under the intended polling schedule.
Test the approved network path and access policy, then record what happens when the upstream link is unavailable.
If a PLC, drive, or SCADA value is stale or timing out, use the separate PLC/Modbus troubleshooting guide to distinguish a device-side fault from a communication-path issue. Keep the point map with the tested firmware and configuration so later changes can be compared.
FAQ
Do all industrial sensors use Modbus?
No. The sensor may provide an analog, discrete, pulse, or digital communication interface. Check its manual and the PLC's supported input or communication modules before choosing a network protocol.
Does a PLC automatically expose every sensor value as a Modbus register?
No. The PLC project and device configuration determine which values are mapped, how they are represented, and which function codes and client/server roles are available. Verify the map in the PLC documentation.
Is a Modbus gateway the same as an IP router?
No. An IP router forwards IP packets. A serial transport device may carry bytes over IP. Protocol conversion requires an explicitly supported gateway function that handles the source and destination variants.
Is register 40001 always the first address to enter in a client?
No. It is commonly used as a human-facing reference for the first holding register, but manuals and software may expect a zero-based offset or another convention. Check both ends and verify with a documented read-only point.
Should a cloud platform poll the PLC directly?
That depends on the approved architecture and security policy. Define the network boundary, access rights, polling load, and behavior during an outage before connecting a remote service. Do not make the remote system part of the control path by implication.
