A Procter & Gamble facility can now expose Allen-Bradley PLC alarm data to Metasys over BACnet/IP without the BAS team decoding packed PLC integers by hand. Getting there required separating bit-level alarms from EtherNet/IP DINT arrays, correcting the BACnet handoff, and staying with the project until both sides confirmed clean data flow.
At this site, the integration problem was not just moving data from an Allen-Bradley PLC into a BACnet/IP BMS. The upstream alarm data lived inside DINT arrays that made sense to the PLC programmer but not to a downstream building automation team expecting individual BACnet points. Chipkin used a Chipkin QuickServer to read the PLC over EtherNet/IP, unpack the alarms into usable BACnet objects, and give Johnson Controls a cleaner handoff into Metasys.
At a Glance
- Industry: Manufacturing
- Location: Kingston, Ontario, Canada
- Customer: Johnson Controls
- Facility type: Consumer products manufacturing facility
- Client role: BAS contractor / controls integrator
- Protocols: From: EtherNet/IP → To: BACnet/IP
- Chipkin product: Chipkin QuickServer FS-QS-2X10
- Project window: February-April 2023
Allen-Bradley PLC → EtherNet/IP → Chipkin QuickServer → BACnet/IP → Johnson Controls Metasys
EtherNet/IP to BACnet/IP Alarm Mapping Challenge
The upstream controller was an Allen-Bradley PLC programmed in Studio 5000. The downstream system was Johnson Controls Metasys, which needed a stable BACnet/IP view of the same alarm and status information. There was no native handoff between the PLC data model and the object-based BACnet view the BAS team wanted to consume.
The harder problem was data shape, not basic connectivity. Critical alarms were packed into DINT arrays such as Y440_IN and L83_Faults. That is normal on the PLC side, but it is not useful to a Metasys engineer who needs separate alarm points, reliable state changes, and predictable object behavior. Until those packed values were broken apart into individual BACnet Binary Values, the BAS side still had too much interpretation work left to do.
The field details also needed refinement during commissioning. One part of the initial mapping had to be reworked when the expected AI and BI behavior did not line up with the PLC-side reality, and the BACnet handoff needed to use the standard port 47808 instead of an alternate port. Those are the kinds of integration details that turn a simple protocol bridge into a real commissioning project, and they are exactly where owning both sides of the translation helps.
Why Chipkin
This project needed more than a gateway that could speak two protocols. It needed a team that understood EtherNet/IP data table read/write, BACnet object exposure, and the practical difference between what a PLC programmer considers a clean tag structure and what a BAS team can commission quickly.
Chipkin QuickServer gave the project a dedicated protocol-conversion platform instead of forcing the customer to build a one-off interface layer. Chipkin support then worked through the data-type handling, bit extraction, and BACnet-side corrections so Johnson Controls was not left debugging the entire path alone.
The Solution
Allen-Bradley PLC → EtherNet/IP → Chipkin QuickServer → BACnet/IP → Johnson Controls Metasys
Chipkin configured the Chipkin QuickServer to poll the Allen-Bradley PLC over EtherNet/IP, read the DINT-based alarm arrays, and expose the resulting points as a cleaner BACnet/IP object set for Metasys. The work included separating bit-level alarms from 32-bit integers so the downstream BAS team could consume discrete states instead of raw packed words.
As commissioning progressed, Chipkin refined the mapping to correct point interpretation issues, split read and write behavior where needed, and align the BACnet-side handoff with the real site requirements. The final handoff also corrected the BACnet port to 47808, which removed an avoidable discovery problem on the Metasys side.
The result was not just a working gateway. It was a gateway configuration and point model the Johnson Controls team could validate in the field without reverse-engineering PLC internals during startup.
Allen-Bradley PLC to Metasys Results
Business outcomes:
- Metasys received a usable BACnet/IP alarm model instead of packed PLC integers that the BAS team would have had to decode manually.
- The PLC and BAS sides both confirmed clean communication after the final adjustments to the EtherNet/IP mapping and BACnet handoff.
- The customer team could commission alarm visibility faster because the project delivered separated BACnet points rather than raw controller data structures.
Delivery proof:
- 5 configuration revisions were completed as the project moved from initial intake to final validation.
- 11.75 support hours were invested across configuration work, troubleshooting, and follow-up.
- 76 calendar days from kickoff to customer confirmation.
- 74% customer-side wait time, which means Chipkin stayed engaged through long testing and confirmation gaps instead of dropping the job after the first config delivery.
Before: Johnson Controls had Allen-Bradley PLC alarm data, but it was packed into DINT arrays and not ready for direct BACnet consumption inside Metasys.
After: The site had a validated Chipkin QuickServer exposing BACnet/IP points that the Metasys team confirmed were coming through smoothly.
“I was able to get everything talking on the Metasys side. The information seems to be coming through smoothly at this point.”
— Kevin Stewart, Building Automation, Johnson Controls
Have a Similar EtherNet/IP-to-BACnet/IP Project?
If you need Allen-Bradley or other EtherNet/IP data to land cleanly in a BACnet/IP BMS, Chipkin can scope the tag handling, map bit-level alarms, and deliver a gateway your BAS team can commission with less guesswork. Tell us about your project.