IO-Link Process Data: Read Value Status and Diagnostic Events Together
ifm distinguishes cyclic, acyclic and event data, with actual fields defined by the device description. Individual interfaces can also define special process codes. The application needs value and state interpretation together rather than treating every received integer as an ordinary valid measurement.
List value and state sources
Map process values, master validity, device status and events, identifying how each is updated. An absence of events does not establish universal value validity. A healthy communication exchange likewise does not establish that the physical measurement is inside its normal usable range.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Handle special codes before scaling
Use the specific device description to identify NoData, overload and other reserved codes before engineering-unit conversion. Do not display a scaled abnormal code as a large ordinary measurement or replace every exceptional case with zero, which removes the evidence needed to interpret the condition.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Define distinct application outcomes
Specify display and retention for valid zero, out-of-range, unavailable device and interrupted link. Downstream algorithms need to know whether input is usable. Collapsing all cases into no object or failed inspection conceals the origin and can mislead both operators and later analysis.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Join events and recovery
Retain event appearance, acknowledgement and disappearance beside process-value quality. Define when the first recovered data becomes trustworthy. An empty event list does not alone establish that the displayed value comes from a new valid measurement rather than retained earlier data.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver normal and abnormal comparisons
Use identified-state samples to review display, logs and downstream results, retaining raw fields. Review device, mapping or state-parser changes. The receiver should be able to trace an application result to both value and quality rather than inheriting only a final decision without its input trust boundary.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.