Modbus Protocol: RTU, TCP, Registers and Diagnostics

Direct answer

Modbus is an application-layer, client/server request-and-reply protocol. A client sends a request that identifies a function and a zero-based data address; one server normally returns data, confirms a write or returns a Modbus exception. The same protocol data unit can travel inside a serial Modbus RTU frame or a Modbus TCP application data unit. RTU adds a server address and CRC to delimit and validate a serial frame. Modbus TCP adds a seven-byte MBAP header and relies on TCP for transport; it does not append the RTU CRC.

The protocol defines four logical data tables: coils and discrete inputs contain single-bit values, while input registers and holding registers contain 16-bit values. It does not define what a particular register means, whether a device exposes all four tables, or how a 32-bit integer or floating-point value is ordered across two registers. The device's controlled register map is therefore part of the interface contract.

To configure a working exchange, freeze six items: transport and endpoint; client and server roles; unit or server identifier where applicable; function code; starting offset and quantity; and value interpretation. To troubleshoot it, capture one known request and classify the outcome as a normal response, Modbus exception, transport/framing rejection or timeout. That distinction prevents address edits from being used to chase wiring, firewall, timing or device-state faults.

Diagnostic answer map

Use this answer map when the symptom is still vague. It maps common natural-language questions to the first evidence boundary and the page section that resolves it. Do not change several fields at once: preserve the original failure, make one controlled test and record the result.

If the question sounds like this	First fact to establish	First evidence to inspect	Continue at
Why is my Modbus value wrong but communication is healthy?	raw register words before conversion	captured response and hexadecimal words	address translation, then value decoding
Why do I receive illegal data address?	actual PDU start offset and quantity	request function/address/quantity plus map revision	exceptions and address bounds
Why does Modbus TCP time out?	TCP connection versus application reply	link, IP route, port, connection and request counters	outcome ladder and timing
Why does Modbus RTU show CRC errors?	whether bytes, timing and line conditions are valid	capture at the suspect segment and error counters	RTU framing and serial evidence
Is register 40001 sent in the packet?	reference notation versus PDU offset	tool display convention and request bytes	zero-based offset trap
Why are two words swapped?	device-defined multi-register order	exact model manual and raw word pair	byte and word order
Which Modbus function code should I use?	logical table and read/write operation	server's supported-function list	function selection
Why does a gateway reach one device but not another?	Unit Identifier routing and serial server address	TCP request, gateway route table and serial trace	gateways and unit identifiers
How fast can I poll?	measured transaction time and device capacity	request/response timestamps and utilization	polling plan
Is ordinary Modbus encrypted?	protocol variant and security architecture	port, certificate/session evidence and zone design	security boundary

What Modbus standardizes and what it leaves to the device

Separate the application contract from the transport

The Modbus Application Protocol Specification V1.1b3 defines the application-layer messaging model, data model, addressing model, public function codes and exception responses. It describes a protocol data unit, or PDU, as a function code plus function-specific data. The PDU remains conceptually consistent while the network-specific application data unit, or ADU, wraps it for a particular transport.

That separation explains why the same Read Holding Registers operation can appear on serial and Ethernet networks without the frames being byte-for-byte identical. It also explains why Modbus is not a complete wiring or network design standard. The application specification does not select an RS-485 cable, assign IP addresses, define switch redundancy, set every response timeout or describe a manufacturer's register meanings.

The Modbus Organization's specification index is the controlled starting point. It identifies the current application document and separate implementation guides for serial line, TCP/IP and Modbus Security. When a device manual conflicts with a generic blog or a software label, resolve the controlled product documentation and actual wire evidence before assuming that either display uses standard reference notation.

Layer or artifact	Standardized or guided by	What must still come from the project or device
function and request/reply meaning	Modbus application specification	functions implemented by this model and firmware
coils and registers	Modbus logical data model	which addresses exist and what each value means
RTU framing and serial behavior	Modbus Serial Line Guide	cable, connector, port, topology and installed electrical evidence
TCP messaging	Modbus TCP/IP implementation guide and TCP standards	IP plan, switching, routing, firewall, connection policy and load
multi-register values	device/application convention	type, scale, signedness, byte order and word order
timeout and retry policy	implementation plus measured behavior	process deadline, device capacity and safe failure response
cybersecurity	risk-based OT architecture and supported protocol controls	zones, conduits, identities, rules, monitoring and recovery

Use client and server roles precisely

A Modbus client initiates a transaction. A Modbus server receives a request and returns the corresponding response when it can. Some older manuals retain “master/slave” terminology, but the Modbus Organization announced its move to client/server terminology; use the product's exact labels when configuring legacy software while keeping the role model clear.

Role is not the same as PLC importance, data ownership or network direction. A supervisory PLC can be a Modbus server when another system reads its data. A field gateway can be a TCP server on one side and a serial client on the other. Record the role per connection rather than assigning one permanent role to a device name.

Understand the four Modbus data tables

Map bits and 16-bit words before mapping tags

The application data model has four primary logical tables. Coils are single-bit read/write values; discrete inputs are single-bit read-only values from the protocol client's perspective. Holding registers are 16-bit read/write words; input registers are 16-bit read-only words. “Read-only” here describes the Modbus operation exposed to the client, not whether the underlying physical process can ever change.

The tables can be separate or mapped onto the same physical storage in a device implementation. A device may expose only a subset. The standard does not require address 0 in every table to exist, does not prescribe a specific number of points for every product and does not make the familiar 0xxxx/1xxxx/3xxxx/4xxxx prefixes part of the PDU.

Logical table	Element size	Typical client operations	Common reference prefix	PDU address field
coils	1 bit	read, write single, write multiple	0xxxx	zero-based 16-bit offset
discrete inputs	1 bit	read	1xxxx	zero-based 16-bit offset
input registers	16 bits	read	3xxxx	zero-based 16-bit offset
holding registers	16 bits	read, write single, write multiple	4xxxx	zero-based 16-bit offset

Treat the register map as an interface-controlled document

A useful register-map row contains more than an address and a label. Record the exact product and firmware, table, documented reference, zero-based offset, supported function, width in registers, data type, signedness, scale, engineering unit, byte/word order, access, update rate, quality behavior, write constraints and safe test method. Add a source page and revision so a firmware update can be assessed.

If the documentation says “40001,” determine whether the client expects 40001, 1 or 0. If it says “address 100,” determine whether that is a human reference or a PDU offset. Never infer a writable point from its location in a table. A holding register can still be read-only by product policy, protected by a mode or constrained to a narrow range.

Interface field	Example project entry	Why it matters
model and firmware	drive family X, firmware A.B	maps can change by revision
table/function	holding, FC03 read, FC06 write	prevents table/function mismatch
documented reference	40101 in manual	preserves the vendor's notation
PDU offset	100 decimal	states the value expected on wire
width and type	two registers, signed 32-bit	defines assembly and sign handling
order and scale	high word first, ×0.1 rpm	converts raw words into meaning
access and constraints	write only when stopped, range 0–18000	prevents invalid or unsafe writes
update/quality	refreshed 100 ms, stale flag at separate coil	prevents stale data being treated as live

Select function codes by operation and table

Start with the requested behavior

Function codes are not interchangeable ways to obtain any address. Select the function that matches the logical table and operation, then verify the server implements it. Common public functions include 01 Read Coils, 02 Read Discrete Inputs, 03 Read Holding Registers, 04 Read Input Registers, 05 Write Single Coil, 06 Write Single Register, 15 Write Multiple Coils and 16 Write Multiple Registers.

The application specification defines exact request and response formats and maximum quantities per function. Do not generalize one quantity limit across all functions, and do not assume a device implements every public function. The product manual or conformance evidence must narrow the standard to that endpoint.

Need	Likely function	Hex	Critical verification
read output/status bits exposed as coils	Read Coils	0x01	bit packing and unused final bits
read input/status bits	Read Discrete Inputs	0x02	actual implemented range
read writable/configuration words	Read Holding Registers	0x03	data type and scale
read measurement words	Read Input Registers	0x04	update and quality behavior
command one coil	Write Single Coil	0x05	permitted values and machine state
write one 16-bit register	Write Single Register	0x06	signedness, range and write authority
write a contiguous bit group	Write Multiple Coils	0x0F	bit count and transactional consequence
write contiguous words	Write Multiple Registers	0x10	multiword order and partial-failure behavior

Keep the request and response contract visible

For a normal read, the request identifies a starting address and quantity. The normal response returns a byte count and packed data. For a write, the response normally echoes identifying request fields according to that function's definition. Validate the response function, transaction identity on TCP, expected byte count and content before publishing values into control logic.

An exception response is still a valid Modbus response. Its function code is the requested function with the high bit set, followed by an exception code. That is materially different from a timeout: an exception proves that a server received enough of the request to return a protocol-level rejection.

Compare Modbus RTU, ASCII and TCP

Preserve the PDU while changing the ADU

The Modbus Serial Line Protocol and Implementation Guide V1.02 describes RTU and ASCII transmission modes and provides serial implementation guidance. The Modbus Messaging on TCP/IP Implementation Guide V1.0b describes client/server messaging, the MBAP header, connection management and gateway behavior over TCP/IP.

RTU is a compact binary serial encoding. Its ADU contains the serial server address, PDU and CRC. Frame timing matters because silent intervals participate in delimiting frames. ASCII encodes bytes as hexadecimal characters, uses delimiter characters and an LRC, and is less common in new PLC installations. TCP carries the PDU after an MBAP header. TCP supplies an ordered byte stream and error handling below the application; the Modbus TCP ADU does not include the serial CRC.

Property	Modbus RTU	Modbus ASCII	Modbus TCP
usual carrier	asynchronous serial media	asynchronous serial media	TCP/IP, commonly Ethernet below IP
encoding	binary	hexadecimal characters	binary PDU after MBAP header
endpoint field	serial server address	serial server address	IP/port plus Unit Identifier when used
integrity/delimiter feature in ADU	CRC plus timing	LRC plus start/end characters	MBAP length plus TCP transport
common configuration evidence	baud, data bits, parity, stop bits, address	serial fields plus ASCII mode	IP, port, Unit ID, connection and timeout
common false assumption	RS-485 electrical health follows from valid settings	every serial device supports ASCII	RTU CRC should appear after the TCP PDU

Do not confuse Modbus RTU with RS-485

Modbus RTU describes protocol framing and serial behavior. RS-485 describes an electrical signaling layer; it is not itself Modbus. RTU can be carried over media described by the serial guide, and an RS-485 segment can carry protocols other than Modbus. A correct function code cannot repair reversed conductors, a topology problem, common-mode stress, missing reference practice, incompatible transceivers or poor termination.

Resolve installed serial guidance from the exact device and interface manuals. The protocol guide provides important implementation classes and recommendations, but a universal distance, speed, node count or conductor color cannot be promised without the electrical standard, transceiver loading, cable, topology, environment and vendor constraints.

Read the frame without mixing its layers

Decode the common PDU first

The PDU begins with one-byte function code followed by function-specific data. For a Read Holding Registers request, that data includes a two-byte starting address and two-byte quantity, transmitted most-significant byte first. The normal response contains the function, a byte count and register data. The application specification limits a PDU to 253 bytes.

The network wrapper sets the larger ADU limit. A serial ADU adds one address byte and two CRC bytes around the PDU, producing a maximum 256-byte RTU ADU. A Modbus TCP ADU adds a seven-byte MBAP header, producing a maximum 260-byte ADU. Those protocol maxima do not prove that a particular device accepts the maximum quantity, buffer load or request rate.

Field group	RTU request	TCP request	Diagnostic use
transaction identity	inferred from ordered serial exchange	two-byte Transaction Identifier	match response to request
protocol identity	implicit Modbus RTU configuration	Protocol Identifier, normally zero for Modbus	reject wrong framing
following length	inferred from function and frame	MBAP Length field	detect truncation/inconsistent ADU
destination hint	serial server address	Unit Identifier, especially through a gateway	verify selected downstream endpoint
application request	function plus data	function plus data	compare the common PDU
frame check	CRC	no RTU CRC	separate serial corruption from TCP/application faults

Interpret the MBAP header field by field

The seven-byte MBAP header consists of Transaction Identifier, Protocol Identifier, Length and Unit Identifier. The Transaction Identifier lets a client associate a received response with its request. The Protocol Identifier is zero for Modbus. Length counts the following bytes, including the Unit Identifier and PDU. The Unit Identifier is particularly important when a TCP-to-serial gateway routes the request to a downstream serial server.

Traditional Modbus TCP uses the IANA-registered modbus service on TCP port 502. IANA's service-name and port-number registry is the authoritative registry, but a port number alone does not identify a safe or correctly configured application. TCP behavior follows the current RFC 9293 transmission-control specification; an established TCP connection still does not guarantee that the server accepts a Modbus function or address.

Translate register references into PDU offsets

Resolve the zero-based offset trap explicitly

The PDU carries a zero-based address between 0 and 65535. Human-facing documentation often uses reference notation in which the first holding register is written 40001, the first input register 30001, the first discrete input 10001 and the first coil 00001. The leading table digit is not sent as part of the address field.

For the common one-based reference convention, holding register 40001 corresponds to PDU offset 0, 40002 to offset 1 and 40101 to offset 100. But client software varies: a field labeled “address” may expect the reference, one-based position or zero-based offset, and some tools provide a “zero based” toggle. Establish the display convention from documentation or a capture rather than trying plus or minus one until a plausible value appears.

Manual notation	Likely table	Common one-based position	PDU offset under that convention	Verify in software
00001	coil	1	0	whether leading prefix is accepted
10001	discrete input	1	0	whether function 02 is selected separately
30001	input register	1	0	whether function 04 is implicit
40001	holding register	1	0	whether function 03/06/16 is separate
40101	holding register	101	100	whether the UI subtracts 40001 or only 1

Prove the translation with one recognizable point

Choose a read-only point with a recognizable, safely changeable or independently measurable value. Record the manual reference, selected function, configured address and captured two-byte PDU address. Compare the raw response with the independent value. If it is wrong, return to the contract instead of sliding across addresses; reading adjacent data until it looks reasonable can silently map the wrong process variable.

Our dedicated Modbus register addressing guide expands this translation and register-map review. Use that owner when the problem is specifically off-by-one addressing rather than the broader protocol lifecycle.

Decode 16-bit and multi-register values

Separate byte order from word order

The application specification transmits multi-byte protocol fields with the most significant byte first. Each register is a 16-bit word. Applications commonly place 32-bit integers, IEEE 754 floating-point values, counters or strings across multiple consecutive registers, but Modbus does not standardize the order of those registers as one universal application type.

Suppose the response carries raw words 0x4145 and 0x70A4. Treat those as two observed 16-bit words first. Only after consulting the device map should software join them as high-word/low-word, low-word/high-word or another documented layout and then interpret the resulting 32 bits. A float setting that makes one sample look plausible is not proof; test zero, sign, fractions and a second known value.

Interpretation field	Questions to resolve	Useful proof case
width	one, two or more registers?	boundary value that changes the upper word
signedness	unsigned, two's-complement signed or status bits?	known negative value if permitted
word order	which register carries the high-order word?	two distinct nonzero word patterns
byte handling	does the application swap bytes within words?	raw captured bytes versus displayed word
numeric type	integer, IEEE 754, BCD, fixed point or packed flags?	values that distinguish encodings
scale/offset	multiply, divide or add after decoding?	zero, midpoint and full-scale evidence
unit	engineering unit and reference condition?	independent calibrated reading
quality	separate status, sentinel or freshness rule?	disconnection/stale-data test

Preserve raw and converted evidence

Keep raw register words, conversion configuration, converted value, quality and timestamp together during acceptance. If a library or PLC instruction hides byte manipulation, create tests with fixed raw vectors and expected outputs. Protect type and order settings under change control; a later library replacement can otherwise change values while communication remains “green.”

For strings, define character order, length, termination and padding. For packed status words, define every used bit and the behavior of reserved bits. For counters assembled from several registers, determine whether the server provides a coherent snapshot or whether the value can roll between separate reads.

Design a polling plan from evidence

Budget transactions instead of guessing a scan rate

A poll is not just the nominal network bit time. It includes client scheduling, request transmission, server processing, response transmission, gateway delay where present, retries and competing traffic. On a serial segment, only one transaction proceeds at a time. On TCP, connections and concurrency can increase throughput, but the server and PLC still have finite tasks, buffers and update rates.

Create a polling inventory by consequence. Fast control-related status, operator display, trends, totals and maintenance diagnostics rarely require the same rate. Group contiguous points only where that does not cross unsupported gaps, access constraints or coherence boundaries. Measure a representative endpoint under normal and worst credible load.

Poll group	Example purpose	Evidence-based design question	Failure treatment
critical state	permissive/status used by approved logic	what freshness deadline does the process require?	controlled fail state and alarm
operator display	values visible on HMI	what update is perceptible and useful?	show stale/bad quality visibly
historian	trends and production context	what sample interval preserves required behavior?	retain gap/quality, do not invent data
totals	energy, count or runtime	can rollover or reset occur between reads?	validate monotonicity and reset event
configuration	infrequently changing setup	should it be read on change/startup only?	compare revision and access authority
diagnostics	counters and identification	can low-priority polling be slowed first?	preserve capacity for operational traffic

Derive timeout and retry behavior from consequences

Measure response-time distributions, not only averages. Set an application timeout that distinguishes a genuinely failed transaction from normal worst-case processing with margin, while meeting the process freshness deadline. TCP retransmission behavior below Modbus does not replace an application deadline. On RTU, frame timing and serial turnaround remain part of the implementation.

Retries can recover an intermittent loss, but immediate repeated retries can amplify congestion or overload a slow gateway. Use a bounded retry policy, backoff where appropriate and a clear stale-data timer. Writes require special care: after a lost response, repeating a non-idempotent action can be unsafe. Design command semantics, acknowledgements and reconciliation at the application layer.

Configure a PLC Modbus link as an interface contract

Freeze the endpoint and request tuple

Before writing PLC logic, create a connection sheet. For RTU, record port identity, media/interface, baud, data bits, parity, stop bits, mode and server address. For TCP, record server IP or approved name, TCP port, connection behavior and Unit Identifier requirement. For both, record function, PDU start offset, quantity, destination buffer, conversion, poll trigger, timeout, retries and quality behavior.

Current vendor instructions are authoritative for the exact controller. For example, the current cited Siemens S7-1200 system manual documents MB_CLIENT parameters, including request trigger, connection identity, endpoint fields, data address, length, data pointer and status outputs. Rockwell publishes a Modbus TCP Client AOI implementation resource with controller and implementation constraints. Those examples do not create portable parameter meanings across brands.

Contract group	RTU entry	TCP entry	Shared acceptance evidence
endpoint	exact serial port and server address	server IP/name, port and Unit ID	endpoint identity and approved owner
transport	baud, data, parity, stop, mode	connection lifecycle and network path	successful transport evidence
application	function, offset, quantity	function, offset, quantity	captured request bytes
destination	PLC buffer and bounds	PLC buffer and bounds	no overlap or out-of-range copy
decoding	width, sign, word order, scale, units	width, sign, word order, scale, units	raw-to-engineering test vectors
execution	trigger, busy/done/error handling	trigger, busy/done/error handling	no overlapping request misuse
health	timeout, retry, stale timer and counters	timeout, retry, stale timer and counters	forced fault and recovery evidence

Build a request state machine, not a permanently true trigger

Many PLC communication blocks are asynchronous. A request input initiates work, a busy state indicates an active transaction, and completion or error outputs report an outcome. Follow the exact block documentation. A permanently true trigger, a new request while busy or several blocks sharing connection resources incorrectly can create intermittent symptoms unrelated to the remote device.

Use an explicit scheduler: select a transaction, issue its permitted trigger, wait for completion/error/deadline, capture status and timestamps, publish data only after validation, then advance. Separate transport health, protocol exception, conversion validity and freshness instead of collapsing them into one “comm good” bit.

Troubleshoot one known request from the outside inward

Classify the outcome before changing configuration

Start with one read-only, documented point. Capture client timestamp, endpoint, function, start address, quantity and raw request. Then classify the outcome. A normal response shifts attention to byte count, raw values and conversion. An exception shifts attention to the function, bounds, state or permissions. A framing/CRC rejection shifts attention to serial settings, timing or physical evidence. A timeout requires proving each transport and endpoint boundary.

Observed outcome	What it already proves	Best next checks	Avoid
normal response, wrong value	request reached a server and returned data	exact point, offset, width, order, scale, freshness	changing network settings
exception 01 illegal function	server returned protocol rejection	supported function and operating mode	treating it as cable noise
exception 02 illegal data address	function recognized but requested range rejected	start offset, quantity, table, firmware map	random address walking
exception 03 illegal data value	request data/quantity rejected	function constraints and allowed range	assuming sensor value is invalid
exception 04 server device failure	server could not perform request	device diagnostics and documented state	automatic infinite retries
RTU CRC/framing errors	serial bytes arrived but frame validation failed	serial settings, timing and electrical evidence	editing register scale
TCP connect failure	application exchange did not begin	link, VLAN/route, IP, port, rules and listener	changing function code first
timeout after request	no accepted response before deadline	correct endpoint, Unit ID, counters, load and capture	declaring “Modbus is broken”

Preserve counters, timestamps and capture position

Counters reveal direction. Track requests attempted, valid responses, exceptions by code, timeouts, CRC/framing errors, reconnects and stale-data events per endpoint. Timestamp at the client and, where possible, at the gateway or server. A rising request count with no received packets is different from responses received and rejected by transaction identity or byte count.

Capture position matters. A client-side TCP capture proves what reached that interface, not what a gateway transmitted on serial. A serial capture at one end can differ from the voltage and noise at a distant node. State where evidence was observed, with which approved tool and under which operating condition.

Diagnose Modbus RTU electrical and timing evidence

Confirm configuration before touching conductors

Verify that both endpoints use the same RTU/ASCII mode, baud, data bits, parity and stop bits. Verify the addressed server exists and that only the intended client initiates on the serial segment. Then compare actual request bytes, silence/turnaround timing, response bytes and CRC result.

Only after the configuration contract is known should an authorized person inspect the physical layer: point-to-point versus multipoint topology, trunk and stubs, end termination, reference/common practice, shield and bonding design, connector/pin identity, polarity naming, cable type, isolation, biasing strategy and common-mode conditions. Follow the current serial implementation guide, exact interface manuals and the applicable electrical design rules.

Use scope evidence within an approved boundary

An oscilloscope or differential probe can help reveal amplitude, ringing, reflections, noise and common-mode behavior, but connection to energized industrial equipment has shock, arc, ground and process risks. Use suitably rated isolated/differential instruments, competent personnel and an approved procedure. A USB adapter, grounded bench oscilloscope or improvised reference lead is not automatically safe for a field segment.

Do not use one “ideal” waveform screenshot as a universal acceptance criterion. Compare measurements with transceiver thresholds, cable/topology guidance, device manuals and the actual data-error evidence at the relevant nodes.

Route through gateways without losing identity

Treat a gateway as two linked transactions

A Modbus TCP-to-RTU gateway receives a TCP transaction, maps its Unit Identifier or configured route to a serial server address, schedules the serial request and returns the serial outcome in a TCP response. That creates two evidence domains: TCP client to gateway and gateway to serial server. A healthy Ethernet link does not prove the serial side, and a responding serial device does not prove the client chose the correct Unit ID.

Create a route table with TCP listener, permitted client, Unit Identifier, downstream port, serial address, serial settings, supported functions, timeout budget and exception behavior. Determine what the gateway does with Unit ID 0, unsupported IDs, broadcasts, late serial responses and multiple TCP clients. The implementation guide discusses gateway architecture, but the product manual controls these details.

Gateway boundary	Evidence	Typical fault	Controlled test
client to TCP listener	connection and packet capture	wrong IP/port or denied conduit	read known gateway-served point
MBAP to route	Unit ID and route table	wrong or unmapped Unit ID	compare one permitted and one invalid ID
serial scheduler	queue and timing counters	overload or timeout budget too short	single-client baseline then staged load
downstream request	serial address/function/offset	incorrect map translation	capture known read-only request
downstream response	valid frame/exception/timeout	device, wiring or configuration issue	test at approved serial boundary
return mapping	transaction ID and exception behavior	mismatched or late response	correlate timestamps and IDs

Include the gateway in the timeout budget

The TCP client's deadline must allow the gateway to queue, transmit and receive the serial transaction under the approved load. But a longer timeout is not the only remedy. Reduce unnecessary polling, group valid contiguous data, prioritize by consequence, fix serial errors and limit concurrent clients. Record gateway diagnostics so “TCP timeout” can be correlated with queue overflow, downstream timeout or invalid route.

Secure Modbus as an OT service

Assume traditional Modbus has no application authentication

Traditional Modbus RTU and Modbus TCP do not add user authentication, authorization or encryption to each ordinary request. If an unauthorized client can reach a server that permits writes, protocol correctness does not prevent an unsafe command. Do not expose port 502 directly to untrusted networks or treat an obscure Unit ID as access control.

Use a risk-based OT architecture: inventory endpoints and data flows; place assets into justified zones; allow only required conduits, directions, peers and functions; restrict engineering access; monitor normal request patterns and configuration changes; manage credentials and device configurations; provide recoverable backups; and test controls without disrupting the process. NIST SP 800-82 Rev. 3 provides current final guidance while emphasizing OT performance, reliability and safety constraints.

The Modbus Organization also publishes a Modbus Security protocol that combines TLS with traditional Modbus, uses X.509v3 certificates and registers port 802. Its existence does not mean an installed “Modbus TCP” endpoint supports it. Verify exact product and client support, certificate lifecycle, interoperability, authorization behavior and fallback policy.

Control objective	Minimum design question	Evidence at acceptance
reduce reachability	which clients genuinely require which servers?	zone/conduit rule and blocked negative test
minimize functions	are writes required, and to which ranges/states?	allowlist or server access-rule test
authenticate administration	who can change maps, routes or firmware?	named identity, log and revocation test
protect remote access	is access brokered, approved and time bounded?	session approval, MFA where supported and recording/log
detect misuse	what request rates, peers and functions are normal?	alert test with safe synthetic deviation
recover	can known configuration and logic be restored?	tested backup, hash/version and restore record
preserve safety	what happens when security control or comms fails?	approved fail-state and recovery validation

Constrain writes at several layers

Where supported, combine network rules with server access control and application-state permissives. Schneider's current Modbus TCP server access-rule documentation illustrates product-specific client and object restrictions. Treat that as one implementation example, not a universal Modbus feature.

A communication success should never bypass machinery safety. Safety functions require their own suitable architecture and validation. A Modbus write can request an ordinary control action only within the approved state machine, authorization and consequence controls.

Build an acceptance test matrix

Test normal, boundary, failure and recovery cases

A green “connected” indicator proves too little. Test each supported transaction with controlled raw vectors, address boundaries, exception behavior, timeout, stale-data handling and reconnection. Test the exact firmware, PLC block/library version, gateway configuration and network path intended for release.

Test family	Example case	Expected evidence	Release criterion
identity	correct and incorrect endpoint/Unit ID	correct route succeeds; invalid route fails predictably	no ambiguous destination
function	supported read and unsupported function	normal data and documented exception	errors classified correctly
bounds	first/last valid point and overrun quantity	valid boundary; exception outside	no buffer overrun or adjacent leakage
decoding	fixed raw words for sign/order/scale	exact expected engineering values	deterministic conversion tests pass
timing	normal and worst credible poll load	response distribution and utilization	freshness deadline met with margin
interruption	cable/link loss or approved simulated loss	timeout, bad quality and bounded retries	no stale value presented as good
recovery	endpoint restarts and returns	controlled reconnect and data revalidation	no uncontrolled command replay
access	unauthorized peer/write attempt	blocked/logged behavior	only approved flows succeed
change	restored configuration and version update	repeatable baseline test	evidence tied to released versions

Preserve an evidence packet for handover

The packet should include the interface contract, controlled register map, topology and route information, device and firmware identities, client block/library version, configuration export, representative captures, raw conversion vectors, polling-load results, exception/failure tests, security rules, backup/restore result and named approvals. Store secrets separately from general documentation.

The Modbus Organization's TCP conformance testing program can provide product-level interoperability evidence. It does not replace the project's configured-system acceptance tests, process consequence review or installed-network verification.

Frequently asked questions

What is the Modbus protocol in simple terms?

Modbus is a request-and-reply language for exchanging bits and 16-bit words between a client and a server. The client selects a function, starting offset and quantity. The server returns data, confirms a supported write, returns a protocol exception or does not respond. RTU and TCP wrap that application request differently.

What is the difference between Modbus RTU and Modbus TCP?

Modbus RTU is a compact binary serial framing mode with a serial server address, timing rules and CRC. Modbus TCP carries a Modbus PDU after an MBAP header over TCP/IP. TCP uses IP endpoint and connection evidence and does not append the RTU CRC. Device maps and application meanings can remain similar, but transport configuration and diagnostics differ.

Is Modbus the same as RS-485?

No. Modbus is an application protocol. RS-485 is an electrical signaling standard commonly used beneath Modbus RTU. A correct Modbus request can still fail because of physical topology, termination, reference, common-mode, cable or transceiver conditions; an RS-485 link can also carry a different protocol.

Is holding register 40001 sent as address 40001?

Not in the Modbus PDU. Under the common reference convention, 40001 identifies the holding-register table and first position, while the PDU starting address is zero. Software fields vary, so verify whether a client expects 40001, 1 or 0 and confirm the actual request bytes.

Are all Modbus registers 16 bits?

The input-register and holding-register elements in the Modbus data model are 16-bit words. A device can define a value across two or more registers. The resulting 32-bit, 64-bit, string or packed interpretation—and especially register word order—must come from the device's controlled map.

Does Modbus define floating-point word order?

No universal multi-register floating-point order is defined by the core Modbus application protocol. Each 16-bit register is transmitted according to the protocol encoding, but the application must document how multiple registers combine. Preserve raw words and test with distinctive known values before choosing a swap setting.

What does illegal data address mean?

Exception 02 means the server recognized enough of the request to reject the addressed data range. Check table/function, zero-based start offset, quantity, implemented range, firmware-specific map and operating constraints. It is not evidence that the Ethernet cable or RS-485 polarity is wrong.

Why does Modbus time out while ping still works?

Ping can prove limited IP reachability, but not that a TCP listener is available, a Modbus server accepts the request, a Unit ID routes through a gateway or a downstream serial device responds before the deadline. Inspect the connection, packet flow, request fields, server/gateway counters and end-to-end timing.

Is Modbus TCP secure by default?

Traditional Modbus TCP does not authenticate or encrypt each ordinary application request. Protect it with a risk-based OT architecture, constrained pathways, least functionality, controlled administration, monitoring, backups and safe failure behavior. Modbus Security adds TLS and certificate-based mechanisms on port 802 only where the exact products support and correctly deploy it.

How should a PLC detect stale Modbus data?

Track the last validated response per transaction, not merely a connected bit. Update data and quality atomically only after function, identity, length and conversion checks. If age exceeds the process-approved freshness deadline, mark the value bad or stale, execute the designed fail response and alarm with enough evidence to diagnose recovery.

Sources, review scope, and limitations

This guide was reviewed on 2026-08-29. The protocol anchors are the Modbus Organization's specifications and implementation guides, Application Protocol Specification V1.1b3, Serial Line Protocol and Implementation Guide V1.02, Messaging on TCP/IP Implementation Guide V1.0b, Modbus TCP toolkit overview, Modbus FAQ, Modbus Security announcement and TCP conformance program. Transport and security context uses the IANA service-name registry, RFC 9293 and NIST SP 800-82 Rev. 3. Product examples link directly to Siemens, Rockwell Automation and Schneider Electric documentation in the relevant sections.

The numerical frame limits and function behavior in this guide are claims about the cited protocol specifications, not a promise that every product implements the maximum or every public function. Register meaning, supported ranges, data type, scale, multi-register order, serial settings, response time, connection capacity, gateway routing and security capability remain product- and firmware-specific. Confirm them in the exact controlled manuals and with an approved test.

The generated figures are editorial concepts, not wiring diagrams, packet captures, electrical measurements, security certifications or permission to connect test equipment. Do not probe, scan, write, interrupt, reconfigure or connect instruments to a production control system without authorization, risk controls and a recovery plan. Electrical work and process testing require competent people, suitable instruments, safe isolation or approved energized-work controls, and site-specific procedures.