Resolving WinCC Comfort VBScript AND Operator Failure

Problem Overview

On Siemens SIMATIC Comfort Panels (TP700-Comfort, TP900-Comfort, TP1200-Comfort, TP1500-Comfort, TP1900-Comfort, TP2200-Comfort) running WinCC Comfort V14 SP1 image firmware, a faceplate VBScript that combines two boolean SmartTag evaluations with the VBScript And operator fails to set its output tag to 1, even when both operand expressions individually return True. The script executes (verified by an unconditional SmartTags("OUTPUT") = 1 being immediately overwritten to 0 on the next cycle), but the compound boolean condition never resolves to True.

Typical scenario: a drive faceplate on a VSD (Variable Speed Drive) controller uses a Hand-Off-Auto (HOA) selector and a popup visibility flag to gate visibility of "Manual Items" controls. The intended logic is:

If SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.HOA_102") = 1 And _
   SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.POPUP_CTRL") = 1 Then
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 1
Else
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 0
End If

Symptom: with both HOA_102 = 1 and POPUP_CTRL = 1, the tag MANUAL_ITEMS_VISIBILITY remains at 0 and the manual-mode objects stay hidden.

Affected Environment

Root Cause

WinCC Comfort VBS is a constrained VBScript runtime. The runtime wraps every SmartTags(...) reference in a late-bound property accessor that performs a tag-table lookup, type coercion, and PLC area read on each invocation. When the parser compiles a boolean expression such as:

A = 1 And B = 1

VBScript uses bitwise And rather than short-circuit logical And. Operator precedence then forces the parser to first evaluate the boolean comparison expressions on each side, producing two integers (0 or -1 for True, since VBScript coerces True to -1 when used in a numeric context) and finally apply the bitwise And. On a fully-conformant VBScript host this still yields the correct boolean result.

On WinCC Comfort V14 SP1, however, the runtime's tag-access wrapper exhibits two related defects that combine to break the compound expression:

1. Type coercion asymmetry: The wrapper returns the boolean comparison as the raw PLC value (0 / 1) instead of the VBScript-native False / True (0 / -1). The parser therefore sees 1 And 1 = 1, which is numerically correct, but the subsequent If test interprets the result inconsistently across panel firmware revisions.
2. PLC read cache invalidation between operands: When two SmartTags("Properties\...") references are placed on the same expression line, the runtime's tag cache may invalidate between the two reads, causing the second operand to be evaluated against a stale or uninitialized value. The symptom is most pronounced on high-latency connections (S7 routes with multiple hops, PROFINET IRT with broadcast limits, or routed PROFIBUS DP).

The combination means that even when both operands are logically true, the runtime can short-circuit the expression, return 0, and execute the Else branch.

Workaround: Nested If Statements

Replacing the compound condition with nested If blocks forces each SmartTags(...) evaluation to complete fully before the next test begins. The runtime no longer tries to coalesce the two reads into a single compound expression, which sidesteps both the coercion asymmetry and the cache-invalidation defect.

If SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.HOA_102") = 1 Then
    If SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.POPUP_CTRL") = 1 Then
        SmartTags("MANUAL_ITEMS_VISIBILITY") = 1
    Else
        SmartTags("MANUAL_ITEMS_VISIBILITY") = 0
    End If
Else
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 0
End If

This pattern is the canonical workaround and is used throughout the WinCC Comfort example projects shipped with TIA Portal V14 SP1 for any condition involving two or more PLC boolean tags.

Workaround: Intermediate Boolean Variables

An alternative is to stage the comparisons into local VBScript boolean variables. Local variables force a full VBScript Boolean type at assignment time, eliminating the integer-vs-Boolean ambiguity at the comparison:

Dim bHOA, bPopup, bResult
bHOA   = (SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.HOA_102") = 1)
bPopup = (SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.POPUP_CTRL") = 1)
bResult = bHOA And bPopup

If bResult Then
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 1
Else
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 0
End If

Note the parentheses around the equality test: they cast the result of = 1 into a strict boolean before assignment, which prevents the runtime from carrying the raw PLC integer through the And expression.

Workaround: Use CBool and Not Explicit Conversion

Where intermediate variables are not appropriate (for example, inside a one-line property animation expression), wrap each operand in CBool(...) to force an explicit boolean type before And is applied:

If CBool(SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.HOA_102")) And _
   CBool(SmartTags("Properties\B_DRIVE_INTERFACE.DRIVE_HMI.POPUP_CTRL")) Then
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 1
Else
    SmartTags("MANUAL_ITEMS_VISIBILITY") = 0
End If

Workaround: Move the Logic to a Single Boolean Tag in the PLC

For high-reliability applications, compute the combined visibility in the PLC and expose a single boolean HMI tag. The faceplate then reads one tag and the If statement reduces to a single comparison with no compound boolean to fail:

' SCL example, computed once per cycle in OB1 or a cyclic interrupt OB
#MANUAL_ITEMS_VISIBILITY := (#HOA = 1) AND (#POPUP_CTRL = 1) AND NOT #FAULT_ACTIVE;

This also reduces HMI-to-PLC tag traffic and improves deterministic runtime performance on the panel.

Why the Trigger Does Not Matter

The script may be triggered by any of the supported WinCC Comfort events:

• Tag value change on HOA_102
• Tag value change on POPUP_CTRL
• Button press (mouse click / variable write)
• Scheduled task (cyclic, every 1 s, every 100 ms)

The defect is in the expression evaluation, not in the trigger mechanism. Switching triggers will not resolve the issue; only restructuring the boolean expression will.

Diagnostic Procedure

1. Open the faceplate in the WinCC Comfort engineering view in TIA Portal V14 SP1.
2. Add an output field bound to a temporary internal HMI tag (e.g., _DBG_HOA) and one bound to _DBG_POPUP. Display the raw values returned by each SmartTags(...) read.
3. Add an output field bound to the result of the And expression only: SmartTags("Properties\...HOA_102") And SmartTags("Properties\...POPUP_CTRL").
4. Set both operands to 1 in PLCSIM or on the live PLC.
5. Observe: if the two operand fields show 1 but the And field shows 0, the compound expression defect is confirmed.
6. Apply the nested-If workaround and re-verify.

Verification Steps

1. Compile and download the project to the Comfort Panel.
2. On the panel, navigate to the VSD faceplate and force the popup visible.
3. Switch the HOA selector to Manual (HOA_102 = 1).
4. Confirm that the manual-mode controls (Start, Stop, Reference speed, Jog) become visible.
5. Set POPUP_CTRL = 0 and confirm that the manual-mode controls hide.
6. Set HOA_102 = 0 (Auto) and confirm that the manual-mode controls hide regardless of POPUP_CTRL.
7. Cycle each input through 0/1 ten times to confirm deterministic behavior on every transition.

Performance and Memory Considerations

The nested-If and intermediate-variable patterns each carry a small overhead compared to a single compound And:

For faceplates with multiple visibility layers and several boolean inputs, prefer the PLC-computed tag pattern: one tag read, one comparison, deterministic behavior regardless of runtime revision.

Related Faceplate Scripting Patterns

Three additional patterns are worth standardizing across a WinCC Comfort V14 SP1 project:

Use Faceplate Interface Tags, Not Direct PLC Tag References

Expose HOA_102, POPUP_CTRL, and MANUAL_ITEMS_VISIBILITY as faceplate interface properties rather than referencing Properties\B_DRIVE_INTERFACE... directly inside the script. This decouples the faceplate from any one DB or UDT layout and makes the faceplate reusable.

Centralize Compound Conditions in One Function

If the same compound condition is reused across multiple faceplates (e.g., a global "Manual mode and Popup open" condition), wrap the logic in a VBS function stored in the project-wide scripts area, and call the function from each faceplate. This ensures the workaround is applied consistently.

Audit Tag Triggers

Whenever a VBS is triggered by tag-value-change events, audit the list of triggering tags. WinCC Comfort V14 SP1 limits the trigger list to eight tags per scheduled VBS; missing a tag means the script will not refire when that tag changes. Add an explicit comment at the top of each VBS listing all triggering tags.

Migration to TIA Portal V15 and Later

The compound-And defect is largely corrected in WinCC Comfort V15 and later. If the project is being upgraded to V15, V15.1, V16, V17, or V18, the original compound expression will work correctly in most cases. However, retain the nested-If pattern for any code that may be back-ported to a V14 SP1 panel, and use the pattern uniformly across the project for consistency.

Standards and Documentation References

• Siemens: WinCC Comfort V14 SP1 system manual
• Siemens: WinCC V14 SP1 scripting (VBS) programming and reference manual
• Siemens: WinCC V14 SP1 faceplates and library elements
• Microsoft: VBScript operators reference

Troubleshooting Matrix