Preventing WinCC V6 Tag Scripts Firing on S7-200 Comm Recovery

Problem Statement

When WinCC v6.0 SP4 reads process values from a SIMATIC S7-200 CPU over PC Access (S7-200 PC Access V1.0 SP6 or V2.0 OPC DA server), every WinCC tag that has a Global Script (C or VBS) configured with the trigger "Tag - On change" fires whenever the tag value transitions - regardless of why the transition occurred. Three distinct events produce a burst of unintended script execution:

1. WinCC Runtime startup. WinCC initializes all configured tags. PC Access returns its cached or initial value, WinCC applies the configured update, and every tag trigger fires once during the start sequence.
2. Communication loss. When PC Access loses the S7-200 link (cable break, CP 243-1 power-cycle, S7-200 STOP transition, hub failure), the tag's quality code flips from OPC_QUALITY_GOOD (0xC0) to a BAD quality, typically 0x18 = OPC_QUALITY_BAD_COMM_FAILURE. WinCC's quality handling applies the configured substitute value, which in most projects differs from the last good process value, so every script bound to that tag fires.
3. Communication restoration. PC Access re-establishes the link and refreshes every item. The newly read S7-200 value (which may or may not equal the substitute value) is written into the WinCC tag, and every tag-triggered script fires a second time - within the same second, on every tag.

The user-visible result is a burst of VB and C actions the moment the link comes back, regardless of whether the actual process value changed. On a panel with several hundred tag-triggered scripts this stalls Runtime for several seconds and can trigger unintended output writes if those scripts contain SetTag / SetTagFloatWait calls back to the PLC. The question "is it normal after a lost comm, and how do I stop WinCC from calling every event when communication is restored?" is one of the most common WinCC v6.0 issues on S7-200 installations. The answer is: yes it is normal, and the only reliable control point is to gate the script body itself.

Why Tag-Triggered Actions Fire on Communication Events

The WinCC v6.0 Global Script runtime executes an action the moment any of the configured triggers become true. The trigger types available in the action properties dialog (right-click action > Properties > Triggers) are summarized below.

The critical detail: "On change" is implemented as a value-edge detector, not a process-edge detector. The WinCC Tag Manager compares the current tag value (whatever the OPC DA server returned) to the previous one it has stored. Any difference - whether the PLC really changed its process variable, whether the OPC layer forced a substitute value, or whether Runtime simply initialized the tag with its starting value - counts as a change and fires the action.

The "Global Script runtime" option in the WinCC project properties (Computer > Properties > Startup > Global Script runtime) is therefore not the place to suppress this behavior: turning it off disables the entire script engine, including the C and VBS actions that are supposed to run on demand from picture events. The same applies to the "Start Global Script runtime after X seconds delay" option - it only delays the first firing, it does not filter re-firings after a reconnect.

WinCC v6.0 SP4 Tag Quality Model and OPC Quality Codes

Every WinCC tag carries a 16-bit quality code that mirrors the OPC DA quality byte returned by PC Access. The WinCC Information System documents the quality-code constants available to VBS and C actions. The values most often seen on an S7-200 link are listed below.

Three values drive the gating logic:

• 192 (0xC0) - GOOD - normal process value, safe to execute the script body.
• 24 (0x18) - BAD_COMM_FAILURE - PC Access has just declared the link lost. WinCC is applying the substitute value, the script is firing on the substitute, not on a real change.
• 8 (0x08) - BAD_NOT_CONNECTED - the first phase of startup, before the link is even up.

The recommended pattern in the WinCC v6.0 Information System ("Working with WinCC > Tag Management > Quality of Tags") is to read the tag quality in the action body and short-circuit early when the value is not GOOD. The quality code is accessible from VBS as HMIRuntime.Tags("Tagname").Quality and from C as GetTagQuality(lpszTagName) declared in apdefap.h. The bit layout of the quality word is also available as QualityStamp and SubstituteValueUsed in the same property set.

Pre-Deployment: S7-200 and PC Access Setup Verification

Before applying the gating logic, the PC Access / S7-200 side must be configured so that comm-loss / restore events are recognized cleanly by WinCC. The following checklist prevents the quality from flipping for unrelated reasons (which would defeat the gate).

1. Open S7-200 PC Access and confirm the S7-200 station is in the "Connected" state, not "Connecting" or "Disconnected".
2. Configure the PC Access item update rate to the project default (typically 500 ms for HMI, 1000 ms for SCADA). Faster rates amplify the re-firing burst after reconnect.
3. For PPI / MPI links, set the Retry Attempts to at least 3 and Timeout to 1000 ms in PC Access > right-click station > Properties > Communication. This prevents PC Access from declaring BAD_COMM_FAILURE on a single missed scan.
4. For Ethernet (CP 243-1), enable the "Keep-alive" option in the CP 243-1 configuration (STEP 7 Micro/WIN > Ethernet Wizard > Configuration > Keep-alive timer = 30 s) so the TCP session is held open and PC Access does not have to renegotiate it on every reconnect.
5. In the WinCC Tag Manager, open each affected tag and confirm Update = "On change" (not "Cyclic only") and that Substitute value is set deliberately (see Solution 3).
6. Verify that the S7-200 CPU is in RUN, not STOP. PC Access returns BAD_DEVICE_FAILURE for a CPU in STOP, which can be confused with a cable fault.

Solution 1 - Internal Tag Gating (Runtime + Connection Health Flags)

The internal-tag gate uses two WinCC internal tags (binary) that are driven by a single health-check action running on a 1 s cycle. All other tag-triggered scripts read those two flags and abort early if either flag is not set. This is the pattern the Siemens WinCC v6.0 support team recommends in production S7-200 panels.

Step 1 - Define the two internal tags in WinCC Tag Manager.

Use the "@" prefix to mark them as internal (no external connection) and set the update to "On change" in the Quality / Substitute dialog so they do not fire value-changed events themselves.

Step 2 - Configure a 1 s cyclic action "Init_RuntimeFlags" as the first action to run.

In Global Script > New Action > Properties > Triggers, set the trigger to a 1 s cyclic time trigger and set the "Global Script runtime must be running" check. Use the project property "Start sequence: First action to run" to ensure this action is always scheduled before any tag-triggered action.

' VBS - Init_RuntimeFlags.vbs
' Set RuntimeStarted after 5 s of stable Runtime.
' Set LinkToS7200OK only when a representative OPC tag has quality = 192.

Dim tElapsed, tStart, oTag, qResult
tStart = HMIRuntime.StartTime    ' returns Date as Variant

' Wait 5 s after Runtime start to let WinCC and PC Access settle.
If DateDiff("s", tStart, Now) >= 5 Then
    HMIRuntime.Tags("@RuntimeStarted").Write 1
End If

' Quality probe on a fast-changing process tag (e.g. S7-200 V200.0 = 1 Hz heartbeat).
Set oTag = HMIRuntime.Tags("S7200_Heartbeat")
oTag.Read
qResult = oTag.Quality
If qResult = 192 Then
    HMIRuntime.Tags("@LinkToS7200OK").Write 1
Else
    HMIRuntime.Tags("@LinkToS7200OK").Write 0
End If

Step 3 - Gate every tag-triggered script on both flags.

' VBS - example tag-triggered action (header)

Dim fRun, fLink, oTrig

Set oTrig = HMIRuntime.Tags("S7200_TagThatTriggersMe")
oTrig.Read

fRun  = HMIRuntime.Tags("@RuntimeStarted").Value
fLink = HMIRuntime.Tags("@LinkToS7200OK").Value

If fRun = 0 Or fLink = 0 Then
    ' Abort: Runtime not stable or link is down.
    Exit Sub
End If

' ... real script body ...

The two-flag gate guarantees that even if the tag-trigger fires 200 times in one second during a reconnect cascade, every gated script short-circuits as long as @LinkToS7200OK is still 0. The health-check action then re-asserts the flag on the next 1 s tick once the heartbeat tag comes back GOOD.

Solution 2 - Quality-Based Gating Inside the Script Body

The quality gate inspects the trigger tag's own quality and only executes the script body when the quality is GOOD (192). This is the most localized fix: it does not require any other tags, it does not depend on a separate health action, and it works even if you forget to add the internal-tag gate. The cost is one extra Read per script firing, which is negligible compared to the cost of an unwanted SetTag.

' VBS - Quality-gated action body

Dim oTrig, q

Set oTrig = HMIRuntime.Tags("S7200_ProcessValue_1")
oTrig.Read
q = oTrig.Quality

' 192 = OPC_QUALITY_GOOD
If q <> 192 Then
    Exit Sub            ' substitute value, comm-loss, or initial value - do nothing
End If

' --- real action body starts here ---
Dim processValue
processValue = oTrig.Value
' ...

C equivalent (apdefap.h):

#include "apdefap.h"

void OnChange_ProcessValue_1(char* lpszTagName)
{
    DWORD q = GetTagQuality(lpszTagName);
    if (q != 0xC0)         // 192 dec, OPC_QUALITY_GOOD
        return;

    float pv = GetTagFloat(lpszTagName);
    // ... real action body ...
}

Quality gate edge cases.

For C actions, also consider GetTagQualityState and the QualityStamp property in WinCC v6.2 / v6.2 SP2, which exposes the time of the last successful read. Combining the quality gate with a "value changed since last good read" check eliminates the residual issue of a fresh process value that happens to equal the substitute value (the gate would still fire, but the body can detect that the timestamp is the same as the last good read).

Solution 3 - Substitute Value Configuration

The substitute value is the value WinCC pushes into a tag when the OPC quality is not GOOD. The wrong substitute value is the root cause of most "tag-triggered script fired unexpectedly" complaints. Two rules eliminate the noise at the source.

1. Set the substitute value to the same value the tag would have when the process is idle / safe. For a digital input, this is the OFF state (0). For a 4-20 mA analog, this is 0.0 (or 4.0 if your engineering units are 0-based). For a 16-bit counter, it is 0. The point is: a comm-loss transition must look identical to a normal idle transition.
2. Disable the substitute value entirely ("Initial value = Substitute value = Quality of the tag"). In WinCC v6.0, open the tag, select "Properties > Update", and check "Apply substitute value only on configured quality code". This forces the tag value to retain its last good process value when the quality is BAD, so the tag-trigger sees no edge on comm loss or restore.

Complete Script Examples (VBS and C)

The example below combines Solutions 1 and 2 in a single tag-triggered action. The action is bound to the tag S7200_Temp_SP (a setpoint from the S7-200) and writes the value to a data-log tag Archive_SP. Without gating, this action fires on every reconnect cascade and floods the archive with duplicate rows.

' VBS - ArchiveSetpoint.vbs
' Trigger: tag "S7200_Temp_SP", on change
' Action: append value to archive tag only if link is healthy and value is fresh.

Const QUALITY_GOOD = 192

Dim oTrig, q, v, fRun, fLink, oRun, oLink

Set oTrig = HMIRuntime.Tags("S7200_Temp_SP")
Set oRun  = HMIRuntime.Tags("@RuntimeStarted")
Set oLink = HMIRuntime.Tags("@LinkToS7200OK")

oTrig.Read
oRun.Read
oLink.Read

fRun  = oRun.Value
fLink = oLink.Value
q     = oTrig.Quality
v     = oTrig.Value

' --- Gate block (3 conditions) ---
If fRun  = 0 Then Exit Sub           ' Runtime not yet stable
If fLink = 0 Then Exit Sub           ' S7-200 link is down or not yet up
If q    <> QUALITY_GOOD Then Exit Sub  ' Substitute or initial value

' --- Real action body ---
HMIRuntime.Tags("Archive_SP").Write v
HMRuntime.Trace "Archive_SP updated to " & v & " at " & Now & vbCrLf

C equivalent with both gates.

#include "apdefap.h"

#define QUALITY_GOOD 0xC0   // 192 decimal, OPC_QUALITY_GOOD

void OnChange_ArchiveSetpoint(char* lpszPictureName, char* lpszObjectName, char* lpszTagName)
{
    // Solution 1: internal flag gate
    if (GetTagByte("@RuntimeStarted") == 0)  return;
    if (GetTagByte("@LinkToS7200OK") == 0)  return;

    // Solution 2: quality gate
    if (GetTagQuality("S7200_Temp_SP") != QUALITY_GOOD) return;

    // Real body
    float v = GetTagFloat("S7200_Temp_SP");
    SetTagFloat("Archive_SP", v);
    printf("Archive_SP updated to %f\n", v);
}

Health-probe action (companion to the example above).

' VBS - HeartbeatMonitor.vbs
' Trigger: 1 s cyclic time trigger (NOT a tag trigger)
' Purpose: keeps @LinkToS7200OK in sync with the S7-200 heartbeat tag quality.

Const QUALITY_GOOD = 192
Const QUALITY_BAD_COMM = 24
Const QUALITY_NOT_CONNECTED = 8
Const QUALITY_BAD_DEVICE = 12

Dim oHB, q
Set oHB = HMIRuntime.Tags("S7200_Heartbeat")   ' S7-200 V200.0 toggled every 1 s in OB1
oHB.Read
q = oHB.Quality

Select Case q
    Case QUALITY_GOOD
        HMIRuntime.Tags("@LinkToS7200OK").Write 1
        HMIRuntime.Tags("@LastQualityCode").Write 192
    Case QUALITY_BAD_COMM, QUALITY_NOT_CONNECTED, QUALITY_BAD_DEVICE
        HMIRuntime.Tags("@LinkToS7200OK").Write 0
        HMIRuntime.Tags("@LastQualityCode").Write q
    Case Else
        HMIRuntime.Tags("@LinkToS7200OK").Write 0
        HMIRuntime.Tags("@LastQualityCode").Write q
End Select

WinCC v6.0 SP4 Configuration Checklist

Verification and Test Procedure

Validate the gating in a controlled sequence before deploying to a live panel. Each step must be performed on a panel with at least 50 tag-triggered actions bound to live S7-200 values, and a process simulator that can hold the S7-200 values constant while the link is cycled.

1. Baseline - link up, process stable. Confirm no script fires for at least 30 s (check WinCC Diagnostic > GSC Runtime > Action call count).
2. Simulated comm loss. Disconnect the PPI cable (or pull the CP 243-1 patch cable). Within 2 s, confirm @LinkToS7200OK = 0, @LastQualityCode = 24, and the "GSC Runtime > Action call count" for every gated action stays at its baseline value (no fires).
3. Link reconnected, process unchanged. Restore the cable. Confirm within 3 s that @LinkToS7200OK = 1 and that no gated action fired during the reconnection window. The only allowed fires are the HeartbeatMonitor (1 s cyclic) and the Init_RuntimeFlags (1 s cyclic).
4. Link reconnected, process changed during outage. Change the S7-200 process value during the outage (e.g. ramp a setpoint from 50 to 75). After reconnection, confirm the gated action fires exactly once with value = 75.
5. PLC STOP / RUN cycle. Toggle the S7-200 from RUN to STOP and back. Confirm that all tag qualities cycle 192 -> 12 -> 192, the link flag drops to 0 in the BAD_DEVICE_FAILURE phase, and that the gate correctly suppresses script execution until the link flag is re-asserted.
6. Runtime cold start with link down. Stop WinCC Runtime, pull the cable, restart Runtime. Confirm the Init_RuntimeFlags sets @RuntimeStarted = 1 after 5 s, but @LinkToS7200OK stays 0 until the cable is restored.

A successful run of all six steps confirms the gate. If step 3 still shows unwanted fires, the most common cause is a tag whose substitute value differs from the value the PLC was holding just before the outage - revisit Solution 3 and set the substitute equal to the last good process value, or disable the substitute entirely.

Migration Notes - Behavior in WinCC Unified (TIA Portal V20)

The root cause (a tag-update event after reconnect) carries forward into WinCC Unified, but the event model is significantly different. The newer runtime exposes a richer set of explicit events on the tag and on the connection, which makes the gate far easier to express.

The WinCC Unified event documentation (Basics on the events (RT Unified)) lists the supported events per object and notes that the runtime fires "Tag value changed" and "Quality changed" as two independent events, so a single reconnect that re-establishes a fresh value can be observed as one "Quality changed (BAD -> GOOD)" event followed by one "Tag value changed" event. A CWC implementation pattern for this is documented in the engineering CWC guide for WinCC Unified. The internal-flag pattern from Solution 1 still applies - it is just expressed in JavaScript on the connection-state event rather than in a 1 s cyclic C action.

Troubleshooting Matrix

Frequently Asked Questions