ifm AL1432 Process Data: A Valid PQI Does Not Prove the EtherCAT Path Is Live

A PLC must not accept an AL1432 input merely because its saved Port
Qualifier Information indicates valid data. The product manual
explicitly warns that PQI can still indicate validity when the EtherCAT
connection is interrupted. The application’s acceptance decision needs
evidence from the upstream transport as well as the IO-Link port.

This analysis uses AL1432 manual 11489157/02, February 2024, and
Beckhoff’s EtherCAT master diagnostics. It concerns process-data
validity, not a certified safety function or a measured detection
time.

Original two-boundary validity model. No bus interruption or PLC test
was performed.

Identify what each
observation covers

The AL1432 manual asks the user to evaluate PQI for the cyclic
process data, then separately requires a means to detect EtherCAT
interruption. Those instructions are complementary. A status associated
with an IO-Link port cannot, by itself, establish that the PLC has just
received that status over a healthy upstream path. AL1432
manual, section 9.2.7

Imagine a harmless test value that remains unchanged while
communication is lost. The PLC’s numeric variable can look identical
before and after the loss. Its last observed PQI can also look
acceptable. A display comparing only the payload with its previous value
cannot distinguish a steady process from missing updates.

Conversely, changing payload bits are not a general validity test. A
noisy or invalid source can change continuously. Preserve source
qualification and transport qualification as different inputs to the
acceptance decision.

Use the master’s cycle
evidence

Beckhoff documents cycle-related master diagnostics such as DevState
and the working-counter state variables associated with cyclic frames.
Its working-counter explanation states that a datagram is not
trustworthy when the expected processing is incomplete; the master
discards that datagram’s input data. EtherCAT
master diagnostics and Sync Unit assignment

Map the diagnostics applicable to the actual project into the
consuming logic. Do not choose a convenient frame-state variable without
establishing that it covers the AL1432 data being consumed. Multiple
frames and configured grouping can make that association
significant.

A useful application rule is: accept a newly received value only when
its transport evidence is acceptable and its relevant port qualification
is acceptable. Define startup and recovery explicitly so an old buffer
is not promoted to a new valid observation merely because one
communication indicator returned to normal.

This is a proposed application contract. The cited manuals do not
supply a universal PLC function block or timeout value that can be
copied into every installation.

Diagnose the two
failure locations separately

Use an approved isolated fixture to compare a port-side fault with an
upstream EtherCAT interruption. In the first case, the bus may still
deliver current diagnostic information about an unavailable or invalid
IO-Link source. In the second, the application must recognize that it
lacks current transport evidence, regardless of the previously received
port status.

Record the consumer’s payload, qualification decision and relevant
transport state together. This makes the acceptance behavior reviewable
even when the payload deliberately stays constant throughout the
test.

After recovery, require the product’s defined fresh-data acceptance
condition. Do not erase the invalid interval from a trend or historian
just because a later value happens to equal the earlier one. Downstream
systems should receive the distinction between “same observed value” and
“no accepted new observation.”

Keep
output behavior outside the input-quality assumption

AL1432 section 9.2.5 separately states that its port outputs do not
have a failsafe function and describes retaining the last output values,
marked invalid, when EtherCAT is interrupted. An invalid input flag is
therefore not evidence that actuators have entered the machine’s
required safe state.

Output fault response needs the machine’s separately qualified
control and safety design. Do not infer it from PQI, a link LED or an
input-data rejection rule. The result of this review is narrower: an
input consumer that does not mistake stale, apparently valid port data
for a live EtherCAT observation.