Script Dump

The --dump flag saves a local copy of every script that WinCC loads at runtime. Scripts are written to disk as the debugger receives them, organized by context (Dynamics / Events) and mirroring the original script paths.

Why use script dump?

WinCC Unified stores scripts inside the TIA Portal project, which makes them difficult to access outside the engineering environment. The dump feature extracts them so you can:

• Back up runtime scripts — Have a local copy of every script running on the HMI, independent of TIA Portal
• AI-assisted code review — Feed the dumped scripts to an AI assistant (Claude, Copilot, ChatGPT) for code review, bug hunting, or refactoring suggestions
• Diff between versions — Compare scripts before and after a VCS change to see exactly what changed
• Search across all scripts — Use VS Code's search (Ctrl+Shift+F) or grep to find patterns across the entire codebase at once
• Understand the project — Get a complete picture of all scripts running on a screen, including faceplates and system modules

Usage

Pass --dump <directory> when starting the proxy:

./wincc-unified-debug-proxy.exe run --dump scripts

On first use, the proxy asks which TIA Portal version you're using and automatically sets up ESLint with the matching type definitions.

This creates the output directory with the following structure:

scripts/
├── .eslintrc.json              ← ESLint config (bug-catching, no style enforcement)
├── jsconfig.json               ← VS Code IntelliSense configuration
├── package.json                ← ESLint dependency
├── ua_rt_device_V19.d.ts       ← WinCC type definitions for your version
├── node_modules/               ← installed automatically via npm install
├── Dynamics/
│   ├── global_modules/
│   │   └── system_V_1_0_0.js
│   └── screen_modules/
│       └── Screen_Content/
│           └── HMI_RT_1__Main_Overview/
│               ├── Triggers.js
│               └── faceplate_modules/
│                   ├── Pump_Symbol_V_1_0_0/
│                   │   └── Triggers.js
│                   └── Reactor_Panel_V_1_0_0/
│                       └── Triggers.js
└── Events/
    ├── global_modules/
    │   └── system_V_1_0_0.js
    └── screen_modules/
        └── Screen_Content/
            └── HMI_RT_1__Main_Overview/
                ├── Events.js
                ├── FunctionLists.js
                └── faceplate_modules/
                    ├── Pump_Symbol_V_1_0_0/
                    │   └── Events.js
                    └── Reactor_Panel_V_1_0_0/
                        └── Events.js

ESLint & IntelliSense

The proxy writes supporting files into the dump directory and runs npm install automatically:

The ESLint config focuses on bug detection, not style enforcement. It catches:

• no-undef — Typos in tag names, wrong API calls, undefined variables
• eqeqeq — Prevents == type coercion bugs (use === instead)
• no-unused-vars — Dead code (function parameters are excluded)
• no-template-curly-in-string — "${x}" instead of `${x}`
• no-unused-expressions — x === 5 instead of x = 5 (comparison vs assignment)
• use-isnan — Must use isNaN(), not x === NaN

Style rules (semicolons, quotes, indentation) are off — WinCC scripts are not enforced by TIA Portal, so strict style linting would produce hundreds of false positives.

The WinCC globals (HMIRuntime, Tags, Screen, Faceplate, UI, PlantModel) are declared as readonly in the ESLint config so they are not flagged as undefined.

Clean on start and target change

The Dynamics/ and Events/ subdirectories are automatically deleted at proxy startup and whenever a target changes (e.g., screen reload). This ensures you always see the scripts from the current session, not stale files from a previous run.

The styleguide files (.eslintrc.json, .d.ts, node_modules/, etc.) are not deleted — they persist across restarts.

How it works

The dump happens continuously while VS Code is connected:

1. VS Code connects to the proxy and the proxy relays CDP traffic to WinCC
2. WinCC sends Debugger.scriptParsed events for every script it loads
3. The proxy intercepts these events, requests the script source from WinCC, and writes it to disk
4. The response is consumed by the proxy and not forwarded to VS Code — the debug session is unaffected

When you navigate to a different screen in WinCC, new scripts are loaded and automatically dumped. The output directory accumulates scripts from all screens you visit during the session.

Navigating screens

Since scripts are dumped as they are loaded, navigate to all screens you want to capture while the debug session is running. Each screen navigation loads new faceplate scripts, which get dumped automatically.

If you reload a screen or reconnect, the target's script directory is cleaned and new scripts are dumped fresh.

Combining with debugging

The --dump flag works alongside normal debugging. You can set breakpoints, step through code, and inspect variables in the live debug session while the proxy silently dumps scripts in the background. The dump does not affect debug performance.

# Debug + dump at the same time
./wincc-unified-debug-proxy.exe run --dump scripts -t 192.168.1.100

Without --dump

When --dump is not specified, the proxy works exactly as before — no files are written and no extra CDP messages are sent. There is zero overhead.