Resolving WinCC TIA C Script Error 1007001 4099 Unresolved

Problem Description

When developing WinCC TIA Professional HMI screens that include C scripts for an S7-1500 / S7-1500TF (e.g., S7-1511TF) project, the following symptom occurs:

• Executing a C script as a local action (tested inline or via direct script call) works correctly.
• Executing the same C script bound to a Schedule event works correctly.
• Calling the C script from another script that is activated by a Schedule event returns fault 1007001 / 4099 with the text "Exception in Action" and "unresolved external function or variable".
• Calling the C script from an object event (e.g., a Button_2 Click event) returns the same fault.

The function itself is present in the project (it is found during a direct/local execution), so the failure is not caused by a missing function body. The error is a linker/symbol resolution failure inside the WinCC RT script engine at the moment the runtime attempts to bind the call site to the function symbol.

Affected Environment

Decoding the Error: 1007001 and 4099

The full OnErrorExecute dump from the WinCC RT trace provides four correlated identifiers that must be interpreted together:

Root Cause: globalDefinition.h Variable Scope vs. Event-Domain Compilation

WinCC TIA Professional uses a C-style scripting engine with two distinct compilation domains:

1. Project-globally compiled C functions — these are the user-defined functions visible in the project tree under "C scripts > Functions". They are compiled once and registered in the global symbol table of the runtime.
2. Event-bound C actions — these are the inline scripts attached to schedules, tag events, and screen object events. They are compiled per-event into a transient unit (@n) that links against the global symbol table at runtime.

The header file globalDefinition.h is the standard project-wide include for WinCC RT. It is automatically prepended to every C function in the project only if the function body itself was generated or edited through the TIA project tree. It is not automatically prepended to event-bound action blocks, which are compiled in a separate domain.

When a project-wide C function such as WriteResults declared a variable in globalDefinition.h, the symbol existed in the project-global domain. As long as the function was invoked from a context that also belonged to the project-global domain (direct execution, local script, or a top-level schedule that resolved the symbol through a different path), the lookup succeeded.

When WriteResults was invoked from an action block bound to a Schedule event or to Button_2, the calling context was the per-event action domain. This domain only sees the global symbol table. The function WriteResults itself was registered there, but any identifier that originated from globalDefinition.h and was referenced inside WriteResults resolved correctly only when the function was compiled as a project-globally compiled unit. The moment the runtime linked the same source against the action-domain symbol table, the unresolved-external error was raised.

Why "Identical Code" Behaves Differently

The script body is identical on disk, but the compilation context differs:

Resolution Procedure

Option A — Recommended: Move the variable into the function (eliminate the cross-domain dependency)

1. Open the C function in the project tree (in this case WriteResults).
2. Remove the global variable declaration from globalDefinition.h. The file should return to an empty or near-empty state.
3. Declare the variable as a static (or local) variable inside WriteResults:

void WriteResults(void)
{
    static int  s_nCounter = 0;   // file-local, no external linkage
    int         nTmp      = 0;   // function-local

    s_nCounter++;
    /* ... original code ... */
}

4. Recompile the project (TIA Portal: Project > Compile > Software (rebuild all)).
5. Download / start RT and re-trigger the Schedule event and the Button_2 event.

Option B — Keep the global, but make it resolvable in the action domain

1. Leave the declaration in globalDefinition.h as extern:

// globalDefinition.h
extern int g_nResultCount;   // declaration only

2. Define the variable in exactly one project-global C function file (not in an action block):

// e.g., in a dedicated file: Globals.c
int g_nResultCount = 0;

3. Verify that the C function using the variable (WriteResults) does not redefine it; it should only #include "globalDefinition.h" and reference g_nResultCount.
4. Rebuild and retest.

Option C — Promote the C function to a project-global function (do not call it from a wrapper)

If you have a wrapper script that just calls WriteResults from a Schedule, eliminate the wrapper. Bind the Schedule event directly to WriteResults. This keeps the call in the project-global domain and avoids the action-domain linker.

Verification

1. Open the WinCC RT trace (HMI device → right-click → "Runtime → Start with trace" or use the RT Trace Viewer).
2. Enable the categories: Scripting, Action, and Error.
3. Force the triggering events:
   • Click Button_2 in STARTPAGE.SCREEN.
   • Wait for the Schedule event to fire.
4. Confirm that the trace shows no dwErrorCode1 = 1007001 and no szErrorTextException entries.
5. Confirm that the side effect of WriteResults (e.g., the written results in the recipe view) updates as expected.
6. Optional — instrument the function:

Check the WinCC RT log file WinCC_TIA_Portal_RT_<date>.LOG in the project runtime directory.

Common Pitfalls and Field-Proven Caveats

Best Practices for C Scripts in WinCC TIA Professional

1. Keep globalDefinition.h lean. Use it only for type definitions, macros, and extern declarations. Place actual variable definitions in dedicated C source files.
2. Avoid implicit cross-domain dependencies. If a project-global C function references a global, ensure that global is reachable from every domain that may call the function (use extern + single definition).
3. Prefer project-global functions over inline action blocks for non-trivial logic. Inline action blocks should contain only orchestration calls into project-global functions.
4. Recompile after every rename. TIA Portal does not always re-validate transitive references; a full rebuild catches stale symbols.
5. Use version control on C scripts. The TIA project tree stores C scripts as plain text; keep them in a Git/SVN repository outside TIA to track changes that may affect symbol resolution.
6. Tag your log lines with the function name and a timestamp. The WinCC RT log rotation can swallow context otherwise:

printf("[%s][%s] event=%s value=%f\r\n",
       __func__, __TIMESTAMP__, "Button_2", GetPropDouble(lpszPictureName, "value"));

7. Always re-test on a clean RT start after a compile. Stale RT caches can mask symbol errors and only surface them on the first call.

Related Diagnostics: Other 1007001 Sub-Codes

Whenever you see 1007001, read dwErrorCode2 first. It identifies the exception subclass, and almost always pinpoints the bug to one of five categories: symbol resolution (4099), types (4098), memory (4097), stack (4100), or arithmetic (4101).

FAQ