Resolving F-DQ Output Activation Failures in TIA Portal V15.1

1. Problem Overview

Engineers commissioning the SIMATIC ET 200SP fail-safe digital output (F-DQ) module frequently encounter a deceptive symptom: the F-output tag in the TIA Portal watch table transitions cleanly to TRUE, the safety program compiles without diagnostics, the F-CPU remains in RUN, yet the channel LED on the F-DQ does not illuminate and the field-side 24 VDC load is never energized. The process image appears to update, but the physical output never closes.

This article documents the root cause of that symptom on the SIMATIC ET 200SP F-DQ 4×24VDC/2A module, Siemens part number 6ES7 136-6DC00-0CA0, when configured in TIA Portal V15.1 (Update 4 or later recommended), and provides a complete diagnostic and remediation procedure. The same root cause applies to the related F-DQ variants 6ES7 136-6DB00-0CA0 (4×24VDC/0.5A), the relay variant 6ES7 136-6RA00-0CA0, and the F-DI counterpart 6ES7 136-6CB00-0CA0, because all F-I/O in the ET 200SP family is bound by the same fail-safe runtime contract.

Two related symptoms appear in the source case:

1. The HMI operator panel (SIMATIC TP1200 Comfort) drives the output with a SetBit operation, but the output never energizes.
2. When the F-program is configured to consume the output and the HMI is wired to the F-tag, the F-CPU transitions to STOP with the diagnostic event "Data corruption in the safety program".
3. The auto-generated block Main_Safety_RTG1 prompts for a password that was never set by the current engineer.

All three are symptoms of the same architectural rule: F-I/O is exclusively owned by the F-runtime group.

2. Affected Hardware and Software

Verify the exact module variant against the Siemens catalog entry for the ET 200SP F-I/O family before applying the procedure below. Firmware revisions from V1.0.x through V2.x behave identically with respect to the F-runtime group contract; the differences are limited to the diagnostic message catalog and the supported PROFIsafe profile revision.

3. Root Cause Analysis

3.1 The F-Runtime Group Contract

Unlike standard I/O, every F-I/O address in the ET 200SP family is owned by the safety program. The F-CPU will not write a fail-safe output to the physical module unless three conditions are simultaneously satisfied:

1. An F-runtime group exists in the safety administration editor and is bound to an F-OB (OB123 "Failsafe_OB" on the S7-1500F generation, or a cyclic interrupt OB such as OB35 on the S7-300F/400F generation).
2. The F-program inside that runtime group actually references the fail-safe output tag, or a derived tag that feeds the output via the F-channel driver (F_DQ_BO instance for boolean outputs) or an F-DB assignment.
3. The F-runtime group is in a clean state, with no passivation pending, no signature mismatch, and no "Data corruption in the safety program" diagnostic.

When a user forces a fail-safe tag to TRUE in the watch table, the value is written into the process image. The watch-table cell shows TRUE because the image contains the value. However, no consumer ever pushes that value to the module. The F-DQ therefore remains in its safe state with all channels de-energized. The F-channel driver's ACK_NEC (acknowledge necessary) flag stays cleared because no F-cycle completed.

3.2 Process Image and F-Output Behavior

The Siemens Knowledge Base article "Why does the status of fail-safe inputs and outputs not change in the watch table" (entry ID 109778637) explicitly states: "For a status change of fail-safe inputs and outputs in the watch table, at least one channel of the corresponding module must be read or written." In the F-DQ case, that "write" only occurs when the safety program emits a passivation token followed by a normal-mode update for that channel. Without a participating F-runtime group, no write to the physical output is ever issued, regardless of what the watch table reports.

3.3 The "Data Corruption in the Safety Program" Error

The second symptom in the source case — "Data corruption in the safety program" — appears when an HMI tag (or any standard tag) is wired into the F-program and the runtime detects a non-safety-grade read or write from standard user code. The F-system enforces a strict data isolation boundary: standard code, HMI, and web server variables can read F-DB fragments only through the F-shared-DB interface, and writing into an F-tag from an HMI SetBit operation is treated as a violation. The CPU responds by transitioning to STOP and reporting the diagnostic, exactly as observed.

The fix is structural, not procedural: the F-program must derive its inputs from F-grade sources (F-DI modules, F-shared DBs with proper acknowledgment, or internally computed safety values) and the HMI must read a mirrored standard tag, never the F-tag itself.

3.4 The Main_Safety_RTG1 Password

Main_Safety_RTG1 is auto-generated the first time the safety administration is created in a TIA Portal project. It is the F-runtime group container and is protected by an F-runtime group password. This password is not a Siemens default and is always user-defined the first time the project is compiled and downloaded. If a freshly opened project prompts for this password, one of the following is true:

• The project was created by a different engineer or integrator and downloaded to the CPU with that engineer's F-password.
• The CPU was previously programmed by an integrator and the original project file is lost.
• The PLC was shipped with a preloaded safety project (rare, but possible on demonstration units and engineering samples).

There is no factory-default or master password that unlocks an F-runtime group. Recovery requires either the original project file or a complete reformat of the safety administration via a new project.

4. F-Runtime Group Architecture

The F-runtime group is the scheduling unit that ties the F-program to a guaranteed execution window. The structure is:

The F-runtime group also enforces the F-monitoring time. This is the maximum interval allowed between two consecutive F-cycles before the F-module is treated as failed and passivated. Typical values range from 1 ms to 10 s. If the standard program overruns and the F-OB cannot be called in time, the F-modules drop to their safe state (de-energized) and the CPU logs a "F-monitoring time exceeded" diagnostic.

Passivation is channel-level on the ET 200SP F-DQ: a single faulty channel does not passivate the whole module, but the F-DB exposes the per-channel QBAD and VALUE flags so that the F-program can react. The reaction to fault is documented in the SIMATIC ET 200Eco PN F-I/O manual collection, which states: "The fail-safe concept depends on the identification of a safe state for all process variables." For an F-DQ channel, the safe state is the de-energized state; the dark/light test pulse must be considered part of the normal operating cycle, not a fault.

5. Diagnostic Procedure

Use this sequence to confirm the root cause before changing any project structure:

1. Open the device configuration of the ET 200SP station and confirm that the F-DQ slot shows green (no diagnostic) and that the slot is assigned to the F-CPU's safety administration. A grey slot with a yellow triangle indicates the safety administration is missing.
2. In Project tree > Safety Administration, verify that a runtime group exists and that the F-OB (typically OB123 for the S7-1500F Failsafe_OB) is present in the program blocks. The runtime group must show "Activated" in the editor.
3. Open the F-program, locate the channel driver for the F-DQ output (an instance of F_DQ_BO for boolean outputs, or the F-DB-tag mapping for SIL 3 applications), and check that the input logic driving that block is permanently TRUE or follows the expected process condition. A common defect is leaving the input tied to a default FALSE constant.
4. Go online with the F-CPU, open the watch table, and force the F-output tag to TRUE. If the LED still does not light, the F-runtime group is not consuming the tag. The QBAD flag in the F-DB will also remain TRUE while the F-DQ is passivated.
5. Open Online & diagnostics > Diagnostic buffer on the F-CPU. Look for entries such as Data corruption in the safety program, Discrepancy error, F-signature mismatch, Passivation of F-module, or F-monitoring time exceeded. Each of these must be cleared before the output will update.
6. On the F-DQ itself, use the channel-level diagnostics in TIA Portal (Online & diagnostics > Channel diagnostics) to confirm channel passivation status. A passivated channel shows the value 0 in the PA (passivated) flag regardless of the process image.
7. Measure the 24 V supply at the BaseUnit terminals 24V and M with a calibrated multimeter. Expect 19.2 V to 28.8 V. A missing supply will leave the F-DQ in startup test indefinitely, and the SF LED on the module will be lit red.

6. Resolution Paths

6.1 Path A — Implement a Proper F-Program (Correct Resolution)

This is the correct resolution when the application actually requires a safety-rated output:

1. Add a new F-Function Block, for example FB1000 "SafetyLogic", and declare an input iEnable : Bool and an output qDqChannel : Bool. Mark both as F-tag-compatible in the block interface.
2. Inside the F-FB, assign qDqChannel to the F-DQ channel tag using the channel driver wizard or a manual F-DB mapping. The wizard will instantiate the F-channel driver block (for example FB1131 "F_DQ_BO") and bind it to the slot and channel.
3. Drive qDqChannel from iEnable through any required safety logic (AND with a healthy state, ESTOP1 cascade, two-hand control, guard-door evaluation). For an SIL 3 / Cat. 4 PL e output, use a 1oo2 or 2oo2 evaluation, with discrepancy monitoring on the F-DI input pair.
4. Insert the F-FB call into the F-runtime group (the Main_Safety_RTG1 block) so that the runtime group actually consumes the F-DQ output on every F-cycle.
5. Compile the safety program. TIA Portal will prompt you to assign or re-enter the F-runtime group password; use a strong password of at least 16 characters and store it in the project archive.
6. Download the entire project to the F-CPU. The F-CPU will run a startup test of all F-channels (typically 1 to 5 seconds depending on the module count) and then release the outputs.

To expose the safety output to the HMI, use a standard DB (e.g., DB100 "HmiInterface") into which the F-program copies a non-safety status bit using the F-shared-DB mechanism. The HMI reads the standard DB; the F-program retains exclusive write authority over the F-tag.

6.2 Path B — Migrate to a Standard DQ Module

If the application does not require SIL/PL-rated behavior, replace the F-DQ with a standard ET 200SP DQ module. Suitable substitutes include:

• 6ES7 132-6BF00-0BA0 — DQ 8×24VDC/0.5A, basic
• 6ES7 132-6BH00-0BA0 — DQ 8×24VDC/2A, high feature
• 6ES7 132-6BD20-0BA0 — DQ 4×24VDC/2A, with diagnostics

Standard DQ modules:

• Read and write from the standard process image with no F-runtime group overhead.
• Accept HMI SetBit operations directly without generating safety violations.
• Eliminate the need for a Main_Safety_RTG1 container and its password.
• Do not provide SIL/PL-rated diagnostic coverage, discrepancy monitoring, or internal dark/light test pulses.

To migrate, delete the F-DQ from the device configuration, insert the standard DQ at the same slot, copy the existing wiring from the F-DQ's channel tags to the standard DQ's tags (TIA Portal offers tag-rename refactoring across the whole project), recompile, and download.

6.3 Path C — Recover the Locked F-Password

When you have lost the F-password but need to keep the F-program structure:

1. Connect to the F-CPU online and read the existing program blocks.
2. Export the standard program blocks (OB1, OB100, FCs, FBs, DBs) to a temporary location. Do not export the F-runtime group or any F-block.
3. Create a new TIA Portal project, add the same F-CPU, and re-import the standard blocks.
4. Re-create the safety administration with a new F-password. Re-enter your safety logic.
5. Download the project. The F-CPU will report a "different safety program" diagnostic on the first cycle; acknowledge the new safety program in the safety administration editor. This step is required by TIA Portal to confirm that the engineer is aware the safety program has been replaced.

7. Verification Procedure

After applying Path A or Path B, verify correct operation with the following sequence. Capture each result in the commissioning report.

1. Confirm the F-CPU is in RUN with no diagnostic LED on the F-CPU, the IM 155-6 PN, or the F-DQ itself.
2. Force the HMI-visible enable bit to TRUE from the TP1200 or the watch table.
3. Confirm the F-DQ channel LED illuminates within one F-cycle. With an F-monitoring time of 10 ms and a 2 ms F-OB cycle, expect the LED to come on within 20 ms.
4. Measure 24 VDC at the field-side terminal of the active channel with a calibrated multimeter. Expect Vsupply − 0.5 V typical drop across the high-side switch at 2 A load. Open-circuit terminal voltage should be 24 V ± 5%.
5. Disconnect the safety-relevant sensor. The F-program should drive the output to its safe state within the configured F-monitoring time, the channel LED should extinguish, and the diagnostic buffer should record a passivation event with the channel number.
6. Reconnect the sensor and acknowledge the passivation (operator reset via the F-FB's ACK input or via the standard acknowledgment tag). The output should re-energize after a successful startup test. The startup test re-energizes the output within 5 ms to 2 s depending on the module's startup behavior setting.
7. Power-cycle the F-CPU. After the restart, confirm that the F-DQ output is not energized until the F-program has completed its first valid F-cycle and the startup test has passed. This is the default fail-safe behavior.

8. Parameter Reference for F-DQ 6ES7 136-6DC00-0CA0

9. Safety Design Considerations

F-modules exist because a standard PLC cannot guarantee safe behavior on its own. The ET 200SP F-DQ implements internal dark/light test pulses that momentarily switch each output off and verify that the channel responds correctly. Loads that do not tolerate those test pulses — for example, fast-actuating pneumatic valves with low holding current, or some solid-state relays — require a suppressor circuit, a hold-current resistor, or a load interface that filters the test pulse. A standard DQ cannot perform this self-test, which is precisely why the F-DQ exists.

If you migrate to a standard DQ (Path B), the safety function that the F-DQ was supposed to perform becomes the responsibility of:

• The mechanical design (guard rails, two-hand controls, interlocks).
• The wiring topology (redundant contactors with monitored feedback via a Cat. 4 / PL e contact arrangement).
• The operator procedure (lock-out/tag-out, key switch, hardwired emergency stop that does not depend on the PLC).

Document this change in the machine's risk assessment file per ISO 12100 and update the safety-related parts of the control system (SRP/CS) per ISO 13849-1. The TIA Portal change log alone does not satisfy the safety file requirement.

When the application is genuinely safety-rated, design the F-program to be self-contained. The HMI should observe but never command. The F-program owns the output; the HMI only acknowledges faults and reads the mirrored status. This separation is what keeps the F-CPU in RUN and prevents the "Data corruption in the safety program" diagnostic.

10. Diagnostic Decision Matrix

11. Related F-CPU Generations and Compatibility

The 6ES7 136-6DC00-0CA0 F-DQ is supported on both the S7-1500F and the S7-300F/400F generations, but the F-program structure differs between them. The S7-1500F generation uses the OB123 Failsafe_OB and the modern F-runtime group editor in TIA Portal. The S7-300F/400F generation uses a cyclic interrupt OB (typically OB35) and a different block container structure. When you upgrade a project from an S7-300F to an S7-1500F, TIA Portal will auto-migrate the F-program but will require re-entry of the F-password.

For an ET 200SP station with an integrated F-CPU (such as the CPU 1510SP F-1 PN), the F-runtime group is local to the station and does not depend on a central F-CPU. The diagnostics and the F-channel driver interface are identical, but the engineering project structure places the safety administration under the local F-CPU rather than a rack-mounted F-CPU.

12. Frequently Asked Questions