Modbus TCP to BACnet MS/TP Leak Detection Monitoring Case Study

Chipkin QuickServer converted Modbus TCP leak and heartbeat registers into BACnet MS/TP binary values for a multi-building leak-detection monitoring deployment.

A building controls contractor needed floor-level leak and heartbeat status from a Modbus TCP master PLC exposed to a BACnet MS/TP BMS. Chipkin QuickServer turned an ambiguous register map and a late BACnet/IP versus MS/TP hardware conflict into a working handoff for a multi-building leak-detection monitoring system.

The project already had a clear operational goal: surface leak alarms and communication-loss conditions for hundreds of suites inside a BAS. The harder part was getting the protocol details into a form that could actually be commissioned. The supplied register map used floor-level words and bit extraction, but it did not clearly state the Modbus addressing convention or function-code expectations. That mattered because the QuickServer still had to read the correct Modbus values, split them into suite-level BACnet objects, and do it on hardware whose single Ethernet port also had to serve the source-side PLC connection.

At a Glance

  • Industry: Building automation / leak-detection monitoring
  • Customer: Building controls contractor
  • Facility type: Multi-building residential / commercial complex
  • Client role: Leak-detection and BMS integration team
  • Project scale: 3 buildings, 9 PLCs, and roughly 366 suites
  • Protocols: From: Modbus TCP → To: BACnet MS/TP
  • Chipkin product: Chipkin QuickServer FS-QS-2110-1138
  • Project start: February 2023

Enerpro master PLC to Chipkin QuickServer to BACnet MS/TP BMS leak-detection architecture diagram.

Enerpro master PLC → Modbus TCPChipkin QuickServerBACnet MS/TP → BMS

Modbus TCP to BACnet MS/TP Challenge

The upstream/server side was a master PLC aggregating leak and heartbeat status from nine distributed controllers across three buildings. The downstream/client side needed those conditions as suite-level BACnet binary values inside a BAS. That meant the project was not just a generic protocol bridge. It needed reliable bit extraction, naming, and point organization so a building controls team could see meaningful alarm objects instead of raw floor registers.

The first obstacle was the Modbus map itself. The original point package referenced addresses such as 12288 and described them as 16-bit words with suite bits packed inside each register. Chipkin flagged the problem immediately: in conventional Modbus notation, 1xxxx addresses indicate binary inputs, not 16-bit registers. In Mike Arslan’s words, Register 12288 is not a word/16bit integer and the data would need to be served through function-code-compatible 3xxxx or 4xxxx handling before reliable bit extraction could begin.

The second obstacle was architecture. The customer initially expected a BACnet/IP handoff, but the selected QuickServer model had a single Ethernet port. That port was already needed for the Modbus TCP master PLC. The project therefore had to either share that port carefully or move the BMS side to BACnet MS/TP. Until that decision was made, the configuration path was still unsettled.

There was also a mapping challenge hidden inside what looked like a simple alarm job. Each suite needed separate leak and heartbeat-loss visibility, and the naming had to be usable by technicians in the field, not just mathematically correct in a spreadsheet.

Why Chipkin

This was a strong fit for Chipkin because the failure point was not raw compatibility. It was protocol interpretation. Chipkin QuickServer could handle the conversion, but only if somebody caught the addressing problem before commissioning, confirmed the correct data-flow direction, and aligned the hardware choice with the final BACnet transport.

Chipkin support added value by stopping the job before a bad assumption became a bad configuration. Mike challenged the 12288 mapping early, asked for the missing function-code detail, and worked through the naming and alarm-model questions instead of simply sending a file based on guesswork. That reduced the risk of a field install built on the wrong Modbus convention.

The Solution

Chipkin gathered a clearer intake, confirmed the application intent, and worked with the customer’s PLC side to verify how the leak and heartbeat states were actually exposed. The revised understanding was that the upstream system produced floor-level words for two conditions: leak alarms and no-heartbeat / communication-loss status. QuickServer then needed to read those words from the Modbus TCP master PLC, extract the relevant bits, and serve suite-level BACnet binary values to the BMS.

The decisive fix was clarifying the Modbus model before the point mapping was finalized. Once the addressing and function-code ambiguity was resolved, the bit-extraction workflow made sense again. The final design used the QuickServer’s Ethernet port for the Modbus TCP connection and moved the BMS handoff to BACnet MS/TP, which the customer later confirmed in writing: Correct, we will use bacnet ms/tp to gateway.

That architecture let the project keep the Modbus source side intact while still delivering the BAS-facing view the customer wanted. QuickServer handled the translation from packed Modbus words into BACnet binary values, and Chipkin support stayed involved long enough to answer follow-up questions about additional BACnet objects such as trend logs and alarms after the core integration was already online.

Leak Detection Integration Results

The project delivered a usable Modbus TCP to BACnet MS/TP handoff for a multi-building leak-detection system.

Project proof points:

  • 3 buildings and 9 PLCs were consolidated through a single master PLC and QuickServer handoff.
  • Approximately 366 suites were represented through extracted BACnet status points for leak and heartbeat-loss conditions.
  • The BACnet transport decision was corrected in time to fit the single-port QuickServer hardware already purchased.
  • The system came online successfully before the customer moved on to optional trend-log and event-object questions.

Before Chipkin intervened, the register map and BACnet transport plan were still ambiguous enough to derail commissioning. After the addressing cleanup, point mapping, and MS/TP handoff decision, the customer reported that the gateway was online and later closed the main integration loop with a concise confirmation:

“I think we are in good shape.”

— Project lead, building controls contractor

Have a Similar Modbus-to-BACnet Project?

Need to expose packed Modbus alarm words to a BACnet BMS without rewriting the upstream controls? Chipkin can help validate the addressing model, split out the point mapping, and deliver a QuickServer configuration that is easier to commission in the field. Tell us about your project.