WinCC WebUX VBScript Support: V7.3 Limitations and V7.4 Setup

Overview

WinCC WebUX is the browser-based runtime delivered with WinCC V7.x and with WinCC Runtime Professional (TIA Portal). It is conceptually different from a WinCC client: the WebUX client is a stateless HTML5/JavaScript front end that talks to the WebUX server, where all picture rendering, tag processing, and script execution take place. This architectural split is the root cause of one of the most common configuration failures reported by integrators: a VBScript or ANSI-C function that runs correctly on a WinCC client or on the server's own WebUX preview, but does nothing when the same picture is opened from a remote browser.

WinCC V7.3 ships with WebUX, but the WebUX of V7.3 supports a strictly limited subset of dynamization. Scripts are not part of that subset. From WinCC V7.4 SP1 onward, WebUX gains VBScript support on a clearly defined set of events; from WinCC V8.0 / TIA Portal V15.1 and later (Runtime Professional), both VBScript and ANSI-C are available subject to the restrictions documented in the WinCC WebUX / RT Professional manual set. Any attempt to bind a script to a property change on an I/O field in V7.3 will silently fail; the tag is still updated, but the event handler never fires in the browser session.

This reference documents the version-by-version capability matrix, the server-side execution model that applies once scripts are enabled, the supported event list, the diagnostic function IsHmiRtWebUx(), and the migration path projects must follow when they want browser-based HMI behavior that depends on event-driven scripting.

Version Compatibility Matrix

Why Scripts Fail in WinCC V7.3 WebUX

The WebUX front end in V7.3 was engineered around three principles:

1. Zero installation on the client. The browser is the only runtime dependency.
2. All picture logic evaluated on the server, never on the client.
3. A static, deterministic dynamization model based on tag names and direct property mapping.

Property-change events (such as Output Value → Change on an I/O Field) require an interpreter to be embedded in the runtime. The V7.3 WebUX stack did not bundle the VBScript or ANSI-C interpreter for the client side, and the server-side picture engine in V7.3 only re-evaluated tags - it did not dispatch a script callback on tag-value changes triggered from a WebUX client. The result is that the property change is committed to the tag database, but no event subscription fires.

Symptoms to look for during commissioning:

• The tag value updates correctly in the WinCC Tag Management and in the WinCC client.
• The VBScript function never executes when the change is performed in the WebUX session.
• No entry appears in the WinCC diagnostic files (WinCC_Sys_<date>.log, WinCC_RT_<date>.log) because the script dispatcher is never invoked.
• The same picture, opened from the WinCC client or from the WebUX preview on the server itself, executes the script normally - this is the diagnostic that confirms the binding is correct and the limitation is version-specific.

WebUX V7.4+ VBScript Architecture

From V7.4 SP1, scripts that are configured in the picture become available in the WebUX context, but the execution model is fundamentally different from a WinCC client:

• Scripts always run on the WebUX server. The browser is a thin client that subscribes to changes.
• When a user changes a value in a WebUX browser, the input is sent to the WebUX server, the server updates the tag, the server fires the bound event, and the server-side script executes. The browser receives the resulting picture diff and re-renders.
• This means scripts that rely on local client resources (file system on the client, local printer dialogs, OCX controls, ActiveX) cannot be reused unchanged. They must be reviewed for server-side compatibility.
• Scripts that rely on long-running blocking calls degrade WebUX performance. Aim for sub-100 ms execution; anything longer should be moved to a triggered background task or a WinCC global script scheduled in the server's task system.

The WebUX server does not load balance scripts across multiple sessions the way a clustered WinCC server does for tag management. In a redundant WebUX pair, the preferred server handles the script execution; on failover, the script subscription is re-established against the new preferred server without operator intervention.

Supported Event Surface for VBScript in WebUX

The event surface in WebUX is intentionally narrower than on a WinCC client. The following bindings are supported in WinCC V7.4 SP1 and later, and correspond to events that the WebUX server can observe:

Configuring an I/O Field Output Value Change Script for WebUX

The original configuration referenced in the field report is the canonical example. The following procedure upgrades it for V7.4 SP1 and later.

1. Open Graphics Designer and load the picture that contains the I/O Field.
2. Select the I/O Field and open Properties → Events.
3. Navigate to Property Topics → Output/Input → Output Value → Change.
4. Right-click the action icon, choose VBS Action, and assign a procedure from the project script library (do not paste anonymous code into the property).
5. Reference tags by their symbolic name (for example HMIRuntime.Tags("MyTag")) so the picture remains portable between the WinCC client and WebUX.
6. Compile the project with Rebuild All in the WinCC Explorer; the WebUX server only sees scripts that were part of a clean build.
7. Start WebUX on the server and test the same action from a remote browser session.

Sample procedure bound to Output Value → Change:

Sub OnOutputValueChange(ByVal Item)
    Dim sValue
    sValue = Item.OutputValue
    HMIRuntime.Trace "WebUX I/O field change: " & sValue & vbCrLf

    ' Example: set a derived tag
    HMIRuntime.Tags("DerivedTag").Write sValue

    ' Example: gate logic by runtime context
    If IsHmiRtWebUx() = True Then
        ' Branch executed only when the picture is rendered in WebUX
        HMIRuntime.Tags("Log_WebUX_Touch").Write 1
    End If
End Sub

Using the IsHmiRtWebUx() Runtime Check

ANSI-C scripts in WebUX include the helper IsHmiRtWebUx(), a function of type BOOL. It returns TRUE while the picture is being rendered in the WebUX environment and FALSE on a WinCC client. Use it to branch logic that must behave differently depending on whether the user is on a browser or a client:

BOOL bIsWebUx = IsHmiRtWebUx();
if (bIsWebUx)
{
    // Server-side only path; e.g. queue a message to the central log
    LogWebUxEvent("User changed setpoint");
}
else
{
    // Native client path; e.g. update local faceplate
    UpdateFaceplate();
}

Reference: Siemens Support entry 109481796 – Special features of WinCC/WebUX configuration. The same entry ships the attached PDF WebUX Controls Scripting (109481796_WebUX_Controls_Skripting_en.pdf), which lists the control events that propagate to the server.

Supported VBScript and ANSI-C Functions in WebUX

The Runtime Professional / WebUX documentation enumerates the supported API surface. Functions are classified as supported, supported with restrictions, or not supported. The headline rules are:

For the authoritative list see Functions supported in WebUX (RT Professional) – WinCC V20 documentation and Supported dynamization functions in WebUX (RT Professional) – WinCC V20 documentation.

Migration Path: V7.3 Project → V7.4 SP1 or Later

Projects that were designed against V7.3 and now need browser-based event scripts should follow this sequence:

1. Verify the WinCC license. WebUX VBScript support requires the WebUX option license on top of the WinCC base license, plus the script engine license bundle added in V7.4 SP1.
2. Open the project in the V7.4 SP1 (or newer) WinCC Explorer. Project migration triggers a one-way upgrade; keep a backup of the V7.3 source.
3. Audit every script that targets an event. Move anonymous VBS code into named procedures in the project script library. Anonymous in-line actions are not portable.
4. Replace client-specific calls (local paths, local printers, COM/OLE automation) with server-side equivalents. Document every replacement in the project release notes.
5. Add the IsHmiRtWebUx() branch to scripts whose behavior must differ between WebUX and WinCC client.
6. Rebuild the project. Confirm that Scripts\Test in WinCC Explorer passes without errors.
7. Activate the runtime, then connect to WebUX from at least two different browsers (Chrome, Edge, Firefox) to verify the script fires in each.

Troubleshooting Matrix

Verification Procedure

1. Activate the runtime in WinCC Explorer. Wait for the status icon to turn green.
2. Open a Chrome or Edge browser on a remote workstation. Navigate to https://<webux-server>/WebUX/ (the exact URL pattern is defined by the WebUX configuration; default is http://<server>/WinCC/WebUX/ for HTTP or the HTTPS equivalent after certificate configuration).
3. Log in with a WinCC operator account. The WebUX login screen is mandatory and uses WinCC user administration.
4. Open the picture that contains the I/O Field. Change the value.
5. Confirm via HMIRuntime.Trace output in the WinCC diagnostic files that the script was invoked on the server.
6. Confirm via tag inspection in WinCC Tag Management that the side-effect tag (for example DerivedTag in the sample above) was written.
7. Open a second browser session as a second user. Confirm that script invocations from both sessions remain isolated - the WebUX server must not cross-pollute sessions.
8. Force a redundant failover (if a redundant WebUX pair is in use) and re-verify the script fires after failover.

Performance and Capacity Notes

Each WebUX script execution is a server-side job. Sizing rules of thumb for a single WebUX server with VBScript and ANSI-C enabled:

• Up to 50 concurrent WebUX clients on a hardware class that already supports 50 WinCC clients.
• Script dispatch latency budget: 100 ms p95; 250 ms p99. Anything outside this budget indicates a script that should be re-factored.
• Global script cycles (1 s, 5 s, 10 s) configured on the server continue to run; their effect is visible in the browser, but they do not consume browser CPU.

FAQ