One DIN-rail module speaking MQTT to the cloud, BACnet to the building, and Modbus TCP to the machines. That sentence used to describe a panel full of gateways. It now describes a single Ethernet-capable compact CPU, and the multi-protocol story on the xLogic platform is not a marketing slide — it is in the firmware, documented across the manual revisions: MQTT since V1.04, BACnet since V1.57, Modbus from day one.
Here is how to use that without creating a maintenance nightmare.
The Protocol Map
Each protocol has its natural audience, and the trick is keeping them seperate:
- Modbus TCP — the machine floor: VFDs, HMIs, SCADA, other PLCs. Deterministic, register-based, the universal industrial handshake
- MQTT — the cloud: publish telemetry to a broker, dashboards subscribe. Event-driven, NAT-friendly, built for unreliable networks
- BACnet — the building: plant rooms, AHUs, BMS head-ends. The property industry's native tongue
One CPU serving all three audiences means the machine builder, the facilities manager and the cloud dashboard see the same device — each in thier own language, none of them needing a converter box.
Real Building: Small Plant Room
A plant room with an AHU, two fan-coil groups and a heat pump: Modbus TCP to the local HMI and the VFDs, BACnet to the building BMS for scheduling and alarms, MQTT to a cloud service for remote trending. Three protocols, one controller, one program. The BMS engineer asked who made the gateway. The answer — "there is no gateway" — earned a silence that lasted a full five seconds.
That silence is the product working.
What to Keep Separate
The protocols can share the CPU, but they should not share the data plan. Map the points once, deliberately: which registers are Modbus-visible, which objects are BACnet, which topics are MQTT. A single point map, maintained in one spreadsheet, prevents the classic failure — a register number changing and three systems quietly going stale.
And remember the model limits: BACnet/IP and MQTT need the Ethernet-capable CPUs. The serial-only models keep Modbus RTU and BACnet/MSTP. Check the model against the requirement before the promise, not after the purchase order.
The Support Angle Nobody Prices
Multi-protocol is not just a feature; it is a sales door. Tenders now ask for BMS integration as standard, cloud connectivity as a checklist item. A controller that answers both without add-ons gets past the pre-qualification filter. The price difference between the single-protocol and multi-protocol versions is small; the difference in which projects you are allowed to bid on is not.
Point Map Discipline
Multi-protocol is a blessing and a trap. The blessing: one CPU serving three systems. The trap: three systems reading slightly different versions of the truth. The fix is boring and non-negotiable — a single point map that lists every value once, with its register, its BACnet object, and its MQTT topic in the same row.
Start the spreadsheet on day one, before the first block is wired. Columns: value name, Modbus register, BACnet object type and instance, MQTT topic, data type, scaling, update rate, and which system is authoritative for writes. The last column matters more than people think — when the BMS and the cloud dashboard both want to change a setpoint, somebody has to win, and the map says who. Without it, two systems fight over one value and the machine behaves unpredictably at 3 AM.
Version the map with the program. Every firmware change, every added point, every renumbering — the map updates in the same commit. I have inherited projects where the map was two years out of date and three people had different copies. Rebuilding it took a week of staring at register tables. A week. Do not be that project.
And test the cross-protocol paths deliberately: write a setpoint from the BMS, verify the machine responds, verify the cloud dashboard shows the change. One end-to-end test per point, at commissioning, catches the mapping errors while they are cheap to fix.
Firmware and Version Reality
The protocol features arrived in waves, and the manual revision history tells the story: MQTT in 4.2, the web server in 4.5, WiFi instructions in 6.0, BACnet in 6.2, SR-22 support in 6.2.1. If you are planning a multi-protocol project, the firmware version is not a detail — it is a requirement. A CPU that shipped two years ago may need an update before it speaks BACnet, and the update path depends on the model.
Make the firmware check part of the pre-sales checklist. Note the version on the order, confirm it on delivery, and document it on the commissioning sheet. The most expensive conversation in this business is "it should support that" followed by "this one does not."
And keep the protocols honest about their strengths. BACnet for the building, Modbus for the machines, MQTT for the cloud — each on the wire type it was designed for. The Ethernet CPU handles all three simultaneously; it does not magically make them one protocol, and it should not. The separation is what keeps the plant running when the cloud link drops — the local Modbus and BACnet traffic does not wait for the internet.
The Protocol Documentation Habit
A three-protocol controller without a protocol map is a museum exhibit. The discipline costs an hour at commissioning and saves a week every time the building changes: one sheet listing every point, its Modbus register, its BACnet object, and its MQTT topic — with the write authority marked. The sheet lives with the panel drawings, versioned with the program. When the BMS engineer asks "which value is the supply temp?" the answer is one row, not an afternoon of register archaeology.
Buy the version with the protocols. The projects will follow.
