Restricting Graphic Screens in a WinCC V7 Server-Client Project

Symptom: an IO field's Change event in WinCC V7.1 runs a C or VBS script on the server, but the same script also fires on every connected client. The user has already added a guard with @LocalMachineName, yet the script still executes on clients. This article explains why the guard fails in some project structures, what the correct tag reference looks like, and how to build a reliable per-machine screen restriction for WinCC V7 / WinCC Professional projects.

1. WinCC V7 Server-Client Architecture Recap

A WinCC V7 (SIMATIC WinCC V7.x) server-client project has a single configuration source (the server project) that is opened by every client. The runtime layout typically follows the table below.

Because the same PDL (process picture) is loaded into the runtime of every machine that opens the project, every event-driven script inside that PDL is also loaded on every machine. Restricting which machine actually executes a script is a runtime decision, not a design-time decision; you must check the machine's identity inside the script body and exit early when the check fails.

2. The @LocalMachineName Internal Tag

@LocalMachineName is a WinCC system tag (internal tag, read-only) that returns the Windows computer name of the machine currently running the script. It is one of several system internal tags prefixed with the @ character.

Important property: @LocalMachineName is resolved locally at the moment a script executes, which means on the server it returns the server's Windows name and on each client it returns that client's Windows name. The tag is updated when WinCC Runtime starts and is not affected by a logged-in user.

3. Why the Original Script Still Runs on Clients

Three root causes account for nearly every reported failure of an @LocalMachineName-based guard in WinCC V7 server-client projects.

1. The guard is on the wrong tag. The script compares @ServerName instead of @LocalMachineName. @ServerName is the same string on every machine, so the guard evaluates true everywhere and the body runs everywhere.
2. The IO field event is configured as a "Change" event with the "Always execute on server" option in the Graphics Designer. The event is then dispatched to the server regardless of which client changed the value. To restrict it to a single client you need a local trigger, not a server-side scheduled or dispatched trigger.
3. The script is compiled on the client with a cached copy of the project. After a server-side change, the client must reload the picture or the change does not propagate. Older WinCC V7 service packs (V7.0 SP1, V7.0 SP2) sometimes keep the picture in memory and re-fire the old C action on the client. Adding the guard in the client-loaded picture usually requires a re-connect of the client.

The user in the source thread has already added the @LocalMachineName guard, so the first cause is unlikely. The second cause is the most common: the event is being evaluated server-side. The fix is to move the script body into a client-only trigger context (a button click on the client picture, a per-machine scheduled action, or a project function dispatched from a local timer).

4. Correct C Action Syntax (WinCC V7 / WinCC Professional)

For a C action attached to an IO field's Change event, the body must be a valid C expression or block. A single-line guard is the cleanest form:

// C action - executes only on the machine whose Windows name is "WCC-SERVER-01"
if (strcmp(@LocalMachineName, "WCC-SERVER-01") == 0)
{
    // server-only logic here
    SetTagWord("Machine_State", 1);
}

For a VBS action (used with WinCC V7 VBScript or WinCC Professional):

' VBS action - server-only branch
If HMIRuntime.Tags("@LocalMachineName").Read = "WCC-SERVER-01" Then
    HMIruntime.Tags("Machine_State").Write 1
End If

For a C action on a client machine, replace the literal with the client's name:

// C action - executes only on client "WCC-CLIENT-02"
if (strcmp(@LocalMachineName, "WCC-CLIENT-02") == 0)
{
    // client-only logic here
    SetTagFloat("Local_Only_Temp", 23.5);
}

5. Restricting an Entire Picture to Specific Clients

If the goal is to hide or block a full PDL on a subset of clients, use one of the following three methods in order of preference.

5.1 Hide PDL objects with a per-machine property expression

In the Graphics Designer, select the object (button, rectangle, IO field, etc.) and open the Properties dialog. Replace the static value of Display with a dynamic dialog or a C action:

// C dynamic - object is shown only on WCC-SERVER-01
(strcmp(@LocalMachineName, "WCC-SERVER-01") == 0) ? 1 : 0

For a property named Visible use the boolean 1/0 form. For Transparency use 0 (opaque) or 100 (fully transparent).

5.2 Open a different PDL per machine

On a button's Mouse Click event, write a C action that selects the picture based on @LocalMachineName:

if (strcmp(@LocalMachineName, "WCC-SERVER-01") == 0)
    OpenPicture("Overview_Server.pdl");
else if (strcmp(@LocalMachineName, "WCC-CLIENT-02") == 0)
    OpenPicture("Overview_Client2.pdl");
else
    OpenPicture("Overview_Default.pdl");

5.3 Use the WinCC Authorization system

If the restriction is by user group rather than by machine, configure User Administration in WinCC Explorer and assign a level (1 to 255) to the picture or to the property. The standard configuration is to right-click the picture object and choose Properties > Authorization > Level 5: Process controlling or similar. The picture is only displayed for users with that level. This is the recommended approach when operators are unique per machine and machines share a user database.

6. Using a Server-Side Trigger, Client-Side Body

// Project function: SetMachineState
// Called from a button click on every machine; executes the right body per machine
int SetMachineState(int newState)
{
    if (strcmp(@LocalMachineName, "WCC-SERVER-01") == 0)
    {
        // server-only logic
        SetTagWord("Server_MachineState", newState);
        return 1;
    }
    return 0; // silently ignored on clients
}

Call from the IO field Change event:

SetMachineState(GetTagWord("UserInput"));

7. WebNavigator and RT Professional Considerations

If the project is later migrated to TIA Portal and the screens are published through the WebNavigator or the WebUX, several functional restrictions apply that affect how the @LocalMachineName guard behaves. The official Siemens documentation lists the differences between WinCC V7 basic and WebNavigator / RT Professional.

• WebNavigator clients do not run C actions, only VBScript in a restricted browser sandbox. The @LocalMachineName tag on a WebNavigator client returns the name of the IIS host, not the browser user's workstation.
• RT Professional (TIA) supports C and VBS but the script is configured per HMI tag and the Change event fires in the runtime of the HMI device, not in the web client.
• Picture-level restrictions should be replicated in the WebUX profile if the same screens are exposed publicly.

Reference: Functional restrictions (RT Professional) - WinCC (TIA Portal V20).

Microsoft's Windows client deprecation list is also worth reviewing before deploying a WinCC client on a Windows 10 / 11 / Server 2022 host, as some UI elements (e.g., legacy Windows authentication dialogs) are removed in newer builds. Reference: Deprecated features in the Windows client - Microsoft Learn.

8. WinCC Explorer Configuration for the Server-Client Pair

Open WinCC Explorer on the server and verify the following entries. A mismatched computer name is a frequent root cause of the guard not firing.

9. Verification Procedure

1. Open the WinCC project on the server in Graphics Designer. Locate the IO field whose Change event you modified and confirm the action compiles (Ctrl+F7 in the action editor). A green status bar indicates a successful compile.
2. In the IO field action, add a temporary debug line at the top: printf("\r\n[DEBUG] Machine=%s", @LocalMachineName); (C) or HMIRuntime.Trace "[" & HMIRuntime.Tags("@LocalMachineName").Read & "] fired" (VBS).
3. Activate the server runtime. Open the ApDiag log viewer (Start > Programs > Siemens Automation > SIMATIC > WinCC > Diagnostics > ApDiag) and filter for the Trace source.
4. From each client, open the picture, change the IO field value, and confirm the trace line shows that client's name on that client only.
5. Remove the debug line before commissioning.

10. Troubleshooting Matrix

11. Migration Notes: WinCC V7.1 to TIA Portal V20

If the project is moved to TIA Portal V20 (or the intermediate V17/V18/V19 branches), the @LocalMachineName tag is exposed as a system constant in the HMI tag list, and the C action syntax changes from @LocalMachineName to a property-call form. The semantics are preserved but the comparison must be updated. For a server-only branch in TIA Portal V20 VBScript:

If HmiRuntime.Tags("@LocalMachineName").Read = "HMI-RT-Server" Then
    HmiRuntime.Tags("State").Write 1
End If

For a multi-client HMI panel deployment on Unified Comfort Panels, the equivalent property is the panel's own device name returned by the HmiRuntime API.

12. Best Practices Checklist

• Always reference @LocalMachineName, not @ServerName, when restricting per machine.
• Use the VBS / C Trace function during commissioning to confirm the tag value on every machine.
• Prefer authorization levels over machine names when the restriction is about user role, and prefer machine names when the restriction is about a physical workstation.
• Compile every C action after editing (Ctrl+F7).
• Restart the client runtime after any change to a server-side action, because clients cache the compiled C action.
• Document the mapping (Windows name ↔ logical role) in the project's README so future maintainers do not silently break the guard.
• Re-validate the guard after any firmware update of the WinCC client (V7.1 SP1, SP2, SP3, SP4 are known to alter the C action dispatcher in subtle ways).