Deactivating Multiple PROFINET IO Devices with D_ACT_DP/SFC12

Problem Overview: Deactivating Many PROFINET IO Devices at Once

Large PROFINET installations routinely contain dozens of distributed IO stations that must be selectively brought offline during seasonal shutdowns, plant reconfiguration, or energy-saving campaigns. A typical example is a Siemens IM151-8 PN/DP CPU (article number 6ES7151-8AB00-0BA0) acting as the PROFINET IO controller for a ring of 30 IM151-3 PN head stations. When only ten of those stations are required for winter operation, the remaining twenty must be taken offline in a controlled fashion without stopping the CPU, without disconnecting the PROFINET cables, and without producing a CPU STOP.

Deactivation must therefore be performed by the application program itself. Two Siemens mechanisms handle this requirement:

• SFC12 "D_ACT_DP" in the S7-300 / ET200S system function library (used by the IM151-8 PN/DP CPU).
• The D_ACT_DP instruction in TIA Portal for S7-1200 and S7-1500 controllers, which exposes the same activation state machine through a structured block interface.

Both blocks issue an internal activation or deactivation request to the PROFINET IO controller's device database. The IO controller then negotiates the new state with the affected IO device, withdraws and releases AR (Application Relationship) and CR (Communication Relationship) channels, and reports the result through a return code. There is no hardware limit on how many devices can be in the deactivated state simultaneously — the practical limit is the cycle time and the number of pending state-machine requests the CPU can handle per OB1 pass.

Hardware: IM151-8 PN/DP as IO Controller

The IM151-8 PN/DP is the CPU module of the ET200S distributed I/O system. It contains an S7-300 compatible CPU core, an integrated PROFINET interface (X2), an integrated PROFIBUS-DP master (X3), and the ET200S backplane connector for power and additional signal modules. The IM151-8 PN/DP runs the same firmware family as the S7-300 CPUs of the same vintage, so the full set of S7-300 system functions — including SFC12 — is available in the application program.

Because the IM151-8 PN/DP is functionally an S7-300 CPU, the deactivation sequence described in this article uses the legacy SFC12 interface. The same logic can be migrated to an S7-1200 / S7-1500 controller by switching to the TIA Portal D_ACT_DP instruction; the parameter semantics are identical.

D_ACT_DP Fundamentals: SFC12 vs TIA Portal Instruction

SFC12 "D_ACT_DP" (German: Aktivieren/Deaktivieren von DP-Slaves/PROFINET-Geräten) is the system function that activates or deactivates configured DP slaves and PROFINET IO devices on the IO controller. Calling SFC12 with the LADDR of an IO device and a MODE value triggers the state transition. The TIA Portal D_ACT_DP instruction exposes the same interface as a typed FB with the additional REQ, DONE, BUSY, and ERROR handshake bits used across the S7-1200 / S7-1500 instruction set.

The semantics of MODE are identical between the two blocks:

• MODE = 0 — query. The block writes the current activation status of the IO device referenced by LADDR into RETVAL. A return value with bit 0 set (W#16#xx01) indicates the device is currently deactivated; otherwise it is active.
• MODE = 1 — activate. Initiates an activation request for the addressed IO device.
• MODE = 2 — deactivate. Initiates a deactivation request for the addressed IO device. Per the Balluff documentation mirrored from Siemens, a deactivation initiated with MODE = 2 cannot be cancelled by an immediate MODE = 1; the IO device must first complete the deactivation sequence before being re-activated.

Prerequisites Before Deactivation

1. Hardware configuration loaded. All 30 IM151-3 PN head stations must be configured in HW Config (STEP 7 V5.x) or in the Device Configuration of the IM151-8 PN/DP project (TIA Portal). Each station must have a unique diagnostic address (the LADDR used by SFC12). Typical diagnostic address ranges start at 0 and step in increments of 4, e.g. 0, 4, 8, …
2. Devices reachable at commissioning. Confirm that the IO devices to be deactivated are physically present and that the PROFINET ring or line is closed. A device that is already in station failure when SFC12 is called will return W#16#000A ("no IO device configured for LADDR") or a station-related error.
3. Application logic must tolerate IO dropout. The deactivation withdraws the AR. Any process image I/O assigned to that device becomes invalid (the peripheral access fault bit is set in the PAE/PAW sense). All user logic that reads inputs from, or writes outputs to, the affected IO device must be either gated by the activation state or be permitted to continue with the last valid value.
4. CPU is in RUN. D_ACT_DP is only processed when the CPU is in RUN. If the CPU is in STOP, no activation state change is performed; the IO devices retain their last commanded state.
5. OB1, OB82, OB83, OB86 are loaded. Diagnostic and pull/plug OBs are required to receive the deactivation confirmations. OB86 (rack failure) and OB83 (pull/plug) are particularly relevant because the IO controller signals the IO device as "not available" once the AR is withdrawn.

Configuring IO Devices in STEP 7 / TIA Portal

The logical address (LADDR) used by SFC12 is the diagnostic address of the PROFINET IO device. In STEP 7 V5.x HW Config, the address is set in the PROFINET interface properties of each IM151-3 PN station under Properties → PROFINET IO → Diagnostic address. In TIA Portal, the same address appears under Properties → PROFINET interface → Diagnostics address of the IO device.

For a project with 30 IM151-3 PN stations, the diagnostic addresses can be assigned as follows:

Compile and download the hardware configuration before downloading the user program. SFC12 will reject any LADDR that does not correspond to a configured IO device.

Step-by-Step: Deactivating Multiple PROFINET IO Devices

The general pattern for deactivating many stations sequentially from a single trigger is:

1. Build an array (or a DB of DWORDs) of diagnostic addresses for the stations that should be offline during the current season.
2. On a rising edge of the season-change trigger (e.g. a tag written from HMI or a calendar block), set a request flag and an index counter to zero.
3. In OB1, if the request flag is set and no deactivation is currently pending, call SFC12 with LADDR = addr[i] and MODE = 2 (deactivate).
4. Monitor RETVAL. If RETVAL = W#16#0000 and the BUSY flag clears (or MODE=0 query returns "deactivated"), increment i and proceed to the next station.
5. If RETVAL = W#16#000C, leave the index unchanged and re-issue the call on the next OB1 cycle.
6. When i reaches the array length, clear the request flag and set a "deactivation complete" status bit for the HMI.

The recommended cycle layout is:

Sample Code: STL, LAD, and SCL

The following examples assume a DB of 20 WORDs holding the diagnostic addresses of the winter-off stations, named DB_Addresses.WinterList[0..19], plus control tags DB_Addresses.Idx (INT), DB_Addresses.Req (BOOL), and DB_Addresses.Done (BOOL).

STL (Statement List) — OB1 / FC100

// FC100 : Deactivate winter IO stations one by one
// Inputs : DB_Addresses.Req   (BOOL, set by HMI)
// Outputs: DB_Addresses.Done  (BOOL, indicates complete)
// State  : DB_Addresses.Idx   (INT,  current index 0..19)

      A     DB_Addresses.Req
      AN    DB_Addresses.Done
      AN    DB_Addresses.Busy       // latched while a request is pending
      JC    DO01

      // Idle branch — nothing to do
      BEA

DO01: L     DB_Addresses.Idx         // i
      SLD   1                        // *2 because WORD takes 2 bytes
      LAR1                          // load AR1 with byte offset
      L     DB_Addresses.WinterList  // base of WORD array
      +AR1                          // AR1 = base + 2*i
      L     W [AR1, P#0.0]           // LADDR = WinterList[i]
      T     #LADDR

      CALL  SFC12
        LADDR := #LADDR
        MODE  := B#16#2              // 2 = deactivate
        RETVAL:= #RetVal

      L     #RetVal
      L     W#16#0                   // 0000 = request accepted
      ==I
      JC    OK1

      // 000C = request already pending — try again next cycle
      L     #RetVal
      L     W#16#C
      ==I
      JC    BUSY1

      // Any other code — surface to HMI diagnostic block
      SET
      S     DB_Addresses.Error
      SPA    CLR1

OK1:  L     DB_Addresses.Idx
      +     1
      T     DB_Addresses.Idx
      L     20                       // array length
      >=I
      JC    ALL_DONE

      // More devices remain — clear Busy so the next cycle issues a fresh call
      SPA    CLR1

BUSY1:SET
      S     DB_Addresses.Busy        // latched; cleared on OK1 or ALL_DONE
      SPA    CLR1

ALL_DONE:
      SET
      S     DB_Addresses.Done
      R     DB_Addresses.Req
      L     0
      T     DB_Addresses.Idx

CLR1: BE

LAD (Ladder) — equivalent skeleton

Network 1 — request issued once per cycle, only if Ready = TRUE
   [DB_Addresses.Req]   [ NOT DB_Addresses.Busy ]   [ DB_Addresses.Idx < 20 ]
            |                  |                            |
            +----[ AND ]-------+----------------+-----------+
                                    |
                                    +---[ CALL SFC12 ]--+
                                            |    |    |
                                          LADDR MODE=2 RETVAL=DB_Addresses.RetVal

Network 2 — RETVAL evaluator (use comparator blocks)
   "0000"  : Idx := Idx + 1;  Busy := 0
   "000C"  : Busy := 1
   default : Error := 1

Network 3 — completion
   Idx >= 20 : Done := 1; Req := 0; Idx := 0

SCL (Structured Control Language) — TIA Portal variant

// FC_DeactivateSeason, called once per OB1 cycle
IF "DB_Addresses".Req
   AND NOT "DB_Addresses".Done
   AND NOT "DB_Addresses".Busy
   AND ("DB_Addresses".Idx >= 0)
   AND ("DB_Addresses".Idx < 20) THEN

    "DB_Addresses".LADDR := "DB_Addresses".WinterList["DB_Addresses".Idx];

    // TIA Portal instruction form
    "D_ACT_DP_DB"(REQ   := TRUE,
                 LADDR := "DB_Addresses".LADDR,
                 MODE  := 2,                  // deactivate
                 DONE  => "DB_Addresses".Done1,
                 BUSY  => "DB_Addresses".Busy,
                 ERROR => "DB_Addresses".Err,
                 RET_VAL => "DB_Addresses".RetVal);

    IF "DB_Addresses".Done1 THEN
        "DB_Addresses".Idx := "DB_Addresses".Idx + 1;
        "DB_Addresses".Busy := FALSE;

        IF "DB_Addresses".Idx >= 20 THEN
            "DB_Addresses".Done := TRUE;
            "DB_Addresses".Req  := FALSE;
            "DB_Addresses".Idx  := 0;
        END_IF;

    ELSIF "DB_Addresses".Err THEN
        // surface to HMI / log; do NOT advance index
        "DB_Addresses".Error := TRUE;
    END_IF;

END_IF;

MODE Parameter Reference

A MODE = 2 call initiated on a device that is already deactivated returns W#16#000B ("device is already in the requested state"). Treat this as success in the state machine; advance the index.

Execution Timing and OB1 Cycle Limits

The PROFINET IO controller processes one activation or deactivation request at a time per IO device. The round-trip time from SFC12 call to completion depends on:

• The configured PROFINET update time of the IO device (typical 1 ms to 4 ms).
• The AR establishment/teardown sequence (typically 3 to 8 PROFINET cycles, plus one DCP identify round).
• CPU scan time and OB1 priority.

For an IM151-8 PN/DP CPU with default PROFINET update time of 1 ms, a single deactivation typically completes in 20 to 80 ms. Twenty sequential deactivations therefore complete in roughly 0.5 s to 2 s of real time, well within the OB1 cycle budget for a 100 ms scan.

Error Codes, RETVAL Values, and Diagnostics

SFC12 returns a 16-bit RETVAL. The most relevant values for the deactivation case are:

Whenever RETVAL ≠ W#16#0000, the diagnostic buffer entry created by the PROFINET IO controller provides the definitive explanation. Read the buffer from the online diagnostic view of the IM151-8 PN/DP station, or programmatically via SFC13 / SFC59 if your SCADA requires automated log retrieval.

Verification Procedures

1. Online view in HW Config / TIA Portal. After the deactivation sequence reports Done = TRUE, open the online view of the IO controller. Each deactivated IM151-3 PN appears with the status "Deactivated" and the diagnostic address is still visible but marked inactive.
2. Diagnostic buffer. The buffer should contain entries of class "IO controller status" with text similar to PROFINET IO device (diagnostic address X) deactivated for each LADDR that was processed.
3. Process image. Inputs from a deactivated device return 0. Writes to outputs of a deactivated device do not produce a peripheral access fault on the S7-300 / ET200S family — the write is silently discarded. Confirm this behaviour for your specific IM151-8 PN/DP firmware version by writing to a dummy output and reading back from a configured HMI tag.
4. OB86 call count. Each successful deactivation triggers an OB86 call with event W#16#39 (rack failure — station failure incoming) followed by an event W#16#38 (rack failure — station failure outgoing) once the AR is fully withdrawn. Counting OB86 invocations is a reliable way to confirm the number of stations actually de-activated.
5. Seasonal round-trip test. After deactivation, issue MODE = 1 (activate) on the same list and confirm that all 20 stations return to the active state. If the round-trip fails on a specific LADDR, that station's PROFINET name, cabling, or GSD mismatch is the cause — not the activation logic.

S7-1200 / S7-1500 Equivalent in TIA Portal

If the controller is later migrated to an S7-1200 or S7-1500, the same logic applies with the structured D_ACT_DP instruction. The instruction is documented in the TIA Portal help and in the official Siemens support entry 109741593 — D_ACT_DP (Enable/disable PROFINET IO devices), and is also referenced in the cloud documentation under D_ACT_DP — activate/deactivate DP slaves (S7-1200 / S7-1500).

Migration differences:

• The LADDR input is a HW_IO (system constant) generated from the IO device's diagnostic address. Replace the literal WORD from your classic S7 array with the HW identifier constant from the project tree.
• The handshake becomes explicit: REQ is edge-triggered, and the instance DB holds DONE, BUSY, ERROR, and STATUS. The state machine from the classic STL example maps directly to these bits.
• Behavioural caveat (per Balluff documentation mirrored from Siemens): a deactivation request with MODE = 2 cannot be cancelled by an immediately following activation with MODE = 1. The IO controller must first complete the deactivation (AR withdrawn) before a fresh activation is accepted. The same restriction applies to the SFC12 variant — this is a PROFINET stack behaviour, not a CPU-specific one.

Seasonal Deactivation Pattern — Recommended Practice

For a "winter-off" campaign on the example 30-station system, store two parameter sets in a recipe DB:

The HMI exposes three commands — Activate Summer Profile, Activate Winter Profile, and Force All Active. Each command sets the request flag, the direction (activate or deactivate), and the address sub-list. The state machine in FC_DeactivateSeason walks the sub-list and processes one LADDR per cycle until completion, then clears Req and sets the corresponding Done bit for the HMI to indicate progress.

This pattern lets the operator change seasons without ever stopping the CPU, without touching PROFINET cables, and without losing diagnostic history. It also gives the maintenance crew a deterministic way to verify which stations are currently active (MODE = 0 query against every LADDR in the recipe).

FAQ