S7-1500 PROFINET: Suppressing LED Alarms on HMI or UPS Disconnect

Problem Statement

An S7-1500 CPU configured as a PROFINET IO controller raises an LED fault (BF on the PROFINET port, and/or SF on the CPU) the moment a downstream IO device stops responding on the wire. In the reference case the IO devices are an HMI panel TP1200 Comfort (6AV2 124-0MC01-0AX0, V14.0.1.0) and a SITOP UPS1600 PN (6EP4136-3AB00-2AY0, V2.2). When the Ethernet patch cable to either device is pulled, the CPU logs a station failure in the diagnostic buffer and the maintenance personnel see a red fault LED even though the unplug action was intentional.

This article documents why the alarm is unavoidable while the IO device is in cyclic exchange, and the three field-proven ways to suppress it:

1. Issue a controlled deactivation with the D_ACT_DP instruction in the user program before the cable is pulled.
2. Reconfigure the TP1200 Comfort as a pure HMI station (no IO controller / IO device assignment), since it typically has no process I/O that the PLC must read cyclically.
3. Keep the UPS1600 in the IO configuration (it has useful diagnostics to expose), but wire its data into the user program so the application can react before anyone pulls the cable.

Hardware and PROFINET Topology

The reference installation is built around the parts in the table below. All three nodes share a single PROFINET subnet. The S7-1500 acts as the IO controller; the TP1200 Comfort and UPS1600 are configured as IO devices in the TIA Portal device view.

Background reading on the SITOP UPS1600 PROFINET interface and the dataset values it can publish (battery status, DC input/output voltage, charge current, remaining buffer time) is provided in the Siemens support article SIMATIC NET / SITOP UPS1600 PROFINET Integration.

Root Cause: Cyclic IO Exchange Cannot Tolerate a Disappearing Partner

When the TP1200 and UPS1600 are configured as IO devices, the CPU opens a PROFINET AR (Application Relationship) with each of them. The AR is held open by a fixed refresh cycle (typically 1 ms for the send clock, 1 ms for the watchdog by default), and the controller expects a fresh input PDU on every cycle. As soon as the watchdog expires the controller issues a station failure alarm on the slot/submodule where the device used to be.

The diagnostic buffer entry written by the CPU at that moment is one of the following (codes per the S7-1500 system manual, entry IDs 0x0001 - 0x00FF for IO events):

Buffer entry 0x001F is the only one that does not turn on the BF LED, and it is generated only when the controller is told in advance that the partner is going away. That is exactly what D_ACT_DP does.

Strategy: Deactivate the IO Device Before You Unplug It

PROFINET supports a controlled shutdown of an AR through the D_ACT_DP (Deactivate DP/PN Slave) instruction. Calling D_ACT_DP with MODE = 2 closes the AR cleanly, sends the right AR-abort primitives to the partner, and the CPU writes a 0x001F removal entry to the diagnostic buffer instead of a 0x0151 station failure. The BF LED on the PROFINET port stays off because the controller is not waiting for any PDUs from a device it has already told to leave.

Recommended workflow:

1. Operator issues a maintenance request on the HMI (or via a keyswitch wired into the PLC).
2. User program calls D_ACT_DP with MODE = 2 against the HW identifier of the IO device that is about to be disconnected.
3. User program polls RET_VAL and BUSY; when BUSY goes FALSE and RET_VAL = 0, the AR is closed.
4. The operator may now safely pull the Ethernet cable. The CPU does not raise BF / SF.
5. When the cable is reconnected and the device is back, calling D_ACT_DP with MODE = 1 re-activates the AR and the IO device comes back online.

D_ACT_DP Block Interface

The instruction lives in the Extended Instructions > Distributed I/O folder of TIA Portal. The block signature is identical for S7-300, S7-400, S7-1200 and S7-1500. On the S7-1500 the call must be made from an OB whose priority is greater than the priority of OB1 and the call must not be skipped by an open / closed gate in the same scan.

Common RET_VAL codes returned by D_ACT_DP on S7-1500:

Step-by-Step TIA Portal Configuration

Perform the following steps once in the TIA Portal project. The procedure is valid for TIA Portal V15.1 through V18 with CPU firmware V2.1 or higher; the S7-1500 system manual describes the same sequence.

1. Read the HW Identifier of the IO Device

1. Open the project in TIA Portal and switch to the device view of the S7-1500 CPU.
2. Click on the PROFINET interface of the TP1200 Comfort (or UPS1600). TIA Portal shows the device's HW identifier in the properties dialog under General > PROFINET interface > Address details. The system constant is of the form "TP1200_Comfort_1~PN-IO" with a numeric value such as 256.
3. Note the value down; the user program uses it as the LADDR input of D_ACT_DP. You can also drag the system constant from the project tree into the SCL editor.

2. Create a Global DB for the D_ACT_DP Instance

1. In the project tree, right-click Program blocks > Add new block > Data Block (DB). Name it DACT_DP_DB, uncheck Optimized block access so the offsets are stable, and click OK.
2. Inside the DB, add the following tags (these are filled automatically the first time D_ACT_DP is inserted, but it is good practice to declare them explicitly):

3. Add the D_ACT_DP Calls in OB1 (SCL Example)

The following SCL fragment lives in OB1 and uses two independent D_ACT_DP instances, one per IO device, so that the operator can disconnect either panel in any order.

// Maintenance request for the TP1200 Comfort
"Maintenance".HMI.bDeactivate := "Maintenance".bHMI_Request
                              AND NOT "Maintenance".HMI.bActive;
// Maintenance request for the UPS1600
"Maintenance".UPS.bDeactivate := "Maintenance".bUPS_Request
                              AND NOT "Maintenance".UPS.bActive;

// --- D_ACT_DP for TP1200 Comfort ---
"DACT_DP_DB_HMI"(
  REQ    := "Maintenance".HMI.bDeactivate
            OR "Maintenance".HMI.bActivate,
  MODE   := SEL(G := "Maintenance".HMI.bActivate, IN0 := 2, IN1 := 1),
  LADDR  := "TP1200_Comfort_1~PN-IO",   // system constant, numeric 256
  RET_VAL => "Maintenance".HMI.iRetVal,
  BUSY   => "Maintenance".HMI.bBusy
);

IF NOT "Maintenance".HMI.bBusy THEN
  "Maintenance".HMI.bActive := "Maintenance".HMI.bDeactivate;
END_IF;

// --- D_ACT_DP for UPS1600 ---
"DACT_DP_DB_UPS"(
  REQ    := "Maintenance".UPS.bDeactivate
            OR "Maintenance".UPS.bActivate,
  MODE   := SEL(G := "Maintenance".UPS.bActivate, IN0 := 2, IN1 := 1),
  LADDR  := "UPS1600_1~PN-IO",           // system constant, numeric 257
  RET_VAL => "Maintenance".UPS.iRetVal,
  BUSY   => "Maintenance".UPS.bBusy
);

IF NOT "Maintenance".UPS.bBusy THEN
  "Maintenance".UPS.bActive := "Maintenance".UPS.bDeactivate;
END_IF;

The trick is to keep REQ latched until BUSY goes FALSE. The SCL fragment above does that by making the bDeactivate / bActivate bits level-triggered off the operator request and clearing them only after BUSY falls.

4. Optional: Ladder Logic Equivalent

If the project standard calls for ladder, the equivalent sequence is shown below. It uses two separate networks, one per IO device, with the REQ bit held by a set/reset coil driven on the falling edge of BUSY.

// Network 1 - TP1200 Comfort
A     "Maintenance".HMI.bDeactivate
S     "DACT_DP_DB_HMI".REQ
A     "Maintenance".HMI.bDeactivate
AN    "DACT_DP_DB_HMI".REQ
O     "DACT_DP_DB_HMI".BUSY
R     "DACT_DP_DB_HMI".REQ
CALL  "DACT_DP_DB_HMI"
      REQ    := "DACT_DP_DB_HMI".REQ
      MODE   := B#16#2
      LADDR  := W#16#100          // = 256 decimal, HW id of TP1200
      RET_VAL := "Maintenance".HMI.iRetVal
      BUSY   := "DACT_DP_DB_HMI".BUSY

The same network is duplicated for the UPS1600 with MODE = B#16#2 and LADDR = W#16#101 (decimal 257 in the example). On every successful deactivation the diagnostic buffer logs entry 0x001F instead of 0x0151 and the BF / SF LED on the CPU stays dark.

Alternative: Reconfigure the TP1200 Comfort as a Pure HMI Station

PROFINET allows an HMI to communicate with the PLC over S7 communication without being an IO device at all. In the typical Comfort Panel / S7-1500 pair the only data flow is:

• HMI tags read from PLC DBs (PUT/GET or HMI tag connection)
• HMI alarms acknowledged by the PLC (alarm subscription)
• Recipe / user data written to PLC DBs

None of these data flows require the panel to be an IO device. If the project does not use the TP1200 as a way to bring physical buttons or LEDs into the PLC (and the reference installation does not), the IO device role can be removed entirely. The PROFINET configuration then treats the TP1200 as a single HMI connection, not a cyclic IO partner.

1. In TIA Portal, open the device view of the S7-1500 and click on the PROFINET interface of the TP1200.
2. Open the inspector window > PROFINET interface > Operating mode.
3. Uncheck IO device (keep HMI connection if it is enabled).
4. Compile and download. The TP1200 no longer opens a cyclic AR with the controller, and pulling the Ethernet cable simply times out the S7 connection. There is no BF on the PROFINET port of the S7-1500 because the S7-1500 is not expecting cyclic PDUs from the panel any more.

UPS1600 PROFINET Diagnostics: What You Get If You Keep It as an IO Device

The SITOP UPS1600 PN (6EP4136-3AB00-2AY0) is one of the few UPS products on the market that natively publishes its battery and power data over PROFINET. The Siemens support article 84977415 documents the data record layout that the UPS exposes as a PROFINET slot.

Typical values available on the cyclic IO data of the UPS1600 (1 byte / 1 word per slot, names per the manual):

Because all of this data is on the cyclic AR, removing the UPS1600 from the IO configuration also removes the visibility into the battery state. If the customer standard requires the device to remain in the IO configuration, keep the D_ACT_DP path and call D_ACT_DP with MODE = 1 again as soon as the operator finishes the maintenance action; this re-opens the AR and the cyclic data resumes within a few hundred milliseconds.

Diagnostic Buffer Inspection

After the maintenance procedure the CPU diagnostic buffer is the single source of truth to confirm that D_ACT_DP did the right thing. Open the buffer in TIA Portal via Online > Online & diagnostics > Diagnostics buffer.

What you want to see after a controlled disconnect of the TP1200:

If the buffer shows 0x0151 Station failure instead of 0x001F Removal, then D_ACT_DP was either never called, was called with the wrong LADDR, or BUSY was not latched long enough for the AR-abort to propagate. In that case the BF LED on the affected PROFINET port will be lit until the cable is reconnected.

Edge Cases and Field Notes

• Watchdog too tight: The PROFINET watchdog on the IO device is set in TIA Portal under device properties > PROFINET interface > Watchdog. The default is 3 missed cycles. If the user program is slow to call D_ACT_DP (e.g. blocked behind a long-running FC), the watchdog can expire before the AR-abort reaches the controller. Increase the watchdog to 10-20 missed cycles for IO devices that are subject to maintenance.
• OB83 / OB86 interaction: A controlled deactivation through D_ACT_DP raises OB83 Insert/remove module on the CPU, not OB86 Rack failure. If OB83 is not loaded, the CPU goes to STOP at the next startup. Always load OB83 and OB86 even if they are empty, especially in plants where the operator may pull cables at runtime.
• Port interconnection mode: If the PROFINET cable runs through a managed switch, the controller may not see the link-down event at all. In that case D_ACT_DP is the only reliable way to suppress the alarm. For direct CPU-to-device cabling, link-down detection works and the buffer will show 0x001F even if D_ACT_DP is not called - but the BF LED is still latched until the next power cycle of the CPU.
• Multiple IO devices in series: When the UPS1600 is connected to a downstream switch that also serves the TP1200, pulling the patch cord on the switch port kills both ARs. Deactivate both devices in the same OB1 cycle before pulling the cable, in the order UPS first, then HMI, to avoid the first deactivation triggering a transient alarm on the second AR.
• Firmware V2.1 caveat: On older S7-1500 CPU firmware versions (around V2.1) transient D_ACT_DP failures may not always be reflected in RET_VAL. Always implement OB82 and OB83 with diagnostic evaluation so that secondary errors are still caught by the application.
• HMI reconnection time: Comfort Panels take 8-15 s to re-establish the S7 connection after the AR comes back. During that time the HMI shows Connection interrupted on its diagnostic view. The PLC continues to run; the operator should be told that the HMI display is not a real-time indicator of the PLC state.
• PUT/GET access rights: When the TP1200 is reconfigured as a pure HMI station, the PLC's PUT/GET access rights must remain enabled for WinCC Comfort to read tags. In TIA Portal this is under CPU properties > Protection > Connection mechanisms > Permit access with PUT/GET communication partner.

Troubleshooting Matrix

Verification Procedure

1. Download the new program to the S7-1500 CPU. The CPU must be in STOP for the first download; subsequent online changes do not require a STOP.
2. Switch the CPU to RUN. The BF / SF LED on the CPU must be off and the diagnostic buffer must not show a station failure for the HMI or the UPS.
3. On the HMI, set the Maintenance bit for the HMI IO device to TRUE. Confirm on the HMI's System > PROFINET diagnostics view that the device is marked Deactivated.
4. Wait for BUSY to go FALSE on the D_ACT_DP call. Read RET_VAL: it must be 0x0000.
5. Pull the Ethernet cable from the TP1200 Comfort.
6. Open the CPU diagnostic buffer. Confirm the most recent IO device event is 0x001F (Removal), not 0x0151 (Station failure). The BF LED on the PROFINET port of the CPU must remain OFF.
7. Reconnect the cable. Wait ~15 s for the AR to come back. Confirm in the buffer that the next event is 0x0152 (IO device return) and the cyclic data is updating on the HMI.
8. Repeat steps 3-7 for the UPS1600. The UPS must report BUF_OK on the HMI after re-activation.

FAQ