ModBus Protocol Overview

[ZerOne]

ModBus Protocol - Quick Highlights

BUS: RS485 : 9600 (Typical, can supports speeds up to 115200 Baud)
BUS Devices: 247 Devices, using a single master -> multiple slaves topology
Error Detection: Yes 16Bit CRC
Encryption Support: No
Device Capability Reporting: No
Primary Use: Industrial Control, Power Control, Relay, Analogue Outputs, Analogue / Digital Inputs

[ZerOne]

Following the overview above, here is a practical series on switching outputs and reading inputs. The important first step is finding the correct entry in the manufacturer's Modbus map.

Four tables, not one big list

• Coils: read/write bits. Read with FC01; write one with FC05 or a consecutive group with FC15 (hex 0F).
• Discrete inputs: read-only bits, read with FC02.
• Input registers: read-only 16-bit words, read with FC04.
• Holding registers: read/write 16-bit words. Read with FC03; write one with FC06 or a consecutive group with FC16 (hex 10).

These are protocol data tables, not a guaranteed wiring diagram. A coil can be an internal flag rather than a relay, and an analogue input may be exposed in holding registers. Always use the device manual, not the name alone.

The common off-by-one trap
In traditional reference notation, the first entries are 00001 (coil), 10001 (discrete input), 30001 (input register) and 40001 (holding register). All four have PDU address 0, in different tables. For example, traditional holding register 40010 becomes PDU address 9, encoded as 00 09. The function code selects the table: do not transmit 40010 as the address merely because the manual calls it that.

Some manuals and software already use zero-based offsets; others expect reference numbers or one-based numbers. Check their conventions before subtracting anything. The traditional prefixes are documentation conventions, not bytes sent on the wire.

How to read the examples in this series
All bytes in code blocks are hexadecimal. FC15 decimal is 0F hex; FC16 decimal is 10 hex. Examples show only the PDU: function code followed by function data. They omit the RTU server address and CRC, or the TCP header. Multi-byte addresses, quantities and register values go high byte first. Packed coil/input bits are a separate case explained below.

All addresses, states and scaling below are illustrative, not a map for any particular product. The message arithmetic has been checked in software; these examples have not been tested on hardware. Use a simulator or a safely isolated, unloaded test setup, never experiment on live locks, heating, pumps, mains equipment or other safety-related loads.

Official references
Modbus Application Protocol V1.1b3
Sections 4.2–4.4 and 6.1–6.6, 6.11–6.12.

[ZerOne]

One output: Write Single Coil (FC05)
Suppose a device manual maps an output to coil PDU address 0. To request ON:

Code: Select all

Request:  05 00 00 FF 00
Response: 05 00 00 FF 00

To request OFF:

Code: Select all

Request:  05 00 00 00 00
Response: 05 00 00 00 00

FC05 uses FF 00 for ON and 00 00 for OFF. Do not use 00 01: other values are invalid for this function. A normal response echoes the function, address and value.

A group: Write Multiple Coils (FC15, hex 0F)
Here is an illustrative request for ten consecutive coils starting at PDU address 0:

Code: Select all

Address:   0 1 2 3 4 5 6 7 8 9
State:     1 0 1 1 0 0 0 1 1 0

Request:  0F 00 00 00 0A 02 8D 01
Response: 0F 00 00 00 0A

The fields are function, start address, quantity (000A = 10), byte count (02), then the packed bits.

The first addressed coil is bit 0, the least significant bit of the first data byte. Thus 8D encodes coils 0–7, and bit 0 of 01 encodes coil 8. Coil 9 is OFF. The six unused high bits in the last byte are zero padding, not extra coils to write. Unlike FC05, this function packs each state into one bit.

FC15 writes 1–1968 consecutive coils per request under the protocol specification; a device can impose a smaller supported block. Its normal reply returns the starting address and quantity, not a copy of the packed states.

What if the outputs are not consecutive?
Use separate requests or a manufacturer-documented mechanism. A group write includes every coil in its range: padding the gap with zeros would turn those intervening coils OFF. Do not overwrite unrelated outputs just to save a transaction.

One grouped message is not a guarantee that physical relays change at exactly the same instant. Output scan timing, interlocks and execution order are device-specific. Do not use this as a safety or synchronisation mechanism.

Official references
Modbus Application Protocol V1.1b3
Sections 6.5 and 6.11.

[ZerOne]

Analogue output commands are commonly stored in holding registers, but the manufacturer's map decides the address, permitted function codes, range and enable/configuration requirements. Modbus itself does not define a universal volts or milliamps encoding.

Illustrative scaling only
Imagine a manual explicitly specifies one unsigned register per output, where raw 0–10000 means 0.000–10.000 V. Then:

Code: Select all

raw = round(volts / 10.0 * 10000)
2.500 V -> 2500 decimal -> 09 C4 hex
7.500 V -> 7500 decimal -> 1D 4C hex

Reject out-of-range values before writing. A 4–20 mA channel could have completely different scaling, live-zero behaviour and fault values. Never assume the formula above applies to it.

One output: FC06
For this imaginary device, suppose output A is at holding-register PDU address 0:

Code: Select all

Request:  06 00 00 09 C4
Response: 06 00 00 09 C4

This writes raw 2500. FC06's normal response echoes the address and register value. It writes exactly one 16-bit register.

Two consecutive outputs: FC16 (hex 10)
Suppose output B is at the next register, address 1:

Code: Select all

Request:  10 00 00 00 02 04 09 C4 1D 4C
Response: 10 00 00 00 02

The request contains start 0000, quantity 0002, byte count 04, then two big-endian register values. The reply confirms the start and quantity; it does not return the values.

FC16 supports 1–123 consecutive registers per request in the specification. A device may accept fewer, or only specific blocks. Non-consecutive channels need separate requests unless the manual provides another mechanism; do not overwrite registers in the gaps. A group write does not guarantee simultaneous physical output changes.

Watch the data type
A setpoint may instead be signed, a 32-bit integer, or a float spanning two registers. Byte order within each 16-bit register is high byte first; interpretation and word order across registers must come from the manual. If a value spans two words, use the documented grouped-write method rather than assuming two FC06 writes are safe. Even a multi-register request does not establish a universal device-level update or atomicity guarantee.

Reading the setpoint back with FC03 is useful, but does not measure the actual output voltage or current. Independent feedback is needed to confirm physical behaviour.

Official references
Modbus Application Protocol V1.1b3
Sections 4.2–4.3, 6.3, 6.6 and 6.12.

[ZerOne]

Digital inputs: FC02
For an illustrative block of ten discrete inputs starting at PDU address 0:

Code: Select all

Request:  02 00 00 00 0A
Response: 02 02 8D 01

The request is function 02, start 0000, quantity 000A. The response is function 02, byte count 02, then two packed data bytes. The response does not echo the starting address; decode it against the matching request.

Bits are packed least-significant-bit first:

Code: Select all

PDU address: 0 1 2 3 4 5 6 7 8 9
State:       1 0 1 1 0 0 0 1 1 0

Only ten bits belong to the requested inputs. The remaining high bits of the last byte are zero padding. To read just the first input:

Code: Select all

Request:  02 00 00 00 01
Response: 02 01 01

This reports that input bit as 1; an OFF response would end in 00.

What does 1 mean?
It means the device reports a logical ON state at that mapped input. Whether that means a closed contact, a healthy circuit, an alarm or an inverted signal depends on wiring and configuration. Debouncing, inversion and polling intervals are also device-specific.

Coil readback: FC01
To read a mapped coil rather than a discrete input:

Code: Select all

Request:  01 00 00 00 01
Response: 01 01 01

This reports coil address 0 as ON. The same numeric address in FC02 accesses a different table and may represent an entirely different point.

Both FC01 and FC02 allow 1–2000 consecutive bits per request in the specification, subject to device limits and valid mapped ranges. Use separate reads for non-contiguous blocks when needed. A group read does not guarantee that all physical signals were sampled at the same instant.

Readback is not physical proof
An ON coil can be a command or internal memory state. It does not prove relay contacts closed, a light illuminated or a valve moved. Use a documented feedback input or an appropriate independent measurement where confirmation matters.

Official references
Modbus Application Protocol V1.1b3
Sections 4.3, 6.1 and 6.2.

[ZerOne]

Input registers: FC04
For two illustrative input registers starting at PDU address 0:

Code: Select all

Request:  04 00 00 00 02
Response: 04 04 09 C4 1D 4C

The request asks for two registers. The response's 04 immediately after the function is the byte count: two registers × two bytes = four data bytes. The values are 09C4 = 2500 and 1D4C = 7500 decimal.

If, and only if, the manual specifies unsigned 0–10000 for 0–10 V, those values mean 2.500 V and 7.500 V. If it specifies hundredths of a degree, signed counts or something else, the interpretation changes. The protocol transports words; it does not attach units.

To read one register:

Code: Select all

Request:  04 00 00 00 01
Response: 04 02 09 C4

Why do some analogue inputs use FC03 instead?
Manufacturers can expose measurements in holding registers. For a device whose manual maps the same example values there, the transaction would be:

Code: Select all

Request:  03 00 00 00 02
Response: 03 04 09 C4 1D 4C

This is an alternative illustrative mapping, not an instruction to assume FC03 and FC04 access the same data. Follow the documented table. An input measurement appearing in a holding register does not mean it is sensible or permitted to write to it.

Before converting a reading

• Confirm the register address convention and whether the value occupies one or more registers.
• Check unsigned versus signed representation, scaling, offset, units, channel mode and reserved fault/invalid values.
• For 32-bit integers or floats, confirm the manufacturer's register/word ordering and data format.
• For multiword measurements, follow any documented snapshot or consistency procedure; do not assume a group read guarantees an atomic physical sample.

Both FC03 and FC04 allow 1–125 consecutive registers per request in the specification, subject to device limits. This counts registers, not channels: a two-register value consumes two. Do not span unmapped holes unless the manual permits it. Check sensor fault/status information before treating a raw value as a valid measurement.

Official references
Modbus Application Protocol V1.1b3
Sections 4.2–4.3, 6.3 and 6.4.

[ZerOne]

PDU examples are not complete RTU or TCP packets
The previous examples start at the function code. Here is how the same single-coil ON command fits into each transport, using illustrative unit/server address 1.

Modbus RTU

Code: Select all

Complete RTU request:
01 05 00 00 FF 00 8C 3A
|  |-----------| |---|
ID      PDU       CRC

The CRC covers the server address and PDU. Its calculated value is 3A8C; RTU transmits the CRC low byte first, hence 8C 3A. That CRC ordering is different from the big-endian address/value fields. A normal FC05 response in this example has the same bytes. RTU also requires the specified inter-frame timing and matching serial settings; a valid CRC alone is not the whole implementation.

Modbus TCP

Code: Select all

Complete TCP request:
00 01 00 00 00 06 01 05 00 00 FF 00
----- ----- ----- -- --------------
Tx ID Proto Len   UI      PDU

The seven-byte MBAP header contains transaction ID 0001, protocol ID 0000, length 0006 and Unit Identifier 01. Length counts the Unit Identifier plus the PDU, not the entire packet. The Unit Identifier's required value/routing meaning depends on the server or gateway. Modbus TCP has no appended RTU CRC. Use the MBAP length when receiving: one TCP receive call is not guaranteed to contain one whole Modbus message. Match responses using the transaction ID and expected unit/function.

Understand exception replies
An exception returns the requested function code with 80 hex added, followed by an exception code:

Code: Select all

05 -> 85   0F -> 8F   06 -> 86   10 -> 90
01 -> 81   02 -> 82   03 -> 83   04 -> 84

Illustrative exception PDU: 85 02

Here 85 02 means the FC05 request failed with Illegal Data Address. Common codes include 01 (Illegal Function), 02 (Illegal Data Address), 03 (Illegal Data Value) and 04 (Server Device Failure). Code 03 concerns the request's data structure/allowed protocol value; it is not a universal engineering-range validator. Device behaviour for out-of-range setpoints must come from its manual.

A practical check sequence

1. Use a simulator first, or a safely isolated unloaded setup. Confirm the manufacturer's map, supported functions, operating mode, interlocks and address convention before any writes.
2. Validate complete replies: framing/length, RTU CRC where applicable, matching server/unit and transaction, expected function, byte count, echoed write fields and exception status.
3. After a supported write, read the mapped coil with FC01 or holding register with FC03. Allow for documented update delays. This checks the reported command/setpoint, not the physical output.
4. For physical confirmation, use documented feedback or an appropriate independent measurement. A successful reply is not proof that a relay, motor or analogue output actually changed.
5. Treat a timeout as an unknown outcome, not proof a write failed. The request may have executed while its reply was lost. Avoid blind retry loops, particularly where a mapped command triggers an action; reconcile state and follow the manufacturer's retry guidance.

Do not use RTU broadcast address 0 for these checks: serial broadcasts are write-only and do not receive replies. Use individual addressed transactions. Keep write-capable control networks appropriately protected; CRC and normal Modbus TCP framing do not provide authentication or encryption.

These are explanatory examples checked for byte construction and arithmetic in software, not a claim of hardware testing or compatibility with a particular board.

Official references
Modbus Application Protocol V1.1b3
Modbus Serial Line Guide V1.02
Modbus TCP/IP Messaging Guide V1.0b
Application specification: sections 4, 6 and 7. Serial guide: sections 2.2, 2.5 and 2.6 / Appendix B. TCP guide: section 3.1.

[ZerOne]

The earlier replies cover the message bytes. This one steps back and explains what the data actually represents.

Think of Modbus as labelled drawers of information
Your automation controller is the client: it asks questions or sends commands. The meter, I/O module or other device is the server: it answers. Its manufacturer decides what is placed in each drawer. The same type of measurement can be placed in different drawers on different products.

Discrete input: a yes/no piece of information
A discrete input is one bit, either 0 or 1. Think of it as an indicator light on your dashboard, not a switch you can operate through that table.

A manufacturer might expose a door contact, a float switch or a fault indication as a discrete input. For a particular installation, 1 might mean “door closed”; on another, it might mean “door open”. Wiring, inversion and the register map decide that meaning. The point could also be an internally calculated status rather than a physical terminal.

The client reads these bits with function 02. It cannot write to the discrete-input table. Read-only does not mean never-changing: the device updates the bit as the contact or internal condition changes.

Input register: a box containing a 16-bit value
A register holds 16 bits, rather than just one yes/no state. The client reads input registers with function 04; it cannot write them through that table. Again, a reading can change continually even though it is read-only to the client.

Temperature, supply voltage or energy measurements are typical information that a manufacturer might expose here. But a register is not automatically an analogue input. It could hold a count, a status word containing several flags, or one part of a larger value. For example, an energy total or floating-point temperature may span two or more registers. Units, signedness, scaling and register order come from the manual, not from the word “register”.

Holding register: a box that can support reading and writing
The holding-register table supports read/write words. Function 03 reads them; functions 06 and 16 write one or several registers where the device permits it.

Typical uses include a temperature target, an analogue-output setpoint, a timer setting or a configuration option. A heating target of 21°C is a command; the measured room temperature is separate information.

“Read/write table” does not mean every entry is writable. Manufacturers also place read-only measurements and status words in holding registers, or restrict writes by operating mode or permissions. Only write entries explicitly documented as writable. Nor does “holding” guarantee a value survives a power cycle: persistence and write endurance are product-specific.

Where do coils fit?
A coil is the one-bit counterpart of a holding register: a logical switch or flag that can be read and, where permitted, written. It might command a relay, but it might also enable an internal feature. A coil reporting ON is not necessarily feedback that a physical relay contact closed.

A simple way to remember it

• Discrete input: “Tell me this yes/no state.”
• Input register: “Tell me this word-sized information.”
• Coil: “Read or set this yes/no command or flag.”
• Holding register: “Read or set this word-sized value, where allowed.”

These examples describe common uses, not a universal hardware map. An actual product may offer only some of these tables, and its measurements may use holding registers rather than input registers.

For the matching technical examples, see addressing and the four tables, digital input reads and register measurements.

Further reading
Official Modbus Application Protocol V1.1b3
See sections 4.2–4.4 and 6.1–6.6, 6.11–6.12 for the data model and functions.

[ZerOne]

Once the four data tables make sense, the next question is: what useful things can we do with them?

The scenarios below are illustrative designs, not claims about a particular product or measured performance. Each depends on suitable hardware, a documented Modbus map and correctly designed control logic.

1. Door and equipment status on one dashboard
A supported I/O module could expose door contacts, tank switches or an equipment fault contact as discrete inputs. Your controller can read those states and display them with other building information.

Potential benefit: less need to visit each device just to check its reported condition, plus event history and notifications if you configure them. But the software needs the correct meaning for 0 and 1. A simple open/closed contact does not necessarily distinguish an open door from a broken cable; that needs suitable supervised hardware and documented status information.

A security dashboard is useful information, not automatically a certified alarm or access-control system.

2. Temperature monitoring and a separate heating target
A controller might expose the measured room temperature in input registers and the desired temperature in a writable holding register. Another manufacturer may expose both through holding registers, with different access permissions.

Your dashboard can show “measured 19°C, target 21°C”. An authorised schedule could adjust the target, within the equipment's allowed limits, while the equipment's local controller handles its own control loop and safety protections.

Potential benefit: a consistent view of actual conditions and requested settings, with fewer trips to local keypads. Appropriate schedules may help avoid unnecessary operation, but Modbus itself does not guarantee comfort or energy savings. Those depend on the system design, occupancy, commissioning and equipment.

3. Energy and maintenance trends
A compatible meter may expose power, voltage and cumulative energy. A controller can log these values over time and compare trends. A mapped run-hours counter or start counter can also help maintenance planning.

Potential benefit: visibility of unusual consumption or changing operating patterns. It does not diagnose a fault on its own. Use the manufacturer's units and multi-register format; account for counter rollover or reset, invalid readings and gaps in communications before calculating totals or raising alerts. A 16-bit register is not necessarily a complete energy value.

4. Command versus confirmation
Suppose a supported output module accepts a fan-enable command as a coil, while an auxiliary contact or airflow device provides separate feedback. The dashboard can distinguish “fan requested ON” from “run feedback present”. An analogue setpoint and an independently measured output are another example of the same distinction.

Potential benefit: discrepancies become visible rather than being hidden behind an ON command. Allow the documented start-up or settling time before declaring a mismatch. Feedback quality matters: an auxiliary contact may show a contactor operated without proving airflow. Choose feedback that actually verifies the condition you need.

The earlier coil-write examples and analogue-setpoint examples explain the commands, not proof of physical operation.

Keep expectations realistic

• Ordinary reads are polled: the controller asks periodically. A display is not an instantaneous view of every change. Device update times, polling intervals, bus load and network delays all matter. A brief event between polls can be missed unless the device provides suitable latching or counters.
• Show a last-successful-update time and an unavailable/stale state. Do not silently display an old value as live, or convert a failed read into zero/OFF.
• Use sensible polling intervals and supported block sizes. Excessive requests can overload a small device or serial bus; grouped reads do not guarantee simultaneous physical sampling.
• Define what happens when communications fail. Use documented local fallback/watchdog behaviour where appropriate, rather than relying on a remote dashboard to keep equipment safe. Decide fail-safe behaviour from the actual application and hazards; “turn everything OFF” is not universally safe.
• Keep safety functions and protective interlocks in appropriate equipment. A successful write reply or matching command readback cannot replace physical feedback or a safety system.

The main value is making useful device information available to a common controller. The benefit comes from what you do with reliable, correctly interpreted data—not simply from having a Modbus connection.

See framing, exceptions and validation for the communication checks behind these ideas.

Further reading
Official Modbus Application Protocol V1.1b3
Official Modbus Serial Line Guide V1.02
Application sections 4–6 describe the request/reply data model; section 7 describes failures and exceptions. Serial section 2.1 describes the request-driven serial exchange. Application scenarios and potential benefits above are illustrative engineering examples, not performance findings from these specifications.

[ZerOne]

A device having digital inputs, analogue inputs or relay outputs does not automatically mean those points are available over Modbus. Equally, an RS485 socket or Ethernet port does not prove Modbus support: those interfaces can carry other protocols.

1. Identify the exact product
Record the manufacturer, full model/order code, fitted communications option and firmware revision. Obtain the matching communications manual and Modbus register map from the manufacturer. Similar-looking models can have different maps, and firmware can add or change features.

Look for “Modbus RTU server/slave” or “Modbus TCP server”, not just “RS485”, “TCP/IP” or “Modbus client/master”. A client-only product does not necessarily answer register reads from your controller. Check whether the feature needs an option card, licence, configuration setting or particular operating mode.

2. Find the supported functions and point definitions
Look for a function-code support table and individual map entries giving address, read/write access, data type, units, scaling, valid range and any conditions. The standard function list is not a promise that every device implements every function.

Here are the relevant codes. In this list the first number is decimal; the 0x value is hexadecimal:

• 01 (0x01): read coils.
• 02 (0x02): read discrete inputs.
• 03 (0x03): read holding registers.
• 04 (0x04): read input registers.
• 05 (0x05): write one coil.
• 06 (0x06): write one holding register.
• 15 (0x0F): write multiple coils.
• 16 (0x10): write multiple holding registers.

In particular, decimal function 16 is hex 10, not hex 16. Read-only use of a holding-register measurement does not establish permission to write it. Physical outputs may be controlled through a manufacturer-specific register rather than coils; physical inputs may be exposed as status bits within a register rather than discrete inputs.

3. Separate “which device?” from “which point?”
For RTU, the server/slave address identifies the device on the serial bus. The register or bit address selects information inside that device; it is not the device ID. An individually addressed RTU server normally uses an address from 1–247. Address 0 is broadcast and receives no reply—do not use it for discovery or read tests.

For TCP, the IP address and configured TCP port reach the server or gateway. The Unit Identifier may select a downstream serial device through a gateway; for a directly connected TCP server, use the value its manual specifies. It is still not a register address.

Confirm the map's zero-based offsets versus traditional reference notation, and how your client software expects addresses. For that distinction, see the earlier addressing explanation.

4. Confirm the transport settings

• RTU: match baud rate, parity, data bits and stop bits; verify the documented wiring, reference/ground, termination and bias arrangements, unique server address and timeouts. Do not disturb a working production bus just to experiment.
• TCP: confirm IP configuration, the configured Modbus TCP port (normally 502), routing/firewall access, Unit Identifier requirements and any enable/access-control settings. An open port alone is not proof that the desired data is available.
• A gateway must also have correct downstream RTU settings and routing; reaching the gateway does not establish that the target instrument is reachable.

Use the manufacturer's supported tools and procedures where available. Regular Modbus RTU and ordinary Modbus TCP do not themselves authenticate or encrypt commands; keep control access appropriately protected.

5. Start with an approved, known read—not a scan
On a simulator or authorised safe test setup, use the manual's documented read-only example or a known readable point, with its correct function and register count. For a two-register value, read the documented pair. Follow any warnings about special or read-to-clear entries: even a read should be chosen from the approved documentation.

Confirm the result has the documented format and is plausible. Compare it with a local display or an appropriate known condition where this can be done safely. A normal response establishes that this specific request worked in the current configuration; it does not prove the whole address space or every function is supported.

Do not sweep unknown addresses, try arbitrary function codes or send exploratory writes. If output control must be verified later, use only documented writable points on an isolated, unloaded bench setup under the manufacturer's procedure—not live building equipment. In many cases the manual and vendor confirmation are enough to establish support without writing anything.

6. Interpret failed tests correctly
Exception codes are not the same thing as a timeout:

• 01, Illegal Function: this action is not allowable for the responding server. It may be unimplemented, or unavailable in the current device state. Check model, firmware and configuration before declaring it permanently unsupported.
• 02, Illegal Data Address: the requested address or address-plus-length combination is not allowable. Recheck the table, offset convention, map version and block boundaries. This does not establish that the entire function is unsupported.
• 03, Illegal Data Value: a request-data or structural value is invalid, for example a bad quantity/length. It is not a universal test of whether an engineering setpoint is within range.
• Timeout/no response: possible causes include wrong device ID, serial settings, wiring, network/gateway routing, access settings, message corruption, overload or an unavailable device. Silence alone does not prove a function is unsupported.

Use logs and the troubleshooting steps in the earlier reliability post. Avoid repeated blind retries; a write timeout leaves the outcome uncertain.

7. Device identification can help, but is not a register-map search
Some devices implement Read Device Identification: function 43 decimal (0x2B), MEI type 14 decimal (0x0E). Where supported, it can report vendor, product code and revision information. Support for this service is not universal. The standard service does not enumerate the device's application register map, nor does its absence mean ordinary reads are unavailable.

This qualifies the original overview's “no capability reporting” shortcut: standard identification information can exist, but you still need the correct manual/map to know what the I/O means and how to access it.

If documentation is missing or ambiguous, ask the vendor for the exact model/firmware map, supported function codes, a safe read example, address convention, data format and write restrictions. Vendor tools can help verify connectivity, but they do not replace those definitions. No hardware has been tested for this guide.

Further reading
Official Modbus Application Protocol V1.1b3
Official Modbus Serial Line Guide V1.02
Official Modbus TCP/IP Messaging Guide V1.0b
Application sections 4.3–4.4, 6.1–6.6, 6.11–6.12, 6.21 and 7; Serial sections 2–4; TCP section 3.1. These define the protocol, not a universal product register map.