Using F-DI Cards as Standard DI on S7-1200 FC CPUs: Why It Fails and What Actually Works

An F-DI (Fail-Safe Digital Input) module on a SIMATIC S7-1200 FC controller cannot be repurposed as a standard 24 V DC digital input when the safety function is disabled, the F-program is removed, or the F-DI is physically missing from its slot. The restriction is enforced at three layers: TIA Portal hardware compilation, the F-CPU firmware, and the safety runtime signature. Engineers frequently arrive at this conclusion only after the project refuses to build, the CPU drops to STOP, and OB82 / OB83 / OB86 / OB121 fail to keep the controller in RUN. This reference explains the exact failure mechanism on CPU 1212FC / 1214FC / 1215FC, the F-I/O architecture that makes the F-DI incompatible with the standard process image, the OB limits that block a quick workaround, and the only officially supported path: option handling (configuration control) plus STEP 7 Safety licensing.

1. Problem Statement

Two scenarios drive the question. The first is bench bring-up: an engineer wants to download a standard user program to a CPU 1214FC (article number family 6ES7214-1AF4x-0XB0) without an SM 1226 F-DI in the rack, so that the standard code can be exercised against a non-safety I/O simulation. The second is field service: a maintenance event requires removing an F-DI from a working machine, and the engineer wants the standard portion of the program to continue running while the safety I/O is offline.

Both scenarios end in the same outcome. TIA Portal refuses a clean hardware compile when an F-DI is configured but the F-CPU is not operated in safety mode. The CPU transitions to STOP the moment it boots with a configured-but-absent F-DI in a central-rack slot, and that STOP is unconditional — no organization block on the S7-1200 platform overrides it. The F-CPU behavior is intentional: a SIL 2 / SIL 3 / PL d / PL e controller must reach a defined state on any F-I/O fault, and a half-configured F-application is not a defined state.

2. F-I/O Hardware Architecture in S7-1200 FC Systems

The S7-1200 FC family — CPU 1212FC, CPU 1214FC, CPU 1215FC — integrates the F-CPU logic into the standard PLC. The F-modules used with these CPUs are predominantly from the SM 1226 family, which is mechanically and electrically distinct from the SM 1221 / SM 1222 / SM 1223 standard modules.

Three architectural differences matter to the question of "can I use it as a normal DI":

1. Channel-pair structure with internal discrepancy monitoring. Each F-DI channel is read as a redundant pair (1001, 1002, or 2004 evaluation, depending on wiring). The module does not expose a simple 0/1 to the cyclic process image; it exchanges PROFIsafe telegrams with the F-CPU. The F-CPU's F-runtime library interprets the telegrams and presents a validated bit (plus a quality / passivation flag) to the user program. The standard input area is never populated.
2. Slot signature and PROFIsafe address. The F-DI module holds a non-volatile F_Dest_Add that must match the address TIA Portal generates from the safety program during compile. If the address mismatches, the module substitutes 0 and passivates its channels — the user program reads 0 regardless of the actual input state. The address is set either by a DIL switch on older SM 1226 revisions or by TIA Portal's "Assign PROFIsafe address" online function on newer revisions.
3. Power supply and wiring constraints. F-DI channels need the same wiring as a standard DI plus adherence to SIL/PL category rules (sensor cross-fault detection, test pulse evaluation, dedicated 24 V DC supply per zone, 20.4 V to 28.8 V DC tolerance). Using the module as a "normal" DI bypasses these but still requires a clean 24 V DC rail; a brownout on the supply drops the module out of the PROFIsafe cycle and the F-CPU will demand a safe state.

Because the F-CPU distinguishes the F-IO image from the standard process image at the firmware level, the SM 1226 is not a drop-in replacement for an SM 1223. The CPU's safety firmware rejects any F-slot that does not have a valid F-runtime connection, even if the standard user program never reads the F-DI tags.

3. Why TIA Portal Refuses to Compile the Hardware Configuration

When an F-DI sits in the device configuration of an S7-1214FC project, TIA Portal performs two parallel checks: the standard hardware consistency check (slot populated, article number known, address range free, signal module width valid for the backplane) and the safety consistency check (F-runtime group present, F-CALL in the user program, PROFIsafe address assigned, F-monitoring time valid, F-I/O DB structure consistent).

If the user has disabled safety globally — Device configuration → CPU properties → "Operate F-CPU in safety mode = No" — or removed the F-runtime group from the program blocks, the F-DI fails the second check. The compiler produces a configuration error along the lines of:

[Device: CPU 1214FC] F-module "SM 1226 F-DI 16x24VDC" (slot 1) is configured but the F-CPU is not operated in safety mode.
[Compile: Hardware (1000:3000)] The configuration cannot be downloaded to the target device.
[Compile: Safety (2000:4500)] PROFIsafe address for F-module slot 1 is not assigned.

The TIA Portal V20 Configuring an F-CPU documentation states that an F-CPU is always configurable in STEP 7, but using F-I/O in safety mode requires the STEP 7 Safety optional package. Without the safety runtime on the PLC, the F-DI is not recognized as a usable I/O module by the firmware. This is not a flag that can be bypassed; the safety configurator owns the F-I/O slot validation, and the standard device editor cannot override it.

The most direct evidence is the compile result. If the user opens a project with an S7-1214FC and an SM 1226 F-DI in slot 1, then sets the CPU to "Operate in safety mode = No" and tries to compile, TIA Portal raises errors at the hardware configuration level (not the program blocks level) and the project will not download. Removing the F-DI from the device configuration is the only way to obtain a clean build when safety is disabled, which by definition defeats the original purpose of keeping the F-DI configured.

4. OB Behavior: Why You Cannot Mask the Missing Module

Engineers accustomed to S7-300 / S7-400 OBs often try to use OB82 (Diagnostic Error Interrupt), OB83 (Pull/Plug of Modules), OB86 (Rack/Station Failure), or OB121 (Programming Error) to keep the CPU in RUN when an F-DI slot is empty or absent. On the S7-1200 platform these OBs behave differently from the larger systems, and on central-rack F-modules the CPU transition is unconditional.

The S7-1200 supports OB1, OB10 (time-of-day), OB20–23 (time-delay), OB30–38 (cyclic), OB40–47 (hardware interrupts), OB55–57 (status, update, profile), OB80 (time error), OB82, OB83, OB86, OB100 (warm restart), OB101 (hot restart), and OB102 (cold restart). OB121 is not in the supported list, which differs from the S7-1500 platform where OB121 is available. The "Which organization blocks can you use in STEP 7 (TIA Portal)?" Siemens help topic is the canonical reference for this list.

For the F-DI scenario the conclusion is clear: no S7-1200 organization block can keep the CPU in RUN if a configured F-DI is physically missing from its central-rack slot. OB83 is the closest semantic match (a pulled or missing module in a central rack is precisely the OB83 trigger), but the firmware is hard-coded to STOP the CPU on this event for safety integrity reasons. The CPU must reach a defined state, and a half-configured F-CPU with an unverified F-DI is not a defined state.

5. Configuration Control and Option Handling: The Officially Supported Path

For machine builders with multiple variants, Siemens supports option handling (also called configuration control) on both S7-1200 and S7-1500 controllers. With option handling, the project is built against the maximum hardware configuration, and at startup the user program tells the CPU which slots are actually populated by writing a control data record. The CPU re-initializes its I/O image to match the variant, and the F-runtime group is adjusted accordingly.

The relevant Siemens help topics are:

• Configuring standard machines in TIA Portal (configuration control) — describes the general mechanism for standard CPUs and standard I/O.
• What should you watch for with configuration control (option handling) with fail-safe controllers S7-1200 and S7-1500? — describes the additional constraints when the controlled slots are F-I/O.

The procedure for option handling on an F-CPU is:

1. Configure the maximum hardware, including every F-DI and F-DQ module that any variant might use. Slot numbering must be continuous from the CPU's perspective; gaps are not allowed.
2. Enable option handling in the CPU properties: Device configuration → CPU → "Support option handling" = Yes.
3. Assign each optional module to an option slot range. TIA Portal generates a control data record (typically a DB of WORD values indexed by slot) that you write at startup.
4. At runtime, write the control data record once at startup using the WRREC instruction. The CPU re-initializes the I/O image to match the variant. This step is mandatory before the F-runtime group is processed.
5. For F-I/O, the F-runtime group is also adjusted. Channels that are not physically present are reported as passivated (F-I/O DB bit = 0, passivation bit = 1). The F-program must tolerate passivated channels — the typical pattern is to treat passivated channels as "no demand" and route the safety output to its de-energized safe state.

This path is officially supported and avoids the "remove module to test" trap. It also keeps the safety signature valid, because the F-CPU still sees a consistent F-I/O configuration — the optional slots are explicitly marked as not present rather than missing. The trade-off is implementation cost: the control data record, the startup logic, the variant selection mechanism (HMI selector, DIP switch, nameplate barcode, or a project constant), and the F-program passivation handling all need to be developed and validated.

For a bench where the F-DI is not in the cabinet at all, option handling is technically the correct way to bring the F-CPU to RUN. Many teams conclude that the engineering cost is disproportionate to the value during bench bring-up, and revert to a different physical CPU (a non-F 1214) for the standard code bring-up phase. The standard code can be re-linked to the F-CPU for the final cabinet integration once the F-DI is installed and the F-program is loaded.

6. Test Bench Workarounds: What Works, What Does Not

Three common bench scenarios and the outcome on S7-1200 FC firmware:

6.1 F-CPU with F-DI configured, module physically absent

Outcome: CPU goes STOP on the first startup or the first scan cycle. OB83 is generated, but loading OB83 does not keep the CPU in RUN — central-rack STOP is forced. TIA Portal download may succeed because the configuration is internally consistent, but the PLC transitions to STOP and remains there. There is no way to bring the CPU to RUN from a missing F-DI without reinserting the module or activating option handling. The diagnostic buffer records an event in the 0x13A1 / 0x13A2 range (module removed / not available) followed by a CPU STOP entry with cause "Module failure on central rack".

6.2 F-CPU with safety deactivated, F-DI still in device configuration

Outcome: TIA Portal refuses to compile. The error chain is described in the project tree under "Safety administration" and "Device configuration". The fixes are mutually exclusive: (a) enable safety mode and load a valid F-program, or (b) remove the F-DI from the device configuration. Option (b) allows the standard project to compile and the CPU to run, but it physically detaches the safety I/O from the program — the safety program is no longer in scope, and the F-DI will not work when reinserted unless the F-CPU is re-configured for safety mode, the F-program is reloaded, and the PROFIsafe address is re-assigned.

6.3 F-CPU with F-DI configured and present, F-program loaded, no test sensors wired

Outcome: This is the supported commissioning state. The F-DI will read 0 (no sensor signal) for every channel. Channels that drive the safety output demand will cause the F-program to demand a safe state (typically de-energize the F-DQ). The standard user program can still be exercised through simulated standard I/O (PLCSIM or signal generators on non-F channels). The F-DI diagnostics show "discrepancy time exceeded" or "sensor supply not OK" on unwired channels; this is expected and does not stop the F-CPU as long as the F-program handles it.

Using PLCSIM (S7-PLCSIM or PLCSIM Advanced in TIA Portal V20 and later) is the only software environment where a full S7-1200 FC including F-DI can be simulated. PLCSIM simulates the F-CPU, the F-runtime, and the F-DI channels as PROFIsafe-talking virtual modules. The simulator does not require any physical hardware. The limitation is that PLCSIM is a TIA Portal feature; it does not run on the real CPU. Once you download the project to a real S7-1214FC, the simulator state is replaced by the physical configuration, and any F-DI that is not physically present will trigger the central-rack STOP described in section 4.

A practical bench procedure that works:

1. Open the project in TIA Portal with the Safety optional package installed.
2. Start PLCSIM (or PLCSIM Advanced) with the F-CPU image.
3. Load the full project (standard + safety) to the simulated PLC.
4. Exercise the standard program against simulated standard I/O and the F-program against simulated F-DI channels.
5. When the bench validation is complete, download the same project to the real F-CPU with the F-DI physically present. If the physical cabinet passes, the F-program is verified.

7. STEP 7 Safety Licensing and F-CPU Configuration in TIA Portal V20

Configuring an F-CPU does not by itself require a paid license. The TIA Portal V20 documentation Configuring an F-CPU clarifies that any F-CPU is configurable in STEP 7 even without the STEP 7 Safety optional package. The package is required only when the engineer needs to edit the F-program, assign PROFIsafe addresses, compile the safety portion of the project, or generate the safety acceptance test report.

For an F-CPU in a non-safety project (i.e., a project where the F-I/O is not in the device configuration), the base TIA Portal is sufficient. The CPU runs the standard program and the F-CPU capability sits idle. The moment an F-DI is added back, TIA Portal demands the Safety optional package to compile the project, regardless of whether the F-program is actually called from the standard OB1.

Removing the F-DI from the project downgrades the licensing requirements to the base TIA Portal. This is one practical reason engineers try to bypass the F-DI: they want to keep the F-CPU as the controller but compile in a base TIA Portal environment because the Safety optional package is not available. The honest engineering answers are: (a) acquire the Safety optional package, (b) use a non-F 1214 (6ES7214-1AG40-0XB0 in the DC/DC/DC variant) for the standard build, or (c) move the bench work to PLCSIM Advanced. There is no fourth option that keeps the F-DI configured and the F-CPU in safety-disabled mode.

8. Verifying the Configuration: Diagnostic Steps

When a project with an S7-1214FC and an F-DI is not behaving as expected, walk through the following diagnostic sequence before changing any hardware.

1. Check the safety state in the device configuration. Right-click the CPU → Properties → "Safety" tab → "Operate F-CPU in safety mode". If this is "No", the F-DI in the project will not compile, regardless of what is in the program blocks.
2. Check the safety program presence. Open the program blocks tree. There must be at least one F-runtime group, typically a Main_Safety OB and an F-CALL block inside it. If the F-runtime group is missing, the F-DI is orphaned and the compile will fail.
3. Check the diagnostic buffer of the CPU. In online mode, PLC → Online & diagnostics → Diagnostic buffer. Look for events of class "CPU STOP", "Station failure", or "PROFIsafe address mismatch". The event ID and timestamp pin down the failure mode. The classic signature for a missing F-DI is event 0x13A1 (module removed) followed by 0x4307 (PROFIsafe communication error) and 0x4301 (CPU STOP due to F-I/O fault).
4. Check the F-monitoring time and PROFIsafe address on the F-DI. In the safety editor, open the F-DI → "PROFIsafe" tab. The F-monitoring time default of 150 ms is acceptable for most applications; lowering it below 50 ms causes nuisance passivations on noisy networks. The F_Dest_Add must match the address assigned online by TIA Portal; mismatched addresses produce persistent passivation.
5. Check the F-DI slot physically. If the module is missing, the CPU reports "Module removed or not available" in the diagnostic buffer with event ID 0x13A1 / 0x13A2. If the module is present but not powered, the event is 0x13A4 (module faulty).
6. Validate the option handling data record. If option handling is enabled, ensure the WRREC instruction executed successfully (RET_VAL = 0) and the response data record confirms the desired option slot map. A typical error is a wrong slot index in the control DB; the CPU reports this as a configuration error rather than a STOP.
7. Check the safety signature. The F-CPU compares the safety signature stored in retentive memory to the signature of the loaded safety program on every restart. A mismatch (caused by editing the F-program while the F-DI was offline, or by downloading the project with a different TIA Portal version) produces a safety signature error and the F-CPU stays in STOP until the signature is acknowledged.

For bench bring-up, the simplest verification is to use PLCSIM with the F-DI simulated. Once the simulation passes, the same project is downloaded to the real hardware. If the real hardware then enters STOP while the simulation was clean, the issue is the physical configuration (slot, PROFIsafe address, supply voltage, F-monitoring time, sensor wiring) — not the F-program.

9. Field-Proven Constraints and Safety Engineering Practice

Several constraints come up repeatedly in field retrofits and are worth stating explicitly.

• Do not de-energize a running F-CPU's safety I/O while in operation. If a service event requires removing the F-DI, follow the OSHA 29 CFR 1910.147 lockout/tagout procedure for hazardous energy isolation. The standard covers placement of lockout devices on energy-isolating points and verifies that the equipment is isolated and de-energized before any service work — OSHA 1910.147 is the public reference. Removing an F-DI from a live system is a controlled service event, not a hot-swap; the F-CPU will STOP regardless of the OB configuration.
• Do not bridge a missing F-DI with a standard DI in the same slot. The mechanical keying, the backplane signaling, and the firmware probe are all specific to the SM 1226 article number. A standard SM 1223 in the same physical slot is detected as a different article number, the configuration will not accept it, and the CPU reports a module-fault event.
• Do not rely on OB82 / OB83 / OB86 / OB121 to keep the CPU in RUN. None of these override the central-rack STOP behavior. The PLC will STOP regardless of OB presence or content, and OB121 is not even available on the S7-1200 platform.
• Do not bypass the safety program by commenting out F-CALL. The safety signature changes, the F-CPU will not start the safety portion, but the F-DI hardware will still demand a valid F-runtime connection. The F-CPU enters a safety signature mismatch state and remains in STOP.
• Plan for the safety optional package license in the project budget. Without it, the F-CPU is effectively a paperweight on the safety portion of the project — the F-CPU will still appear in the device catalog, but anything that touches F-I/O will be blocked at compile time.
• Treat F-DI channel passivation as a deliberate state, not an error. Passivated channels read 0 and the F-I/O DB exposes a passivation flag. The F-program must route around passivated channels and demand a safe state, not raise a non-recoverable fault. This is a normal part of the safety lifecycle (commissioning, sensor replacement, restart after a detected fault).

10. Practical Recommendations for the S7-1214FC Bench Engineer

Based on the constraints above, the practical decision tree for the bench engineer is:

1. If the bench needs to validate the standard PLC program only, replace the F-CPU with a non-F 1214 (6ES7214-1AG40-0XB0 in the DC/DC/DC variant) for the bench, and keep the F-CPU in the cabinet. The standard program will run identically, and the hardware compile will be clean without the Safety optional package.
2. If the bench must use the F-CPU, simulate the F-DI with PLCSIM or PLCSIM Advanced in TIA Portal V20. Do not attempt to bring up the real F-CPU without either a real F-DI or option handling.
3. If option handling is acceptable as a project cost, implement it as a long-term machine-variants feature, not as a one-off test workaround. Document the control data record, the WRREC call, the variant selection mechanism, and the F-program passivation handling in the project manual.
4. If the F-CPU is forced into STOP on a missing F-DI in production, treat it as a hardware fault, not a software bug. Investigate the slot, the connector, the PROFIsafe address, the 24 V DC supply, and the F-monitoring time. The PLC is doing what the safety case requires, and a field engineer who "fixes" the STOP by removing the F-DI from the project is breaking the safety case.

11. Diagnostic Decision Diagram

12. Summary

An F-DI module on an S7-1200 FC controller cannot be repurposed as a standard digital input when the safety program is disabled, when the F-DI is removed from the device configuration, or when the F-DI is physically missing from its central-rack slot. TIA Portal refuses the hardware compile, the F-CPU firmware refuses to leave STOP for a missing F-DI in the central rack, and no S7-1200 organization block (OB82, OB83, OB86, or OB121) can override this behavior. The officially supported path for absent F-I/O at runtime is option handling / configuration control, which requires the STEP 7 Safety optional package and significant engineering effort. For bench bring-up, the most efficient options are PLCSIM simulation, a non-F 1214 CPU for the standard code, or full option handling for production variants. Treat the F-CPU's STOP transition on a missing F-DI as a safety feature, not a bug, and follow OSHA 1910.147 lockout/tagout for any field service that requires F-I/O removal.

FAQ