Resolving LIOLlink_Diagnose FB Busy State on Siemens CM 4xIO-Link

Problem Overview

When a Siemens ET 200SP CM 4xIO-Link communication module (6ES7 137-6BD00-0BA0) is connected to a Festo solenoid valve manifold and the LIOLlink_Diagnose function block is executed from the IO-Link Function Block Library, two failure modes appear repeatedly in field reports:

1. The FB stays in the BUSY state indefinitely and never asserts DONE or ERROR.
2. The FB returns DONE but the diagnostic buffer (DIAG) is empty; pulling the manifold from the IO-Link port produces no status code, no error flag, and no event change in the HMI alarm list.

Both symptoms are almost always caused by the same root cause: the REQ input on the FB is not edge-triggered, so the request is continuously re-asserted on every OB1 cycle. The IO-Link master interprets this as a never-ending diagnostic request and the busy state never clears. The second symptom is a side effect: when the FB cannot reissue a request, it cannot re-poll the port, so a disconnect that occurs after the first successful read is never observed in the cached DIAG buffer.

This article walks through the proper way to call the LIOLlink_Diagnose FB, including the full interface, the meaning of cap = 227, the diagnostic data structure returned, the reason a held REQ input hangs the block, the code patterns that fix it, and the commissioning checks that prove the link is healthy. Reference material is drawn from the Siemens application document IO-Link Diagnostics and the IO-Link technology primer Understanding how IO-Link works published by IFM.

CM 4xIO-Link Module Technical Specifications

The CM 4xIO-Link (Siemens part number 6ES7 137-6BD00-0BA0) is a SIMATIC ET 200SP communication module that provides four independent IO-Link master ports (channels 0 to 3), each conforming to the Single-Drop Digital Communication Interface (SDCI) standard IEC 61131-9. The module is plugged into a TM-E or TM-P terminal module on an ET 200SP station, headed by an interface module such as the IM 155-6 PN HF.

For the product-specific manual and firmware download, search the article number 6ES7 137-6BD00-0BA0 on the Siemens Industry Online Support portal at support.industry.siemens.com. The manual lists the diagnostic interrupt mapping and the supported IODD descriptors. The IO-Link diagnostics document 109772813 is the primary engineering reference for the LIOLlink_Diagnose FB itself.

IO-Link Diagnostic Architecture

IO-Link is a point-to-point serial protocol that runs on top of a standard 3-wire sensor cable. The master (the CM 4xIO-Link) handles all electrical, timing, and message-layer concerns, while the device (the Festo MPA-S, VTSA, or VTOC manifold) exchanges cyclic process data and acyclic service data with the PLC. The diagnostic model is layered into four levels, each addressed by a different part of the IO-Link stack:

1. Port-level diagnostic. The master reports whether a device is connected, whether the port is shorted, whether the supply voltage is present, and whether the most recent frame had a checksum error. This data is always available, even when no LIOLlink_Diagnose request is in flight.
2. Master-level diagnostic. The master aggregates port status into a port-qualifier byte (0x00 = no device, 0x01 = device present and OK, 0x02 = device present but not yet ready, 0x03 = device error, 0x04 = port reserved).
3. Device-level diagnostic (events). The device can push asynchronous events to the master. Each event contains a 16-bit event code, an event qualifier (notification, warning, or error), and a vendor-specific payload. The Festo manifold uses events to report undervoltage, coil short, or communication timeout.
4. Identification and parameter data. Reading IODD-defined parameters (Vendor Name, Product Name, Function Tag, cycle time, revision). These are read with READ_REQ and stored in the diagnostic structure.

The LIOLlink_Diagnose FB addresses levels 2, 3, and 4. It does not read process data; that is the job of LIOLink_Master or the cyclic IO data update. The architectural placement of the FB and its relationship to the master is shown in the IFM primer Understanding how IO-Link works, which also describes the role of the IODD as the device description file.

LIOLlink_Diagnose FB Interface Definition

The FB is delivered as part of the Siemens "IO-Link Function Block Library" (the global library that ships with TIA Portal V15 and later). The current block is LIOLlink_Diagnose V2.x and can be called from OB1, OB82, or a cyclic interrupt OB. The block is multi-instance capable and re-entrancy-safe inside one CPU.

Input parameters

Output parameters

Capability codes (CAP parameter)

The capability selector tells the FB which section of the master/device diagnostic memory to retrieve. The most relevant codes for IO-Link V1.1 devices (such as the Festo manifolds that ship with the Festo IODD V1.1) are:

The value 227 (0xE3) is the most useful for engineers who want to see the full state of the IO-Link link in a single read. It returns the MasterDiagnosticData, the PortStatus, the LastEvent with timestamp, and the DeviceStatus, packed into the DIAG output structure. This is the capability the original question asked about and the capability that produces the largest single-call data set.

STATUS code reference

Always record the last non-zero STATUS value to a non-volatile data block so the HMI can display the master error code when a fault occurs. The Siemens IO-Link Diagnostics document 109772813 contains the full STATUS reference.

Root Cause: Why the FB Stays Busy

The most common reason for an FB stuck on Busy is the request input being held high. The IO-Link FB family implements a non-reentrant request model: while BUSY is true, the FB ignores further REQ pulses. If the calling code asserts REQ = 1 on every scan while the FB is busy, the FB continues to process the first request, then sees that REQ is still high and starts a second request immediately. The master returns a "busy, request in progress" status (typically STATUS = 16#0000_0001) until the cycle is complete, and the user sees a permanent BUSY.

The reason REQ ends up held high is almost always one of these:

1. The REQ input is wired directly to a level-driven flag such as a function-key input, an HMI tag that is set in one screen and only reset in another, or a tag that is written from a recipe and never cleared.
2. The REQ input is wired to the output of another FB that never resets (e.g., a comparison that stays true).
3. The developer is using a "trigger coil" in ladder logic that stays on for more than one OB1 cycle because the rung is not pulsed by a clock generator.

The same root cause also explains why no status code is reported when the manifold is disconnected. The FB can only re-poll the port when it sees a fresh REQ edge. As long as REQ is held high, the FB will issue exactly one diagnostic read and then sit in the "request already running" state. When the cable is pulled, the port status byte changes from 1 to 0, but the FB never gets a chance to read it again, because it is still serving its original (held) request.

Step-by-Step: Proper FB Execution Flow

The correct call pattern for LIOLlink_Diagnose on the CM 4xIO-Link is:

1. Build the hardware identifier (LADDR) for the CM 4xIO-Link module from the TIA Portal device configuration. This is the same value used as the input on LIOLink_Master; the system constants view exposes it under the slot's HW identifier.
2. Set CAP = 227 (0xE3) for a full diagnostic block.
3. Set PORT to the physical port number (0 to 3) on the module that the Festo manifold is wired to.
4. On the rising edge of a one-second heartbeat (or an operator trigger), set REQ = TRUE for exactly one OB1 cycle. Use an R_TRIG instance in SCL or a --|P|-- contact in ladder.
5. Monitor DONE, ERROR, BUSY, and STATUS. On the first cycle where any of these go true (DONE, ERROR, or BUSY), record the values. This is the "edge capture" step.
6. After DONE or ERROR, clear the trigger so the next event can start a new read. The next read can be requested on the next rising edge of the heartbeat.
7. If BUSY remains high for more than two OB1 cycles, you have either addressed the wrong module, the LADDR does not match the slot, or the FB is in a stall. See the troubleshooting matrix for the diagnostic next step.

The DONE bit is pulse-shaped, not latched. If your code only samples DONE on a slow scan, you will miss it. Capture DONE the same cycle it goes high. The same applies to ERROR.

SCL Implementation Example

The following SCL block demonstrates the proper call pattern. It can be instantiated in OB1, in a cyclic interrupt OB (e.g., OB35 at 100 ms), or behind a function-key input from the HMI.

FUNCTION_BLOCK "FB_DiagFestoManifold"
VAR
    RTrig_Req    : R_TRIG;          // rising-edge detector on the request
    RTrig_Done   : R_TRIG;          // edge-capture of DONE
    RTrig_Err    : R_TRIG;          // edge-capture of ERROR
    fbDiag       : LIOLlink_Diagnose; // instance DB of the library FB
    tHeartbeat   : TON;              // 1-second cyclic timer
    tDiagBusy    : TON;              // 5-second stall timer
    sDiag        : StructLiollinkDiag; // output structure
    wStatus      : DWORD;            // last STATUS
    bError       : BOOL;
    bDiagValid   : BOOL;             // TRUE after first Done
END_VAR

BEGIN
    // Heartbeat: pulse TRUE for one OB1 cycle every 1 s
    tHeartbeat(IN := NOT tHeartbeat.Q, PT := T#1S);
    RTrig_Req(CLK := tHeartbeat.Q);

    // Call the FB every cycle, drive REQ from the rising edge
    fbDiag(
        LADDR  := "HwCM4xIOLink",   // HW identifier from TIA Portal
        CAP    := 227,              // full diagnostic block
        PORT   := "i_Port",         // 0..3 (pass in from HMI or fixed)
        REQ    := RTrig_Req.Q,      // EDGE-triggered, never level-driven
        RD_WR  := FALSE,            // read mode
        DONE   => ,
        BUSY   => ,
        ERROR  => ,
        STATUS => wStatus,
        DIAG   => sDiag
    );

    // Edge-capture DONE / ERROR so the user does not miss them
    RTrig_Done(CLK := fbDiag.DONE);
    RTrig_Err (CLK := fbDiag.ERROR);
    bError := fbDiag.ERROR;
    bDiagValid := bDiagValid OR RTrig_Done.Q;

    // Stall detection: 5 s of continuous BUSY is a bug
    tDiagBusy(IN := fbDiag.BUSY, PT := T#5S);
    IF tDiagBusy.Q THEN
        // The FB is hung. Reset heartbeat to force a clean re-issue.
        tHeartbeat(IN := FALSE, PT := T#1S);
    END_IF;
END_FUNCTION_BLOCK

The pattern is the same in ladder: use a normally-open contact from a one-second clock generator to provide the leading edge, wire that contact directly to the REQ input of the FB, and use separate --|P|-- contacts on DONE and ERROR to latch an "event happened" bit for the HMI. Do not put a --|N|-- contact on the clock generator; use only the leading edge, otherwise the FB will receive a request on the falling edge as well on some FB revisions.

Edge-Triggered Request Pattern

The principle of edge-triggered requests applies to every block in the LIOLlink family: LIOLlink_Diagnose, LIOLink_Master, LIOLink_Device, LIOLink_Port, and the lower-level READ_REQ / WRITE_REQ blocks. Holding REQ high is never correct.

Pattern 1: Cyclic heartbeat

Use a timer that is on for one OB1 cycle every N seconds (N typically 1 to 5). Wire the timer's output through a rising-edge detector to REQ. This pattern is best for periodic background diagnostics that the HMI does not need to drive. The advantage is deterministic load: the diagnostic read happens at a known rate and consumes a known amount of CPU time. The disadvantage is that the diagnostic data is up to N seconds stale when the operator views it.

Pattern 2: Operator button

Wire an HMI button directly to a rising-edge detector. Do not latch the button in an HMI tag; let the detector produce the edge. If you latch, the HMI sets the tag, REQ goes high, the FB goes busy, the HMI does not clear the tag until the next round-trip, REQ is still high, and you are back at the original problem. If the HMI must show a busy indicator, drive the indicator from the FB's BUSY output, not from the button state.

Disconnect Detection: Why No Status Code

After the FB returns DONE, the diagnostic structure (DIAG) contains a snapshot of the master and device state at the moment of the read. The PortStatus byte for the affected port will be 0 (NoDevice) if the manifold was disconnected at the time of the read, or 3 (Error) if a short or a watchdog fault occurred.

If the user disconnects the manifold after the FB has returned DONE, the PortStatus byte in the cached DIAG structure does not change, because the FB is not polling continuously. To detect a later disconnect, the application must:

1. Issue a new diagnostic read at a faster heartbeat (250 ms to 1 s is typical for disconnect detection).
2. Compare the cached PortStatus with the freshly read PortStatus. A transition from 1 (OK) to 0 (NoDevice) is a disconnect event.
3. Optionally, also read the port's cyclic diagnostic bit from the I/O area. The CM 4xIO-Link maps the port diagnostic interrupt (per channel) to the channel fault bit in the input process image. A high-to-low transition on that bit is a near-instant disconnect signal and is much faster than a 1 s LIOLlink_Diagnose cycle.

A common misconception is that pulling the cable should be reflected in the same DIAG buffer that was read 30 s earlier. IO-Link diagnostics are pull-based, not push-based, at the application layer. The master does push events to the OB82 diagnostic interrupt, but the LIOLlink_Diagnose FB does not automatically subscribe to that interrupt; the application has to read the data.

For a robust Festo manifold installation, the recommended detection chain is:

• OB82 (diagnostic interrupt) for sub-cycle disconnect detection, raising a fast "port lost" flag.
• LIOLlink_Diagnose at 1 Hz, providing the full event log and last event code for the HMI alarm.
• Cyclic process data read from LIOLink_Master, providing the coil states.

Diagnostic Data Structure with cap = 227

When CAP = 227, the DIAG output structure contains the full diagnostic block, with the subfields listed in the table below. Engineers should focus on the fields that map directly to user-visible problems:

Festo event codes observed on the manifold

If the diagnostic block returns all zeroes except PortStatus, the FB read the master successfully but the device did not answer. Re-check the cable, the port configuration, and the IODD assignment in TIA Portal (the IO-Link device must be assigned to a port with the correct IODD file). If the VendorName is non-zero, the read did reach the device and any zero subfield is a "no event" or "no data" by design.

Comparison: LIOLlink_Diagnose vs. LIOLink_Master

Engineers often confuse LIOLlink_Diagnose with LIOLink_Master. The two blocks serve different purposes and should be used together.

A complete Festo manifold solution typically calls both: LIOLink_Master continuously for process data, and LIOLlink_Diagnose at 1 Hz for the diagnostic page and the HMI alarm list.

Commissioning Verification Checklist

After wiring the FB call, run through this checklist before declaring the IO-Link link healthy:

1. The CM 4xIO-Link module is plugged into a powered terminal module and the IM 155-6 reports it as OK in the device configuration (no red diagnostic LED on the station).
2. The IO-Link port is configured in the TIA Portal port configuration with the correct IODD. For the Festo manifold, import the IODD from the Festo IODDfinder or from the Festo support site and assign it to the correct port.
3. The LADDR constant matches the HW identifier in the TIA Portal project. Open the system constants view, expand the module, and copy the HW identifier of the CM 4xIO-Link slot.
4. The REQ input is rising-edge triggered. Confirm by adding a watchpoint on the trigger and verifying it is TRUE for one OB1 cycle only, then FALSE.
5. The FB returns DONE within two OB1 cycles. If it does not, the trigger is being re-asserted. The STATUS output will show 16#0000_0001 (in progress) or 16#8600_0000 (FB stall) if the trigger is held.
6. The DIAG structure contains a non-zero VendorName. If it does not, the device is not answering. Check the cable, the port mode (must be IO-Link, not DI/DO), and the IODD assignment.
7. Pull the manifold cable. The PortStatus[PORT] byte in the next DIAG read is 0. Reconnect the cable. The next read reports 1.
8. The HMI alarm list displays the LastEventCode from the FB on a transition from 0 to a non-zero value.
9. The STATUS output never reports 16#8001_xxxx. If it does, the LADDR is wrong; if it reports 16#8003_0001, the device is not answering.
10. The cyclic process data from LIOLink_Master reflects the coil states correctly. The two blocks should agree on the port status.

Troubleshooting Matrix

Safety and Field-Notes

A few caveats that come up in real installations:

• The CM 4xIO-Link requires the head module (IM 155-6) to be on a current firmware. Mix-and-match with older IM 155-6 PN ST stations can produce partial diagnostic reads. Check the compatibility list on the Siemens support portal before substituting head modules.
• Festo manifolds ship with a 3-wire M12 connector on a pigtail. If you use a Y-distributor (e.g., to retain a manual override switch), confirm that the IO-Link signal still reaches the device; some Y-distributors attenuate the C/Q line below the SDCI threshold.
• Do not assign the same port to two different IODDs in TIA Portal. The portal will warn you at compile time, but the runtime behaviour is undefined.
• If you have more than one CM 4xIO-Link in the ET 200SP station, each gets its own LADDR. The library does not auto-discover.
• Always verify the FB instance name in the call (e.g., i_FestoManifold.fbDiag) before posting to a support request. The STATUS code alone is not enough to diagnose the issue.

FAQ