Loop Check vs Function Test: Troubleshooting Causes and Fixes

Feature graphic showing a signal path of seven boxes: field device, cable and junction box, marshalling panel, I/O card and HMI, logic and cause and effect, output and solenoid, and final element. A teal bracket over the first four is labelled loop check and asks whether the right value reaches the right tag in the right units. An amber bracket under the last three is labelled function test and asks whether the system does the right thing with the signal.

Feature image: a loop check proves the signal path; a function test proves what the system does with it. Conceptual illustration.

A loop check and a function test are two commissioning tests that are constantly mixed up, and the mix-up has a price. A loop check proves that a signal gets from a field device to the operator display (or from the controller out to a final element) correctly, on the right tag, in the right engineering units. A function test proves that the control and safety logic then does the right thing with those signals: that interlocks, permissives, voting, alarms and trips behave as specified. When either one fails, or when one is skipped and the other is asked to do its job, people lose days chasing a wiring fault that looks like a logic fault or a logic fault that looks like a wiring fault.

This guide shows how to troubleshoot loop check versus function test problems: how to tell which test a failure belongs to, the causes that show up most often in each, the tests that separate them, and the solutions that work. It includes a worked scaling fault, a voltage-headroom calculation, a response-time budget, a count of how many function tests a cause and effect matrix really needs, and an animation that runs a loop check and a function test side by side.

What you will be able to do after reading

State in one sentence what each test proves, and what it does not prove.
Place both tests, with calibration, point-to-point checks and acceptance tests, in the commissioning sequence.
Use the rule "find the first boundary where the value goes wrong" to separate wiring, configuration, logic and final element faults.
Diagnose the most common 4-20 mA loop check failures from the loop current, the raw input and the scaled display.
Diagnose function test failures: wrong or missing effects, unmarked effects, voting, delays, latches, forces and bypasses, fail position and response time.
Calculate what a mis-scaled range, a small current error and a long cable do to a reading, and what a response-time failure means.
Write records and closeout checks that keep the two tests distinct and auditable.

About the numbers. Definitions, procedures and symptom lists come from the cited sources and are labelled SOURCE. Worked examples use ILLUSTRATIVE inputs (a 0 to 10 bar transmitter, a 24 V loop, a 3.0 s response requirement and a 12-cause matrix) and CALCULATED results with the substitution shown. One example reuses a source's own numbers and I recomputed them. Nothing here is plant data, and none of it replaces your project test procedures, the cause and effect documentation or the safety validation plan.

Table of contents

The short answer: one proves the path, the other proves the behaviour
Where the two tests sit in the commissioning sequence
What a loop check proves, and what it leaves open
What a function test proves, and what it assumes
See the difference: the animation
Symptom to test to cause: the quick lookup table
How to troubleshoot a failed loop check
How to troubleshoot a failed function test
How the two tests interact: reading the combined result
Safety instrumented functions: loop check, validation and proof test are different
Records and evidence levels that keep the two tests distinct
Planning: how long does this take?
Prevention: how to avoid the failures in the first place
Common mistakes
Safety notes and limitations
Frequently asked questions
Conclusion: what to do next
Related reading on this site
Sources and further reading

The short answer: one proves the path, the other proves the behaviour

The cleanest statement in the sources is this one: a loop check proves the plumbing carries the signal, a functional test proves the system does the right thing with it, and loop checks are normally completed before functional testing (Merobix). A second source uses a nerve analogy: loop check is "is the nerve signal reaching the brain?" and functional test is "is the brain responding correctly to that signal?" (Automation Forum).

Table 1. Loop check versus function test (author synthesis of Merobix, Electric Neutron, PLCprogramming.io and Automation Forum)

Aspect	Loop check	Function test
Question answered	Does the right value arrive on the right tag, with the right scaling and units, or does the commanded output reach the right device?	Does the logic respond as specified: trips, interlocks, permissives, sequences, alarms and final element actions?
Typical failure points to	Wiring, termination, channel or tag mapping, polarity, range or scaling, power, shielding	Logic errors, wrong setpoint, voting, qualifiers (delay, latch, bypass), cause and effect mismatch, final element action
What it exercises	One signal path at a time, from field device to display or from controller to final element	Relationships between values and actions, per function or per specification requirement
Typical stimulus	Known current injected at the field end, or a real process variable applied at the sensor	Simulated or real process conditions that cross a trip or interlock condition
Record kept	Per loop: tag, cable, I/O address, readings at test points, punch items	Per function: expected result, observed result, pass or fail, timing where specified
Normally performed	After installation and termination; cold before the process, hot with the process	After loop checks; live confirmation once the process is introduced
Does not prove	That the logic makes a good decision with the value	That the wiring is right; a passing function test does not guarantee signal continuity or correct loop configuration

The last row is the one that matters most when troubleshooting. A function test assumes the signals it uses are already trustworthy, and a loop check does not care whether the logic is sensible. Each test is blind to the other's faults, which is why skipping either leaves a class of fault untested until a real demand finds it (Tagsight).

Where the two tests sit in the commissioning sequence

Projects use the names differently. PLCprogramming.io states this directly and recommends defining the test boundary, prerequisites and acceptance criteria in the commissioning plan so that "loop checked" has one meaning (PLCprogramming.io, Loop check procedure). The table below shows the commonly described order and what each step proves.

Table 2. Typical order of verification steps (author synthesis of Merobix, PLCprogramming.io, Instrumentation Blog; projects vary)

Step	What it proves	What it does not prove by itself
Calibration	The instrument itself reads accurately; done on the bench or in the field before loop checking begins (Instrumentation Blog)	That the signal reaches the control system correctly
Cable continuity and insulation	Conductor identity, continuity and insulation as applicable	I/O assignment, scaling or display
Point-to-point check	Each wire lands at the endpoints the drawing shows	Complete measurement or action
Cold loop check	The signal path, with an injected or simulated signal, while the process is offline	Behaviour under real process conditions; logic decisions
Function test	Logic, interlocks, permissives, sequences, alarms and final element actions	Wiring or configuration of the signals it relies on
Hot loop check and live confirmation	The loop under real process signals and dynamics	Long-term performance
FAT and SAT	FAT: system behaviour in a controlled pre-site environment. SAT: installed system behaviour at site	FAT does not prove installed field wiring and real utilities; SAT does not prove long-term performance

Merobix describes the order as point-to-point checkout, then cold loop checks, then functional tests on those trusted signals, then hot loop checks and live functional confirmation, and adds that each layer assumes the one beneath it is sound, so a functional test run before the loops are checked can waste hours chasing a wiring fault that masquerades as a logic problem (Merobix). A Saudi chapter of the Project Management Institute describes a similar gate on a major project: loop checks can only commence when the control system site acceptance test is complete, the loop folder is prepared and a pre-loop test is done; functional testing follows after loop checks complete, and one functional test folder may cover several loop folders because tests are grouped by subsystem or package (PMI Saudi Arabia chapter, Plant pre-commissioning).

Practical consequence. If a function test fails and you have not finished the loop checks for every signal it uses, stop and finish the loop checks. You cannot tell a logic fault from a wiring fault until the inputs are known to be good.

What a loop check proves, and what it leaves open

PLCprogramming.io defines a loop check as proof that a field input or output travels through the correct wiring, I/O channel, PLC logic, HMI or SCADA display, alarm or final element, and that the recorded values and actions match the approved design. It stresses that it is an end-to-end commissioning test, not merely a continuity check or a value forced inside the PLC, and that simulation inside the controller can test logic but cannot prove the field device, polarity, terminals or cable (PLCprogramming.io).

Calibration is not loop checking

The Instrumentation Blog separates them clearly: calibration adjusts the instrument itself to read accurately and is done before loop checking begins, while a loop check confirms that every component in the chain (field instrument, wiring, junction box, marshalling cabinet, I/O card and control system configuration) is connected, configured and displaying the right value in the right units (Instrumentation Blog, Instrument loop checking). A calibrated transmitter in a mis-scaled loop will still show the wrong number.

Cold and hot loop checks

Merobix describes a cold loop check as one done without the real process: a calibrator applies a current, a technician strokes a valve by hand, or a signal is forced at the transmitter, and the value is confirmed on the display. A hot loop check uses the real process signal once the plant is running (Merobix). The Instrumentation Blog treats insulation resistance below 1 megohm as a point to investigate during its cold checks (Instrumentation Blog).

Not all loop checks provide the same evidence

PLCprogramming.io makes a point that is easy to lose on a busy site: preferred proof starts at the sensing end, such as applying pressure to a pressure transmitter, and where a physical variable cannot be applied a calibrated current or voltage source can be used at an approved injection point. It then says to record whether the test is a complete sensor and measurement check or an electrical loop simulation, because they are different levels of evidence (PLCprogramming.io). A current-injection loop check proves the cable, channel and scaling, but not the sensing element or impulse line.

Table 3. Levels of loop check evidence (author synthesis from PLCprogramming.io)

Loop check evidence level	What it proves	What remains open
Current injected at the field terminals	Cable, junction box, marshalling, input channel, scaling, units, alarms at the display	The sensing element, impulse lines, transmitter output stage and range as the transmitter really behaves
Current injected at the junction box or marshalling	From that point to the display	Everything upstream, including field cable
Value forced in the controller	Display, scaling after the force point, alarms	Everything physical
Real stimulus at the sensor (pressure, temperature)	The whole measurement chain end to end	Behaviour under real process dynamics (hot check)

What a function test proves, and what it assumes

The Electric Neutron defines a function test as one that validates that the control logic and interlocks perform as expected in response to actual field conditions: process sequences, logic and safety interlocks work as intended, operating scenarios are validated, and final control elements actuate correctly (Electric Neutron). A project-management paper describes functional testing as conducted after loop checks to verify the integrity and functionality of the programmed logic and its display through the operator console graphics (PMI Saudi Arabia chapter).

The cause and effect matrix is the script

Tagsight describes the cause and effect matrix as the tabular document that defines the trip logic: causes in the rows, effects in the columns, with a mark at each intersection where a cause drives an effect. At factory acceptance the matrix is the test script. The witness forces each cause in turn and verifies three things: every marked effect actuates, every qualifier behaves as footnoted, and no unmarked effect actuates (Tagsight, Cause and effect matrix). That last point changes how a function test is run: an unmarked intersection that actuates is a failure exactly as a marked one that does not.

A second practitioner source says every interlock tag on the P&ID must appear as a cause and that alarms must be distinguished from trips (Front End Engineering, Cause and effect matrices). Mangan SIS publishes a validation checklist for the matrix, which is a useful starting point for building a function test script (Mangan SIS).

Qualifiers carry the real behaviour

The grid answers only whether a cause drives an effect. Tagsight lists the qualifiers that carry everything else: a time delay, a latched output that holds until a named manual reset, a bypassable cause under a maintenance override, a first-out capture of the initiating event in a cascade, and a permissive. Each of these needs its own test, because none of them is visible in the grid alone (Tagsight).

Table 4. What a function test checks and where failures point (SOURCE-informed: Tagsight, Automation Forum; synthesis)

Item to test	Typical function test check	A failure usually points to
Marked effect	The final element actuates when the cause is applied	Logic not programmed, wrong output assigned, wrong tag, final element fault
Unmarked effect	No other device actuates during the same cause	Extra logic, wrong cross-reference, copy and paste errors
Setpoint	Trip occurs at the specified value, with the specified direction	Wrong value or units in the program, wrong alarm limit, wrong range upstream
Voting	Single channel does not trip; the required number does; behaviour on a failed channel matches the specification	Voting configuration, channel mapping, degraded mode
Time delay	The delay is timed, starts on the correct trigger and the confirming device is read	Timer value, trigger or position switch mapping
Latch and reset	The trip holds until reset; the reset device is a tagged input	Latch not configured, self-resetting logic
Bypass or override	Allowed only for causes marked bypassable; indicated and logged; restored	Overrides in the program that the matrix does not show
Permissive	Start is blocked until conditions are met; behaviour once running matches the specification	Permissive logic wired as a trip, or a trip wired as a permissive
Final element	Reaches the safe state in the specified time and the specified direction	Positioner, air, solenoid, linkage, fail position, stroke time

Safety note. Function tests move valves, start motors and trip equipment. Use the permit, isolation and authorisation process, know which functions are safety instrumented functions, and know what is forced, bypassed or inhibited before you start. PLCprogramming.io says an ordinary loop sheet does not replace safety validation (PLCprogramming.io).

See the difference: the animation

The animation runs four scenes on one illustrative transmitter and one shutdown function. In scene 1 a healthy loop check injects 4, 12 and 20 mA at the transmitter and the value reaches the display correctly. In scene 2 the same 12 mA injection exposes a scaling fault: the display shows 10.0 bar where the datasheet range says 5.0 bar, and the first wrong value appears at the scaling block. Scenes 3 and 4 are a function test with a response time requirement of 3.0 s: the first run fails with a 2.6 s valve stroke, the second passes after the stroke is corrected to 1.8 s.

Animation in four scenes. Scene 1 injects 4, 12 and 20 milliamps at a transmitter and shows the value passing junction box, marshalling and input card to a correct display. Scene 2 injects 12 milliamps and shows the display reading 10 bar instead of 5 bar because the system range is 0 to 20 bar while the datasheet range is 0 to 10 bar, with the first wrong value at the scaling block. Scene 3 is a function test where a valve stroke of 2.6 seconds gives a 3.5 second response and fails a 3.0 second requirement. Scene 4 shows a corrected 1.8 second stroke giving 2.7 seconds and passing.

V01 (animated GIF): a loop check that finds a scaling fault, then a function test that finds a response-time fault. Illustrative values; not plant data.

The GIF contains no script and works anywhere an image does. If your reader shows a still frame, the table gives the numbers.

Table 5. The four animation scenes (ILLUSTRATIVE inputs, CALCULATED results)

Scene	Test	Observation	Verdict	First wrong boundary
1	Loop check, healthy	4.00, 12.00 and 20.00 mA injected; display 0.0, 5.0 and 10.0 bar	Pass	None
2	Loop check, scaling fault	12.00 mA injected; display 10.0 bar; expected 5.0 bar (system range 0 to 20 bar, datasheet 0 to 10 bar)	Fail	Scaling, after the raw value
3	Function test, as found	Trip simulated; stroke 2.6 s; total 3.5 s against 3.0 s	Fail by 0.5 s	Final element
4	Function test, after fix	Stroke 1.8 s; total 2.7 s against 3.0 s	Pass, margin 0.3 s	None

What the animation teaches

Percent can agree while units do not. At 12 mA the display read 50 % of its own span in scene 2, exactly as expected, but the engineering value was doubled. Check the engineering value against the datasheet range, not only the percentage.
The first wrong value is the fault boundary. The raw input was right and the scaled value was wrong, so the fault is in the scaling, not in the transmitter, cable or card.
A function test can fail with every signal healthy. Scene 3 passes every loop check boundary and still fails the specification because of timing in the final element.

Symptom to test to cause: the quick lookup table

Start here when something is wrong on site. The table maps what you see to the test that owns the fault, the most likely causes and the first check. It combines the symptom list in the PLCprogramming.io procedure (PLCprogramming.io), the common start-up problems listed by Automation Forum and the current bands given by Instranova and KKM Solutions. The mapping and the ordering of checks are my synthesis, not a standard.

Table 6. Symptom lookup (author synthesis of PLCprogramming.io, Automation Forum, Instranova and KKM Solutions)

Symptom	Owning test	Likely causes	First check
Display shows 0 mA or no reading when the field device is energised	Loop check	Open circuit, blown fuse, no loop supply, reversed polarity, open barrier	Measure loop current in series at the field end, then at the marshalling terminals
Loop current is correct but the raw value in the controller is wrong	Loop check	Wrong channel, wrong input module type, terminal or channel mapping error, card calibration	Compare the raw input against the measured current; check the channel address on the I/O list
Raw value is right but the scaled value is wrong	Loop check	Range, scaling, engineering unit or tag configuration	Compare the configured low and high range with the instrument datasheet
Percent of span is right but the engineering value is wrong	Loop check	Units or span configured differently from the instrument	Check configured units and URV against the datasheet (see the worked example below)
Display reads 0 % for a half-full tank (as reported by the source)	Loop check	Polarity swap at a marshalling panel	Check polarity at the termination points on both sides
Reading cannot reach 100 % or the high alarm current is not available	Loop check	Insufficient supply voltage for the loop resistance	Calculate voltage headroom: supply, transmitter minimum voltage, receiver, barrier and cable
Reading is noisy or jumps	Loop check	Loose terminals, shield not terminated correctly, interference, poor earthing	Inspect terminations and shield; check whether noise follows the cable route
Valve command is 60 % but feedback shows 35 % (as reported by the source)	Loop check, output side	Positioner, air supply, linkage, travel stops, scaling of feedback	Measure the output current, then check the positioner, air and linkage
Valve does not move although the controller output is correct	Loop check, output side	Output current not reaching the positioner, positioner or air fault, linkage	Measure the output current at the field end; then inspect the positioner and air supply
Alarm or trip does not occur when the signal crosses the setpoint	Function test	Setpoint not configured, logic not programmed, wrong tag, bypass or force in place	Check that the scaled value really crosses the setpoint; then inspect the logic and any forces
Trip occurs on the correct cause but the wrong equipment moves	Function test	Output mapped to the wrong tag, matrix and logic disagree	Compare the logic output with the matrix column and the I/O list
An unmarked effect actuates during a trip test	Function test	Extra logic, cross-reference error, copied logic	Search the logic for the actuated output and all its sources
Trip occurs on a single channel when two of three are required	Function test	Voting not configured, channel mapping, degraded-mode setting	Test each single channel and each pair as in the voting matrix below
Trip works but the plant restarts without a reset	Function test	Latch not configured, self-resetting logic	Check the latch and the tagged reset input
Valve closes but outside the required time	Function test, final element	Stroke time, solenoid, volume booster, air supply, positioner	Time each element and compare with the response time budget
Function test passes but a real demand later fails	Both, or neither was complete	Loop check skipped or done by simulation only, test did not cover qualifiers, final element not proven	Review the evidence level of each test record

Rule of thumb. The test that owns a fault is the one that can first see it. A wrong value on the right tag belongs to the loop check. The right value on the right tag producing the wrong action belongs to the function test. A right action that is too slow or in the wrong direction belongs to the final element.

How to troubleshoot a failed loop check

Find the first wrong value

The method that appears in several of the sources is the same: walk the signal path and stop at the first boundary where the value is wrong. ControlsCalc puts it plainly: find the first point in the signal path where the value becomes incorrect (ControlsCalc). PLCprogramming.io gives the boundaries to examine one at a time: field source, cable, input terminal, raw PLC value, scaled value, HMI value, alarm or event, and final effect (PLCprogramming.io). SEESII recommends capturing four observations at the same process condition: the process or transmitter value, the physical loop current, the raw controller input and the scaled display. V02 turns this into a flow.

Troubleshooting flow with three questions. Does the field signal reach the console on the right tag with the right value and units; if not, a loop check fault. Does the logic produce exactly the effects the cause and effect matrix specifies; if not, a function test fault. Does the final element move to the specified state inside the required time; if not, a final element fault. Below, eight boundaries checked in order: field source, cable, input terminal, raw value, scaled value, HMI value, alarm or trip, and final effect.

V02: a three-question flow and eight boundaries for finding the first wrong value. A heuristic drawn from published sources, not a standard.

Table 7. Boundaries to check, in order (SOURCE-informed: PLCprogramming.io, SEESII, ControlsCalc; author synthesis)

Boundary	What to measure	If it is wrong, suspect
1. Field source	Transmitter output current, device status	Transmitter configuration, supply, sensing element, local calibration
2. Cable and junction box	Loop current at the junction box terminals	Open circuit, polarity, wet junction box, loose terminals
3. Marshalling and barrier	Loop current and voltage at the marshalling terminals	Barrier, fuse, termination, cross-wiring
4. Input terminal	Current at the I/O terminals	Receiver resistor, wrong module or channel, short
5. Raw value	Raw counts or mA in the controller	Channel mapping, input card, input type
6. Scaled value	Engineering value against the formula	Range, scaling, unit configuration
7. HMI value	Graphic value against the controller tag	Display binding, wrong tag, display units
8. Alarm or event	Alarm limit, priority, annunciation	Alarm configuration, deadband, wrong tag
9. Final effect	Output current, positioner, valve position	Output card, positioner, air, linkage, travel stops

Measure the loop, do not trust the display. Instmates and SEESII both say to measure the current first and not rely on the control system value (InstMates, SEESII). Put the meter in series with the loop, and never place a current meter across a voltage source (KKM Solutions).

Read the current: what the mA value tells you

The loop current is the quickest discriminator. The bands below are described in two instrumentation troubleshooting guides and follow NAMUR NE43 style alarm levels, but the actual failure currents vary by manufacturer and configuration. Always read the device documentation (Instranova, KKM Solutions).

Table 8. Loop current bands (SOURCE: Instranova, KKM Solutions; manufacturer values differ)

Measured current	Typical meaning (SOURCE)	First action
0 mA	Open loop, no supply or reversed polarity	Check supply, fuse, polarity, continuity
Below 3.6 mA	Low failure indication	Read the transmitter diagnostics
3.8 to 4.0 mA	Low saturation (value at or below range minimum)	Compare with the real process condition
4 to 20 mA	Normal measurement range	Compare with the expected value for the stimulus
20.0 to 20.5 mA	High saturation (value at or above range maximum)	Compare with the real process condition
Above 21 mA	High failure indication	Read the transmitter diagnostics; check for short

Worked example: a scaling mismatch that passes the percentage check

A pressure transmitter is ranged 0 to 10 bar. The control system input is configured for 0 to 20 bar by mistake. The conversion from loop current to engineering value is the same in both places, only the range differs:

EV = LRV + ((I - 4) / 16) x (URV - LRV)

EV = engineering value; I = loop current in mA; LRV and URV = lower and upper range values (ControlsCalc)

Substituting, at 12 mA: the percent of span is (12 - 4) / 16 = 50 %. The instrument reads 0 + 0.5 x (10 - 0) = 5.0 bar. The control system displays 0 + 0.5 x (20 - 0) = 10.0 bar. Both are 50 % of their own span, which is why a check that only compares percent passes.

Table 9. Scaling mismatch, five test points (ILLUSTRATIVE inputs, CALCULATED values)

Injected current (mA)	Percent of span	Instrument range 0 to 10 bar (bar)	System range 0 to 20 bar (bar)	Error (bar)
4.0	0 %	0.0	0.0	0.0
8.0	25 %	2.5	5.0	2.5
12.0	50 %	5.0	10.0	5.0
16.0	75 %	7.5	15.0	7.5
20.0	100 %	10.0	20.0	10.0

The error grows with the signal: zero at 4 mA and 10.0 bar at 20 mA. A loop check that tested only 4 mA would have passed this fault. That is the reason the sources specify more than one test point: NFM Consulting tests at 4, 12 and 20 mA and also checks alarms and the behaviour on a wire break (NFM Consulting). Solution: correct the range in the system configuration to the datasheet values, record the change, and repeat the check at the same points. Do not trim the scaling to force a pass; PLCprogramming.io warns against undocumented scaling changes made only to get a result (PLCprogramming.io).

A source example I could not reproduce. One consulting guide gives an example of a 0 to 500 PSI transmitter and a system range of 0 to 1000 PSI and says the display "reads half" (NFM Consulting). Using the formula above, a larger configured range makes the display read double the true value, not half. The example looks reversed; the principle (a range mismatch shows as a consistent error) is correct.

How small a current error matters

A source on field versus control-room mismatches uses a flare flow transmitter ranged 0 to 150,000 kg/h with a lower range value of 0. At 6.00 mA the formula gives 18,750 kg/h, and at 5.99 mA it gives 18,656.25 kg/h, a difference of 93.75 kg/h for 0.01 mA, or 9,375 kg/h per mA (CALCULATED from the source range; Automation Forum). Wide ranges magnify small current errors. A reading that is a few tenths of a percent off may be a calibration or input card tolerance and not a wiring fault, so decide the acceptance tolerance before the test, not after.

Worked example: why a loop cannot reach 20 mA

A loop that reads correctly at 4 mA and 12 mA but flat-lines near 19 mA may be short of voltage. The supply requirement from Argatech is that supply voltage must be at least the transmitter minimum voltage plus the maximum current times the loop resistance. With ILLUSTRATIVE values:

V_supply = 24 V; transmitter minimum V_min = 12 V (ILLUSTRATIVE)

Receiver 250 ohm; barrier 300 ohm (ILLUSTRATIVE)

Cable: 2 km of 1.0 mm2 copper at 17.2 ohm per km per conductor, out and back: R_cable = 2 x 17.2 x 2.0 = 68.8 ohm

I_max = (24 - 12) / (250 + 300 + 68.8) = 19.39 mA

Percent of span at I_max = (19.39 - 4) / 16 = 96.2 %

The transmitter cannot go above 19.39 mA, so the display tops out at 96.2 % of span and a 22 mA alarm current could not be driven either (CALCULATED). The maximum cable resistance that still allows 20 mA is (24 - 12) / 0.020 - 550 = 50 ohm, about 1.45 km each way at the assumed resistivity. Solutions: a larger conductor, a higher supply voltage, a lower-resistance barrier or receiver, or a shorter run. Re-check the loop resistance whenever a device is added to the loop.

Limitation. Resistivity, minimum transmitter voltage and barrier resistance vary with the cable, device and barrier. Use the datasheet values for your loop.

Cause	Typical sign	Solution
Wrong I/O mapping or tag	Right signal appears at the wrong tag, or another loop changes	Verify against the I/O list; correct the address; re-test both loops
Polarity reversed	0 mA or 0 % reading (in one reported case a half-full tank showed 0 %)	Correct the polarity at the termination and document it
Range or unit mismatch	Consistent proportional error across the range	Align the range and units with the datasheet
Shield earthed at both ends	Noise or erratic readings (listed by NFM Consulting among common failures)	Terminate the shield at one end according to the project earthing design
Valve command and feedback disagree	60 % command with 35 % feedback in a reported example	Check positioner, air, linkage, travel stops and feedback scaling
Simulated test treated as full proof	Value forced in the controller; field wiring never exercised	Repeat with current injected at the field end or a real stimulus

A small script that locates the first wrong boundary

The following Python function encodes the method. It takes the measured loop current, the raw controller value, the scaled percent and the expected percent, and returns the boundary to investigate. It is an ILLUSTRATIVE aid for a commissioning log; the thresholds follow Table 8 and the tolerance is an assumption to set per project.

from operator import gt, lt

def classify(ma_meas, raw_ma, scaled_pct, expected_pct, tol=0.5):

"""Locate the first boundary where the value goes wrong."""

if lt(ma_meas, 3.6):

return "loop: open, unpowered or failed low (read device status)"

if gt(ma_meas, 21.0):

return "loop: short, saturated or failed high (read device status)"

if gt(abs(raw_ma - ma_meas), 0.05):

return "input channel, wiring or card calibration"

if gt(abs(scaled_pct - expected_pct), tol):

return "scaling, units or range configuration"

return "no fault found here; check display mapping, alarms and logic"

Run on the scaling example: classify(12.0, 12.0, 50.0, 50.0) returns the final line, because the percentage matches; the range mismatch needs the engineering value comparison in Table 9. This is why the record must hold the engineering value as well as the percentage.

How to troubleshoot a failed function test

Before troubleshooting a function test, confirm that the loop checks for every signal in the function are complete and recorded. The functional path described by Automation Forum has eight elements: the initiating instrument, the input signal, the alarm or trip condition, logic processing, permissives, voting logic, the final command and the final element response. A loop check covers the first two and the last two in part; the function test covers what lies between. Work from the first element that does not behave as specified.

A marked effect does not occur

Confirm the cause is actually applied. Read the scaled value in the logic and check that it crosses the setpoint in the correct direction. A mis-scaled input (see the worked example) can leave the trip condition untriggered.
Check that the logic exists. A reported compressor skid case had a trip that was never programmed, so the motor kept running when the condition was simulated (as reported by Automation Forum). A loop check could not have found it.
Look for forces, bypasses and inhibits. A bypass or override left in place blocks the effect. Use forcing only with permission and record what was forced (Automation Forum, logic check procedure).
Check output mapping. The logic may drive an output that is not wired to the intended device; this is also visible in the output loop check.
Check the final element. The command may be correct and the device may not respond: solenoid, air supply, positioner, actuator.

The wrong effect occurs, or an unmarked effect actuates

Because the matrix is the script, an actuated unmarked effect is a failure (Tagsight). Search the logic for the actuated output and trace all its sources. Typical causes are cross-references to the wrong tag, copied logic that still references the old equipment, and output logic that combines signals from two functions. Compare the logic and the matrix column by column. Where they disagree, Tagsight says the safety requirement specification governs, so the matrix, the logic or both must be corrected, not assumed to be right (Tagsight).

Trip direction and fail position

Tagsight notes that the action on the matrix has to match the valve fail position and the safe state in the design; a matrix that says close for a valve that fails open on loss of air has to be resolved before the test, not during it (Tagsight). During the test, confirm the direction of travel, the position feedback and the state on loss of signal.

Delay, latch, bypass and reset problems

Table 11. Qualifier tests and failures (SOURCE-informed: Tagsight; author synthesis)

Qualifier	Test	Typical failure	Solution
Time delay	Apply the cause; time the effect with a stopwatch or log	Timer value wrong, timer starts on the wrong trigger, timer confirms a feedback that is not mapped	Correct the value or trigger; re-time; check the position feedback loop check
Latch	Clear the cause; confirm the effect remains; operate the reset	Self-resetting output, reset not mapped	Add the latch; map the reset device; test the reset from a safe state
Bypass	Apply the bypass; apply the cause; confirm no effect; remove the bypass; confirm the cause now acts	Bypass not indicated, bypass on a cause that is not bypassable, bypass left active	Align with the matrix; add indication; add the restoration check to the closeout
First-out	Trigger a cascade; check the initiating event is captured	Wrong event captured or none	Review the first-out logic and the time resolution

Voting tests: single channel, pairs and degraded modes

Automation Forum gives the 2oo3 (two out of three) test as simulating the combinations AB, BC and CA, and tests that a single channel does not trip (Automation Forum). The table lists the six tests needed for each 2oo3 cause.

Table 12. Voting test matrix for a 2oo3 cause (SOURCE: Automation Forum for the combinations; test count CALCULATED)

Test	Channels in trip state	Expected result
1	A only	No trip
2	B only	No trip
3	C only	No trip
4	A and B	Trip
5	B and C	Trip
6	C and A	Trip

If the specification also defines behaviour when one channel is in fault or bypass, add those tests. Do not assume a degraded vote because the standard logic has one; test what the specification says.

Response time: where the seconds go

A function test often has a response time requirement from the specification. A response time budget adds up the time of each element. The following budget is ILLUSTRATIVE, with a 3.0 s requirement:

Table 13. Response time budget (ILLUSTRATIVE inputs, CALCULATED totals)

Element	Time (s)
Transmitter response incl. damping	0.5
Analog input filter	0.2
Logic solver, worst case two scans	0.2
Solenoid, actuator dead time and valve stroke (design)	1.8
Total, as designed	2.7
Margin to 3.0 s	0.3

As found, the valve path took 2.6 s instead of 1.8 s, so the total is 2.7 - 1.8 + 2.6 = 3.5 s, which fails the 3.0 s requirement by 0.5 s (CALCULATED). Nothing in the loop check would see this because the signal path was correct. Time each element separately to find the one that moved: a solenoid vent restriction, low air pressure, a sticking actuator or an incorrectly set speed control all lengthen the stroke. After the fix, repeat the timed test and record the measured value, not the calculated one.

How many function tests does a matrix really need?

A matrix grid of 12 causes and 6 effects has 72 intersections, of which 22 are marked and 50 are unmarked (ILLUSTRATIVE). It does not need 72 separate tests. Each trip test observes all effects at once, so one trip test per cause covers every intersection of that cause, marked and unmarked. The count rises where a cause has voting and where qualifiers exist:

Single-channel causes: 9 x 1 = 9 tests

2oo3 causes: 3 x 6 = 18 tests

Qualifier tests: delay 4 + latch 3 + bypass 2 + first-out 1 = 10

Total = 9 + 18 + 10 = 37 function tests

The numbers are ILLUSTRATIVE and CALCULATED, and a real project may need more (for example, tests under degraded conditions and for each operating mode). The point is that a function test plan should be built from the matrix and its qualifiers, and its size should be known before the test window opens.

How the two tests interact: reading the combined result

The two results together tell you where to look. The table gives the common combinations and what they usually mean (author synthesis).

Table 14. Combined results (author synthesis)

Loop check	Function test	Interpretation	Action
Pass	Pass	Signal path and logic both behave as specified, within the evidence level of each test	Record both; proceed to the next stage
Pass	Fail	Signals are trustworthy; the problem is in the logic, qualifiers, voting, final element or timing	Troubleshoot the function test starting at the first element that deviates
Fail	Not run	Do not start the function test	Fix and repeat the loop check first
Fail	Pass	Suspicious: the function test may have used simulated or forced inputs, or a different path	Check what the function test really exercised; repeat the loop check at the field end
Not run	Pass	Logic may be right, but wiring and scaling are unproven	Perform the loop check; do not close out on the function test alone
Pass (simulation only)	Pass	Field device, polarity or terminals not exercised	Repeat the loop check with a field-end stimulus or a real process variable

Three misdiagnoses to avoid

Chasing logic when the loop is wrong. The trip never occurs because the input was mis-scaled. The logic is correct; the value never reached the setpoint.
Chasing wiring when the logic is wrong. The channel was proven good but the trip was never programmed. A reported compressor skid case matches this pattern (as reported by Automation Forum).
Accepting a test that did not exercise the field. A forced value in the controller proves the display and the logic, not the cable or the device (PLCprogramming.io).

Safety instrumented functions: loop check, validation and proof test are different

For safety instrumented functions, a loop check and a function test are necessary but are only part of the evidence. Two practitioner sources explain that validation (confirming that the installed system meets its safety requirements, done before the system is put into service) differs from verification (checking each design step) and from proof testing (periodic tests during operation) (EHS Consulting Group, Mangan Software). Tagsight adds that the safety requirement specification governs where it disagrees with the matrix (Tagsight).

Table 15. Related but different activities (SOURCE-informed: EHS Consulting Group, Mangan Software; synthesis)

Activity	Question it answers	When
Loop check	Does each signal path work and show the right value?	Commissioning, before function tests
Function test	Does the logic do what the cause and effect matrix says?	Commissioning, after loop checks
Validation	Does the installed system meet the safety requirements?	Before the system is put into service
Proof test	Is the function still free of hidden dangerous failures?	Periodically during operation

The proof test interval, the performance calculation and the test coverage are separate subjects. See the related article on troubleshooting proof test interval and PFDavg for those. The standards themselves (IEC 61508 and IEC 61511) were not accessed for this article, and the statements above come from practitioner summaries; check the standard and your safety management procedures for the requirements that apply.

Records and evidence levels that keep the two tests distinct

The sources describe the records differently, so make the distinction explicit in the test sheet. Loop checks are recorded per loop; functional tests are recorded per function or specification requirement (Merobix). The PMI paper lists the contents of a loop folder: P&IDs, loop diagrams, calibration certificates, cable continuity records and a punch log (PMI Saudi Arabia chapter).

Table 16. Suggested record fields (author synthesis)

Record field	Loop check sheet	Function test sheet
Identifier	Tag, loop number, cable, I/O address	Function or matrix cause and effect reference, revision
Stimulus	Injected current or real variable; where applied	Cause applied; how (simulated, forced, real); permits
Evidence level	Field-end stimulus, injection point or force	Real signal, simulated signal or forced value
Expected and observed	Values at 4, 12 and 20 mA (and alarms)	Effects, qualifiers, timing, unmarked effects
Result and punch items	Pass, fail or conditional; punch list	Pass, fail or conditional; punch list
Restoration	Test equipment removed, simulation cleared	Forces, bypasses and inhibits removed and verified
Signatures	Tester, witness, date	Tester, witness, date

Planning: how long does this take?

The Instrumentation Blog budgets 20 to 25 loops per day for a two-person team (Instrumentation Blog). For an ILLUSTRATIVE project of 480 loops, that is 480 / 25 = 19.2 days to 480 / 20 = 24.0 days (CALCULATED). Function testing is planned from the matrix, not from the loop count (see the count of 37 tests above). Time lost to failed first attempts is not in the source rate, so add an allowance from your own experience; no figure is given here because none was verified.

Prevention: how to avoid the failures in the first place

Define in the commissioning plan what "loop check" and "function test" mean on this project, the boundaries, the prerequisites and the acceptance criteria (PLCprogramming.io).
Keep the instrument datasheet ranges in the same database as the control system configuration, and compare them automatically before the loop check.
Test at 4, 12 and 20 mA, and check the alarms and wire-break behaviour (NFM Consulting).
Calculate voltage headroom for long or heavily loaded loops before site work.
Build the function test script from the cause and effect matrix and its qualifiers, and include tests for unmarked effects (Tagsight).
Settle fail positions and safe states with the design team before the test.
Record the evidence level of every test and the forces and bypasses used.
Control scaling and logic changes during commissioning; do not make undocumented changes to force a pass.

Common mistakes

Table 17. Common mistakes (author synthesis)

Mistake	Why it hurts	Better practice
Testing only at one point	A scaling fault can pass at 4 mA	Test at 4, 12 and 20 mA at least
Comparing percentage only	A range mismatch can show the right percent	Compare the engineering value with the datasheet
Trusting the display	The display may be mis-scaled or mapped	Measure the loop current first
Forcing values in the controller and calling it a loop check	Field wiring never exercised	Record the evidence level; repeat with a field-end stimulus
Running function tests on unchecked loops	Wiring faults look like logic faults	Complete the loop checks first
Not testing unmarked effects	Extra actions remain hidden	Observe all effects for every cause
Testing a voted cause as a simple trip	Single-channel behaviour untested	Test each single channel and each pair
Leaving a force or bypass in place	Later demand does not act	Add a restoration check to the closeout
Not timing the final element	Response time failure hidden	Time each element and total
Changing scaling to get a pass	Hides the real fault, no traceability	Fix the cause; document the change

Safety notes and limitations

Standards not accessed. IEC 61508, IEC 61511 and other standards were not read for this article. I have not quoted clause numbers. Verify requirements against the standard and your project documents.
Source authority. Most of the sources are practitioner, integrator and vendor articles, not standards or regulator documents. Several belong to publishers that sell related products or services. Case studies are labelled as reported by the source and were not independently verified.
Illustrative numbers. The ranges, voltages, resistances, timings and the 12-cause matrix are assumptions, not plant data.
One source example could not be reproduced. See the 0 to 500 PSI example above.
Terminology varies. Projects define loop check, functional test, point-to-point and commissioning stages differently.
Visuals. The images are conceptual and illustrative and should be reviewed by a qualified instrument engineer before being used in training or procedures.
Working safely. Follow the permit to work, isolation, lockout and authorisation procedures when testing. Never place a current meter across a voltage source.

Frequently asked questions

What is the difference between a loop check and a function test?

A loop check proves that a signal travels correctly between a field device and the control system, on the right tag with the right scaling and units, or that an output command reaches the right final element. A function test proves that the control and safety logic responds as specified: interlocks, permissives, voting, alarms, trips and final element actions. Loop checks are normally completed first, because a function test relies on trustworthy signals.

Which comes first, the loop check or the function test?

In the sequence described by the cited sources, the loop check comes first, then the function test, then hot loop checks and live confirmation once the process is running. Running a function test before the loops are checked can waste time chasing a wiring fault that looks like a logic problem. Projects define the boundaries differently, so confirm the order in your commissioning plan.

If the function test passes, can I skip the loop check?

No. A function test checks logic, not wiring, so a passing function test does not prove signal continuity or correct loop configuration. A transmitter on the wrong channel, a polarity error or a wrong range can still be present. Equally, a loop check does not prove that the logic is correct.

Why does my display show the wrong engineering value when the percentage is correct?

The range or units configured in the control system differ from the instrument datasheet. In the worked example, a 0 to 10 bar transmitter is configured as 0 to 20 bar: at 12 mA both show 50 percent of span, but the instrument reads 5.0 bar and the system displays 10.0 bar. Compare the configured low and high range values and units with the datasheet, and test at more than one point.

How do I find where a loop check fails?

Walk the signal path and stop at the first wrong value. Measure the loop current in series, then compare the raw controller input and the scaled display at the same condition. If the current is wrong, the fault is in the field device, cable or supply. If the current is right and the raw value is wrong, it is the input channel or wiring. If the raw value is right and the scaled value is wrong, it is the scaling, units or range.

What does a 4 to 20 mA reading below 3.6 mA or above 21 mA mean?

In the cited troubleshooting guides, 0 mA indicates an open loop, no supply or reversed polarity, below 3.6 mA indicates a low failure condition, and above 21 mA indicates a high failure condition. These follow NAMUR NE43 style levels, but the exact failure currents vary by manufacturer, so check the device documentation.

How do I troubleshoot a function test where an unexpected device actuates?

Treat it as a failure: in a cause and effect test an unmarked effect that actuates is as much a failure as a marked effect that does not. Search the logic for the actuated output and trace all its sources. Look for cross-references to the wrong tag, copied logic and combined outputs, and compare the logic with the matrix. If they disagree, the safety requirement specification governs.

How many function tests does a cause and effect matrix need?

It depends on voting and qualifiers, not on the number of intersections. In the illustrative example, a matrix of 12 causes and 6 effects has 72 intersections but needs 37 tests: 9 single-channel trip tests, 18 tests for three 2oo3 causes (6 each), and 10 qualifier tests for delays, latches, bypasses and first-out. A real project may need more.

Does a loop check replace safety validation or proof testing?

No. A loop check confirms the signal path. Safety validation confirms that a safety instrumented system meets its safety requirements before it goes into service, and proof testing is a periodic test during operation that looks for hidden dangerous failures. The cited sources treat these as different activities, and an ordinary loop sheet does not replace safety validation.

Conclusion: what to do next

A loop check proves the path and a function test proves the behaviour. Troubleshooting both comes down to the same discipline: decide which test owns the fault, find the first boundary where the value or action is wrong, fix that boundary only, and repeat the test with the evidence level recorded. The scaling example showed a fault that passes a percentage check, the voltage example showed a loop that cannot reach 20 mA, and the timing example showed a function test failing with every signal healthy.

For your next commissioning job, write the definitions into the plan, test at 4, 12 and 20 mA, measure the loop current before reading the display, build the function test script from the matrix and its qualifiers, time the final elements, and close out forces and bypasses explicitly. Download the images, check the animation scene by scene against Table 5, and walk a real loop through the eight boundaries in Table 7.

Sources and further reading

Educational content. Product and company names appear only as sources. Not a substitute for the applicable standards, plant procedures or review by a qualified instrumentation and functional safety engineer.