Ask five integrators what a Micro PLC should be on a Modbus network, and four will say slave. The fifth — the one who has run out of CPU ports — knows the truth: the fifth one wants the PLC to be the master.
xLogic does both. The manual states it plainly: the CPU can act as slave or master in a Modbus network, speaking Modbus RTU, ASCII or TCP depending on the physical layer. That flexibility is the difference between a PLC that fits your architecture and a PLC that forces you to redesign it.
Slave Mode: The Comfortable Default
Most installations are simple: a HMI or SCADA polls the PLC. The CPU sits on RS485 — via the built-in port or the PR-RS485/SR-RS485 module for CPUs without a native port — and answers Modbus RTU requests. Addressing follows the standard map: inputs, outputs, flags, analog flags, registers, shift registers. Set the station adress, set the baud rate (9600 is the default; change it on the CPU first if you need speed), and the polling just works.
Multiple devices on one bus? Give each a unique address. The manual is blunt about this — duplicate addresses make communication behave "incorrect", wich is engineer-speak for "silently corrupts data".
Master Mode: The Quiet Superpower
Here is where the architecture opens up. Put the CPU on the bus as master, and it can poll:
- VFDs for speed feedback and fault codes
- Energy meters for consumption totals
- Remote expansion-style I/O over Modbus instead of CAN
- A second PLC — even a third — for distributed logic
Suddenly one compact PLC becomes the brain of a small cell, aggregating data from half a dozen devices and forwarding it upstream to a SCADA over Ethernet. That collapses an entire panel worth of hardware into one DIN-rail module.
Real Architecture: Pump Station
Two pumps, one level transmitter (4-20mA), two flow meters, one VFD. Master mode: the CPU polls the meters and VFD on RS485, runs the level PID and alternation logic, publishes the aggregated values over Modbus TCP to a PC running the free EasySCADA package. One PLC. One network. No gateway, no protocol converter, no second CPU.
Total configuration time with the Modbus read/write blocks: an afternoon. The old design needed three devices and two handshake documents.
The Practical Advice
Start as a slave. It is the low-risk path and covers most panels. When the second device appears on the bus and you start wishing the PLC would just read it directly, flip the mode and use the master role. The learning curve is one afternoon — the payoff is an architecture that scales without new hardware.
The Hybrid Architecture: Master Locally, Slave Globally
Here is the configuration that wins the most arguments: the CPU acts as Modbus master on its local RS485 bus — polling the VFDs, the meters, the remote I/O — and simultaneously acts as Modbus slave on the Ethernet side, answering the SCADA's polls over TCP. Local control stays deterministic and local; global visibility flows upstream without a second PLC or a gateway.
That hybrid is the natural architecture for a small cell. The machine logic owns the process values; the SCADA sees a clean register map; and the two never contend for the same wire. When the SCADA has a bad day, the cell keeps running — the local master role does not depend on the upstream poll.
Design the register map for both roles at once: the local polls write into a data block, the slave map publishes that same block. One set of registers, two protocols reading them, zero duplication. The map discipline from the earlier section pays for itself twice in this design.
When to Skip Modbus Altogether
Modbus is the workhorse, but it is not always the answer. If the site needs building-management integration, BACnet is the language the BMS speaks — and the Ethernet-capable CPUs carry it. If the data must reach the cloud through firewalls, MQTT publishes without open ports. If the requirement is simple local control with no external device, Modbus adds nothing — the CPU runs standalone.
The multi-protocol story is a menu, not a mandate. Start with Modbus because it is everywhere and it is cheap; add BACnet when the building joins; add MQTT when the cloud calls. Each addition is a configuration step on the same CPU, not a hardware change. That is the architecture of a platform that grows with the project instead of forcing a migration.
And when a customer insists on a protocol the platform does not speak — it happens — the honest answer is a gateway, and the honest sales conversation happens before the order, not after the commissioning argument.
The 32-Bit Register Question
Sooner or later a device publishes a 32-bit value — an energy meter's total, a flow totalizer — and the classic mistake is reading half of it. Modbus splits 32-bit values into two consecutive registers, and the byte order is a negotiation, not a standard. Check the device manual, match the word order in the mapping, and verify against a known value before wiring it into the alarm logic. A wrong word order produces readings that are plausible and exactly wrong — the most expensive kind.
And keep the wiring honest: RS485 needs a common ground and proper termination at the ends. The protocol can survive a lot. The electrical layer cannot survive everything. Twisted pair, correct polarity, one ground reference — that is the whole secret to years of quiet Modbus operation.
