Resolving WinCC VBS Button: Writing 0 Then 1 to PLC Tag

Problem Description

A WinCC Runtime (WinCC RT, WinCC RT Professional, or PCS 7 OS) project uses a button event (typically OnLButtonDown or OnClick) to start a motor. The motor logic in the AS (PLC) only acknowledges a rising edge (0 → 1) on the start tag. A single Visual Basic Script on the button must therefore write 0 first, then 1, so that any residual 1 from a previous latched state is cleared and a fresh positive edge is generated.

The script as written never reaches the PLC: only the value 0 is delivered; the trailing Tag.Write 1 is silently lost. Symptoms include:

• Clicking Start does not start the motor.
• Clicking Stop followed by Start works.
• Manually pressing Start only works after a previous successful stop has cleared the bit.
• Inserting a MsgBox between the two writes "magically" makes the script work.
• Splitting the two writes across OnLButtonDown and OnLButtonUp (mouse press / release) also works, but is unreliable when the user releases the button outside the control.

The defect is in the runtime write semantics, not in the ladder/CFC logic.

Root Cause Analysis

Three independent mechanisms conspire to drop the second write. All three must be addressed for a robust fix.

1. Asynchronous Tag.Write

The VBS method HMIRuntime.Tags("Tag").Write queues the value into the WinCC data manager; it does not block until the value has been transmitted to the AS. The next line of script executes immediately. When two writes are issued back-to-back against the same tag within microseconds, the second write overwrites the first in the queue before the data manager has had a chance to dispatch the first value to the PLC.

Consequence: only the last assignment in the script survives — in this case Tag.Value = 1 is written, but the prior forced write of 0 is lost, so no edge is generated if the previous value was already 1.

2. PLC Cycle Time and Read-Back Race

When the script does a Tag.Read immediately after Tag.Write 0, the readback returns the value held in the local WinCC tag image, not the value currently latched in the AS. With a typical PCS 7 / S7-300 OB1 cycle of 100 ms, the value 0 may not yet be confirmed in the WinCC image by the time the second write fires, so the conditional If Tag.Value = 0 Then Tag.Write 1 branch is never entered.

3. WinCC Data Manager Cycle

The data manager flushes pending tag updates on its own cycle (default 1000 ms / 1 s for standard projects, configurable). Two rapid-fire writes inside one script tick collapse into a single delta event in the tag log because the second write cancels the first before transmission. Increasing the script-trigger cycle does not solve this; only a synchronous write primitive can.

Affected Products and Versions

Siemens documents the asynchronous write behavior in FAQ entry 18943009 on the Siemens Industry Online Support portal — see Why are values not written to / read from the PLC by means of WinCC scripts?

Workaround 1 — Two-Event Split (OnLButtonDown / OnLButtonUp)

The simplest workaround is to split the two writes across mouse press and mouse release events. The human interaction time between down and up (typically 80–300 ms) gives the data manager enough time to flush the first write.

' Button event: OnLButtonDown (Mouse Action)
Sub OnLButtonDown(ByVal Item, ByVal Flags, ByVal x, ByVal y)
    HMIRuntime.Tags("MOTOR_CMD").Write 0
End Sub

' Button event: OnLButtonUp (Mouse Action)
Sub OnLButtonUp(ByVal Item, ByVal Flags, ByVal x, ByVal y)
    HMIRuntime.Tags("MOTOR_CMD").Write 1
End Sub

Drawback: If the user drags the cursor off the control before release (common in operator HMI environments), OnLButtonUp does not fire, and the motor command stays at 0, latched off. This is unsafe for a motor-start HMI.

Workaround 2 — MsgBox Delay

A MsgBox between the two writes blocks the script long enough for the data manager to transmit. Engineers sometimes use this as a diagnostic step, not a production solution:

Sub OnLButtonDown(ByVal Item, ByVal Flags, ByVal x, ByVal y)
    Dim Tag, OK
    Set Tag = HMIRuntime.Tags("CFC_variable")
    Tag.Value = 0
    Tag.Write, 1          ' force flush, no read-back
    Tag.Read
    If Tag.Value = 0 Then
        OK = MsgBox("Start motor?", 308, "Confirm")
        If OK = 6 Then Tag.Write 1
    End If
End Sub

Drawback: A modal MsgBox is unacceptable in a process HMI: it blocks operator acknowledgement, cannot be localized through the WinCC text library, violates GAMP 5 / 21 CFR Part 11 audit trail requirements, and confuses the operator because the focus leaves the control.

Workaround 3 — Global VBS Action with Toggle Tag

This pattern uses a separate boolean edge-request tag (named iSTRT in the field report) that triggers a global action. The action reads the current motor state and flips it through a debounced state machine.

Tag configuration:

Button configuration (no VBS required on the button):

• Button Start: Mouse → Mouse Action → Direct connection → set iSTRT = 1
• Button Stop: Mouse → Mouse Action → Direct connection → set MOTOR_CMD = 0

Global VBS Action (trigger: iSTRT, cycle 500 ms):

Option Explicit

Function action
    Dim motor, i
    Set motor = HMIRuntime.Tags("MOTOR_CMD")
    motor.Read
    Set i = HMIRuntime.Tags("iSTRT")
    i.Read

    If i.Value <> 0 Then
        If motor.Value = 1 Then
            ' First pass: clear the bit
            motor.Value = 0
            motor.Write, 1           ' force immediate write
            i.Value = i.Value + 1    ' request the rising edge on the next cycle
            i.Write
            If i.Value > 2 Then
                i.Value = 0          ' safety clamp
                i.Write
            End If
        Else
            ' Second pass: rising edge delivered
            motor.Value = 1
            motor.Write
            i.Value = 0
            i.Write
        End If
    End If
End Function

The 500 ms cycle guarantees the data manager has flushed 0 before 1 is queued. Increase the cycle to 1000 ms if the AS scan is sluggish, but never drop below 500 ms.

Drawback: Adds a global scheduler, two extra tags, and a 500 ms minimum latency between press and motor start. Not acceptable for fast jog commands.

Recommended Solution — Synchronous C Functions (SetTagXXXWait)

The clean, deterministic fix is to replace the asynchronous VBS Tag.Write with the synchronous C-function equivalent from the WinCC API. These functions block the calling thread until the value has been confirmed by the data manager (and, with the Wait suffix, until the next AS cycle has latched the value).

Siemens exposes the following synchronous primitives for Bool tags:

To use these in a button event, expose them through a project-wide C function or call them directly from a global action written in ANSI-C (WinCC V7.x) or a C# wrapper in WinCC Unified (V16+). For a VBS-only project, create a small C function in the project, then call it from VBS using HMIRuntime.SysFct....

Implementation: C function in the WinCC project

Open Graphics Designer → C scripts → project functions. Add a new function:

// Project function: PulseMotorCmd(LPCTSTR lpszTagName)
// Writes 0, waits for acknowledgement, then writes 1.
#include "apdefap.h"
void PulseMotorCmd(LPCTSTR lpszTagName)
{
    // Step 1: clear the bit and wait for the data manager to flush it
    SetTagBitWait(lpszTagName, 0);
    // Step 2: small grace period (AS scan-time dependent, default 50 ms)
    Sleep(50);
    // Step 3: deliver the rising edge
    SetTagBitWait(lpszTagName, 1);
}

Reference the C-function documentation at WinCC V7.5 - Scripting: VBS, ANSI-C, VBA for the full API and the apdefap.h header definition. The SetTagBitWait semantics are formally described in the WinCC Information System under Runtime API > C-Scripting > Tag functions > Synchronous tag access.

Calling the C function from a VBS button

Sub OnLButtonDown(ByVal Item, ByVal Flags, ByVal x, ByVal y)
    HMIRuntime.SysFct.PulseMotorCmd "MOTOR_CMD"
End Sub

This is the production-grade fix: single button event, deterministic edge, no MsgBox, no global scheduler, no reliance on human timing.

Alternative: Pure-VBS Pulse Using a Hidden Trigger Tag

When C functions are not available (e.g., WinCC RT Professional on TIA Portal with restricted scripting), the following pure-VBS pattern produces a clean 0→1 pulse by writing the trigger and letting a scheduled global action perform the actual edge. This is the most portable workaround.

' Global action triggered on iSTRT, cycle 250 ms
Sub PulseTrigger()
    Dim cmd, req, ack
    Set cmd = HMIRuntime.Tags("MOTOR_CMD")
    Set req = HMIRuntime.Tags("iSTRT")
    Set ack = HMIRuntime.Tags("iSTRT_ACK")

    cmd.Read
    req.Read
    ack.Read

    If req.Value = 1 And ack.Value = 0 Then
        If cmd.Value = 0 Then
            ' We are already low; deliver the edge
            cmd.Write 1, 1
            ack.Write 1
        Else
            ' Force low first; next cycle raises the edge
            cmd.Write 0, 1
        End If
    End If
End Sub

The ack tag is reset from the AS on receipt of the rising edge, releasing the latching so the operator can re-trigger.

Step-by-Step Commissioning Procedure

1. Open the WinCC project in Graphics Designer (or TIA Portal → HMI for RT Professional).
2. Create the output tag MOTOR_CMD of type Bool, mapped to the AS address (e.g., DB100.DBX0.0). Update cycle = 100 ms.
3. If using the C-function route, add the project function PulseMotorCmd shown above. Compile.
4. Open the Start button properties → Events → Mouse → Mouse Action → Direct connection to call HMIRuntime.SysFct.PulseMotorCmd "MOTOR_CMD", or a small VBS that calls the function.
5. Open the Stop button → Direct connection → set MOTOR_CMD = 0.
6. In the PLC (STEP 7 / TIA Portal), implement the motor block as a positive-edge evaluation on MOTOR_CMD, e.g., using FP on a Bool, or a TON/TOF pulse generator on the rising edge.
7. Activate the Runtime. Click Start. The motor should start on every press, even if it was latched off due to a previous AS error.

Verification Checklist

Troubleshooting Matrix

Why the PLC-Side Cycle Matters

Even with synchronous C functions, the AS scan time determines the minimum separation between the 0 and the 1 writes. With a 100 ms OB1 cycle, a 50 ms Sleep() inside the C function is sufficient. With a 1000 ms CFC cycle (typical PCS 7), increase the grace period to at least 1100 ms, or — preferred — let the AS-side logic confirm the 0 before the HMI sends the 1. The most robust pattern is a small AS-side handshake:

// AS code (SCL, FB "MotorHmi")
IF HMI_Start_Pulse THEN
    IF NOT Motor_Running THEN
        Motor_Running := TRUE;
    END_IF;
    HMI_Start_Pulse := FALSE;       // acknowledge and reset
END_IF;

The HMI then sets HMI_Start_Pulse for one cycle and the AS clears it; the rising edge is generated entirely on the AS side, eliminating the HMI-side race entirely.

Standards and Documentation References

Siemens documents the asynchronous write behavior in FAQ 18943009 — Why are values not written to / read from the PLC by means of WinCC scripts? — and the synchronous API in the WinCC Information System under ANSI-C for Creating Functions and Actions > Synchronous Tag Access. The full WinCC V7.5 SP2 scripting manual is available at SIMATIC HMI WinCC V7.5 - Scripting (VBS, ANSI-C, VBA). For TIA Portal WinCC Unified V17/V18, the equivalent is documented under JavaScript runtime API > HMIRuntime.Tags.SysFct.