Overview
This guide covers the most common OPW gateway failures Chipkin is likely to see: conflicting RS-232 pinout guidance, incorrect assumptions about TLS-350 style compatibility, and projects that try to build a final map before tank and probe inventories are actually known. Use it with the OPW when exposing tank-gauge data into Modbus, BACnet, or a related fuel-management workflow.
Diagnostic Flow
- Confirm the exact OPW console model.
- Confirm the actual site wiring and serial settings.
- Confirm the source protocol or compatibility expectation.
- Confirm the tank, probe, and alarm inventory.
- Only then review target-side mapping.
Symptoms & Solutions
| Symptom | Likely Cause | Action | Related Page |
|---|---|---|---|
| The gateway never reaches stable communication | The serial pinout or RS-232 wiring assumption is wrong | Rebuild the wiring model from site-verified information | OPW |
| The team copied a Veeder Root-style template and nothing behaves correctly | The console is not behaving exactly like the assumed TLS-350 compatibility model | Reconfirm the source protocol expectation before more revisions | Veeder Root |
| Communications exist but there is no usable map | Tank, probe, or alarm inventory was never collected | Stop and gather the real point list before changing protocol settings | Modbus |
| The first deployment worked but phase two points are missing | New probes or sensors were added without a revised scope | Update the point inventory before diagnosing the gateway | OPW |
| Source-side values look reasonable but BAS values are wrong | The target-side presentation now needs review | Recheck BACnet or Modbus exposure after source validation | BACnet |
The Wiring Assumption Is Wrong
This is the first branch in most OPW failures.
Confirm The Physical Serial Path
Confirm:
- Pinout from the installed site
- Whether all required serial conductors are present
- Baud rate, data bits, stop bits, and parity
- Whether any adapter or converter is in the path
[!WARNING] Conflicting documentation is common on OPW projects. Trust site-verified wiring over a copied generic serial diagram, especially when the job depends on Integra 100 to TLS-350 style behavior.
The Console Compatibility Model Was Assumed
Many projects start with a template borrowed from another fuel-monitoring job.
Separate Similar From Equivalent
Look again at:
- Exact console model
- Claimed compatibility mode
- Existing site documentation
- Whether the live behavior matches the assumed data model
If the job was framed as generic Veeder Root, validate that assumption before deeper mapping work.
[!TIP] Partial similarity to Veeder Root is not the same as guaranteed protocol equivalence. Confirm the exact OPW model, wiring, and expected point families before copying a proven template.
The Point Inventory Was Never Final
Fuel-system jobs are often quoted before the final scope exists.
Rebuild The Real Tank Model
Confirm:
- Tank list
- Probe list
- Sensor list
- Alarm and event requirements
- Any later phase additions that changed the source scope
Quick Diagnostic Decision Tree
- Start by confirming the exact OPW console model.
- If that is unclear: stop and confirm it first.
- If it is clear: continue to wiring validation.
- Check whether the site wiring and serial settings are verified.
- If not: rebuild the serial path first.
- If yes: continue to protocol validation.
- Check whether the compatibility model is proven rather than assumed.
- If not: validate the source protocol expectation.
- If yes: continue to point inventory review.
- Check whether the tank, probe, and alarm inventory is complete.
- If not: collect it before more mapping work.
- If yes: continue to target-side validation.
- Check whether target-side values are still wrong after the source side is proven.