1. Problem Overview
The SIMATIC S7-416F CPU (6ES7416-3ES07-0AB0 and related variants) operates fail-safe I/O through the F-runtime group, with F-DI modules such as the SM 326F (6ES7326-1BK02-0AB0, 24xDC 24V) performing the physical acquisition of safety-relevant digital signals. When a single F-DI channel pair is configured for 1oo2 evaluation (1-out-of-2), the module continuously compares the two physical input signals assigned to one logical channel. If the signals deviate for longer than the configured discrepancy time, the F-system reports a discrepancy error and the standard response is to passivate the affected channel — the same behavior triggered by a channel fault.
The specific failure mode reported in this scenario is symptomatic of a programming/configuration environment issue rather than the parameter value itself:
- F-DI module configured for 1oo2 evaluation with discrepancy time = 100 ms.
- One channel of the pair exceeds the 100 ms window intermittently (typically a sensor with bounce or a contactor with mechanical lag).
- The operator increases discrepancy time (e.g., to 300 ms) to absorb the legitimate hardware delay.
- After download, the module remains in fault state and will not return to RUN even with the new value.
- Reverting to the previous 100 ms value restores normal operation, confirming that the parameter range itself is valid but the modified project is not being accepted by the F-system.
Because the discrepancy error behaves identically to a channel fault, both events trigger channel passivation. The standard remedy — accept a wider discrepancy window — is technically correct, but the surrounding project state (F-signature, F-block consistency, F-CPU operating mode, EEPROM write status) gates whether the change is accepted at all. This article addresses the conditions under which a discrepancy-time change is accepted and the procedure to recover when it is not.
2. F-DI Module Variants and 1oo2 Channel Pairs
The S7-416F couples to the following F-DI modules commonly used in 1oo2 configurations:
| Module | Order Number | Channels | Nominal Voltage | Discrepancy Range |
|---|---|---|---|---|
| SM 326F DI 24xDC 24V | 6ES7326-1BK02-0AB0 | 24 | 24 V DC | 1 ms – 30000 ms |
| SM 326F DI 8xAC 120/230V | 6ES7326-2BF01-0AB0 | 8 | 120/230 V AC | 1 ms – 30000 ms |
| SM 326F DI 24xDC 24V (older) | 6ES7326-1BK01-0AB0 | 24 | 24 V DC | 1 ms – 30000 ms |
In 1oo2 evaluation, two physical input channels are bonded into one logical channel by the F-DI firmware. The discrepancy analysis runs entirely inside the module's safety layer; the user program receives a single passivation bit for the logical channel plus a discrepancy-error flag. The pair assignment is fixed in the hardware: e.g., channels 0 and 1 form logical channel 0, channels 2 and 3 form logical channel 1, and so on. Reassigning a pair to a different logical channel is not supported.
3. Discrepancy Time — Definition and Range
Discrepancy time is the maximum permitted interval between the two redundant input signals of a 1oo2 / 2oo2 channel pair. If the inverse of the channel that is currently logic 0 does not appear within this window, the F-DI module raises a discrepancy error. Per the Siemens TIA Portal fail-safe modules documentation, a discrepancy error is handled by the safety program identically to a channel fault — meaning channel passivation occurs and the F-runtime group's passivation logic takes over.
Key parameter properties:
- Default value: 100 ms (matches the symptom described in the source case).
- Minimum: 1 ms.
- Maximum: 30000 ms (30 s), although values above several seconds are rarely justified for digital inputs and are typically flagged as project warnings.
- Resolution: 1 ms increment.
- Behavior on overshoot: Channel passivation, F-CPU entry in diagnostic buffer, OB82 (diagnostic interrupt) call if configured, and if the F-program uses F-channel passivation logic — full de-energization of the affected safety zone.
The discrepancy time must be greater than the worst-case signal asymmetry of the sensor pair (mechanical bounce, contactor drop-out, optical sensor dark/light transition). A value of 100 ms is the Siemens default because it covers most electromechanical inputs (limit switches, contactors, E-stops with mechanical linkages). Increasing the value reduces nuisance trips but lengthens the time before a true discrepancy is recognized.
4. Preconditions Required Before Modifying Discrepancy Time
Discrepancy time is a safety-relevant parameter. The F-CPU enforces several preconditions; if any are violated, the new value is silently rejected or the F-CPU remains in STOP/Fault. All of the following must be true before the parameter download:
- F-CPU in STOP or RUN with password-protected online access. The F-CPU does not need to be in STOP to change discrepancy time, but a safety-relevant parameter change requires the F-password to be entered online. The STEP 7 Safety password dialog appears when the modified F-I/O parameters are compiled/downloaded.
- F-signature of the F-runtime group must be re-computed. Any modification to an F-block, F-DB, or F-I/O parameter invalidates the current collective F-signature. A new F-signature is generated automatically during the next compile cycle of the safety program, but the user must acknowledge the change in the F-admin dialog.
- F-program must compile without errors. The safety compiler in STEP 7 Safety (S7 Distributed Safety or F-Configuration Pack depending on the editor) must complete successfully. A non-zero return code from the safety compiler produces an "incomplete F-block container" — the project compiles in the standard sense but the F-blocks are not regenerated, and the discrepancy-time change is never written to the F-I/O parameter set.
- F-I/O parameter assignment must be consistent. The 1oo2 channel pair, sensor evaluation, and discrepancy time are part of the F-I/O parameter set. If only the standard project is downloaded (not the F-blocks), the parameter change is dropped on the next F-CPU restart.
- Consistent F-block download to the F-CPU. The "Download to Target System" operation must include both the standard blocks and the F-blocks. Selecting only the standard blocks leaves the F-runtime group running on the old F-I/O parameter set.
- PLC operating mode allows safety parameter update. Some firmware versions of the S7-416F (FW ≥ 6.0) require the PLC to be in STOP for the F-I/O parameter set to be re-initialized. In RUN, the parameter set is held in the F-DI module's volatile mirror; on the next warm restart it is reloaded from the F-CPU's retentive F-parameter set. Forcing STOP and a subsequent RUN (or MRES) ensures the new value is applied.
5. Symptom-to-Cause Matrix
| Symptom | Likely Cause | Verification |
|---|---|---|
| Module stays in fault after discrepancy-time increase; reverting to old value restores operation | Compiler did not regenerate F-I/O parameter set; old F-signature still active | Check F-admin dialog collective F-signature; force full recompile |
| Online discrepancy time shows old value after download | Download to target system included only standard blocks, not F-blocks | Repeat download with "Include F-blocks" selected |
| F-CPU in STOP, SF LED on, diagnostic buffer shows "F-I/O parameter assignment error" | F-password not entered or wrong F-password | Enter the F-password during the online download; verify via F-admin dialog |
| F-CPU RUN, F-DI module SF LED steady red, channel status = passivated | Discrepancy error still active because input signals continue to deviate beyond new value | Check the two physical inputs with a scope; verify sensor wiring and contact bounce |
| Discrepancy-time field grayed out in HW Config | Channel pair not configured as 1oo2; only 1oo1 or 2oo2 channels expose the parameter | Open channel properties; confirm evaluation = 1oo2 sensor evaluation |
| Compile completes with no error, but project upload from CPU shows the old discrepancy time | F-block container from CPU is older than the offline F-block container | Force "Download to Target System" with "Overwrite target system" option; do not use "Upload to PG" |
6. Step-by-Step Procedure: Correctly Changing the Discrepancy Time
- Open HW Config. In STEP 7 (Classic) for the S7-400F, navigate to the rack containing the SM 326F module and open its properties.
- Open the channel pair. Double-click the 1oo2 channel pair. Verify the channel pair number (e.g., channel 0 = inputs 0 and 1) and the sensor evaluation mode.
- Modify the discrepancy time. Enter the new value in ms. Do not exceed 30000 ms. Typical engineering values: 100 ms (default), 200–500 ms (mechanical contactors, valve position feedback), 1000–2000 ms (slow hydraulic/pneumatic actuators). Avoid values > 5000 ms without risk assessment — the longer the discrepancy window, the longer a genuine single-channel fault is masked.
- Save and compile HW Config. Station → Save and Compile. Verify the diagnostic buffer does not show parameter errors.
- Open the safety program editor. In STEP 7 Safety (S7 Distributed Safety) or the F-Configuration Pack for S7-400F, open the F-runtime group containing the F-DB for this module.
- Trigger a full safety recompile. Right-click the F-runtime group → Compile. Watch the output window — the safety compiler must report "Compilation completed successfully" and list a new collective F-signature.
- Open the F-admin dialog. Verify that the collective F-signature has changed and that the new discrepancy time is reflected in the F-I/O parameter view.
- Download the complete project. Target System → Download to Target System. Select the option to include F-blocks. Enter the F-password when prompted.
- Force an F-CPU restart if necessary. On firmware versions that hold the F-I/O parameter set in volatile mirror memory, perform a STOP → RUN transition (or STOP → MRES → RUN) to re-initialize the F-DI module with the new parameter set.
- Read back the parameter. Online → Monitor/Modify. Open the F-DI channel properties; verify the discrepancy time online value matches the offline value.
7. Compiler-Related Failure Mode (Matches the Reported Symptom)
The reported root cause — "compilation of the safety software produced no error messages, but the project was still in a stale state; multiple EEPROM downloads eventually resolved it" — is consistent with a known intermittent behavior of the STEP 7 Safety compiler when the F-block container is partially cached. Symptoms and remediation:
- Symptom: Standard compile reports success. Safety compile reports success. Diagnostic buffer shows no parameter errors. Yet the F-DI module accepts the old discrepancy time and rejects the new one as if it were invalid.
- Diagnosis: The F-block container on the PG/PC disk has been updated, but the F-block container being staged for download is from a previous compile cycle. STEP 7 caches F-block binaries in the project's global directory; if the cache is not invalidated (e.g., because a referenced F-FB was modified and then reverted in the same session), the cache may still hold the previous parameter set.
- Remediation A — forced full recompile: In the safety editor, right-click the F-runtime group → Properties → recompile. Alternatively, delete the *compiled F-DBs* in the offline block container and trigger a fresh compile.
- Remediation B — multiple EEPROM downloads: Project → Save to Memory Card → EPROM (or MMC). Repeat 2–3 times. Each write forces STEP 7 to flush the F-block container to the memory card, which the F-CPU then reads on the next restart. The procedure is operationally acceptable but should be considered a workaround, not a primary fix.
- Remediation C — clean rebuild: Save the project under a new name. Delete the F-block folder from the project directory. Reopen and recompile from scratch. This eliminates any residual cache state.
8. Diagnostic Buffer Entries
When a discrepancy-time change fails to apply, the S7-416F diagnostic buffer typically contains one or more of the following entries. Reading these entries is the fastest path to confirming whether the parameter was accepted:
| Event ID (hex) | Meaning | Resolution |
|---|---|---|
| 0x75A0 | F-I/O parameter assignment error — the parameter set loaded into the F-DI module does not match the F-CPU's expected set | Re-trigger F-I/O parameter assignment; verify F-password and F-signature |
| 0x75A1 | F-I/O channel passivated | Acknowledge error only after the physical cause is resolved; do not acknowledge to clear a discrepancy |
| 0x75B0 | F-I/O parameter set corrupt / inconsistent | Force full F-program recompile and re-download |
| 0x75C0 | Discrepancy error on F-DI channel | Increase discrepancy time beyond measured signal asymmetry; verify sensor wiring |
| 0x75C1 | Discrepancy error cleared | Informational; the F-DI module will automatically reintegrate on the next passivation-clear |
| 0x70A2 | Module parameter assignment error (standard, not safety-specific) | Check standard HW Config parameter consistency |
9. Verification Procedure
- After download, place the F-CPU in RUN. Confirm the SF LED on the F-DI module is off.
- Open the module's online diagnostics. Confirm channel status = "not passivated" for all 1oo2 channel pairs.
- Force the sensor pair to a known good state. Verify the logical channel reports the correct process value (1 or 0) in the F-DB.
- Force a controlled discrepancy: briefly interrupt only one channel of the pair. The discrepancy timer must start. Confirm the channel does NOT passivate if the deviation is shorter than the new discrepancy time.
- Force a sustained discrepancy (longer than the new discrepancy time). The channel must passivate, the F-CPU must log a 0x75C0 event, and the F-program's passivation logic must take over.
- Document the new discrepancy time, the date of change, and the F-signature in the safety lifecycle log per IEC 61511 / IEC 62061 change management requirements.
10. Engineering Recommendations for Emergency-Stop Channels on F-DI Modules
Mixing E-stop signals with other safety functions on a single F-DI module is common but creates the failure mode reported here. The discrepancy of any channel pair on the module causes passivation of all 1oo2 channel pairs, including the E-stop channel. Recommendations:
- Allocate E-stop channels to a dedicated F-DI module where possible, so non-E-stop discrepancy events do not disable the E-stop.
- Where physical separation is not possible, size the discrepancy time of every channel pair on the module to the worst-case sensor in the group. The most demanding sensor dictates the value for all pairs.
- For electromechanical contacts, 100–200 ms is typically adequate when the contacts are from the same manufacturer and age cohort. For older or mixed-age contacts, 300–500 ms is a safer starting point.
- Consider replacing mechanical contacts with electronic sensors (inductive, magnetic, RFID-coded) where the application allows. Electronic sensors typically have sub-millisecond asymmetry, allowing a 10–20 ms discrepancy window and faster fault detection.
- Re-verify the safety function after every F-parameter change. The verification must include a documented test of the worst-case channel pair timing.
11. FAQ
What is the valid range for the discrepancy time on an S7-416F SM 326F module?
The valid range is 1 ms to 30000 ms (30 s) with 1 ms resolution. Siemens default is 100 ms. Values above several seconds are unusual and produce a project warning because they delay detection of genuine single-channel faults.
Why does the F-DI module stay in fault state after I increase the discrepancy time, even though the new value is in range?
The most common cause is an incomplete F-block container — the safety compiler reports success, but the F-I/O parameter set was not regenerated or the new value was not staged for download. Force a full safety recompile, then re-download with F-blocks included, then perform a STOP → RUN transition to re-initialize the F-DI module. Reading the F-CPU diagnostic buffer for event 0x75A0 or 0x75B0 confirms this diagnosis.
Is the F-CPU required to be in STOP to change the discrepancy time?
Not strictly, but the F-password must be entered during the online download for any safety-relevant parameter change. On S7-416F firmware versions that hold the F-I/O parameter set in volatile mirror memory, a STOP → RUN transition (or MRES) is required for the new value to be applied to the F-DI module.
Does a discrepancy error behave the same as a channel fault?
Yes. Per the Siemens fail-safe modules documentation, a discrepancy error is handled by the safety program in the same way as a channel fault — the affected channel is passivated and the F-runtime group's passivation logic takes over.
Can I acknowledge a discrepancy error and clear the passivation without fixing the underlying cause?
Technically yes, but it is not safe practice. The discrepancy error will reappear on the next signal cycle because the physical cause (sensor wiring, contact bounce, EMC, loose terminal) is still present. Acknowledge the passivation only after the physical cause has been corrected and the channel pair has been re-verified.