FROM SYMPTOM TO ROOT CAUSE

Fault diagnostics for industrial equipment

A fault appears in one place. Its cause may be somewhere else entirely.

I investigate PLCs, signals, drives, industrial communication and electrical systems together to identify the actual cause and help restore operation.

Describe the fault Real diagnostic cases

01 / 08

SYMPTOMMotor will not start

SignalsConditionsRoot cause

Technical illustration. Actual signal paths and the order of checks depend on the equipment.

Follow the signal. Find the interruption.

The investigation includes the conditions upstream of the visible fault, from sensors and logic through commands to the drive and its feedback.

01Sensor
02PLC input
03Logic / interlock
04Command
05Industrial network
06Drive
07Motor
08Feedback

CAUSE FOUND IN THIS EXAMPLE

Feedback signal missing

In this illustration the command gets through, but the expected confirmation is absent. Why that feedback is missing on a real machine still needs to be established.

Not checkedBeing checkedDeviationCause located

Technical illustration. Actual signal paths and the order of checks depend on the equipment.

Try a diagnostic example

The motor will not start. See how checking its conditions narrows the investigation.

DEMONSTRATIONPLC → DRIVE → MOTOR

MOTOR WILL NOT START

01Start command✓ Present
02PLC interlocks✓ Permitted
03Drive communication✓ Working
04Drive ready✕ No

Enable JavaScript to run the example. In this scenario the command and communication are present, but drive readiness is missing.

Ready to check

Signal monitor

DEMO / 01

START_REQUESTNot checked

SAFETY_OKNot checked

AUTO_MODENot checked

DRIVE_READYNot checked

MOTOR_FEEDBACKNot checked

Every state is simulated. The checks do not change protective functions.

AREA FOR FURTHER INVESTIGATION FOUND

Drive is not ready to start

This does not yet mean the inverter is defective. The next investigation concerns its messages, supply, readiness conditions and related signals. A real diagnosis requires real data.

This demonstration illustrates the principle of fault finding. It is not connected to real equipment.

One symptom. Many possible causes.

SYMPTOM

Motor will not start

Select a possible area to investigate

Is the required state present, and does the signal reflect the actual process?

Which controller state and program section generate the command?

Which process condition required for starting is not satisfied?

What state does the safety system report? Its protective functions remain in place.

Does the command reach the participant, and does current data return?

Is the drive ready, and what diagnostic messages are recorded?

Do the supply, circuit diagram and electrical feedback agree?

Could the cause involve load, movement or the mechanism's condition?

Diagnostics starts with the chain of conditions. A stationary motor does not by itself establish a motor defect.

What is happening to your equipment?

The symptom defines the starting point. The actual machine determines the required checks.

Equipment will not start

Start request, operating mode, permits, equipment readiness and feedback are compared.

Unexpected stops

Events before the stop, signal-chain states and process conditions are investigated.

An intermittent fault

Event timing, signal changes, communication and load are compared.

Drive trips

Drive messages, supply, motor, load and communication with the controller are analysed.

PLC in STOP / ERROR

The diagnostic buffer, hardware configuration and circumstances of the state transition are reviewed.

HMI cannot reach the PLC

The connection, addressing, data-exchange configuration and participant states are examined.

PROFINET / PROFIBUS / Modbus error

The interruption is traced to a participant, connection, supply, configuration or data exchange.

Equipment fails after a repair

Recent changes are compared with the circuit diagram, signals and starting conditions.

No start after a component replacement

Compatibility, configuration, signal assignment and feedback are investigated.

Unknown reason for a stop

Observations and messages are collected first, then hypotheses are checked systematically.

Where could the problem be?

Reliable fault finding does not automatically stop at PLC code. A program condition may reflect the actual state of another part of the machine.

AREA TO
INVESTIGATE

Load, movement and the mechanism's actual condition.

Supply, switching devices and electrical feedback.

Process signals and the behaviour of field devices.

Readiness, diagnostics, motor and operating conditions.

States, commands, permits and process interlocks.

PROFINET, PROFIBUS, Modbus, CAN and consistent data exchange.

Messages, displayed values and the connection to the PLC.

The cause was somewhere else.

CASE 008 / SCHNEIDER PACDRIVE

One month stopped. One incorrect feedback signal.

Original equipment photograph · Case 008 · Enlarge photo ↗

A Schneider PacDrive packaging machine would not start after a servo drive replacement. The customer and electricians had investigated for about a month; the manufacturer had connected remotely twice.

Investigation: Real signals, interlocks and PLC logic analysed and compared with the circuit diagram and contactor feedback.
Cause: Incorrect electrical feedback in the circuit of relay KA20, which had previously been replaced.
Result: After the connection was corrected, the alarm disappeared and the machine started. No further replacement of working components was needed.

Read the full case

≈ 1 monthstopped before diagnosis

≈ 2 hoursdiagnosis in this case

100%remote work

Two hours is this project's result, not a promised diagnosis time for every fault.

CASE 004

Rapida 75 / CAN Bus

The communication error persisted despite component replacements. Investigation led to the main drive's communication board. Restoring its contacts allowed the machine to run again.

Read the full case ↗

CASE 002

Siemens S7-414 / Prisma / OPC

Commands from an old visualization system no longer reached the line. Analysing the PLC, OPC and SCADA restored communication and production.

Read the full case ↗

How I investigate a fault

Every hypothesis must survive a check. If the data does not support it, the investigation returns to the facts before changing code or replacing a component.

TEST THE
HYPOTHESIS

01
Symptom
Understand the behaviour, timing and whether the fault can be reproduced.
02
Facts
Record messages, changes and the sequence of events.
03
Signals
Trace requests, commands and feedback.
04
Conditions
Examine the permits and interlocks that govern operation.
05
Logic
Compare the program, configuration and process state.
06
Equipment
Check the hypothesis against the actual hardware condition.
07
Confirmation
Confirm the cause, agree on the correction and verify the result.

Keep working components.
Confirm the cause first.

Randomly replacing parts can extend downtime. First establish which condition is missing and where the logical or physical chain breaks.

A fault message is information.

Codes and messages are a starting point, but not always a full explanation. A drive fault may require investigation of several related areas.

The message shows where the investigation starts. Not necessarily where it ends.

Drive faultDEMONSTRATION

MotorSupplyOverloadCommunicationEnable conditionsProcess

Remote or on site?

The approach depends on data access and the checks required. Remote diagnostics and a technician at the machine can complement each other.

Remote

PLC, HMI or drive accessible online
Agreed remote access available
Documentation available
A local technician can carry out necessary checks

On site

Measurements at the equipment are needed
Wiring requires investigation
Sensors, hardware or mechanics need inspection
No suitable remote connection exists

Remote support

What helps before diagnostics?

Photo of the message
Equipment type / nameplate
Short description
When the fault occurs
Recent changes
Circuit diagram
PLC / HMI project
Video of the behaviour
Available remote access

Missing some of this? No problem.

We can first discuss the situation even with limited information. Start with what you already know.

Questions about fault diagnostics

Is the error code enough for a diagnosis?

A code helps choose where to investigate. Confirming a cause usually requires context, actual signals and equipment information.

Can we start without the PLC project?

Yes. We can first discuss the symptoms and available data. Access to the project and documentation determines how far the subsequent analysis can go.

Is an on-site visit always necessary?

No. Suitable remote access and local assistance allow many checks to be performed remotely. Measurements or hardware inspection may require an on-site visit.

How long does fault finding take?

It depends on complexity, reproducibility, access and the available information. A result from one case is not a time guarantee for another installation.