Fault-Finding Workflows: Evidence, Timing and Root Causes

Fault-finding workflows help you choose the next useful observation, explain what it means and leave a record another technician can follow. They do not guarantee a root cause within thirty minutes. An intermittent fault may require a suitable capture setup, a particular operating condition or a longer observation period before the evidence distinguishes the remaining explanations.

This guide uses a fictional signal-path worksheet, a short-pulse sampling example and a declared filter model. They are learning exercises, not reports from South African customer plants or instructions to reproduce a hazardous machine failure. Start with PLC troubleshooting training for the broader relationship between commands, feedback, data quality and diagnostics.

Define the problem before choosing the tool

Write the symptom in observable terms. “The conveyor is faulty” is too broad. “The program's Ready input changed from true to false while the operator expected the loading station to remain ready” gives you a signal and an expectation to investigate. Record how you observed the transition, rather than silently assuming that an HMI graphic is the raw terminal signal.

Capture equipment identity, program revision, time, operating mode, product or recipe, current diagnostics and the last known good condition. Mark statements from an operator interview as reported observations. They are valuable evidence, but a remembered twenty-minute interval is not the same measurement as a timestamped event record.

Define the boundary of the task. You might be investigating why a displayed value went stale, why an input changed, why an output command was absent or why commanded equipment did not move. Each problem has a different path through the system. A communication investigation can use PLC network troubleshooting checks; a tag-display investigation can start with HMI binding and data-quality checks.

A useful initial result can be a narrower problem statement. If you discover that only the HMI value is stale while the controller's current value is valid, you have changed the next action even if you have not yet identified the failed configuration. Progress means reducing justified uncertainty, not merely replacing something visible.

A repeatable workflow with evidence at each step

Use the following sequence as a review structure. Return to an earlier step when new evidence contradicts an assumption. The sequence is not a requirement to make a running machine fail again before you are allowed to investigate it.

Step	Question	Record to keep
Define	What differed from the intended behaviour?	Symptom, scope and expected result
Preserve	What evidence might disappear after a reset?	Logs, configuration and observations
Observe	Can the available instruments see the event?	Capture method and its limitations
Distinguish	Which test separates plausible explanations?	Predictions for each hypothesis
Evaluate	What did the observation support or contradict?	Result and remaining uncertainty
Verify	Did the authorised correction meet its criteria?	Retest conditions and follow-up

Use time boxes for communication and reassessment, not as promises of diagnosis. After an initial review interval, report what is known, what remains uncertain and what evidence is needed next. If the fault has not occurred during the observation window, say so. Do not record “passed” when the triggering condition was never exercised.

For physical equipment, follow the site's operating, isolation and maintenance procedures. Simulation is a useful place to practise controlled changes. A production stop, protective trip or uncertain machine state changes what can safely be reproduced. A workflow should help a technician recognise that boundary, rather than reward a fast restart regardless of evidence.

02

Worked signal-path worksheet: separate five possible causes

Consider a deliberately simplified virtual path with four Boolean observations. S is a source signal, T is the signal after a wire, I is the input-channel value, and P is the program's mapped value. In the healthy exercise all four are true. The exercise has no timers, communication delays, quality failures or other logic between these points.

Assume observations are accurate, simultaneous and taken while the same condition persists. Define five hypothetical fault models. A source fault makes S false. An open path makes T false while S stays true. A channel fault makes I false while T stays true. A mapping fault makes P false while I stays true. A shared-supply fault makes both the source and downstream values false.

These models are intentionally limited. They let you practise deduction without suggesting that every physical PLC fault belongs to one of five complete categories.

Worksheet condition	S	T	I	P
Healthy	1	1	1	1
Source fault	0	0	0	0
Open path	1	0	0	0
Channel fault	1	1	0	0
Mapping fault	1	1	1	0
Shared-supply fault	0	0	0	0

Start with the observation P = 0. Every listed fault still fits. A false program value alone does not locate the fault. Observe I = 0 next: this contradicts the particular mapping-only fault model, which predicts I remains true. It does not contradict the source, open-path, channel or shared-supply models.

Now observe T = 0. The channel-only model predicts T remains true, so it no longer fits. Source, open path and shared supply remain possible. Finally, observe S = 1. Only the open-path model matches all four observations in this worksheet.

The conclusion must include its scope: “The observations identify the open-path case among the declared models.” In a real installation, additional explanations, measurement errors, shared references and changing states may remain. A useful diagnostic report names those limits instead of converting a classroom result into universal proof.

There is also an important ambiguity. If S, T, I and P are all zero, both the source-fault and shared-supply models fit exactly. Re-reading the same four values cannot distinguish them. You need a different observation whose predictions differ, such as an appropriate independent supply observation in a correctly designed lab.

03

What bisection and channel swaps can actually establish

Bisection means choosing an intermediate observation that splits a plausible fault path. It works well in the worksheet because the path, expected state and fault models are declared. In a real control system, shared supplies, feedback, parallel paths and changing conditions can invalidate a simple “upstream versus downstream” split.

Suppose a fault remains after a signal is moved to another channel on the same module in an authorised isolated exercise. That result may weaken a hypothesis about the original individual channel. It does not eliminate shared module circuitry, the common reference, a supply issue, configuration applied to both channels or the program consuming the input.

Record precisely what changed. Moving a wire and changing the program mapping are two modifications, even if they belong to one planned comparison. A connector may also be disturbed, the controller restarted or the operating state changed. Those effects matter when interpreting a fault that disappears temporarily.

A useful comparison includes a prediction before the change. For example: “If only channel A is faulty, with all relevant conditions held equivalent, moving the same signal to verified channel B should change the result.” Then document whether the assumed equivalence was achieved. Avoid writing “module ruled out” when the test addressed only one narrower model.

Do not assume that the last component replaced caused the problem. It is a sensible place to look for configuration or installation differences, but chronology is not proof. Equally, do not discard it merely to avoid that bias. Keep competing explanations until the evidence distinguishes them.

Why a one-second trend can miss an 80 ms input drop

Define an ideal source that is normally true and becomes false from 430 ms inclusive to 510 ms exclusive. Its low interval lasts 80 ms. A logger taking instantaneous samples at 0, 1000 and 2000 ms records true at all three times. The event happened entirely between samples.

Move the same 80 ms interval to 970–1050 ms. The logger now records false at 1000 ms. That observation establishes a low value at one sample time. It does not establish that the event lasted 80 ms, nor reveal the exact start and end. Different short and long intervals can produce the same three saved samples.

Low interval	Samples at 0, 1000, 2000 ms	What the record establishes
430–510 ms	True, true, true	No low value was sampled
970–1050 ms	True, false, true	A low value was sampled at 1000 ms
500–1500 ms	True, false, true	The same sample pattern despite a different duration

Now use ideal instantaneous samples every 20 ms for the original 430–510 ms event. Around the transition, the record is true at 420, false at 440, 460, 480 and 500, then true at 520. Under the single-contiguous-pulse assumption, the falling transition occurred after 420 and no later than 440; the rising transition occurred after 500 and no later than 520.

Those observations bound the duration to greater than 60 ms and less than 100 ms. They still do not measure exactly 80 ms. The exact duration is known here because we defined the source. A real capture must also account for timestamp resolution, sample timing, acquisition behaviour and any filtering before the observed tag.

A clean rectangular trend does not establish whether the original cause was electrical interference, mechanical motion, a software assignment or display processing. That shape may be a consequence of sampling and rendering. Use PLC scan-cycle timing examples to separate physical input changes, program observations and a slower display.

04

Match measurement capability to the question

Before choosing a meter or logger, state what you need to observe: a steady potential difference, a minimum value, a short transient, an event sequence or a relationship between two signals. A tool that answers one question may provide insufficient evidence for another.

Fluke's fast and peak min/max explanation distinguishes specialised capture modes from ordinary readings and identifies differences between instrument models. Check the actual model, function, response specification and recorded information. Do not assume that every handheld meter captures the same pulse durations or retains the same timestamps.

A minimum reading alone also lacks context. Record the measurement points, reference, range, mode, start and finish times and operating condition. If probes were connected or disconnected while recording, consider whether those actions affected the recorded extrema. Preserve the original data as well as a cropped screenshot.

When comparing devices with separate clocks, record their synchronisation and uncertainty. A switch event timestamp that appears 30 ms before a controller event is not reliable evidence of order if the clock relationship is unknown. Even accurately ordered events require a causal explanation: the earlier event may be a consequence of another shared cause.

Input filtering: a declared model, not a universal repair

Filtering changes which transitions reach the program and when they arrive. It must be understood as part of the application's timing requirements. Making a nuisance indication disappear does not establish that the underlying condition has been corrected.

For a separate mathematical exercise, define an ideal continuous-stability filter. The output begins true. A changed input must remain at its new level for 50 ms before the output adopts that level. Returning to the current output level before 50 ms cancels the pending transition. Apply the same rule in both directions. The chosen 50 ms is a worksheet parameter, not a recommended hardware setting. Evaluate this model once per millisecond, reading the current input before considering a pending transition. If the input returns to the existing output level exactly at the deadline, cancellation wins. Otherwise accept a pending change when its elapsed time reaches 50 ms.

If the raw input becomes false at 100 ms and returns true at 140 ms, the 40 ms low interval never reaches the threshold. The filtered output remains true. If the raw input instead remains false until 180 ms, the filtered output becomes false at 150 ms and returns true at 230 ms. The 80 ms event is delayed; it is not removed by this model's 50 ms threshold.

Time	Raw input for the 80 ms case	Filtered output
0 ms	True	True
100 ms	False	True
149 ms	False	True
150 ms	False	False
180 ms	True	False
229 ms	True	False
230 ms	True	True

Real input filters need their own documentation. Siemens describes an accumulating up/down filter for the cited S7-1200 digital input configuration, including behaviour when pulses alternate. That is not identical to our continuous-stability rule for every input history. The documented available settings also differ from our arbitrary worksheet value.

Rockwell's 1756 input-filter configuration guidance notes that configured filter times exclude other delays, including input-circuit and switching-device effects. A complete response-time assessment therefore requires more than reading one parameter. Do not alter a protective function or mask a trip to obtain a cleaner trend.

05

From a supported cause to corrective action and verification

Separate immediate restoration, the mechanism supported by evidence and the conditions that allowed it to arise. A component replacement may restore operation without establishing why the component failed. A wiring discrepancy may explain the measured symptom while leaving an unresolved documentation or modification-control issue.

The US Department of Energy's archived root cause analysis guidance is a reference for causal analysis and corrective-action thinking. It is not presented here as a South African PLC certification requirement. Apply a level of investigation proportionate to the issue and your organisation's process.

For a fictional software lab, suppose an incorrect mapping is identified by comparing the configured tag with the declared I/O worksheet. The proposed correction is a specific mapping change. Before applying it, preserve the original configuration and define a retest: independently toggle the intended and adjacent virtual inputs, verify only the intended tag follows, then repeat after the documented restart procedure.

A passing retest supports that correction under the tested conditions. It does not establish immunity to unrelated intermittent failures. If the original problem appeared only in one recipe or operating mode, include that condition. If it appeared after a long run, a short idle test provides weak evidence about recurrence.

Keep temporary restoration and permanent corrective action as separate records when they are different. Record the owner, outstanding work and review conditions. Avoid calling the investigation closed simply because an alarm has not reappeared during an unspecified period.

Write a handover another technician can use

A good handover allows someone else to continue from the evidence. Include the current machine or lab state, modifications still applied, the exact observation method, results and unresolved hypotheses. State which tests were not performed and why their evidence is still missing.

For the virtual path worksheet, a useful entry is: “P=0 and I=0 observed simultaneously in worksheet version A. Mapping-only case contradicted; source, open path, channel and shared-supply cases remain. Next observation is T, whose predicted value separates the channel case.” That record is more useful than “checked inputs, probably wiring”.

Keep reported symptoms, measured facts and interpretations distinguishable. If a later measurement contradicts the preferred explanation, update the conclusion without deleting the earlier record. The change in interpretation is part of the investigation, not something to hide from the next shift.

06

Practise fault-finding workflows in a virtual lab

Use the virtual multimeter learning environment to practise selecting voltage or continuity mode and choosing two virtual probe points. The reviewed implementation calculates readings from its circuit model. It does not establish physical probe technique, transient bandwidth, insulation condition or competence for live electrical testing.

For each exercise, predict the result before probing. Explain what the reading would support and what it would leave unresolved. The introductory meter lesson explicitly distinguishes a potential difference at the chosen points from proof that the PLC program is running or reading an input correctly.

Then use PLC program testing with expected results for the software part of the investigation. Keep the signal-path and timing worksheets in this guide separate unless your chosen scenario implements those exact rules. Do not describe them as a built-in menu of physical EMI or thermal faults.

Questions for South African fault-finding training

Which course suits a maintenance electrician or millwright?

Ask for the actual equipment, prerequisites and assessed tasks. A Johannesburg, Durban, Cape Town or online course should explain whether learners investigate wiring models, PLC logic, networks or physical measurement problems. Compare the electrician learning route with the millwright training route, then choose the gap that matches your work.

Can a short course guarantee faster breakdown diagnosis?

It can provide practice and assessment, but a fixed repair-time promise ignores fault frequency, access, documentation and measurement limits. Ask whether the assessment rewards accurate scope, sound predictions, preserved evidence and recognition of uncertainty. Those outcomes are more informative than a generic “find any fault in thirty minutes” claim.

What should I submit as evidence of troubleshooting ability?

Submit a problem statement, hypothesis table, capture settings, expected-versus-observed results and a justified next action. Include one case that remains ambiguous and explain what additional evidence would distinguish it. A portfolio that recognises its limits demonstrates more useful reasoning than a polished report that claims every observation proves a root cause.