Technology

M2MB – Multi-Master Modbus RTU (serial)

Expanding a proven protocol without replacing it.

True multi-master Modbus RTU over a shared twisted pair backbone.

True multi-master access Standard RTU devices Session-based routing Up to 32 RTU masters

What it is

M2MB is a XIAC communication technology that expands the proven Modbus RTU protocol by allowing multiple RTU masters to share the same communication backbone.

Rather than replacing Modbus, M2MB preserves the original Modbus RTU data stream and adds a small session layer around it. This allows existing PLCs, HMIs, loggers, gateways, drives, sensors and I/O modules to remain standard Modbus devices while gaining a far more flexible network architecture.

The result is a practical upgrade path for systems that already depend on Modbus RTU, but need more access, better diagnostics, and less dependence on a single polling master.

Conceptual illustration of M2MB showing multiple Modbus RTU masters communicating with standard RTU slave devices over one shared twisted pair cable.

Compatible with existing Modbus RTU devices

M2MB preserves standard Modbus RTU communication at the endpoints. Existing PLCs, HMIs and Modbus devices can continue operating normally while M2MB manages session routing and arbitration on the shared backbone.

Internally, the M2MB backbone transports the original Modbus RTU frame together with a lightweight session header, preserving standard Modbus communication while enabling deterministic multi-master operation.

Why it exists

Modbus RTU became popular because it is simple, reliable and widely supported. Its limitation is that a conventional RTU network normally has one master controlling access to the bus.

Modern machines often need more than one system to access the same information. A PLC may control the process, an HMI may provide operator access, a logger may record production data, and a service tool may need live diagnostics. With standard Modbus RTU, these devices cannot all act as independent masters on the same network.

M2MB exists to remove that bottleneck while keeping the parts of Modbus RTU that made it successful in the first place.

Why M2MB Is Different

Most so-called multi-master Modbus systems rely on polling gateways, cached registers, protocol conversion, or shadow memory techniques. In these systems, the original Modbus transaction is typically terminated, copied into memory, and re-served to other masters as virtual data.

M2MB takes a fundamentally different approach.

True multi-master operation.
Many existing “multi-master” Modbus solutions operate by multiplexing or scheduling access between masters, effectively allowing only one active master at a time.

M2MB uses deterministic bus arbitration and session-aware routing, allowing independent masters to communicate dynamically over the same backbone.

M2MB does not virtualise Modbus registers — it virtualises the serial link itself.

M2MB allows overlapping live transactions on the shared backbone, efficiently utilising otherwise unused Modbus RTU idle periods to transport additional live transaction data.

One master can issue a request to a slave while another master issues its own request to the same slave, or to a different slave, before the first master has received its reply.

Each transaction remains individually owned by its originating Session Node. The Session Gateway preserves transaction ownership, queues or routes replies as required, and returns each real slave response to the correct master session.

Multiple masters can share the same Modbus infrastructure in real time, without relying on cached or copied register data.

Instead of mirroring slave registers into a central controller, M2MB preserves live end-to-end Modbus transactions between the originating master and the real slave device.

The M2MB backbone uses a field-proven arbitration system that allows multiple independent session masters to transparently share the same physical slave network while preserving transaction ownership and reply routing.

In a conventional multi-master Modbus multiplexer, requests from different masters are normally queued and processed one transaction at a time. Even if Master 1 requests data from slave ID 3 while Master 2 requests data from slave ID 4, one complete transaction must normally finish before the next can proceed.

M2MB uses session-based routing instead. Independent transactions can exist on the backbone at the same time. A reply from slave ID 4 may return before a reply from slave ID 3, regardless of which master sent its request first. Each reply is routed back to the correct master using its Session Node identity.

In traditional queued Modbus multiplexers, a missing or slow slave device can delay unrelated traffic while the gateway waits for a timeout to expire.

M2MB uses independent session-based routing instead. If one slave device does not respond, unrelated traffic on the shared backbone can continue largely undisturbed. This helps maintain overall network responsiveness, even when individual devices are offline or experiencing communication delays.

Scalable by Session, Not by Serial Port

Traditional multi-client Modbus solutions typically scale by adding more physical serial ports: one isolated port for each master, plus one or more ports for the slave network. This works for small systems, but it quickly becomes impractical as the number of masters increases.

For example, supporting 32 independent Modbus masters in a conventional port-isolated gateway architecture would require 32 master-side UARTs, plus at least one additional UART for the slave network.

M2MB scales differently. Multiple masters share the same physical backbone, while transaction ownership is separated by Session Node identity. The practical limit is therefore no longer the number of serial ports, but the selected session-address space, arbitration policy, and available bus bandwidth.

Typical Gateway-Based Systems	M2MB Technology
Polling and cached slave data	Live end-to-end Modbus transactions
Virtual slave devices	Real slave replies routed to originating session
Shadow register memory	No shadow register dependency
Centralised communication controller	Distributed backbone arbitration
Copied or delayed data possible	Direct access to real slave registers
Masters indirectly access cached data	Multiple independent virtual Modbus links

Unlike conventional gateway systems, M2MB does not require a central polling engine continuously mirroring slave registers into memory before other masters can access them.

This allows legacy Modbus RTU devices to participate in a shared multi-master environment while maintaining direct transaction-based communication behaviour.

How it connects

A session master module connects to a standard Modbus RTU master, such as a PLC, HMI or data logger. The module adds a small session header to the Modbus data stream before placing the request onto the M2MB backbone.

At the other side, an M2MB session slave connects to the standard Modbus RTU slave network. This may be a complete multi-drop RTU segment or individual RTU slave devices. The session slave forwards the original Modbus request to the target device and routes the reply back to the correct originating master.

1. Standard master A PLC, HMI, logger or service tool sends a normal Modbus RTU request.

2. Session header The session master adds a small identifier without changing the Modbus payload.

3. Shared backbone Multiple masters share the same twisted pair cable using M2MB arbitration.

4. Correct reply The session slave remembers the request source and returns the reply to the right master.

In general, up to 32 RTU masters can connect simultaneously and access RTU slaves on the same network, either sharing the same slave devices or communicating with different RTU slave nodes.

Why it matters

Multiple masters

PLCs, HMIs, loggers and service tools can all access the system without forcing everything through one polling master.

Existing devices stay standard

Modbus RTU slaves do not need to know that M2MB exists. They receive and answer normal Modbus requests.

Live device access

M2MB transports requests to the real device registers rather than relying on copied or shadow data in a gateway.

Backbone performance

The M2MB backbone is designed for efficiency as much as flexibility.

Unlike many traditional multi-master approaches, M2MB does not rely on short cable segments or Ethernet-style switching infrastructure. Depending on baud rate and installation quality, cable lengths of several kilometres without repeaters are considered realistic.

Operating at speeds up to 500 kbit/s, the backbone transports Modbus RTU data with minimal overhead, avoiding the fixed timing gaps that are inherent to standard RTU communication.

In conventional Modbus RTU systems, each transaction requires mandatory silent intervals between frames. These gaps significantly reduce effective bandwidth, especially in systems with many short messages.

M2MB removes this limitation:

Communication occurs when required, not only after fixed delays
Multiple masters share the bus without waiting for a polling cycle
Idle time is minimised, increasing overall utilisation

As a result, the effective system throughput can be dramatically higher.

In practical terms, a single M2MB backbone running at 500 kbit/s can deliver performance comparable to 10–20 independent Modbus RTU masters operating at 115.2 kbit/s, each on its own cable.

This improvement is not only due to higher baud rate, but to reduced protocol overhead and the elimination of rigid polling cycles.

Flexible baudrate architecture

M2MB separates backbone communication from local Modbus RTU communication, allowing each part of the system to operate at its optimal speed.

The backbone runs at its own fixed high-speed baudrate (up to 500 kbit/s), while each session node independently handles communication with its connected Modbus RTU devices.

Each session master can use its own local RTU baudrate
The M2MB backbone operates independently at high speed
Each session slave defines the baudrate for its connected RTU segment

This allows different parts of the system to operate at different speeds without compromise.

For example:

Master 1 operating at 9600 baud
Master 2 operating at 19.2 kbit/s
Master 3 operating at 115.2 kbit/s

All connected via session master modules to a shared 500 kbit/s backbone.

On the slave side:

A group of RTU slaves connected to a shared session slave can operate at a common baudrate (e.g. 9600 baud)
An individual RTU slave connected via its own session slave can operate at a different baudrate (e.g. 115.2 kbit/s)

This architecture allows legacy and high-speed devices to coexist on the same network, without forcing system-wide baudrate compromises.

Deterministic bus arbitration

No collisions. No lost packets. Deterministic multi-master communication.

M2MB uses a field-proven bus arbitration mechanism to ensure reliable operation in a multi-master environment.

In conventional multi-master systems, simultaneous transmissions can lead to collisions, resulting in corrupted packets, retries, or loss of communication.

M2MB avoids this by applying deterministic arbitration directly on the physical bus:

Only one device can win bus arbitration for any given session
Simultaneous transmission attempts are resolved in real time
Losing nodes automatically withdraw without corrupting the message

This ensures that no packets are lost, even when multiple masters or slaves attempt to start transmission at the same time.

The result is a stable, predictable communication system where multi-master operation does not introduce the typical risks associated with bus collisions.

Efficiency comparison

Traditional Modbus RTU

One master polling multiple slaves over a single bus.

Fixed inter-frame delays
Sequential polling only
Limited bandwidth utilisation

Typical performance limited by idle time and polling overhead.

M2MB Backbone

Multiple masters communicating dynamically over a shared bus.

No fixed polling cycle
Minimal idle time
High utilisation of available bandwidth

One backbone can replace multiple independent RTU links.

System-level impact

A single 500 kbit/s M2MB backbone can match the performance of multiple traditional RTU networks.

Reduced wiring complexity
Faster system response
Scalable multi-master architecture

Equivalent to ~10–20 × 115.2 kbit/s RTU links in real-world usage.

Operational behaviour

Each request is tagged with its originating session node.
Replies are routed back to the correct RTU master automatically.
Multiple masters can access the same slave network without modifying the RTU slave devices.
Bus access is coordinated by the M2MB layer so communication remains orderly and deterministic.

Modular by design

M2MB can be applied as a compact point-to-point expansion, a shared machine-level communication backbone, or a distributed gateway system for larger installations. Because the session layer sits around the Modbus RTU data stream, systems can be expanded gradually without replacing the existing Modbus devices.

A natural evolution of Modbus RTU

M2MB preserves the familiar simplicity of Modbus RTU while extending it with deterministic arbitration, session-aware routing, and true multi-master operation.

For many industrial systems, this is the ideal expansion path. It protects existing investment, improves access and diagnostics, and extends one of the world’s most popular industrial protocols without forcing a move to a completely different fieldbus.

How M2MB Compares

M2MB is not intended to replace Modbus RTU or Modbus TCP. Instead, it fills the gap between them: deterministic multi-master communication over traditional industrial twisted-pair wiring, while preserving standard Modbus RTU communication at the endpoints.

Feature	Modbus RTU	M2MB	Modbus TCP
Physical layer	RS-485 / RS-232	Industrial twisted pair using CAN-style physical arbitration	Ethernet
Multiple masters	No	Yes, fully supported with session-based arbitration	Yes, limited by socket/client capacity
Existing RTU device support	Native	Native at the endpoints	Usually requires gateways for RTU devices
Communication model	Single master polling slaves	Multiple session nodes sharing one deterministic backbone	Multiple TCP clients connecting to a server
Session-based routing	No	Yes, tiny session header added to Modbus frame	TCP socket based
Typical endpoint complexity	Low	Low	Medium to High
Real-Time serial behaviour	Yes	Yes	Not deterministic
Retrofit friendly	Excellent	Excellent	Moderate
Large factory Network Integration	Limited	Strong	Strong
Long distance capability	Strong	Very Strong	Moderate without switches
Endpoint complexity	Low	Low for endpoint devices; intelligence is in the session layer	Higher, requires Ethernet/TCP stack and socket handling
Deterministic bus access	Yes, but only for one master	Yes, with hardware-assisted arbitration	Not inherently deterministic
Retrofit suitability	Excellent for simple networks	Excellent for multi-master upgrades and legacy systems	Good, but often requires new infrastructure
Infrastructure required	Serial wiring or Traditional twisted-pair	Traditional twisted-pair wiring	Ethernet cabling, switches, IP configuration
Best suited for	Simple single-master serial systems	Retrofits, shared RTU access, multi-controller systems, long-distance industrial links	High-bandwidth Ethernet-based systems and IT integration

M2MB combines the simplicity and long-distance robustness of Modbus RTU with deterministic multi-master operation normally associated with Ethernet-based systems.

Why M2MB is Different from Traditional Modbus RTU

M2MB keeps the simplicity and familiarity of Modbus RTU, but removes many of the practical limitations that normally appear when multiple devices, masters, HMIs, loggers, service tools, or gateways need access to the same network.

Multiple masters on one shared backbone — no separate serial port required for each master.
Session-based routing — replies are returned to the correct master using Session Node identity.
Live data access — transactions access the real device registers, not cached or shadowed gateway data.
Automatic bus arbitration — simultaneous access attempts are resolved by the bus arbitration system.
True multi-master operation — unlike multiplexed or scheduled sharing systems, independent masters can communicate dynamically over the same backbone.
Independent transactions — different masters can communicate with different slave nodes without forcing all traffic into one strict queue.
Graceful fault behaviour — if one slave does not reply, unrelated traffic can continue largely undisturbed.
Efficient high-speed backbone — the backbone can run at a higher speed than the local Modbus RTU segments.
Flexible baudrate architecture — local RTU masters and slave segments can operate at different baudrates while sharing the same high-speed M2MB backbone.
Traditional twisted pair cabling — M2MB still uses robust differential signalling over familiar industrial twisted pair cable.
Long cable capability — depending on baud rate, cable quality, topology, and installation practices, cable lengths of several kilometres without repeaters are realistic.

M2MB is designed for systems where standard Modbus RTU is still the right interface, but traditional single-master bus architecture has become the limitation.