A government engineering team needed to retire an older CAS-2700 gateway and move a Hobart HPG integration onto QuickServer. Chipkin combined a custom HPG driver with hands-on serial troubleshooting to recover live Hobart data and expose it to a downstream Modbus RTU client.
The job was not a standard protocol conversion with a mature public driver stack. It involved legacy Hobart equipment, a migration away from an older gateway already familiar to the site, and a serial path that looked correct on paper but kept failing in practice. The result was a project where the breakthrough depended as much on reproducing the physical issue as on translating the protocol.
At a Glance
- Industry: Government / industrial equipment support
- Customer: Government engineering team
- Facility type: Legacy equipment monitoring environment
- Client role: Engineering lead replacing an obsolete gateway workflow
- Protocols: From: Hobart HPG → To: Modbus RTU
- Chipkin product: Chipkin QuickServer CAS-2220 / FS-QS-2X10
- Project start: May 2022
Hobart MCP board → Hobart HPG serial data → Chipkin QuickServer → Modbus RTU → customer monitoring client
Hobart HPG to Modbus RTU Challenge
The upstream/server side was a Hobart MCP board using the Hobart HPG protocol over a fragile serial connection. The downstream/client side needed a stable Modbus RTU presentation that could replace an older CAS-2700 workflow already known at the site. That meant Chipkin had to do more than translate points. The team had to replace a legacy operational pattern the customer already trusted.
The first complication was that this was a custom-driver job. There was no plug-and-play public Hobart HPG workflow that the customer could configure alone. Chipkin had to build and support the custom driver, answer basic migration questions, and help the site understand where the live values now appeared inside QuickServer. In the old setup, the customer was used to browsing a familiar status page. In the QuickServer workflow, the live values had to be checked through the DA_Data array and corresponding Modbus presentation.
The second complication was more stubborn: the gateway would connect, but the live Hobart values were still not behaving consistently. The customer reported that all of the fields are still zero in DA_Data, even with the hardware connected. That is exactly the kind of symptom that can waste days if the team treats it as a pure configuration problem when the real fault lives in the physical layer.
Why Chipkin
This project was a good fit for Chipkin because it required both custom protocol work and field-grade troubleshooting discipline. A generic gateway vendor could have supplied hardware, but the hard part here was the combination of a custom Hobart HPG driver, the need to preserve a legacy integration outcome, and the serial-layer debugging required to prove why the data stayed at zero.
Chipkin support did not stop at sending a file. The team clarified how the customer should read the mapped Modbus side, pushed for diagnostics when the live data stayed blank, and reproduced the same behavior on a Hobart test setup. That reproduction step mattered. It turned the troubleshooting from speculation into a specific explanation the customer could act on.
The Solution
Chipkin first delivered the custom HPG driver and mapped the Hobart-side values so they could be exposed through Modbus RTU. The support thread then shifted into commissioning mode. The customer asked where the live values should appear, Chipkin pointed them to the DA_Data array and the correct Modbus register access pattern, and the team used that as the primary validation surface instead of relying on the older CAS-2700 status-page habit.
When the live values still stayed at zero, Chipkin escalated the debugging properly. Peter Chipkin asked for diagnostics, reproduced the same symptoms on a Hobart test rig, and then identified the decisive issue: the Hobart RS-232 connection was mechanically unreliable. In Peter’s words, I think there is something mechanically wrong with the rs232 port on the Hobart. Its behaviour changes depending on how I seat the connector.
That insight changed the whole direction of the job. Instead of endlessly reworking the logical mapping, Chipkin treated the connection as intermittent hardware behavior. Peter then sent an updated firmware and config pair, rev726aC and rev200, so the customer could retest with the improved debug path and known-good configuration.
Legacy Gateway Replacement Results
The project achieved a working Hobart HPG to Modbus RTU handoff without replacing the underlying Hobart equipment.
Project proof points:
- A custom Hobart HPG driver made the QuickServer migration possible in the first place.
- The real blocking issue was reproduced and isolated to intermittent serial-port seating on the Hobart side.
- Updated firmware and config gave the customer a clear retest path after the physical-layer issue was identified.
- The last working configuration was archived for future support and repeatability.
Most importantly, the customer confirmed that the updated setup was no longer stuck at zero-value troubleshooting. After the firmware and config change, the external engineering lead reported:
“With the updated Firmware and the config file, we were able to get the full data from the Hobart within 10 to 20 seconds. That is a big step forward.”
— Engineering lead, government equipment integration team
Have a Similar Legacy Serial Migration?
Need to replace an aging gateway without replacing the legacy device it talks to? Chipkin can help with custom protocol support, serial troubleshooting, and QuickServer delivery that preserves the downstream protocol handoff your team already depends on. Tell us about your project.