Configuring Continuous Scripts in WinCC RT Advanced

WinCC Runtime Advanced (the panel-side runtime for Siemens SIMATIC HMI Panels and PC-based RT Advanced stations) exposes a single, shared scheduler for all VBScript actions. Engineers frequently ask how to keep a script "running all the time" without an external trigger. The runtime does not support a literal "free-running" script, but it provides three deterministic substitutes: scheduled tasks, cyclic triggers, and tag-triggered actions. Choosing the right mechanism is the difference between a stable HMI and a runtime that stalls under load.

1. Runtime Execution Model

WinCC RT Advanced uses a single execution queue for every VBScript action and every C-action in the project. This architectural constraint — present since WinCC flexible 2008 and carried forward through TIA Portal V16 through V19 — drives every design decision below.

Because there is only one queue, a slow script blocks every other scheduled action, every value-change trigger, and every screen update tied to a script. The runtime does not preempt a running script — it waits for completion before dispatching the next scheduled call.

2. Prerequisites

• TIA Portal V16, V17, V18, or V19 with WinCC Comfort/Advanced option installed.
• A configured HMI device (Comfort Panel TP700..TP2200, or PC-based RT Advanced) compiled and transferred.
• Project rights to edit "Schedules" under HMI Tags & Connections → Schedules.
• For VBScript authoring: enabled VBScript runtime on the target (default on all Siemens panels).
• Familiarity with WinCC Advanced scripting manual (entry ID 109755202).

3. Method A — Scheduled Task (Recommended)

A scheduled task invokes a VBScript function on a fixed time interval independent of any tag value change. It is the cleanest substitute for a "continuous" loop because the runtime owns the timer, the script returns control to the scheduler after each call, and the task is dispatched on the same single queue (so timing is predictable but you must keep the script short).

3.1 Creating the schedule

1. In the TIA project tree, expand the HMI device and open Schedules.
2. Right-click → Add new schedule. Name it (e.g., Poll_Loop_1s).
3. In the schedule's properties set the trigger type to Cyclic and enter the interval. Minimum selectable interval is 100 ms; practical minimum is 1 s.
4. Assign a VBScript function as the event handler of the schedule.

3.2 VBScript template

Function Poll_Loop_1s_Trigger(ByVal Item)
    Dim t0
    t0 = Now

    ' --- user logic (must complete well inside cycle time) ---
    SmartTags("AuxValue") = SmartTags("AuxValue") + 1

    ' --- diagnostic timer (optional) ---
    ShowSystemAlarm "Poll_Loop_1s execution ms: " & _
        DateDiff("s", t0, Now) * 1000
End Function

The schedule object exposes a single VBScript event [ScheduleName]_Trigger. The argument Item is the runtime schedule object and is rarely needed for poll loops.

4. Method B — Tag-Triggered Cyclic Execution

Tag triggers are often the better choice because they let the runtime batch value updates and only invoke the script when something changed. To produce a periodic trigger you can either:

• Use an internal tag whose value is updated by the PLC on a fixed cycle (typical scan time = 100 ms).
• Use the HMI's own "Update" cycle of an internal pointer tag set to "Cyclic in operation" with a 1 s update.

4.1 Configure the trigger tag

1. Add an internal HMI tag Heartbeat (type: Int, length 1).
2. Set Acquisition mode = Cyclic continuous, Cycle = 1s.
3. In the tag's Events tab add a VBScript action tied to Value change.

4.2 Trigger handler

Sub Heartbeat_OnChange(ByVal Item)
    ' Item.DSMObject gives access to runtime tag info if needed
    If SmartTags("EnablePolling") = 0 Then Exit Sub

    ' --- short, deterministic body ---
    SmartTags("Counter") = SmartTags("Counter") + 1
End Sub

The advantage over a fixed schedule is that the action only fires when the runtime actually observed a value change. With a 1 s update cycle on an internal tag this is functionally identical to a 1 s scheduled task but consumes one fewer scheduler object.

5. Method C — Cyclic Trigger on a Screen or Function Key

WinCC RT Advanced also allows a "Cyclic" event on a screen object or a function key. This is rarely the right answer because the trigger only fires while that screen or that key object is loaded and in focus. It is mentioned here only to caution against using it as a substitute for a continuous poll.

6. Monitoring Execution Time with ShowSystemAlarm

The runtime function ShowSystemAlarm writes a string into the system's alarm buffer with timestamp. Sandwiching the script body between two timestamp captures is the standard way to verify that your "continuous" script finishes inside its cycle budget.

Sub PollLoop(ByVal Item)
    Dim t0, ms
    t0 = Timer            ' seconds with sub-second resolution

    ' --- work ---
    CalcDerivedTags

    ms = (Timer - t0) * 1000
    If ms > 800 Then
        ShowSystemAlarm "PollLoop over budget: " & ms & " ms"
    End If
End Sub

Use Timer (VBScript built-in) rather than Now; Now only resolves to whole seconds and cannot capture sub-cycle execution time.

7. Why You Should Not Use an Internal Do...Loop

A common first attempt is:

' DO NOT DO THIS
Sub StartLoop(ByVal Item)
    Do
        SmartTags("Counter") = SmartTags("Counter") + 1
        ' ...
    Loop
End Sub

This blocks the only script queue for the entire duration of the loop. While the loop runs:

• No other scheduled task fires.
• Tag-triggered events queue up but never run until the loop exits (or the runtime watchdog trips).
• Screen change scripts and alarm-triggered scripts are deferred.
• The runtime watchdog (typically a few seconds) eventually raises 70022-class alarms and the panel may restart.

The correct pattern is to design the function as a stateless "tick" and rely on the scheduler for periodicity.

8. Performance Budget for a Comfort Panel TP900

Empirical guidance for an 800 MHz ARM-based Comfort Panel running TIA V18 RT Advanced:

9. Step-by-Step: Build a 1 s Continuous Poll

9.1 Add the schedule

1. Project tree → HMI device → Schedules → right-click → Add new schedule.
2. Name: Poll_1s.
3. Trigger: Cyclic, Interval: 1 s.
4. Confirm with OK.

9.2 Add the VBScript

1. Project tree → HMI device → VBScripts → right-click → Add new VBScript.
2. Name the script file mod_Poll.vbs.
3. Paste the body from section 3.2.
4. Right-click the schedule Poll_1s → Properties → Events → Trigger event → assign the function Poll_Loop_1s_Trigger.

9.3 Compile and transfer

1. Right-click the HMI device → Compile & download (full).
2. On the panel, navigate to the alarm buffer and look for the Poll_Loop_1s execution ms messages.

10. Verification Procedure

1. After transfer, open the system alarms screen and verify Poll_Loop_1s fires approximately once per second.
2. Force the function to a 2 s body by adding WScript.Sleep 2000 (debug only — never ship) and confirm the runtime surfaces a queue-overrun alarm.
3. Open multiple screens concurrently and confirm that scheduled task continues to fire — this proves you are using a runtime-wide schedule, not a screen-bound cyclic event.
4. Toggle the internal tag EnablePolling from the PLC and verify the function honours the guard clause.
5. Capture the runtime log for one hour; verify no 70022 "Script execution time exceeded" alarms.

11. Troubleshooting Matrix

12. Common Anti-Patterns

• Internal infinite loop: blocks the single queue and triggers watchdog.
• Reading many external tags per tick: each SmartTags() call is a marshalling op; cache and reuse.
• Polling on screen-c open instead of a schedule: poll stops when the screen closes.
• Multiple overlapping schedules: 2 s and 1 s on similar logic double the queue load with no benefit.
• Using Now for timing: only second-resolution, masks over-budget scripts.

13. Migrating From WinCC flexible 2008

The schedule concept is preserved in TIA Portal, but the property pages and event binding locations changed. In WinCC flexible 2008 the schedule event was bound in the schedule editor; in TIA Portal V16+ it is bound in the schedule's properties → Events → Trigger. If you are importing a WinCC flexible project with a continuous poll into TIA, verify the event binding survived the migration and re-test on a 1 s body to confirm queue capacity.

14. When to Move Up to WinCC RT Professional

If your application needs multiple long-running background scripts, genuine multithreading, OPC UA server publishing, or redundant HMI pairs, escalate to WinCC Runtime Professional. RT Professional provides background tasks with their own threads, which removes the single-queue constraint that drives every rule in this article.

15. Summary of the Recommended Pattern

1. Design the function as a stateless "tick".
2. Bind it to a schedule at the largest interval that still meets functional requirements.
3. Wrap the body with Timer-based timing and ShowSystemAlarm for diagnostics.
4. Keep the body under 40 % of the cycle period.
5. Use a tag trigger instead of a schedule when the script should only run when external state changes.
6. Never use an internal Do...Loop to simulate continuity.