Resolving S7-417F FILE_NOT_FOUND (1739:10) Safety Compile Error

Problem Summary

When compiling a fail-safe (F-) CFC program in SIMATIC PCS 7 / STEP 7 V7.x with the S7 F-Systems option on an S7-417F or S7-417FH controller, the CFC compiler aborts with the dialog "Compile chart as block type (1739:10)" followed by "Hardware error: FILE_NOT_FOUND" and a referenced .scl source file inside the project's s7asrcom\00000001\ subfolder. The compiler stops at that point, no new F-block types are generated, and downstream signature/consistency checks fail.

The error is reproducible on a project that previously compiled cleanly and starts to appear only after the user adds six or more additional F-CFCs above the original threshold (the working case in the field was four F-CFCs plus two standard CFCs; the failure case adds six more F-CFCs for a working total of ten F-CFCs). The error window changes file reference on each compile attempt — forceswitch.scl, setparamassignment.scl, and castingassignmentcode.scl have all been observed — and is not deterministic between runs.

Symptom Details and Error Message

The CFC editor reports the condition as two layered messages inside the "Compile chart as block type" dialog:

The path segment s7asrcom\00000001\ is the working directory written by the SIMATIC Safety F-Compiler during generation of the F-shared DB (F-DB) and F-runtime group sources. The numeric subfolder 00000001 corresponds to the safety program / F-runtime group index. The error is raised when the F-Compiler opens the temporary .scl source generated in that folder for read or write and the OS returns ERROR_FILE_NOT_FOUND (Win32 error 2, mapped in the Siemens error catalog to 1739:10).

Affected Hardware and Software Stack

Although the originally reported environment is STEP 7 classic plus S7 F-Systems, the symptom, root cause, and fix are equally relevant to TIA Portal V20 + SIMATIC Safety projects that target F-CPUs in the SIMATIC Safety Configuring and Programming manual. The compiler there surfaces the same condition under Info > Compile, and the same file-system race conditions apply when endpoint protection interferes with the safety compiler's working directory.

Root Cause Analysis

The FILE_NOT_FOUND (1739:10) error is generated when the F-Compiler attempts to open an .scl source that should have been written moments earlier in the same compile pass, but the file is no longer on disk when the open call executes. The two mechanism paths that produce this in a previously stable project are:

1. Endpoint-protection deletion (primary cause). Antivirus products with real-time file-system protection — most commonly reported with Microsoft Security Essentials, but also observed with Windows Defender, Trend Micro OfficeScan, and Symantec Endpoint Protection — quarantine newly created .scl files in s7asrcom\00000001\ as soon as the F-Compiler flushes them. The F-Compiler then fails the subsequent open call with Win32 error 2. The pattern of the failure changing file names from compile to compile is the diagnostic fingerprint: each compile run creates a different sequence of temporary .scl files, and the AV scanner quarantines whichever one it scans first during that pass.
2. F-block-type name collision after copy/paste from a second project (secondary cause). When an F-block type is copied from a different project without renaming its header and symbolic name, the F-Compiler writes both copies to the same s7asrcom\00000001\ path. The second write atomically replaces the first; the F-Compiler then opens the file by its original creation handle and receives a not-found error. This condition is reproducible independent of antivirus state.

Both paths converge on the same observable symptom: a previously compiling project begins to abort after the F-CFC count or the fail-safe block-type inventory changes, and the error only surfaces during Compile chart as block type (the F-block-type generation phase) — not during the standard CFC chart compilation phase.

Diagnostic Verification Checklist

Before changing the project, run the following checks in order to confirm mechanism (1) versus mechanism (2):

1. Reproduce on baseline. Open the project, do File > Reorganize, then trigger Compile > Charts as Block Type. If the error is transient and cycles through different .scl file names, mechanism (1) is overwhelmingly likely.
2. Inspect the quarantine vault. In MSE open History > Quarantined items; in Windows Defender open Virus & threat protection > Protection history > Quarantined items. Look for forceswitch.scl, setparamassignment.scl, or castingassignmentcode.scl with timestamps matching the compile window.
3. Confirm by selective shutdown. Temporarily disable the AV real-time protection, recompile Entire program. If the compile completes, mechanism (1) is confirmed. Reinstate protection as soon as the diagnostic is finished.
4. Diff the F-block-type inventory. In the CFC editor, right-click the chart folder and select Chart > Block types. Confirm that no two block types share the same F-block-type name + symbolic name + header signature triple. Cross-check this against the S7 F-Systems KB article Entry ID 34468224 for known F-block-type name collision patterns.
5. Check the F-runtime group count. The F-Compiler generates one .scl per F-runtime group per F-block-type. Confirm that the number of F-runtime groups and F-block types matches the expected count after the recent edits.

Solution 1 — Antivirus Folder Exclusion (Primary Fix)

The corrective action for the MSE / generic-AV root cause is to add the project working directories to the AV exclusion list. Required paths vary by product but always include the project root, the s7asrcom tree, and the STEP 7 global working directory:

Microsoft Security Essentials procedure:

1. Open MSE, select the Settings tab.
2. Choose Excluded file locations.
3. Add each path above one at a time and click Add.
4. Repeat for Excluded processes and add s7asrcomp.exe, s7cfcexe.exe, S7WBXBUF.EXE, and STEP7.EXE.
5. Click Save changes and trigger Compile > Entire program.

If MSE cannot be reconfigured (locked corporate image), the field-proven mitigation is to uninstall MSE and allow the next engineering cycle to run with Windows Defender in passive monitoring mode, or to deploy the S7 engineering workstation as a managed exclusion in the corporate endpoint policy via Group Policy Computer Configuration > Administrative Templates > Windows Defender Antivirus > Exclusions.

Solution 2 — Compile "Only Changes" Workaround

When the project must be compiled immediately and AV cannot be reconfigured in time, triggering Compile > Charts as Block Type > Only changes succeeds in the majority of cases because the F-Compiler reuses existing .scl files and only writes deltas — fewer writes means fewer AV scanner touches, and no FILE_NOT_FOUND is raised. In field reproduction, this is consistent: entire program fails, only changes succeeds.

Recommended procedure:

1. Save and close all editors.
2. Right-click the F-CPU in the project tree.
3. Choose Compile > Software (only changes).
4. Verify the inspector window reports Compile: Completed without errors under Info > Compile — see the TIA Portal guidance at Compiling the safety program.

This is a workaround only. The next full-rebuild compile (for example, before a download to a different CPU or before a sign-off pass) will still need Solution 1 in place.

Solution 3 — Project Reorganization and Cleanup

For mechanism (2), the F-block-type name collision, perform a full reorganization and re-bind of the F-block-type library:

1. In the SIMATIC Manager, right-click the S7 Program node and choose Reorganize. Wait for the Reorganization completed dialog.
2. In the Options > Block type library view, list all F-block types and confirm unique F-block-type names.
3. If two F-block types have the same name but different content, rename one to a unique symbolic name. Re-open every chart instance that referenced the old name and re-bind to the renamed type.
4. Right-click each F-CFC and choose Chart > Compile > As block type to regenerate the corresponding .scl cleanly.
5. Finally run Compile > Entire program from the project tree root.

Alternative Causes to Rule Out

Verification of Fix

1. Trigger Compile > Entire program. The inspector window must read Compile: Completed without errors.
2. Open the Safety > F-runtime groups view and confirm every F-runtime group shows its assigned F-block types with green status indicators.
3. Run Safety > Consistency check on the F-program. The result must be No errors, no warnings.
4. Perform Download > Complete download to target with the F-CPU in STOP, then run Safety > Accept safety program (or the equivalent Accept safety program workflow in the S7 F-Systems option) to confirm the F-signature is correctly transferred.
5. Repeat the compile twice more on the same project without re-touching anything; both passes must complete without re-introducing the error. If the error returns, the AV exclusion is incomplete.

Prevention and Best Practices

• Maintain a standard AV exclusion baseline on every S7 engineering workstation: project root, s7asrcom, STEP 7 working dirs, and the F-Compiler executables.
• Document exclusion paths in the workstation image ("F-CPU engineering workstation base image") so new PCs receive the exclusions automatically.
• Avoid copying F-block types between projects; when unavoidable, rename the header and symbolic name immediately on copy.
• Run Reorganize on every project at least weekly when active development is in progress.
• Prefer Compile > Entire program before every download so all F-block-type signatures are refreshed in the project history.
• For TIA Portal V20 projects, follow the SIMATIC Safety guidance in Compiling the safety program and the S7-1200F getting-started procedure Step 12: Compiling the safety program for the safety-specific compile path.

FAQ