Resolving Siemens S7-1500 F-CPU Error 16#75D1 Variable Overflow

Overview of Internal Error 16#75D1

Error 16#75D1 is a STOP-class diagnostic event reported by Siemens SIMATIC F-CPUs (fail-safe controllers) in the S7-1500, S7-300, and S7-400 families. The hexadecimal code maps to a generic safety-program fault detected by the F-runtime group's integrity check. According to Siemens Support Entry 109783988, when the F-CPU enters STOP with 16#75D1, the firmware has detected a safety-critical violation inside the safety program (the F-block container compiled from the FBD/LAD/ST safety logic). The CPU cannot continue execution because doing so would compromise the SIL 2 / SIL 3 / PL d / PL e guarantee the F-system is rated for.

The same error code applies to legacy controllers running STEP 7 V5.x, as documented in Siemens Support Entry 16770414. Although the symptoms are identical, the diagnostic buffer entries, the F-signature regeneration procedure, and the recompilation rules differ between TIA Portal (S7-1500F) and STEP 7 V5.x (S7-300F / S7-400F).

Catalogue of Documented Causes for 16#75D1

Siemens lists several root causes in the support entries cited above. Each maps to a different failure mode inside the F-runtime group:

This article focuses on the first row: arithmetic overflow of a safety-related variable, which is the most common cause reported by users who observe the F-CPU entering STOP without an obvious hardware fault.

Why a Simple +1 Loop Will Not Trigger 16#75D1

Engineers frequently attempt to provoke the overflow deliberately by incrementing a safety-tag until it wraps. They observe that the value rolls over from +32767 to -32768 (for INT) or from +2147483647 to -2147483647 (for DINT) without raising any diagnostic event. This behaviour is by design, not a bug.

The F-runtime compiler emits a ADD_I or ADD_DI instruction that performs modular arithmetic in hardware. The CPU's ALU does not flag a status bit for signed wraparound because the result is mathematically well-defined in two's-complement representation. The result is wrong from a process-safety perspective (the tag no longer represents a meaningful count), but the instruction itself completed successfully and therefore does not raise 16#75D1.

The F-runtime's overflow detection operates at a different level. The error is raised when:

1. The F-runtime invokes the F-block integrity check after the F-cycle.
2. The integrity check compares the declared value range of an F-tag (set in the F-tag DB or declared at the F-FB interface) against the actual value produced by the F-block.
3. If the actual value falls outside the declared range AND the tag has been marked with the "Range check" attribute in the F-block properties, the F-runtime raises 16#75D1 and forces the F-CPU into STOP.

Incrementing a tag with Range check = disabled (the default for performance reasons) will not raise the error even when the value wraps. This is why bench testing often fails to reproduce the field failure.

Conditions That Genuinely Trigger the Overflow Path

To raise 16#75D1 through overflow, the F-tag must be configured with an active range check. The following table summarizes the configuration paths in TIA Portal V17 and later:

Reproducible Test Procedure in TIA Portal

1. Create a new F-Function Block (F-FB) inside the safety program.
2. Declare an F-tag of type INT named iTestCount.
3. Open the F-tag properties and enable "Range check". Set lower bound to 0 and upper bound to 30000.
4. In the F-FB body, add a network with: iTestCount := iTestCount + 1;
5. Assign the F-tag to a non-safety retention DB only if the test is run on a real PLC. For simulation, use PLCSIM V17+.
6. Download the safety program. The TIA Portal prompts for an F-signature regeneration; confirm.
7. In the safety administration editor, set the F-monitoring time to its maximum (5000 ms) to avoid a parallel watchdog STOP.
8. Force the tag to 29999 from the watch table.
9. Single-step the F-runtime group. The next +1 instruction raises 16#75D1 and the F-CPU transitions to STOP within one F-cycle (typically < 10 ms on an S7-1516F).

The same procedure is described implicitly in the diagnostic flow of Siemens Support Entry 109783988: the entry requires the engineer to verify that the offending F-tag has a non-default range configuration before treating the error as a real overflow.

Diagnostic Workflow After a STOP Event

When a fielded F-CPU enters STOP with 16#75D1, follow the decision tree below. This sequence aligns with the official Siemens recovery procedure documented for both S7-1500F and S7-300F / S7-400F.

1. Read the diagnostic buffer. Open TIA Portal → Online → Diagnostics → Diagnostic buffer. Note the timestamp, the F-block instance that raised the event, and any passivation events from F-I/O modules.
2. Identify the F-runtime group. The diagnostic buffer entry lists the F-runtime group number (1, 2, or 3) and the F-FB name. S7-1500F supports up to three independent F-runtime groups.
3. Cross-check F-tag ranges. Open the F-FB or F-DB identified in step 2 and inspect every F-tag with the range-check attribute enabled. The most likely candidate is a counter, accumulator, or position-integral value.
4. Review the online/offline difference. If the safety program was modified since the last safety acceptance, the F-signature mismatch itself can raise 16#75D1. TIA Portal will display a yellow warning triangle on the safety program node.
5. Check F-I/O substitution values. If the offending tag is sourced from an F-I/O channel that has been passivated, the substitution value (default 0) may push the running sum of an F-block accumulator out of range on the next cycle.
6. Capture the safety log. The S7-1500F maintains a non-volatile safety log (up to 512 entries) accessible via the web server or TIA Portal → Safety Administration → Logs. Export the log before any restart attempt.

Restart Procedure Once the Root Cause Is Known

Restarting an F-CPU that has stopped on 16#75D1 requires a deliberate operator sequence. The firmware refuses to return to RUN automatically.

Firmware-Specific Behaviour

The behaviour of 16#75D1 varies slightly across firmware versions. The table below summarises documented changes:

Comparison: Real Overflow vs. False Positive on S7-300/400F

Engineers migrating a safety program from S7-300F or S7-400F (STEP 7 V5.x) to S7-1500F (TIA Portal) sometimes report 16#75D1 for the first time. The discrepancy usually has one of two causes:

The crucial insight is that the legacy controllers also do not raise 16#75D1 on bare modular wraparound. A migrated program with the same arithmetic will exhibit the same lack of detection unless the F-tag range check is explicitly enabled in TIA Portal.

Prevention Best Practices

1. Enable range check on every F-tag that is an accumulator or integrator. Counters, position integrals, and runtime-hours tags are the three most common offenders.
2. Clamp the F-tag upper bound below the INT/DINT maximum. Setting the upper bound to 32000 for a count that realistically never exceeds 10000 gives a 220% safety margin before 16#75D1 is raised.
3. Use F-validated wrap-around logic. If the process genuinely requires a counter that rolls over (e.g., cycle counter), implement the wrap with a conditional reset: IF iCount >= 32000 THEN iCount := 0; END_IF; Place the reset logic in the same F-FB so it is part of the F-signature.
4. Avoid implicit type promotion. Adding a DINT constant to an INT F-tag in TIA Portal promotes the operation to DINT, which silently widens the F-tag. Ensure the F-tag type matches the operation.
5. Document the F-tag ranges in the safety requirement specification (SRS). The SRS must list every F-tag's declared range; the F-block implementation must match.
6. Use PLCSIM Advanced for FAT coverage. Force the F-tag to within 1 count of its upper bound and verify the STOP behaviour. This step is mandatory for SIL 3 systems per IEC 61508-3.

Verification Checklist After Restart

Use this checklist to confirm that the F-CPU has returned to a valid safe state:

Related Diagnostic Background

Although the support entries focus on 16#75D1, the underlying overflow / underflow detection mechanism is shared with other TIA Portal diagnostics. For example, the ET 200SP analog input module AI Energy Meter CT ST (6ES7134-6PA01-0BU0) exposes an overflow / underflow diagnostic alarm on the voltage channel, configured via the "Tolerance factor overvoltage/undervoltage" parameter. The TIA Portal manual collection describes the tolerance-band logic in TIA Portal documentation for the ET 200SP AI Energy Meter. While the module's diagnostic is hardware-level rather than F-runtime-level, the same pattern of declaring an expected range and triggering an alarm on violation applies.

Troubleshooting Matrix