Resolving F-I/O Access Error on Siemens 4/8 F-DI with SFDOOR

Problem: F-I/O Access Rejection on SFDOOR Inputs

During commissioning of an ET 200S fail-safe I/O station controlled by an F-CPU 1516-3 PN/DP (6ES7516-3AN02-0AB0), engineers routinely wire safety-door interlock switches into the 4/8 F-DI 24VDC HF electronic module and assign the two input signals directly to the IN1 and IN2 parameters of the SFDOOR function block from the Safety Function Library. With TIA Portal V13 (Update 9 and similar versions), the safety program is rejected with the diagnostic entry:

F-I/O access 'Safety_Door_SW2' accesses a channel of the F-I/O that is either disabled or cannot be used.

The same string is raised for the second instance, e.g.:

F-I/O access 'S6004EmrPushbuttonChB' accesses a channel of the F-I/O that is either disabled or cannot be used.

Both faults point to the same root mechanism: PROFIsafe rejects a logical F-channel combination that is not permitted by the module's hardware evaluation model. Channel tagging, slot assignment, and PROFIsafe address configuration may all appear correct in the device view, but the F-runtime still refuses to bind the symbol to the F-I/O.

Affected Hardware and Software Stack

The diagnostic and channel-grouping rules for the related F-DI 8x24VDC HF (6ES7136-6BA01-0CA0) of the ET 200SP family and the 4/8 F-DI/4 F-DO DC24V/2A PROFIsafe digital electronic module in ET 200pro follow the same evaluation logic and are documented in the Fail-Safe Modules Manual Collection and the F-DI 8x24VDC HF device manual.

Root Cause: Channel-Group Architecture vs Sensor Evaluation

The 4/8 F-DI 24VDC HF has eight physical input channels split into two input groups:

• Group 1: Channels 0, 1, 2, 3
• Group 2: Channels 4, 5, 6, 7

A 1oo2 (one-out-of-two) sensor evaluation requires the two F-channels to be adjacent and belong to the same group. Valid 1oo2 pairs are therefore (0,1), (2,3), (4,5), and (6,7). The pair (0,4) used in the original configuration straddles the two groups and is not a legal PROFIsafe channel pair. The F-CPU detects this at compile/runtime and refuses the binding, which surfaces as the "disabled or cannot be used" message.

Sensor Evaluation: 1oo1, 1oo2, and 2-Channel Equivalent

Siemens safety blocks distinguish between two physical sensor wirings. Selecting the wrong mode for the wiring you have is the most common cause of the fault.

If you need two independent sensor signals at channels 0 and 4, you are not implementing a 1oo2 sensor pair - you are implementing two 1oo1 evaluations. Drop a second instance of the block and configure each with 1oo1.

SFDOOR Block Interface Recap

The SFDOOR block (Safety Function Library > Safety > Door Monitoring) is a Type 3 / Type 5 safety block per IEC 61131-3 with the following input surface:

Critical detail: IN1 and IN2 must be F-symbols generated by TIA Portal from the F-I/O configuration. Assigning a non-F tag or a tag whose channel is "disabled / cannot be used" triggers the F-runtime fault. The compiler does not always reveal this - the F-runtime does, the first time the safety program is downloaded and the F-CPU is restarted.

Solution Path A: Two Independent 1oo1 Evaluations

Use this path when the two sensors are physically separate devices (e.g. a guard-door switch on channel 0 and a magnetic interlock on channel 4) and no cross-fault monitoring between them is required.

1. Open the F-DI device view in TIA Portal.
2. For channel 0, set Sensor evaluation = 1oo1 evaluation, Type of sensor interconnection = Single-channel.
3. For channel 4, set Sensor evaluation = 1oo1 evaluation.
4. Leave Discrepancy time = default 1000 ms (not used in 1oo1).
5. In the safety program, replace the single SFDOOR block with two instances: SFDOOR_Door1 (IN1 <- Ch0 tag) and SFDOOR_Door2 (IN1 <- Ch4 tag).
6. Combine the two Q_Door outputs with an F-AND or F-Vote block if a single safety function must close only when both doors are closed.
7. Recompile the safety program (right-click > Compile > Software (rebuild all)).

Solution Path B: 1oo2 Evaluation with Adjacent Channels

Use this path when the sensor is a true dual-channel switch (e.g. a 3-terminal Euchner CKS or Schmersal RSS 36) and SIL 3 / PL e is required.

1. Re-wire the switch into an adjacent pair. Choose (0,1) for group 1 or (4,5) for group 2 based on terminal strip layout.
2. Open the F-DI device view and select the lower channel of the pair (e.g. channel 0).
3. Set Sensor evaluation = 1oo2 evaluation, Type of sensor interconnection = 2-channel equivalent (or 2-channel non-equivalent if the switch is wired NC/NO).
4. Set Discrepancy time to the value dictated by your risk assessment. Typical: 100 ms - 1000 ms. Below 100 ms risks nuisance trips from contact bounce; above 3000 ms violates IEC 62061 response-time constraints in most machinery applications.
5. Enable Short-circuit test (test pulse from the module) only if you use sourcing outputs without external short-circuit detection. Disable it if you are using a switch that requires continuous power.
6. Verify that the second channel of the pair automatically inherits the 1oo2 setting in the channel table.

Step-by-Step Reconfiguration in TIA Portal V13

1. Open the project and select the ET 200S station in the project tree.
2. Double-click the 4/8 F-DI module to open the device view.
3. Switch to Properties > I/O addresses and confirm the F-channel tags are generated. The default symbolic names follow the pattern I_{Slot}_CH{ChNo}, e.g. I_4_CH0 and I_4_CH4.
4. Switch to Properties > Module parameters. Select the offending channel pair and apply the corrected evaluation mode per Solution Path A or B above.
5. If the F-channel tags do not refresh, perform the Re-Tag procedure: clear the Tag for the active channel field (set to <none>), apply, then re-assign the symbolic tag. This forces the F-shim to rebuild the channel descriptor table.
6. Save and recompile the project. The "F-I/O access ... disabled or cannot be used" diagnostic should disappear from the compile log.
7. Download the hardware configuration and the safety program to the F-CPU. Use the menu Online > Download to device and confirm the safety password prompt.
8. Run the F-CPU through one STOP > RUN cycle to re-initialise the PROFIsafe channels.

Verification

1. Open Online & diagnostics > Diagnostic buffer of the F-CPU. Confirm there are no new entries containing "F-I/O" or "PROFIsafe".
2. Open Watch table_1 (or create a new one) and force the safety tags (password required). Verify that:
   • Setting I_4_CH0 = 1 updates SFDOOR_Door1.IN1 with no diagnostic interruption.
   • Setting I_4_CH4 = 1 updates SFDOOR_Door2.IN1 with no diagnostic interruption.
   • For 1oo2 mode, forcing channels out of the discrepancy window (e.g. Ch0 = 1, Ch1 = 0) raises a discrepancy diagnostic and trips Q_Door to 0 after the configured discrepancy time elapses.
3. Open the F-IO DB and confirm the QBAD (quality bad) bit for each bound channel is 0.
4. Open Online & diagnostics > Safety > Status of the F-CPU. The safety summary must read "Safety mode active" with no channel errors.
5. Document the wiring, the parameter set, and the discrepancy time in the safety validation report per ISO 13849-2 / IEC 62061.

Diagnostic Buffer Entries You Will See

Hardware Re-Tag Recovery (Field-Proven Workaround)

On TIA Portal V13 Update 9 (and the V13 SP1 family), engineers have observed a behaviour in which the F-channel binding cache is not invalidated when the channel's Sensor evaluation is changed in place. The symptom is the same diagnostic as the original fault, even after the correct mode is selected. The recovery is to force the F-shim to re-derive the channel tag:

1. Open the module's Properties > Module parameters.
2. For the affected channel, clear the Tag for the active channel field (set to <none>) and click Apply.
3. Re-select the symbolic tag (e.g. Safety_Door_SW2_IN1) from the drop-down.
4. Click Apply, save the project, recompile, and download.

This clears the cached channel descriptor and forces a fresh PROFIsafe slot/subslot binding. The fault clears in the compile log and at the next F-CPU restart.

Common Pitfalls and Field Lessons

• Mistaking two independent sensors for a 1oo2 pair. If each sensor has its own wiring and no cross-fault monitoring is required, use two 1oo1 instances. Do not pick 1oo2 just because the safety block has an IN2 input.
• Wiring into a non-adjacent pair. Channel 0 and channel 4 are not a legal 1oo2 pair. Always check the module's channel diagram; on the 4/8 F-DI it is group (0,1,2,3) + group (4,5,6,7).
• Discrepancy time too aggressive. 0 ms or sub-50 ms values cause nuisance tripping from contact bounce. Use 100 ms as a minimum, 300-1000 ms for most electromechanical switches.
• Short-circuit test left on with sourcing sensors. If the sensor is a 3-wire PNP device that is permanently powered, the test pulse can cause a transient loss of sensor voltage and create a false discrepancy. Disable the test pulse or use a sensor that tolerates the 1 ms interruption.
• Re-tagging not performed after parameter change. TIA Portal V13 sometimes retains the old channel descriptor; always re-tag the active channel after a parameter change, or the diagnostic will persist.
• Mixing F-IO and standard IO on the same slot descriptor. Each F-channel can only be bound to one safety block at a time. Reusing the same F-symbol in two blocks will fail the compile.
• PROFIsafe address mismatch. The F-destination address (1..65535) configured in TIA Portal must match the rotary switch / DIP on the physical module, otherwise the F-IO stays in passivation with a similar "channel disabled" appearance.

Cross-Reference: ET 200SP F-DI 8x24VDC HF

The same evaluation logic applies to the F-DI 8x24VDC HF (6ES7136-6BA01-0CA0) in the ET 200SP family, which supports additional operating modes ("Digital inputs", "Counter", "Standstill and Overspeed") as documented in the F-DI 8x24VDC HF device manual. When an F-DI 8x is configured in Standstill and Overspeed mode, the relevant channel pair is reserved by that function and cannot be used by SFDOOR - this manifests with the identical "disabled or cannot be used" diagnostic. Always confirm the channel's operating mode in the device view before re-tagging.

Putting It Together: Decision Matrix

FAQ