Excellent PLC
By Michael Grant – DCS & Industrial Communications Specialist
RS485 rarely fails dramatically.
No smoke. No alarms. No red lights.
It just… stops talking.
That’s exactly what happened with a Honeywell 07191/1/1 RS485 communication board on a mature control system that had been running quietly for years.
How the Problem First Appeared
Operators didn’t report a communication failure.
They reported “frozen values.”
-
Process data stopped updating
-
No bad-quality flags
-
No DCS communication alarms
-
Field devices still powered and active
From the operator’s point of view, the system looked alive — just stuck in time.
System Context
-
Honeywell DCS with multiple serial field devices
-
RS485 multidrop network
-
07191/1/1 acting as the primary communication interface
-
Network length close to design limits
-
System expanded several times over the years
No recent configuration changes. No firmware updates. Just gradual network growth.
First-Level Checks (And Why They Didn’t Help)
We checked the usual suspects:
-
RS485 baud rate – correct
-
Device addressing – unchanged
-
Termination resistors – present
-
Power supply – stable
Everything looked fine.
And yet, no data movement.
This is where RS485 problems get frustrating — because static checks often pass.
What Gave It Away
We connected a protocol analyzer to the RS485 trunk.
What we saw was telling:
-
The 07191/1/1 board was transmitting
-
Field devices were attempting to respond
-
Responses were colliding and corrupting
-
No clean reply frames reached the DCS
In short: communication existed, but it was unusable.
Root Cause
Over time, additional devices had been added to the RS485 network without adjusting:
-
Line biasing
-
Termination strategy
-
Cable routing
The result was a marginal RS485 bus, operating just inside failure conditions.
Under light load, it worked.
Under normal load, it collapsed.
The 07191/1/1 RS485 board wasn’t defective — it was being asked to drive a network that exceeded its stable operating envelope.
Why No Alarm Was Generated
This is important.
RS485 is not Ethernet.
There is no handshake. No session state.
From the DCS point of view:
-
Frames were sent successfully
-
No hardware fault occurred
-
The board remained operational
The failure happened between bits, not at the board level.
Corrective Actions
We addressed the issue in layers:
Physical layer fixes
-
Re-segmented the RS485 network
-
Reduced node count per segment
-
Improved cable shielding and routing
-
Corrected termination placement
Timing adjustments
DCS-side handling
After these changes, communication stabilized immediately.
Validation
-
Continuous polling for 72 hours
-
No dropped frames
-
No frozen values
-
Stable update intervals
The same 07191/1/1 board that “failed” before now ran without a single issue.
Key Lessons from This Failure
-
RS485 networks degrade quietly
-
Communication boards are often blamed for network design problems
-
“No alarm” does not mean “no fault”
-
Network expansion without revalidation is a long-term risk
Final Thought
The Honeywell 07191/1/1 RS485 communication board did exactly what it was designed to do.
The mistake was assuming the network around it would remain healthy forever.
In serial communication, stability is not guaranteed — it must be maintained.
— Michael Grant