Why a controller fault can be a support problem, not a broken board
An industrial robot controller rarely fails on a single, tidy date. What usually happens is subtler: the cell starts throwing intermittent alarms, a specific axis hesitates, a teach pendant reboots, and the same fault returns after every reset. Maintenance replaces a board, the fault disappears for three weeks, then returns. That pattern looks like electronics. Often it is a lifecycle issue, because the controller sits at the end of a chain that includes the drive modules, the safety interface, the fieldbus cards, the software version, the spare-part pool and the licence archive.
This guide treats lifecycle exposure as a diagnostic hypothesis in its own right, sitting beside the usual causes. The question is not only what failed but can this configuration still be supported, and does the evidence you hold actually describe it. Work through the symptom groups below, keep the checks inside the safe envelope described, and use the decision points to decide whether you repair, replace or escalate.
Symptoms that point toward support exposure
No single symptom proves a lifecycle problem. The combination does. Look for faults that behave in these ways:
- Recurrence after replacement. A module is swapped and the same alarm code returns within weeks, often on a different station or shift.
- Version-dependent behaviour. The fault appears on one controller in the line but not another with a visually identical cabinet, or appears after a firmware or software update.
- Safety-channel asymmetry. One protective stop channel, door circuit or enabling-device path shows a different response time or a sporadic discrepancy while the mechanical hardware looks intact.
- Configuration drift. A restored or reloaded backup brings back some functions but not others, or the machine runs differently after a restore than it did before the fault.
- Documentation gaps. The spare fitted is a later revision than the drawing, the parameter file predates the last cell change, or the only copy of the program is inside the controller.
- Parts latency. The same consumable or module now takes noticeably longer to obtain, or arrives as a repaired exchange unit rather than an identical new part.
If two or more of these appear together, treat lifecycle exposure as a leading hypothesis before spending further money on component-level substitution.
1. Establish what version of the machine you are actually diagnosing
Nothing else is reliable until the baseline is fixed. Before any intervention, record from the controller itself rather than from memory or from the project folder:
- Controller model and full type designation as printed on the nameplate, including option codes.
- Serial number of the controller and of the manipulator, kept separately; they age independently and are serviced as separate items.
- Robot software and firmware versions, plus the version of any safety or motion option pack.
- Drive and module revisions currently installed, matched against the as-built drawing.
- Fieldbus and safety interface configuration, including network node names and addresses.
- The date and source of the last verified backup, and where the copy is stored outside the cabinet.
Where the nameplate disagrees with the drawings, the nameplate wins and the drawings are corrected. A controller whose recorded identity is wrong will keep producing faults that look inexplicable, because every subsequent check is aimed at the wrong machine.
2. Separate safety-channel faults from process faults
Safety-path symptoms deserve their own track. A protective stop that releases slowly, an enabling device that needs a firmer press, a door channel that intermittently reports open, or a discrepancy between two redundant channels are not faults to be worked around. They are conditions that must be corrected or escalated.
The safe approach is to observe and document, not to defeat:
- Read the safety status and diagnostic buffer through the controller's own interface; do not bridge, jumper or force a safety input to keep production running.
- Record the exact timestamp, alarm text, active channel and machine state for each event, and photograph the alarm screen if the log rotates.
- Check whether the event correlates with a specific program state, a manual-mode action, a door cycle or a payload change.
- Confirm that the safety configuration on the controller matches the validated drawing, and that no one has edited it since the last sign-off.
Escalate immediately if a safety function has been bypassed, if a guard interlock can be satisfied by hand, if protective-stop response differs between channels, or if the safety configuration has been changed without a documented re-validation. Do not resume automatic operation to "see whether it comes back".
3. Test the backup and restore chain before you need it
For many sites, the single most consequential lifecycle fault is a backup that exists but cannot be restored. This fails quietly for years and surfaces on the worst possible day.
A workable check, done in a planned window with the cell in a safe state and the program and configuration archived first:
- Confirm the archive was taken from this controller, not from a sister machine, and note its version stamp.
- Verify the archive opens in the vendor's offline tooling and that the program structure, I/O mapping and safety configuration are present.
- On a spare or offline controller of the same type where available, perform a test restore and compare the resulting configuration against the as-built record.
- Record who holds the media, where the second copy lives, and how often it is refreshed. A backup held on one laptop in one technician's bag is not a backup.
If a restore produces a machine that runs but behaves differently, for example different tool frames, altered zone limits, a missing option or a different fieldbus mapping, the archive is incomplete or was taken after undocumented changes. Correct the record before the next intervention, not after it.
4. Judge parts and support status from evidence, not from age alone
The age of a controller tells you very little on its own. Some platforms stay in service for decades with strong parts support; others lose option-level support long before the cabinet looks old. Vendors speak in terms of product availability, exchange and repair programmes and regional stock, and those statements are usually general rather than a promise about one specific part number.
What you can establish locally, and should:
- Ask for the specific part, not the policy. Enquire about the exact module, option card or pendant revision you hold, with its part number and revision letter, and record the answer and the date.
- Log lead times over time. A rising trend in quoted lead time for the same part is a leading indicator, well before any formal notice.
- Note what arrives. If replacements now come as repaired exchange units where new parts used to be supplied, the support route has changed and your spares strategy should change with it.
- Watch the software side. Operating-system versions, programming tools and licence mechanisms age faster than mechanics; an unsupported engineering tool can block you from diagnosing a perfectly healthy controller.
- Keep licences and keys recoverable. Store licence files, activation records and vendor account details with the backup, under the same access control.
Treat vendor figures on stock availability or service coverage as general marketing statements with unstated scope, and never quote them to justify deferring a replacement decision. A documented answer about your part number is worth more than any published percentage.
5. Build a decision point, not a repair loop
After the checks above, the fault should land in one of four places. Decide explicitly and write the decision down:
- Repair. The cause is identified, the part is available at acceptable lead time, the configuration is documented and the safety chain is verified. Repair, then re-verify the safety functions and the restore chain.
- Contain. The cause is understood but the fix is scheduled. Define the interim control: reduced duty, additional inspection, restricted mode, a named person responsible and an expiry date for the workaround.
- Replace or migrate. Parts latency, tool obsolescence or configuration risk is high enough that further fault-chasing costs more than planned replacement. Start the migration plan while the machine still runs, not after it stops.
- Escalate. Safety function integrity is in doubt, the configuration cannot be verified, or the same fault has returned after two documented repair attempts on the same root cause.
Two failed repair attempts on the same underlying cause is a reasonable trigger to stop substituting parts. At that point the productive question is whether the design, the version or the support chain, rather than the component, is at fault.
What to record during the investigation
Keep a single lifecycle record per controller, updated whenever anything changes. It should hold the nameplate data and serial numbers, software and option versions, module revisions, the safety configuration reference and its validation date, backup locations and last verified restore, the part numbers with quoted lead times and dates of enquiry, licence and key storage, and every decision with its owner and date.
This record is what converts a recurring alarm into a managed risk. Without it, each new fault is diagnosed from scratch and each new technician repeats the same substitutions. With it, the second occurrence of a fault is already halfway to a decision, and the escalation threshold is written down before anyone is under production pressure to cut a corner.