Triggering WinCC VB Scripts from C Scripts on Specific Clients

1. Problem Statement and Design Goal

In Siemens WinCC (both the legacy WinCC V7.x and the TIA Portal WinCC Comfort/Advanced runtime), engineers frequently need to execute project logic on a specific client of a multi-client distributed HMI station. The runtime supports two scripting languages:

• C scripts (ANSI-C, WinCC API), which are pre-compiled at project startup and executed natively by the runtime.
• Visual Basic Scripting (VBS) actions, which are interpreted at every execution cycle.

A practical requirement arises when an automation function is required only on Client 2, but the scripting language that fits the function best is VBS - typically because VBS gives quick access to the WinCC graphics runtime object model (HMIRuntime, Screen, ScreenItems, Tags) and is easier to maintain for graphics-driven logic. WinCC, however, allows the property Computer assignment of an action to be set per computer, but this option is exposed cleanly for C actions. For VBS actions scheduled under Global Script > Actions, the computer-filter is either hidden or not honored in the same way, depending on the WinCC version and patch level.

The design goal is therefore:

1. Schedule the VBS action as a cyclic action (e.g., 1 s, 2 s, or event-driven).
2. Ensure the body of the VBS only executes on a single designated client.
3. Avoid the recurring interpretation overhead on every other client/server where the VBS is not required.

The standard, manufacturer-supported way to achieve this is to use a local, non-shared tag as a handshake between a C action (which is the one that is assigned to a specific computer) and the VBS action (which is project-wide).

2. Why a C Action Is Used as the Gatekeeper

C actions in WinCC are compiled to native code by the WinCC project editor at compile time. Once compiled, the runtime loads the binary and invokes it on the schedule you set. Because the C action is bound to a specific computer in the project tree (right-click → Properties → Computer assignment), only that computer's runtime will ever execute it. This makes C the natural place to put the "should I run?" decision.

By contrast, a VBS action is re-parsed by the scripting host (vbscript.dll) on every cycle when it is triggered. On a four-client project, that overhead is multiplied by the number of clients that have the action in their local Global Script container - even when the work the script does is intentionally a no-op. Moving the actual work into a guarded block and using a binary tag to enable/disable the VBS is the simplest, robust pattern.

3. Prerequisites

• WinCC V7.4 SP3 or later (the pattern works from V6.x onward; tested on V7.4 SP3, V7.5 SP2, V7.5 SP3).
• WinCC Explorer with Global Script editor accessible (password may be required, depending on project settings).
• Both the client and the server sides of the distributed system must be running. Server data must be visible to the client (configured package on the server).
• A free internal tag slot, datatype BOOL (binary), to be used as a handshake. Name suggestion: bRun_ClientOnlyLogic.
• The Tag Logging and Alarm Logging services do not need to be running for this pattern - it is purely a runtime tag-based handshake.

4. Tag Architecture for the C → VBS Trigger

The handshake uses two pieces of state:

Because both tags are marked internal and not shared, each runtime instance has its own copy. The C action on the target client flips its local copy to TRUE every cycle; the VBS on every other runtime instance sees FALSE on its own local copy and skips the work.

5. Step-by-Step Implementation

5.1 Create the Handshake Tag

1. Open WinCC Explorer → Tag Management → right-click Internal tags → Add new tag.
2. Name: bRun_ClientOnlyLogic, datatype Binary tag (BOOL), length 1 bit.
3. Confirm with OK. Do not enable tag logging - this is a pure runtime handshake.

5.2 Create the C Action on the Target Client

1. In WinCC Explorer, select the computer that will be the trigger client (e.g., CLIENT_02).
2. Open Global Script > C actions.
3. Right-click → New action. Name: act_GateClientOnly. Trigger: Cyclic - 1 second (or the smallest cycle that meets your latency needs).
4. Open the Properties dialog and confirm under Computer assignment that this action is bound only to CLIENT_02. Remove the assignment to the server and any other client.

Paste the following C body:

/* act_GateClientOnly - cyclic C action on CLIENT_02 only */
#include "apdefap.h"

int gsc_Action(void)
{
    /* Local handle to the internal handshake tag */
    DWORD dwTrigger = 0;

    /* Read current value of the internal BOOL tag */
    if (GetTagBit("bRun_ClientOnlyLogic", &dwTrigger) == FALSE)
    {
        /* If the tag cannot be read, abort this cycle cleanly */
        return 0;
    }

    /* Set the trigger TRUE every cycle on this client. The VBS
       is responsible for resetting it back to FALSE after consuming. */
    dwTrigger = 1;
    SetTagBit("bRun_ClientOnlyLogic", dwTrigger);

    return 0;
}

Click Compile in the C editor toolbar. The C action must compile with 0 warnings, 0 errors. Save the action.

5.3 Create the VBS Action (Project-Wide)

1. Open Global Script > VBS actions (not C actions).
2. Right-click → New action. Name: act_ClientOnlyLogic. Trigger: Cyclic - 1 second (match the C action's cycle).
3. Assign the action to all computers on which it should exist (the gating happens in the script, not the assignment).

Paste the following VBS body:

' act_ClientOnlyLogic - guarded VBS action
Option Explicit

Dim bTrigger
Dim sMachine

' Read the local handshake tag. This is a *local* tag on every
' runtime, so each client sees its own copy.
bTrigger = HMIRuntime.Tags("bRun_ClientOnlyLogic").Read

' Only the client where the C action is running will have bTrigger = 1
If CBool(bTrigger) = True Then

    ' Optional: identify which client we are on, for diagnostics.
    sMachine = HMIRuntime.Tags("@local_machine_name").Read
    HMIRuntime.Trace "act_ClientOnlyLogic running on: " & sMachine & vbCrLf

    ' ---- Place the real client-2-only logic here ----
    ' Example: update a header text on the active screen
    HMIRuntime.Screens("MainHeader").ScreenItems("txtStation").Text = _
        "Client " & sMachine & " active"
    ' ------------------------------------------------

    ' Reset the trigger so we do not run the work twice
    HMIRuntime.Tags("bRun_ClientOnlyLogic").Write 0

End If

Save the action. Note that the VBS itself is loaded on every runtime that has it assigned; the body is essentially a no-op except on the gatekeeper client.

5.4 Compile, Distribute, and Activate

1. Close the Global Script editor.
2. From the server project, recompile the OS (WinCC Explorer > Server > Save and compile OS). Wait for OS compilation completed.
3. Distribute the package to every client (Server Data > Package > Configure package > Update clients).
4. On the target client, activate the WinCC runtime. After a few seconds, the VBS should be running only on that client.

6. Identifying the Local Machine

WinCC exposes several system tags (prefixed with @) that describe the local runtime. The most useful for client identification are:

You can read these in C with GetTagCharValue or in VBS with HMIRuntime.Tags("@local_machine_name").Read. They are computer-local and do not propagate through the WinCC tag system, so they are the canonical way to ask "who am I?" from inside a script.

7. Optional: Direct Script Execution via cscript

If you want the C action to launch an external .vbs file via the Windows Script Host instead of triggering an in-project VBS action, you can call cscript as an external program. Microsoft's official documentation describes this mechanism: Running a Visual Basic Scripting Edition Query.

From a WinCC C action, use the Win32 API WinExec or ShellExecute:

#include "apdefap.h"
#include <windows.h>

int gsc_Action(void)
{
    /* Launch an external VBS file non-blocking */
    ShellExecute(NULL, "open", "wscript.exe",
                 "C:\\Scripts\\ClientOnly.vbs",
                 NULL, SW_HIDE);
    return 0;
}

Drawbacks of the external approach compared to the in-project VBS action:

• The external VBS has no access to the WinCC runtime object model. It cannot read/write WinCC tags, move the active screen, or interact with the graphic system without a separate channel (OPC UA, file, named pipe).
• Process startup latency (typically 80-300 ms) makes this unsuitable for 1 s cyclic logic.
• Process management (cleanup on runtime stop, logon changes) is your responsibility.

Use the in-project VBS approach whenever the script needs the WinCC object model; use the cscript/wscript approach only for purely external tasks (file I/O, FTP, mail, network calls) that the WinCC VBS host cannot do conveniently.

8. Performance and Compilation Considerations

For a 1 Hz cyclic handshake between a C action and a VBS action, the expected CPU contribution on a typical WinCC client is below 0.5% of a single core, even with 100 tags being read inside the VBS body. The dominant cost in such a setup is the VBS parser, which is paid on every runtime that has the action assigned - this is the overhead the gatekeeper pattern is designed to avoid.

9. Verification

1. Activate runtime on the target client only. Open the WinCC Diagnose > ApDiag tool and add the trace output of act_ClientOnlyLogic. Confirm that the trace prints the local machine name once per cycle.
2. Activate runtime on a non-target client (e.g., CLIENT_01). The same VBS action is loaded, but bRun_ClientOnlyLogic stays FALSE because the C action is not assigned there. The trace should remain silent.
3. Stop and re-activate the target client runtime. Within one cycle, the C action sets the trigger; within the next cycle, the VBS body executes and resets the trigger. The latency is bounded by the cycle period of the two actions.
4. Add a temporary Trace in the C action to confirm it runs only on the intended computer:

   printf("act_GateClientOnly on %s\n", GetTagChar("@local_machine_name"));

5. For an end-to-end check, attach a WinCC Tag Simulator forcing bRun_ClientOnlyLogic = 1 on a non-target client. The VBS body should still run on that client (because the tag is forced locally), proving the gating is purely a per-runtime tag-based decision. Remove the simulator when done.

10. Troubleshooting Matrix

11. Best-Practice Checklist

• Always use internal tags for the handshake. Shared tags defeat the purpose.
• Always reset the trigger from the VBS body after consumption to prevent re-execution within the same cycle window.
• Match the cycle of the gatekeeper C action to the cycle of the consumer VBS action, or set the C cycle to a multiple of the VBS cycle.
• Use descriptive tag names (bRun_<Subsystem>) to make the intent clear in the tag list.
• Add a Trace on first commissioning, then remove or comment it out for production.
• If you have more than one gated subsystem on the same client, give each one its own handshake tag - do not multiplex the trigger.
• Do not call HMIRuntime APIs that require a logged-in user from the gatekeeper C action. C has no access to the user session model.

12. FAQ