Excellent PLC
By Leo Martins – OT Network Engineer
I spent two days blaming a processor that wasn’t guilty.
The Triconex 3101 main processor module looked like it was randomly dropping communication.
Random, intermittent, impossible to pin down.
The kind of problem that eats weekends.
It turned out the CPU was fine.
The network around it wasn’t.
What the Operators Saw
-
HMI showed brief communication dropouts
-
Control logic never tripped
-
Safety functions remained intact
-
Logs pointed fingers at the CPU
The 3101 became the suspect simply because it was the “brain.”
What the Network Was Actually Doing
-
Old unmanaged switches in the cabinet
-
Occasional broadcast storms from legacy devices
-
Buffer overruns during traffic bursts
-
Momentary packet loss on the CPU interface
To the network, this was noise.
To the monitoring software, it looked like the processor had gone silent.
How We Cornered the Real Problem
Once we watched the packets, the story changed.
The CPU never stopped talking.
The switch stopped listening.
Why the 3101 Looked Guilty
-
Safety CPUs are conservative with network retries
-
Missed packets trigger brief communication resets
-
Monitoring tools interpret resets as module failure
In reality, the processor was being cautious, not unstable.
Fixes That Actually Worked
-
Replaced unmanaged switches with industrial-grade units
-
Segmented control traffic from noisy legacy devices
-
Added basic QoS to critical communication paths
-
Updated monitoring thresholds to ignore sub-second gaps
After that, the “CPU problem” vanished overnight.
A Small Reminder
In distributed control systems, the weakest link is rarely the processor.
It’s usually the forgotten piece of infrastructure nobody has touched in ten years.
Final Note
The Triconex 3101 didn’t drop off the network.
It was drowned out.
When diagnosing CPU “failures,” always listen to the network first.
— Leo Martins