Line down in Utah? Call us.
Troubleshooting is a different discipline from programming. It is mostly about eliminating possibilities in the right order, quickly, without breaking something else while you look.
Being local matters more for troubleshooting than for any other kind of work. A remote session can resolve a great deal, but when the fault is a loose terminal or a sensor that only fails when a conveyor is loaded, somebody has to be standing there with a meter.
From Centerville we can reach most of the Wasatch Front quickly. Before that, though, we will usually try to solve it on the phone, because a surprising proportion of downtime calls are resolved by asking the right three questions.
Bring us the fault code, when it started and what changed around that time. Those three things eliminate more possibilities than any amount of on site inspection.
Before you call
- The exact fault code, not a description of it
- When it started and what changed around then
- Whether it is constant or intermittent
- Photos of the processor, drive display and panel
- The PLC program and drawings if you have them
- Whether remote access is possible under your IT policy
What this involves.
Processor & I/O faults
Module errors, channels that read wrong and processors that will not go into run.
Communication failures
Dropped EtherNet/IP connections, Modbus timeouts and networks that fail only when a particular machine runs.
Intermittent downtime
The hardest category, solved with logging and correlation rather than inspection.
Tell us the fault code.
Call (801) 946-2710, Monday, Friday, 8:00am, 4:30pm MT. Often the phone call is enough.
Or call (801) 946-2710, Monday, Friday, 8:00am, 4:30pm MT