Finding Script Usage in WinCC V7.4 Projects Cross-Reference Guide

Finding Script Usage in WinCC V7.4 Projects: Cross-Reference Guide

When maintaining or refactoring a Siemens WinCC V7.4 or V7.4.1 SCADA project, engineers routinely need to answer a single question: where is this script used? Unlike the TIA Portal, which provides a unified "Cross-references" view across PLC, HMI, and script objects, WinCC V7.4 distributes its scripting engine across several editors and runtime databases. Locating every call site of a VBScript or ANSI-C procedure therefore requires combining Report Designer output, project tree inspection, and runtime diagnostics. This guide consolidates the official Siemens methods into a single workflow for engineering teams, integrators, and commissioning engineers.

1. WinCC V7.4 Scripting Architecture Overview

WinCC V7.4 supports two parallel scripting technologies, each with its own project tree node, editor, and runtime container:

A complete cross-reference search must inspect both branches, because a single HMI event can call a project function in either language. Scripts can be attached to:

• Graphics Designer object events (mouse click, value change, dialog open/close)
• Tag management actions (on change, on limit violation)
• Scheduler / Time-triggered actions (cyclic, daily, weekly)
• Alarm logging acknowledgment and message procedures
• Tag Logging scripts (open/close archive, calculation)
• User archive callbacks
• Report Designer print jobs (VBS only)
• Global Script actions invoked from C or VBS via HMIRuntime or PDLRT APIs

Reference: WinCC V7.4 Scripting: VBS, ANSI-C, VBA (Entry ID 109736230).

2. Prerequisites for Cross-Referencing Scripts

Before running the procedures below, verify the following on the engineering station:

1. WinCC V7.4 or V7.4.1 installed, including the "WinCC Scripting" option (added during install or via Setup → Modify).
2. Project opened in WinCC Explorer with write access to the project directory.
3. Report Designer installed (default with WinCC). The Report Designer appears under "Graphics Designer" siblings in the WinCC Explorer navigation tree.
4. For ANSI-C cross-references, the C Editor must be openable. Confirm by double-clicking "Global Script → C" in the project tree.
5. Local administrator rights on the engineering station; Report Designer writes a temporary PDF into the project folder.

3. Report Designer Project Documentation (Recommended Method)

The Report Designer is the only built-in tool that produces a comprehensive, machine-readable inventory of all WinCC objects, including scripts. For script discovery specifically, two of the supplied layout templates are essential.

3.1 Available Documentation Layouts for Scripts

Open the Report Designer (right-click "Report Designer" in the WinCC Explorer tree → Open). The following system layouts directly enumerate scripts and their call sites:

3.2 Generating the PDF

1. In WinCC Explorer, right-click Report Designer → Open.
2. In the navigation tree, expand Layouts → System Layouts. The two script layouts appear as @Documentation Global Script Actions and @internal Global Script Project-function.
3. Open the Print Job tree, right-click the print job you intend to bind (typically @Report Viewer for on-screen display), and select Properties.
4. Set the Layout field to the desired documentation layout.
5. Trigger the print job manually (right-click → Print Preview) or call it from a temporary button to produce a PDF in \<Project>\<Computer>\PrintJobs.

3.3 Interpreting the Cross-Reference Output

For @Documentation Global Script Actions, each row contains:

• Action name (e.g., Aktion_1)
• Trigger type (cyclic / tag trigger / time-of-day / event)
• Cycle / trigger tag
• Function called (e.g., MyProjectFunction(arg1))
• Script language (VBS or C)

For @internal Global Script Project-function, each row contains:

• Function name
• Parameters and return type
• Body excerpt (first 200-400 characters; full source is not in the PDF)
• Internal references (calls to other project functions)

Use both layouts together: the actions report tells you what fires the script, the project-function report tells you what the script does and which other functions it calls.

4. Manual Inspection in the Graphics Designer

When you need a quick answer for a single picture (e.g., "what does StartScreen.pdl call?"), the Graphics Designer provides immediate, visual feedback.

1. Open the target picture in Graphics Designer.
2. Right-click any object → Properties → tab Events.
3. Each event row shows the configured action. An event with a configured script displays the script language (VBS / C) and the function name in column "Action name".
4. Hover the action; the tooltip shows the full function name including parameters.
5. To navigate to the function definition, right-click the action and select Go to (only available in VBS editor for project functions).

5. Global Script Editor Self-Search

Both Global Script editors include a built-in Find References (or similar) feature, but its scope is limited to the active project and the same scripting language.

5.1 VBScript Editor

1. Open Global Script → VBS in WinCC Explorer.
2. Open the project function or standard module.
3. Position the cursor on the function or procedure name.
4. Press F12 (Go to Definition) to jump to the declaration; press Shift+F12 to see local references within the same module.
5. Use the toolbar icon "Find All References" (binoculars) to enumerate references in the current file. Note: this only scans the active VBS module, not the entire project.

5.2 ANSI-C Editor

1. Open Global Script → C in WinCC Explorer.
2. Open the function header.
3. Right-click the function name → Find All References. The C editor searches all *.c and *.h files in the project.
4. Results appear in a list at the bottom of the editor. Double-click a result to jump to the call site.

The C editor's "Find All References" is more powerful than the VBS equivalent because the C compiler maintains a symbol table across all source files. The VBS editor's reference search is lexical and limited to the open module.

6. File-System Search (Last Resort / Comprehensive)

Because the project is a folder of text files, you can use OS-level search tools to find any string in seconds. This is the most complete method and the one used by veteran WinCC integrators.

6.1 Project Folder Layout

Default project root: C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<Project>\

6.2 PowerShell Example

Use the following PowerShell one-liner to enumerate every picture that references a VBS function named MyFunction:

6.3 Limitations

• PDL files are binary in WinCC V7.2 and later for compiled pictures; the source XML is regenerated only on save. Search only *.pdl if the project was opened and saved at least once in V7.3+.
• Function names are case-sensitive in C, case-insensitive in VBS. Match your search accordingly.
• Dynamic calls via HMIRuntime.Screens("Screen_1").ScreenItems(...) cannot be resolved statically. Use runtime logging instead (Section 7).

7. Runtime Diagnostics (GSC Diagnostics Window)

For applications that build function names at runtime, static analysis misses call sites. Use the WinCC GSC diagnostics tool to log every script invocation at runtime.

1. On the WinCC runtime computer, open WinCC Explorer.
2. Select menu Tools → Global Script Diagnostics (sometimes labelled "GSC Diagnostics").
3. In the diagnostics window, enable Trace Active and Trace Function Calls.
4. Start runtime and exercise the screens. Every C function call appears in the trace with timestamp, calling script, and arguments.
5. Export the trace to *.txt for offline analysis.

The GSC Diagnostics window corresponds to the ANSI-C runtime only. For VBS, enable VBS Debug Mode via Computer → Properties → Graphics Runtime → VBS Debug; calls are logged to WinCC_VBS.log in the project directory.

8. Script Discovery Workflow (End-to-End)

Combine the methods above into a single repeatable procedure:

1. Start with the Report Designer: Generate @Documentation Global Script Actions and @internal Global Script Project-function. These two PDFs cover ~85% of the call graph.
2. Open each picture referenced in the report and verify event bindings via Graphics Designer Properties → Events tab.
3. Use the C Editor for ANSI-C functions: right-click → Find All References covers all *.c / *.h files in the project.
4. Use PowerShell grep across the entire project folder to catch indirect references in PDL, SCF, and CDF files.
5. For uncertain dynamic calls, run GSC Diagnostics and VBS Debug logs in runtime for 1-2 hours to confirm the true call path.
6. Document the result in a spreadsheet: Function name | Type | Call sites | Owner | Last modified. This becomes part of the project's engineering baseline.

9. Verification: Confirming a Refactor Is Safe

After identifying all call sites, you can safely modify a script only when:

• The Report Designer output shows zero "stale" actions pointing to the function (i.e., no action lists the old function name).
• Graphics Designer event bindings on every referenced picture are updated to the new function signature.
• The C Editor "Find All References" returns zero hits for the old symbol.
• PowerShell search of the project folder returns zero hits for the old function name (excluding comments).
• Runtime test: enable GSC Diagnostics and VBS Debug, run the system through all operator scenarios, and confirm zero "function not defined" or type mismatch errors.

10. Cross-Reference Limits in WinCC V7.4 vs TIA Portal

Engineers familiar with TIA Portal often expect a single "Cross-references" view. WinCC V7.4 has no equivalent because the script engines predate TIA's unified database. The table below summarizes the difference:

For new projects targeting full TIA cross-reference capability, consider WinCC Unified V18+ (TIA Portal). The classic WinCC V7.4+SPx line remains the right choice for migration of legacy installations.

11. Troubleshooting Matrix

12. FAQ