Excellent PLC
By Steven Patel – Control System Architecture Consultant
Communication modules usually fail for obvious reasons: power loss, wiring damage, configuration errors.
The Honeywell 10008/2/U communication module in this case failed for a different reason.
It failed because the system grew.
Original System Design
-
Honeywell control system with centralized communication architecture
-
10008/2/U used as the primary communication interface
-
Stable traffic, predictable polling cycles
-
Adequate bandwidth margin
For years, the module operated without a single issue.
What Changed
Over time, the plant expanded:
-
Additional remote I/O stations
-
New third-party analyzers
-
Extra diagnostic polling enabled
-
Higher data refresh expectations
No hardware was replaced.
No firmware was upgraded.
The communication module remained the same.
First Signs of Trouble
-
Data update latency increased gradually
-
Some remote points updated slower than others
-
Occasional communication timeouts
-
No module fault alarms
From the operator’s perspective, the system still worked — just not consistently.
Why the 10008/2/U Looked Guilty
The communication module became the visible bottleneck:
-
All traffic passed through it
-
All delays appeared downstream of it
-
Operators blamed the hardware
But the module wasn’t defective.
It was overloaded.
Root Cause: Bandwidth Saturation
The Honeywell 10008/2/U was operating near its maximum effective throughput:
-
Increased polling density reduced response margin
-
Retries accumulated during peak traffic
-
Time-critical data competed with low-priority diagnostics
-
Queueing delays compounded under load
The system crossed a threshold where latency, not data loss, became the dominant failure mode.
Why No Alarms Were Triggered
Most communication diagnostics monitor:
-
Link up/down status
-
Frame errors
-
Physical layer faults
They do not monitor saturation.
From the module’s perspective:
-
Communication was active
-
Frames were transmitted
-
Responses were eventually received
Nothing violated hardware rules.
How We Confirmed It
We reduced non-essential polling temporarily:
Immediate result:
-
Latency dropped
-
Timeouts disappeared
-
System responsiveness improved
That test isolated the issue to traffic load, not hardware integrity.
Corrective Actions
Architectural changes
-
Segmented communication paths
-
Distributed load across additional communication modules
-
Prioritized time-critical data
Configuration optimization
Operational discipline
-
Communication load reviewed before every system expansion
-
Bandwidth margin documented as a design parameter
Outcome
-
Same 10008/2/U module remained in service
-
Communication stability restored
-
Predictable update timing achieved
-
No further unexplained delays
The fix was architectural, not mechanical.
Key Takeaways
-
Communication modules don’t scale automatically
-
Latency is a failure mode, even without data loss
-
Expansion without revalidation creates invisible risks
-
Saturation failures look like hardware problems — until you zoom out
Final Reflection
The Honeywell 10008/2/U communication module didn’t fail electrically.
It failed as a design assumption.
In control systems, capacity is not infinite — it is borrowed from the future until expansion demands it back.
— Steven Patel