Testing WinCC Flexible VBScripts Offline Without a TP270 Panel

Overview

Siemens SIMATIC WinCC flexible is the legacy HMI engineering suite for the TP170, TP270, OP170, OP270, MP270, MP370, and Mobile Panel 170/270 families. The engineering station typically runs Windows XP Professional SP3 (or Windows 7 SP1 32-bit in later cycles), while the target panel hardware executes the compiled runtime on Windows CE 5.0 or Windows Embedded Compact 7. This split creates a recurring field problem: how do you validate VBScript logic when the physical TP270 10" panel is on another site, on a different machine, or simply not on the bench?

This reference documents three field-proven paths that practicing engineers use to test VBScripts offline, the prerequisites for each, the limitations that surface, and the verification steps required to sign off a script before it ships to the panel. The three methods are:

1. WinCC flexible built-in simulator — Start → Start Runtime from the engineering software.
2. WinCC flexible PC Runtime — installed on the engineering PC as a separate component.
3. Microsoft Virtual PC 2007 SP1 — plus a Windows CE 5.0 evaluation image.

The choice depends on what the script does. Pure logic (tags, math, screen calls) is fine in the simulator. File I/O, ActiveX, and OPC need the PC Runtime. CE-only COM, registry look-ups, and panel-image extensions need the Virtual PC path. A final hardware FAT on the physical TP270 is always required for sign-off; no offline path covers touch calibration, the panel buzzer, or live fieldbus I/O.

Prerequisites

How VBScripts Are Compiled for WinCC flexible

VBScript in WinCC flexible is stored in the project tree under two locations:

• Scripts → Project Scripts — global functions and subroutines callable from any screen.
• Per-screen Events — handlers attached to object properties (e.g., OnClick of a button, OnValueChanged of an IO field, OnScreenOpen of a screen).

The compiler emits Microsoft VBScript 5.x bytecode targeting one of two runtime hosts:

• Win32 target — WinCC flexible PC Runtime on Windows XP / Windows Embedded Standard.
• WinCE target — Compact Framework runtime for TP/MP panels.

The two targets diverge in three areas that frequently break naive cross-platform scripts:

1. Object model coverage: WinCE lacks WScript.Shell, full Scripting.FileSystemObject semantics, and most third-party COM objects. The CE build ships a stripped VBScript host with only the core object set.
2. Path conventions: TP panels use device paths like \Storage Card\... and \Flash\..., while the PC Runtime uses conventional Windows paths under C:\Program Files\Siemens\Automation\WinCC flexible 2008\....
3. Available libraries: Date, math, and string functions are intact, but FormatCurrency, regional settings handling, and CreateObject calls against unregistered COMs behave differently. The CE VBScript host coerces empty variants to empty strings more aggressively than the Win32 host.

Method 1 — Built-in Simulator (Primary Path)

The WinCC flexible engineering software includes a simulator that loads the compiled project into a hosted environment on the engineering PC. The simulator executes the project's VBScript using the host's VBScript engine — VBScript.dll version 5.8 on Windows XP SP3, or 5.812 on Windows 7 — so path and COM semantics match the Win32 target. It is the right tool for logic validation when the script uses only tags, math, and screen functions.

Procedure

1. Open the project in WinCC flexible ES.
2. From the Project menu, run Compiler → Start Compiler. Resolve every error and every warning. The build must complete with status "Compile completed without errors" before the simulator will launch.
3. From the same menu choose Start → Start Runtime (or press F5). The WinCC flexible RT window appears.
4. Operate the screen as a user would on the panel. Mouse clicks emulate touches. The on-screen keyboard appears automatically when an IO field receives focus.
5. Open View → Output Window to read HMIRuntime.Trace messages.

Trace Helper

Add this debug function to the project's global script:

Sub Dbg(s)
    HMIRuntime.Trace "DBG: " & s
End Sub

Call it from any event:

Dbg "Tag value = " & SmartTags("Level")
Dbg "Error: " & Err.Number & " " & Err.Description

What the Simulator Does and Does Not Cover

Method 2 — WinCC flexible PC Runtime on Windows XP

For higher-fidelity behavior — Sm@rtAccess, OPC, full file I/O semantics, and ActiveX controls — install the WinCC flexible Runtime (PC RT) on the engineering PC. This is the same runtime that ships on the panel hardware, recompiled for x86, and is the closest you can get to panel behavior without the actual panel.

Procedure

1. Insert the WinCC flexible 2008 SP4 DVD and run Setup.exe.
2. Select WinCC flexible Runtime 2008 as an additional installation. Do not deselect the engineering software; the PC RT can co-reside with it.
3. Restart the PC. The Automation License Manager opens automatically.
4. Activate the PC Runtime license. Without one, the RT runs in demo mode for 30 days with a watermark on the start screen.
5. Open the project, recompile (Project → Compiler → Start Compiler), then transfer to the local PC Runtime: Start → Programs → SIMATIC → WinCC flexible → Transfer → Transfer Mode, then select Project → Transfer → PC Runtime. Use transfer mode Ethernet (TCP/IP) with target address 127.0.0.1.
6. Start the PC Runtime from the Start menu. It runs the same compiled project the panel would.
7. Inspect runtime errors via Start → Programs → SIMATIC → WinCC flexible → Diagnostics. The diagnostic dump captures tag values, last event, and the script's VBScript host version.

Licensing Notes

• A single PC Runtime license is required per engineering PC, regardless of project count.
• A panel license (e.g., for the TP270 10") does not enable the PC Runtime; they are separate SKU lines.
• Multiple Runtime instances on the same PC are not supported; one PC = one Runtime.
• License transfer between PCs requires the Automation License Manager and a license USB stick or softcontainer.

Method 3 — Virtual PC 2007 SP1 + Windows CE Image

When the script depends on CE-only APIs (registry look-ups under [HKEY_LOCAL_MACHINE\...], file paths under \Program Files\Siemens\..., or Siemens panel-side COM extensions), use Microsoft Virtual PC 2007 SP1 with a Windows CE 5.0 evaluation VHD. This is the closest you can get to panel-side execution without panel hardware.

Procedure

1. Download and install Microsoft Virtual PC 2007 SP1 on the engineering PC. Virtual PC 2007 is a 32-bit hypervisor and only runs on Windows XP or 32-bit Windows 7.
2. Download the Windows Embedded CE 5.0 Evaluation Edition VHD from the Microsoft download center. Verify the SHA-1 of the VHD against the published manifest before booting.
3. Launch Virtual PC. Create a new virtual machine, allocate 256 MB of RAM, and attach the CE VHD to IDE 0.
4. Boot the VPC. Configure the virtual network as Bridged so the VPC receives a real DHCP address on the engineering LAN. (NAT works too, but Bridged is the most predictable for the WinCC flexible transfer protocol.)
5. In WinCC flexible ES, set the project target to TP270 10", set the transfer channel to Ethernet, and set the target address to the VPC's bridged IP.
6. Compile and transfer the project to the VPC. The WinCC flexible Runtime on the VPC executes the project's VBScript inside the CE VBScript host.
7. Test scripts against the CE-hosted runtime. The same VBScript engine that runs on the TP270 10" will execute inside the VPC — file paths, COM object availability, and host VBScript version all match.

Caveats

• Virtual PC 2007 is a 32-bit hypervisor and is not supported on Windows 10/11. Use an older engineering PC for this path.
• The CE evaluation VHD is a generic image. Siemens-specific panel extensions (e.g., the SiemensHMI.AudioControl ActiveX, the HMI Tags COM) are not present. Scripts that call into these will throw "ActiveX component can't create object".
• The VPC approach is excellent for logic validation but limited for graphic fidelity. The Siemens panel image is custom, and the CE evaluation image is a reference build, so screen rendering, fonts, and control visuals will differ.
• For panel-side ActiveX testing, the only fully faithful path is on the physical panel. Plan for a hardware FAT window.

Testing Topology and Decision Flow

The diagram below summarizes the relationship between the engineering PC, the three test paths, and the target TP270 10".

Decision Matrix

VBScript Debugging Best Practices

• Trace instead of MsgBox: HMIRuntime.Trace writes to the engineering output window without blocking the script. MsgBox halts execution and is invisible on a WinCE panel that runs headless.
• Always wrap external COM calls:

  On Error Resume Next
  Set fso = CreateObject("Scripting.FileSystemObject")
  If Err.Number <> 0 Then
      Dbg "FSO unavailable: " & Err.Description
      Err.Clear
  End If
  On Error Goto 0
  

• Tag-driven path constants avoid hard-coded strings:

  Dim basePath : basePath = SmartTags("PathBase")
  Dim logFile  : logFile = basePath & "\Logs\shift_" & Format(Now, "yyyymmdd") & ".csv"
  

• Date math: use DateAdd("s", offset, Now) rather than direct Now + offset to avoid integer-conversion surprises on WinCE's VBScript host. The CE VBScript host coerces date addition to a Double differently than the Win32 host.
• Avoid DoEvents on WinCE: it can starve the polling loop and produce missed tag updates. Use the scheduler tag system (cyclically updating time tags) instead.
• Minimize global variable use: a global Dim in WinCC flexible creates a single shared instance across the runtime. For thread-like behavior, use a state tag and route logic through it.
• Keep Sub / Function parameter types explicit: VBScript is variant-only, but document expected types in comments. This avoids type-mismatch errors at the call site rather than deep inside the routine.
• Profile in the simulator before transfer: a script that runs in < 50 ms on the engineering PC may run in 400 ms on the CE host due to JIT differences. Use Timer in WinCC flexible to log script duration and trim hot paths.

Common Script Errors and Workarounds

Recipe and Audit Trail Handling

Recipes and audit trails are the two most common script-driven features on the TP270 10" in regulated environments. Each has its own offline testing pitfalls.

Recipes

WinCC flexible supports single-record and array-record recipes backed by CSV files on the storage card. A typical script-driven recipe save looks like:

Sub SaveRecipe(name)
    On Error Resume Next
    Dim path : path = SmartTags("RecipePath") & "\" & name & ".csv"
    Dim fso  : Set fso = CreateObject("Scripting.FileSystemObject")
    If Err.Number <> 0 Then
        Dbg "FSO failed: " & Err.Description
        Exit Sub
    End If
    Dim ts : Set ts = fso.CreateTextFile(path, True)
    ts.WriteLine "Field,Value"
    ts.WriteLine "Setpoint," & SmartTags("Setpoint")
    ts.WriteLine "Tolerance," & SmartTags("Tolerance")
    ts.WriteLine "Operator," & SmartTags("CurrentUser")
    ts.Close
    Dbg "Recipe saved: " & path
    On Error Goto 0
End Sub

Testing notes:

• In the simulator, SmartTags("RecipePath") must be set to a writable directory on the engineering PC (e.g., C:\Temp\Recipes). The TP270 panel does not have a C:\.
• In the PC Runtime, the same path is honored, but file operations complete at desktop speed; panel-side card writes are 5–10x slower.
• In the Virtual PC + CE VHD path, the CE file system is case-sensitive in paths but case-insensitive in lookups. The script works unchanged, but watch for case mismatches when cross-debugging log files.
• Always test the disk full case: fill the storage card, attempt a save, and confirm the error handler logs and recovers rather than hanging the RT.

Audit Trail

Audit trails on the TP270 are configured in the project properties and written automatically by the runtime for operator actions, recipe changes, and value entries. Scripts that read or post-process the audit trail must run on the same path:

Sub ExportAuditTrail()
    Dim srcPath : srcPath = SmartTags("AuditPath") & "\auditlog.csv"
    Dim dstPath : dstPath = SmartTags("BackupPath") & "\audit_" & Format(Now, "yyyymmdd_hhnnss") & ".csv"
    Dim fso : Set fso = CreateObject("Scripting.FileSystemObject")
    fso.CopyFile srcPath, dstPath, True
    Dbg "Audit exported: " & dstPath
End Sub

Audit trail validation must always run on the physical panel in the qualified environment. The simulator and the PC Runtime differ in how they hash and time-stamp entries, and only the panel produces the regulatory-compliant audit log.

Performance and Memory Considerations

The TP270 10" ships with 32 MB of working memory, of which roughly 16 MB is available to the runtime after the Windows CE kernel and panel image load. Heavy VBScript usage can exhaust this. Practical limits observed in the field:

For performance, the relevant rules are:

• Tag update storm: on power-up the panel requests every configured tag from the PLC. With thousands of tags on a 187.5 kbps MPI link, the storm can take 30–60 s. Stagger tag acquisition groups by 100–250 ms to flatten the curve.
• Script cycle: a script that completes in < 50 ms on the engineering PC can take 200–400 ms on the CE host. Profile with Timer:

  Sub HeavyWork()
      Dim t0 : t0 = Timer
      ' ... work ...
      Dbg "HeavyWork took " & FormatNumber(Timer - t0, 3) & " s"
  End Sub
  

• String allocation: VBScript on WinCE is conservative with string interning. Avoid building large strings in a loop; use Replace in place or write to a file in chunks.
• Array reuse: ReDim with Preserve is slow on WinCE. Pre-size arrays based on the worst case observed in the field.

Verification Procedure

After each script revision, complete this checklist before the next commit:

1. Compile clean: Project → Compiler → Start Compiler reports zero errors and zero warnings. Fix every warning; they frequently become runtime errors on WinCE.
2. Simulator smoke test: Start Runtime, click every interactive element on every screen that uses the script. Confirm expected tag writes in the output window.
3. Tag boundary test: for each numeric tag used in arithmetic, set it to its min, max, and a typical value; confirm the script handles all three without overflow. Watch for DateAdd overflow, division by zero, and integer wrap.
4. Error path test: force at least one error condition (bad file path, missing tag, out-of-range index) and confirm the script's error handler logs and recovers without hanging the RT.
5. PC Runtime cross-check (when applicable): transfer the project to the PC Runtime and rerun the smoke test. PC RT surfaces file I/O and ActiveX errors that the simulator masks.
6. Virtual PC cross-check (when applicable): transfer the project to the VPC-hosted CE runtime and rerun any script that touches CE-only APIs.
7. Performance test: on the engineering PC, run the script 1 000 times in a loop and confirm the average duration is within budget. Use Dbg to log every 100th iteration.
8. Hardware FAT: when the panel is available, transfer via Ethernet, reboot the panel, and confirm the start screen loads. Run the full script suite on the physical TP270.

TP270 10" Field Commissioning

Edge Cases and Field Caveats

• TP270 10" with 32 MB memory: large VBScripts (> 2 000 lines) and big recipe databases can exhaust the heap. Move heavy logic to the S7 CPU and keep the HMI scripts as thin wrappers.
• Cold-start tag update storm: on power-up, the panel requests every configured tag from the PLC. With thousands of tags, this can flood a 187.5 kbps MPI link. Stagger tag acquisition groups by 100–250 ms.
• Time-zone drift: the TP270 does not include a battery-backed RTC in all variants. On panel reboot, the clock resets to 2000-01-01. Always read the time from the PLC.
• Storage card removal mid-write: a pulled CF card during a recipe save can corrupt the FAT. Add a WriteFile wrapper that copies to a .tmp extension and renames atomically.
• Heat near the panel: TP270 10" has a 0–50 °C operating range. In cabinets above 40 °C, the backlight inverter may flicker, which is mistaken for script issues. Check the cabinet temperature first.
• Long tag names from migrated projects: importing a project from WinCC flexible 2004 into 2008 may surface tag names longer than 32 characters. The compiler truncates silently on the panel. Rename tags to ≤ 24 characters before commissioning.
• Network address collision: when multiple panels share a subnet, IP conflicts only surface at transfer time. Use DHCP with reservations, not static IPs, for service simplicity.

Migration to TIA Portal (For Reference)

When the TP270 must be replaced, TIA Portal's WinCC is the successor. The migration path from WinCC flexible 2008 to TIA Portal V17 / V18 is mechanical for most projects:

1. Open the WinCC flexible project in TIA Portal via Project → Migrate project. TIA Portal handles the device swap, tag mapping, and screen conversion.
2. Review the migration report. Common adjustments: HMIRuntime → HmiRuntime, SmartTags("X") → HmiRuntime.Tags("X").Read / .Write, file system paths adjusted to the new OS.
3. Retest the scripts using TIA's built-in simulator (which uses the same Win32 VBScript engine pattern).
4. Re-FAT on the new Comfort Panel hardware (e.g., TP900 Comfort, 6AV2 124-1MC01-0AX0).

The TP270 10" maps cleanly to the TP900 Comfort 9" for most recipes, screen counts, and tag counts. For larger applications, the TP1200 Comfort 12" is the recommended replacement.

FAQ