Checking PROFINET Connection State on S7-1500 in TIA Portal LAD

Overview

On a SIMATIC S7-1500 acting as a PROFINET IO controller, the application program frequently needs to confirm that the PROFINET IO connection (the AR – Application Relationship – to each configured IO device) is established, exchanging cyclic data, and free of diagnostic alarms before it performs write actions, recipe loads, or motion enable. The PLC exposes this information through three layers:

1. System state bits and standard status words in the process image (e.g. %IW.. status of the IO device).
2. Diagnostic instructions provided by the S7-1500 firmware: DeviceStates and GetStationInfo.
3. Application-level life-bit handshaking implemented between the S7-1500 and the third-party PROFINET device over a freely usable slot.

This reference documents all three mechanisms in LAD/FBD, the relevant data types, return values, and the diagnostic LED meaning (RN/NS, ER/MS, MT/IO) on PROFINET stations, with practical examples for both Siemens and third-party IO devices (Universal Robots, Delta Motion, and similar).

Prerequisites

• S7-1500 CPU with PROFINET interface (any firmware from V2.0 onward; DeviceStates available from V1.8, GetStationInfo from V2.0).
• TIA Portal V14 SP1 or later (V16+ recommended for the latest diagnostic block versions).
• PROFINET IO device with a GSD file imported into the TIA Portal hardware catalog.
• The device must be assigned to a PROFINET IO system on the S7-1500 interface (e.g. PN-IO X1 / PN-IO X2).
• For life-bit: at least 1 bit of input and 1 bit of output freely available in the IO device slot configuration.

PROFINET IO Architecture: What "Connection State" Actually Means

PROFINET IO is built on a real-time channel (RT or IRT) and an Application Relationship (AR) between the IO controller and each IO device. The connection state the application code sees is the AR state, and the device state. From the controller's point of view, an IO device moves through the following high-level states, which map to the values returned by DeviceStates and to the iOCR/iAR status reported in GetStationInfo:

The S7-1500 firmware provides dedicated instructions in the Diagnostics folder of the Instructions task card to read this state synchronously from the user program.

Method 1: Use DeviceStates (Recommended First Step)

DeviceStates returns the run/communicate/fault status of every PROFINET IO system, every PROFINET IO device, or every submodule of a given IO device. It is the simplest, fastest, and most idiomatic way to check connection state in LAD.

Block interface

LAD example: read every PROFINET device on PN-IO X1

   ┌──────────── DeviceStates ────────────┐
   │  MODE    := 1                        │  // 1 = per device
   │  LADDR   := "PN-IO_X1"               │  // system constant from HW config
   │  STATE   := "dbDeviceState".state    │  // ARRAY[0..127] of BOOL
   │  RET_VAL => "dbDiag".retVal          │
   └──────────────────────────────────────┘

Meaning of the bits in STATE (MODE = 1)

The bit indices map directly to the device number in the PROFINET IO system: device 0 → bit 0, device 1 → bit 1, etc. Use STATE[i] in LAD to gate downstream actions.

Typical RET_VAL errors for DeviceStates

LAD snippet: gate a write on "device 3 in data exchange"

   "dbDeviceState".state[3]    "dbLogic".bDevice3OK    "dbLogic".bStartSequence
   ──────( )───────────────────( )──────────────────────────( )─────(S)
                                  │
                                  │ (one-shot enable)

Method 2: Use GetStationInfo for Detailed Diagnostics

When DeviceStates reports "diagnosis" or "maintenance required", you need to know which slot and channel is affected. GetStationInfo returns a structured PNIO_ALARM_DATA-style record and the slot / submodule status of one IO device.

Block interface (S7-1500 firmware V2.0+)

The INFO output is a PLC data type (UDT) of family PNIO_… (e.g. PNIO_SLOT_INFO for MODE=1). Each entry includes a SlotNumber, a ChannelNumber, a Properties bit field, and a SlotErrorCode. The Properties bits contain flags such as:

• Bit 0: Module/Submodule is OK
• Bit 1: Module/Submodule has a diagnosis
• Bit 2: Module/Submodule has a problem (not reachable)
• Bit 3: Submodule is in maintenance state
• Bit 4: Submodule does not match the configuration

LAD example: read the slot information on a rising edge

   bReqGetInfo   "dbStInfo".busy   "dbStInfo".done    "dbStInfo".err
   ─────( )──────(   )────(REQ)──────────────────(DONE)──────────(ERR)───  GetStationInfo
                              │   LADDR := "ThirdParty_Head"        │
                              │   MODE  := 1                        │
                              │   INFO  := "dbStInfo".slotInfo       │
                              └──────────────────────────────────────┘

Method 3: Application-Level Life-Bit Handshake

When the third-party PROFINET device has no GSD-level status word – or when the application wants a stronger guarantee than the AR is alive (e.g. "the device's application program is running") – implement a free cycle in the IO data:

1. Reserve one input bit and one output bit in the slot configuration (e.g. slot 0 subslot 1, just a 1-bit module on each side).
2. The PLC toggles "dbLife".bOut every 50 ms (use a 50 ms cyclic interrupt OB or a clock memory bit).
3. The third-party device mirrors the bit on its input back to the controller as bIn.
4. The PLC confirms a connection is "live" when bIn == bOut(t-D) for at least one full period.

LAD snippet

        clk50ms    "dbLife".bOut
   ───────( )────────────────────────────────( )

   "dbLife".bOut    "dbLife".bIn    "dbLife".bConnOK
   ─────( )───────(==)──────────────────────────────────( S )

   "dbLife".bConnOK  (one-shot clear on next cycle)
   ──────────────────────────────────────────────────( R )

This method is independent of the PROFINET stack and detects situations where the AR is alive but the device's own application is hung, and it works with any vendor, including Universal Robots, third-party drives, vision systems, and Delta Motion controllers that expose a PROFINET IO channel.

PROFINET Status on the Third-Party Device Side

While the S7-1500 reports the AR state, the third-party device sees the same connection through its own PROFINET stack. A typical example is the Universal Robots UR3e / UR5e / UR10e / UR16e / UR20 / UR30, which exposes the PROFINET slot/channel state through URScript variables and through the Real-Time Data interface:

• rtde_input.bit_registers.X – reflects the input word configured on slot 1, including any bit your PLC drives.
• Diagnostic alarms from the UR's PROFINET stack surface in the robot's event log; from the PLC side, they appear as standard PROFINET channel diagnostics in GetStationInfo.

For motion controllers such as the Delta Motion RMC series, a PROFINET controller state register is exposed to the user program. The Delta Motion RMC maintains a DINT register that holds the PROFINET controller state with the documented values 0 = Unknown, 1 = Run, and 2 = Program – mirroring the S7-1500's RUN / STOP transition. Treat this register as an additional application-level life bit in the application code of the controller, not as a substitute for the AR state inside the S7-1500.

Status and Error LEDs on PROFINET Stations

The physical link and the AR state are also visible on the LEDs of the PROFINET ports. The conventions for the standard Siemens nomenclature (used on ET 200, SCALANCE, and most third-party PROFINET stations) are:

The full table for the IM 157-1 MF (6ES7157-1MA00-0AB0) head module of the ET 200AL system applies to most distributed I/O with a PROFINET interface. For S7-1500 CPUs the LED PN-IO is on the PROFINET port; for the CPU 1515-2 PN, the X1 and X2 ports have their own RN / ER / MT LEDs.

Mapping of Common PROFINET Alarms to S7-1500 OB82 / OB83 / OB86 / OB122

The S7-1500 reports AR and module events through standard organization blocks. Map them to a unified buffer and to the HMI alarm view:

Use RALRM (read alarm) inside OB 82 / 83 / 86 to pull the structured PROFINET channel diagnostic and decode the channel properties / error type / error value. The decoded information is what populates the HMI diagnostic view and what to log if a recipe is interrupted.

Step-by-Step: Building a "PN-OK" Bit in LAD

1. Open the S7-1500 device configuration in TIA Portal and confirm that the third-party device is in the same PROFINET IO system as the CPU's PROFINET interface. Note the system constant for the IO system (default name PN-IO_X1).
2. Add a global DB dbDiag with: retVal : INT;, state : ARRAY[0..127] OF BOOL;, bPN_OK : BOOL;, and a clock memory byte if not already enabled.
3. Insert a DeviceStates instruction (Instructions > Diagnostics) in OB 1. Wire MODE = 1, LADDR = "PN-IO_X1", STATE = dbDiag.state, RET_VAL => dbDiag.retVal.
4. Build a small OR/AND network that sets dbDiag.bPN_OK = TRUE when all relevant bits in dbDiag.state are FALSE for "device failed" and FALSE for "diagnosis" and the "OK" bit is TRUE.
5. Use dbDiag.bPN_OK as an interlock in front of any write that must not be sent while the AR is down. For belt-and-braces safety, AND it with the OB 86 status flag (slot present) and with the application-level life bit from Method 3.
6. Optional: in OB 86 (station failure), drive a one-shot pulse that triggers GetStationInfo to capture the slot that dropped out, and store the offending slot in a retention DB for the maintenance engineer.

Verification Procedure

1. Download the hardware configuration and the program to the S7-1500. Go online in TIA Portal.
2. Open the device view of the third-party station and confirm the online state is green (cyclic data exchange). The PROFINET diagnostics entry in the inspector must show "OK" and no alarms.
3. In the watch table, force dbDiag.bPN_OK = 1 only after a successful connect. Observe that downstream writes are enabled.
4. Disconnect the PROFINET cable of the third-party device. Within one to three update cycles (<= 30 ms at a 1 ms send clock), dbDiag.state[<devNo>] bit 1 (device failed) must transition to TRUE and dbDiag.bPN_OK must go FALSE. OB 86 must be called exactly once with OB86_FLT_ID = 1 (station failure) on the rising edge, and again with OB86_FLT_ID = 0 on the falling edge when the cable is reconnected.
5. Reconnect. Confirm OB 86 is called for the recovery, the "OK" bit in state returns, and the life-bit handshaking in Method 3 resumes within one period of the 50 ms toggle.
6. Force a slot-level fault (e.g. pull a sub-module of an ET 200 station) and verify OB 82 is called and GetStationInfo returns the affected slot/channel.

Troubleshooting Matrix

Programming Notes and Engineering Best Practices

• Call DeviceStates only once per OB 1 cycle. The instruction is non-blocking and does not need an enable edge; calling it every cycle simply refreshes the state array.
• For high-reliability applications, combine the AR state from DeviceStates with the slot-level slot 0 subslot 1 status from GetStationInfo. Both can disagree briefly during an AR recovery: AR is back up but the channel diagnostics of the previous fault are still queued.
• Use a PN-OK interlock rather than a PN-FAIL one. The default of a power-on state (FALSE on the "OK" bit) is the safe state – writes remain disabled until a confirmed "OK" is observed for at least one full cycle.
• Capture the last known good configuration in a retentive DB. If the AR is dropped due to a GSD change, the application can refuse to start until engineering confirms the change.
• Reserve PROFINET device names statically when the network is small. For larger installations, use a PROFINET naming tool or the device's web server to assign names on commissioning.
• Do not place the life-bit toggle in OB 1 with a one-second cycle; the controller's watchdog may already have failed the device before the next toggle. Use a 10–50 ms cycle from a cyclic interrupt OB (OB 30 to OB 38) or a clock memory bit.

Cross-Platform Notes

• On the S7-1200 (CPU 1211C through 1217C and 1214FC through 1215FC), DeviceStates and GetStationInfo are also available from firmware V4.2 onward. The block interface and the meaning of the state bits are identical to the S7-1500, with the same MODE values.
• For an S7-300 / S7-400 PROFINET IO controller (e.g. CPU 315-2 PN/DP, CPU 416-3 PN/DP), use the older SFC 51 "SZL" reads (SZL ID W#16#0F31 / 0x0F32 / 0x0F33 / 0x0F34 / 0x0F39 / 0x0F3A) to obtain the same information. The numeric layout is identical: bit 0 = device OK, bit 1 = device failed, bit 2 = diagnosis, bit 3 = not available.
• For ET 200SP / ET 200AL / ET 200MP head modules the head module's HW identifier is what you pass to GetStationInfo MODE 1; the IO system's HW identifier is what you pass to DeviceStates MODE 1/3.

FAQ