A line is down. Let us find out why.
Troubleshooting is a different discipline from programming. It is mostly about eliminating possibilities in the right order, quickly, without breaking anything else while you look.
The fault is usually not where the fault code says.
A drive reporting an overcurrent fault is telling you what it measured, not what caused it. A PLC showing a module fault may be reporting a backplane problem, a power supply that sags under load, or a terminal that vibrated loose eight months ago.
We work outward from the symptom methodically: what changed, what is common to the failures, what the historian recorded in the seconds before, and what can be eliminated cheaply. Intermittent faults in particular are almost always solved by data rather than by inspection.
Where the system has any logging at all, that is where we start. Where it has none, adding temporary logging is frequently faster than continuing to guess.
What helps us help you faster
- The exact fault code, not a description of it
- When it started and what changed around that time
- Whether it is constant or intermittent
- Photos of the processor, drive display and panel
- The PLC program and electrical drawings if you have them
- Remote access, if your IT policy allows it
What we troubleshoot.
Some of these are ten minute phone calls. Others are two days with a scope and a lot of patience.
Processor & module faults
Fault codes, major and minor faults, module errors and processors that will not go into run.
I/O problems
Inputs that read wrong, outputs that do not drive, analogue scaling errors and channels that fail only when something nearby starts.
Communication failures
Dropped Ethernet/IP connections, Modbus timeouts, duplicate addresses and networks that work until a particular machine runs.
Field devices
Sensors, transmitters, encoders and valves, deciding whether the device, the wiring or the logic is at fault.
Drive & motor faults
VFD trips, overcurrent and overvoltage faults, and mechanical problems presenting as electrical ones.
Intermittent downtime
The hardest category. Usually solved with logging, timestamps and correlation rather than inspection.
How a troubleshooting call goes.
Phone call
Symptom, fault code, timeline and what changed. Often this alone identifies the likely cause, or at least eliminates half the possibilities.
Remote look
Where access allows, we go online with the processor, check I/O status and review whatever history exists.
On site if needed
Meters, drawings and the actual panel. Most faults that survive remote diagnosis are physical.
Fix and verify
Repair, then run it enough to be confident. An intermittent fault that has not recurred in ten minutes has not been proven fixed.
Tell you the cause
Not just what we did, why it happened, and what would stop it happening again.
Answers before you call.
For remote support, usually the same business day, often within a couple of hours. On site response along the Wasatch Front is typically next day. Elsewhere in the country it depends on flights, and we will give you a realistic answer rather than an optimistic one.
Frequently. If we can get a VPN or remote session onto the network, we can read the processor, check I/O and look at the historian. Even without remote access, photographs of the fault display and a description of the sequence often narrow it substantially.
That describes most troubleshooting calls. We will need the source code or the ability to go online with the processor; without one of those we are limited to electrical fault finding.
Yes. That is common enough that we have a separate page about it, because the constraints are different when there is no vendor to escalate to.
The fault code or symptom, when it started, what changed around then, and whether it is constant or intermittent. If you have the program and drawings, send them.
Line down? Call us.
(801) 946-2710 during business hours. Tell us the fault code and what changed.
Or call (801) 946-2710, Monday, Friday, 8:00am, 4:30pm MT