WinCC 7.3 WebUX Dynamic Color Change via Tag Connection

Overview

Siemens WinCC V7.3 introduced the WebUX runtime as a browser-based visualization client that publishes WinCC screens directly to operators via Internet Information Services (IIS). Unlike the classic WinCC WebNavigator, WebUX targets HTML5-capable browsers without requiring a plugin, which is why the runtime engine intentionally limits the active content it will execute on the client.

One of the most frequently encountered operational limits is the inability to dynamically change the background color (or any other visual property) of a WinCC graphic object through VBScript, C script, or the Dynamic Dialog wizard. All three of these routes rely on server-side or embedded script execution that the WebUX client rejects. The Dynamic Dialog, in particular, is internally compiled to a C-script and shares the same execution restriction.

The only dynamization method that survives the WebUX translation to the browser is the Direct Tag Connection. When a property of an object is wired directly to a WinCC tag without an intervening script, the WebUX runtime polls the tag value on a fixed cadence and rewrites the property in the DOM. This article explains how to use that mechanism to switch background colors, both for binary (on/off) states and for arbitrary RGB values, and how to avoid the pitfalls that surface when developers assume the classic WinCC scripting surface is available.

Prerequisites

Before configuring dynamic colors in WebUX, verify the following items are in place. Skipping any of these is the most common cause of "I configured it but the color never changes" support calls.

1. WinCC V7.3 SP2 or later. WebUX is delivered as a separately installed component on top of WinCC; the SP level determines which runtime fixes are included. SP2 added stability fixes that affect tag-polling refresh.
2. WebUX Publisher installed and licensed. Open WinCC Explorer, right-click Web Navigator, and select WebUX Publisher. A non-greyed dialog confirms the license is present.
3. IIS role configured for WebUX. The WebUX installer registers the application pool and the WebUX web application under the default web site. Confirm the WebUX application pool is running and the ASP.NET v4.0 managed pipeline mode is enabled.
4. WebUX viewer object placed in the start screen. Open Graphics Designer, drop the WinCC WebUX Control from the Controls palette onto the start picture, configure the server prefix and authentication.
5. Tags and tag connections modeled in Graphics Designer first. Always build and test the dynamization in the WinCC runtime (or WebNavigator) before publishing to WebUX. This isolates configuration errors from WebUX translation errors.
6. Operator client browser. Use a current desktop browser (Chrome 90+, Edge 90+, Firefox ESR) or a supported mobile browser. JavaScript must be enabled.

Reference: Siemens Support entry 109770628 - WebUX functionality and configuration

WebUX Functional Limits: What Works and What Does Not

WebUX translates the WinCC runtime model to a JavaScript-driven HTML5 representation. To keep latency low and to avoid executing arbitrary code in the browser, the runtime imposes a strict whitelist on dynamization methods. The matrix below summarizes the support level for the most commonly used dynamization techniques as of WinCC V7.3 SP2 / WinCC V7.4 / WinCC V7.5.

Method 1: BOOL Tag for Two-State Color Switching

The fastest way to drive a binary color change (for example, Red on fault / Green on run) is to connect a BOOL tag to the flashing-color group of the object. WebUX honors flashing on properties and the static fallback colors map cleanly to two tag states. The technique relies on the fact that the flashing state and the static state are independent properties, both readable over the direct-connection path.

Step-by-step configuration

1. In Graphics Designer, select the object (line, rectangle, button, or polygon).
2. Open the Object Properties > Properties > Flashing group. Note the four properties:
   • Flashing Background Active (BOOL)
   • Flashing Background Color On (RGB)
   • Flashing Background Color Off (RGB)
   • Background Color (RGB, static)
3. Set Flashing Background Color On and Flashing Background Color Off to the same static color. This is the color the object will adopt when the BOOL tag becomes true.
4. Right-click Flashing Background Active > Dynamic > Tag. Bind it to a 1-bit WinCC tag (for example, Plant.Unit.HMI.PumpRunning).
5. Set the static Background Color property to the color the object will adopt when the tag is false.
6. Compile, save, and (in WebNavigator) verify the flashing boundary before publishing to WebUX.
7. Republish the WebUX project and reload the browser.

Why this works in WebUX

WebUX implements the flashing mechanism as a simple direct-connection on the boolean Flashing Background Active property, plus static fallback values for the active color. The runtime rewrites the DOM based on the polled BOOL value. Because the entire mechanism maps onto direct connections (no script), the WebUX whitelist accepts it.

Color stack reference

For applications that need a third state (e.g., Run / Stop / Fault as green / gray / red), use Method 2 because BOOL only carries two states.

Method 2: INT32 Tag for Arbitrary RGB Color

When the project requires more than two distinct colors, drive the Background Color property directly with a 32-bit signed integer holding the packed BGR color value used by the WinCC color system. Siemens documents this encoding in the WinCC Information System under Color encoding for direct connection and references the conversion procedure in support entry 109770628.

Color value encoding

The WinCC 32-bit color value packs the color components as:

• Bits 0-7: Blue (0..255)
• Bits 8-15: Green (0..255)
• Bits 16-22: Red (0..255, only the lower 7 bits are used; bit 23 is a flag)
• Bit 24: Fill pattern transparency flag

For a pure solid color, set bits 23 and 24 to 0. The formula to compute the integer from (R, G, B) components is:

Int32 colorValue = R * 65536 + G * 256 + B

Note the byte order is BGR, not RGB, when reading the hex. Most engineers precompute these integers in Excel and store them as integer constants in the PLC.

Pre-computed color values

WebUX applies the integer verbatim to the browser's CSS color. Because the upper bits (transparency flags) are interpreted as part of the CSS color (alpha is in the high byte of an ARGB integer), leave them at zero to keep the color opaque.

Wiring the INT32 Tag Connection

Steps to drive the background color from a 32-bit integer tag:

1. In the PLC (or WinCC internal tag), create a DINT/INT32 tag that the control logic writes with the desired color constant. For example, write 16,711,680 for red, 65,280 for green.
2. In Graphics Designer, select the target object and open Object Properties > Properties > Colors.
3. Right-click Background Color > Dynamic > Tag.
4. In the Tag selection dialog, choose the INT32 tag and confirm with OK.
5. The dialog refreshes the property to show the dynamic connection symbol (a small lightning icon at the right of the property field).
6. Do not add a Dynamic Dialog or a VBScript to compute the value. WebUX will silently ignore both.
7. Set a sensible default static color in case the tag is in an undefined state.
8. Compile and save the picture, then publish the WebUX project.

Wiring the BOOL Tag Connection (Two-State)

Steps to drive a two-state color change with a BOOL tag using the flashing mechanism:

1. Open the object properties and navigate to the Flashing group.
2. Set Flashing Background Color On and Flashing Background Color Off to the same target color (the True color).
3. Right-click Flashing Background Active > Dynamic > Tag.
4. Select the BOOL tag.
5. Return to Colors > Background Color and set the static color for the False state.
6. Save and publish.

Direct connection example for an event

For event-driven changes (e.g., the operator pressing a button in the WebUX view), use the Direct Connection dialog on the event itself. Direct connections on events are routed through the WebUX server back into the runtime, so they remain fully functional.

Event: Mouse click on "Ack" button → Direct Connection → Type: Set Tag → Tag: MyPlant.AckRegister

IIS Configuration Specific to Color Polling

Most WebUX color issues are not IIS-related once the WebUX site is installed, but two IIS settings can prevent the property from refreshing:

1. Application Pool Identity. The WebUX application pool must run under an account that has read access to the WinCC project directory (by default WinCCProjects\<ProjectName>) and the tag database. A common misconfiguration is to run the pool under ApplicationPoolIdentity, which lacks the required ACL.
2. ASP.NET Impersonation. Configure ASP.NET Impersonation = Enabled with the same Windows user used for the WinCC runtime. Without impersonation, WebUX can serve screen images but cannot subscribe to tag change notifications, so the property never updates even though the screen renders.
3. WebSocket support (WinCC V7.5+). Older IIS installations block WebSocket upgrade headers. The polling fallback still works, so colors do update, but with a higher latency. Enable the WebSocket Protocol feature on Windows Server 2012 R2 and newer to take advantage of the push channel.

Refresh Rate and Polling Behavior

WebUX refreshes tag-driven properties on a poll cycle rather than a push channel (unless WebSocket push is enabled and supported on the browser and IIS). For color properties specifically:

• Tag-cycle dynamizations honor the configured picture cycle. Setting the picture cycle to 500 ms yields a 500 ms worst-case color update.
• Screen-cycle dynamizations are throttled to a 2-second minimum regardless of the configured picture cycle.
• Flashing colors (the BOOL-method described above) toggle at the configured flashing frequency, but WebUX rounds the frequency to discrete steps of 250 ms.
• Browsers do not re-render the screen when only a CSS background-color value changes for an off-screen element, so verify with the window focused and on-screen.

Reference: Supported functions - Dynamization (WebUX).

Verification Procedure

After wiring, validate the configuration using the following procedure before declaring the screen production-ready.

1. Local runtime check. Open the picture in Graphics Designer run mode (F5). Toggle the BOOL tag or change the INT32 value and confirm the color updates in the local WinCC window.
2. WebNavigator check. Publish to WebNavigator and connect with the WebNavigator client. Confirm the color updates in the browser. If it does, the configuration is correct and the limitation is purely WebUX-specific.
3. WebUX check, fresh browser session. Open a private/incognito window, browse to the WebUX URL (http://<server>/WebUX), authenticate, and confirm the screen renders.
4. Force a tag change. Write the BOOL or INT32 tag from the WinCC tag management or from the PLC. Observe the WebUX screen. Within 2 s the color should update.
5. Open the browser developer console and inspect the network panel. Look for repeated POSTs to /WebUX/Refresh at the configured cycle (typically 1 s or 2 s). A flat line indicates the polling channel is broken.
6. Inspect the DOM. Right-click the object in the browser, choose Inspect, and confirm the inline background-color style changes when the tag toggles.

Troubleshooting Matrix

Migration Considerations

If the project is being migrated from WinCC V7.0 / WebNavigator to WinCC V7.3 / WebUX, audit every property for script-based dynamization. The Excel report Graphics Designer → Tools → Output → List of Dynamizations contains every property with its dynamization type. Filter on script methods and convert them one-for-one to direct connections before publishing to WebUX; otherwise the WebUX view will appear frozen on the static value.

For larger refactors, consider whether the project is a better fit for the newer WinCC Unified (TIA Portal) runtime, which supports JavaScript-based dynamization in the browser and removes the WebUX-style restriction entirely. However, the direct-connection technique above continues to work in WinCC Unified for backward compatibility.

FAQ