Fixing TIA V15 WinCC Comfort Scripts That Fail Without Debugger

1. Problem Summary

A VBScript written in TIA Portal V15 Update 3 reads data from a SIMATIC S7-1500 CPU 1511-1 PN and writes it to a Microsoft SQL Server database using ADODB.Connection and ADODB.Recordset. The project is targeted at a TP1500 Comfort panel running WinCC Comfort, with the PLC simulated through PLCSIM Advanced. When the script is executed under the Visual Studio 2017 debugger attached to the TIA engineering environment, every For loop completes, every row is committed, and the SQL log is populated exactly as designed. The same script, compiled and downloaded to the TP1500 Comfort panel, fails silently: the tag table stops updating, no SQL inserts are observed, and no native script error is raised on the panel.

The failure is not caused by the script logic, the UDT structure, the multiplex tag mapping, or the connection string. It is caused by the absence of the ADODB COM layer on the Windows Embedded Compact 7 (WinEC 7) operating system that ships with the Comfort and Multi Panel product line. The Visual Studio debugger runs the script on the engineering workstation's full Win32/Win64 stack, which is why the same code that fails on the panel appears to work in the lab.

2. Affected Components and Versions

The TP1500 Comfort uses Windows Embedded Compact 7, not Windows IoT, not Windows 10 IoT Enterprise, and not Win32. The Comfort, Multi Panel, and Mobile Panel product families up to and including the current Comfort V4 generation share the same WinEC 7 / WinEC 2013 core when WinCC Comfort V15 or V16 is used. The SIMATIC HMI WinCC Comfort / WinCC Advanced V15.0 SP3 system manual explicitly documents the supported operating system and the list of COM objects available to the VBScript runtime, and ADODB is not on the list.

3. Root Cause: ADODB Is Not Present on WinEC 7

VBScript on a WinCC Comfort runtime is implemented as a reduced Win32 scripting host. The host exposes WScript.Shell, FileSystemObject, Scripting.Dictionary, and a small set of HMIRuntime objects, but it does not load the msado15.dll that implements ADODB.Connection, ADODB.Recordset, or ADODB.Command. The same applies to ADODB.Stream and the OLE DB enumerator objects.

When the script is run on the engineering PC, either through the TIA integrated debugger or the Visual Studio script debugger, the Windows desktop user space resolves CreateObject("ADODB.Connection") against the system-wide msado15.dll registered in HKEY_CLASSES_ROOT\CLSID. The connection opens, the Execute call returns, and the loop completes. On the panel, CreateObject returns Nothing, and the very first .ConnectionString = assignment throws a Microsoft VBScript runtime error: Object required: 'objConn', which the panel's HMI runtime logs to the diagnostic file \flash\LogFiles\HmiRTm.txt but does not surface to the operator.

The same is true for any technology that ultimately depends on OLE DB providers, ODBC drivers, or .NET Framework assemblies that are not embedded in the panel image: System.Data.SqlClient, MySql.Data.MySqlClient, OdbcConnection, and similar wrappers are not available on WinEC 7.

4. Why Debugging Hides the Failure

TIA Portal attaches a process-level debugger to the script host that is part of the engineering environment, not the panel. The script that runs during a debug session executes inside the engineering PC's script process; the COM object resolver is the desktop resolver, and the network stack is the engineering PC's network stack. The panel is only a passive target that supplies tag values over the simulated or real S7 channel. The "debugger works, runtime does not" symptom is therefore a sign that the script depends on a component that is not deployed to the panel image, not a sign of a timing or a threading defect in the loop body.

A second common confusion is the difference between the WinCC Comfort script debugger and a Windows native debugger. The TIA integrated script debugger is implemented through Visual Studio 2017 using the VSDebugEngine interface and never leaves the engineering host. The TIA "simulate HMI runtime" feature (RT simulation) is also a Win32 process and shares the same host-side COM registry. Both can give a false positive on a script that targets a WinEC 7 panel.

5. Verifying the Diagnosis

1. Download the project to the TP1500 Comfort and let it run for two full scan cycles.
2. Open a service page (Control Panel > Service > Service Desktop) or transfer \flash\LogFiles\HmiRTm.txt from the panel to the engineering PC using ProSave.
3. Search the file for VBScript and Error. The expected entry is VBScript: Object required: 'objConn' followed by the line number of the first .ConnectionString assignment.
4. From the panel command shell (Control Panel > OP > Execute), run regquery ADODB.Connection. The expected response is Object not registered, which confirms the missing COM class.
5. On the engineering PC, run the identical regquery. The expected response lists the ADODB.Connection CLSID under HKEY_CLASSES_ROOT\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}, confirming the asymmetry.

If step 3 reports the object error and step 4 confirms the missing registration, the diagnosis is closed: the script cannot be salvaged on the Comfort image and must be moved off-panel or rewritten against an in-panel data sink.

6. Solution Paths

Four practical options exist. They differ in hardware reuse, licensing, and latency. The choice is driven by whether the TP1500 Comfort can be replaced, whether the SQL Server is on the plant network, and the required write rate.

6.1 Option A: Migrate the Runtime to WinCC Runtime Advanced (PC-Based)

WinCC Runtime Advanced runs on Windows 10 IoT Enterprise 2019 LTSC and exposes the full Win32 scripting host. ADODB.Connection resolves correctly, the SQLOLEDB.1 provider is loadable, and the same script runs unchanged. This is the lowest-risk migration for an existing project that already targets a Comfort panel.

1. In the TIA Portal project, change the panel device from TP1500 Comfort (6AV2 124-1MA01-0AX0) to a WinCC Runtime Advanced target (for example a SIMATIC IPC227G, 6AG4 022-2AA20-0AX0, with Windows 10 IoT).
2. Transfer the existing HMI tags, screens, alarms, and scripts unchanged. TIA migrates the project tree and warns only on Comfort-specific features (such as the SMI library and the comfort-specific faceplate library).
3. On the IPC, install SQL Server Native Client 11.0 (or the OLE DB driver 18 if you use MSOLEDBSQL.1) from the Microsoft OLE DB Driver for SQL Server download page.
4. Enable the SQL Browser service and TCP/IP listener on the SQL Server host and open TCP 1433 between the IPC and the database.
5. Re-download the project, start the runtime, and verify the first SQL insert through SQL Server Management Studio.

6.2 Option B: Stay on the TP1500, Buffer in the PLC, Sink from a Middleware

If the TP1500 must remain in service, the only practical architecture is to remove all database I/O from the panel. The panel reads and writes HMI tags; the S7-1500 stores the data in a PLC DB; a separate Windows service or a SIMATIC WinCC Unified / WinCC Professional client on the network sinks the DB to SQL Server.

This pattern keeps the existing Comfort panels in the field, requires no panel firmware change, and is the only way to reach deterministic write rates above 5 Hz from a PLC-resident buffer.

6.3 Option C: OPC UA Middleware on a Network Node

A SIMATIC S7-1500 CPU 1511-1 PN with firmware V2.6 or later exposes an OPC UA server directly. A small .NET 8 console service running on a Windows host subscribes to the tags, calls SqlBulkCopy to a staging table, and lets SQL Server merge the batch into the destination. This is a lighter option than B and works with the existing PLC program; it requires only that the panel be reconfigured to point at the OPC UA endpoint rather than the SQL sink.

6.4 Option D: Built-In WinCC Tag Logging with RDB Archive

WinCC Comfort does not include the SQL-based RDB Archive Segment of WinCC Professional. The Comfort logging options are CSV, RDB (txt) and an internal proprietary format that is not directly importable to SQL Server. If the project can be migrated to WinCC Unified V16 or later, the SIMATIC WinCC Unified V18 system manual documents the WinCC Unified - SQL Server connector, which writes the runtime database directly through System.Data.SqlClient without any VBScript on the panel side.

7. Rewriting the Script for WinCC Runtime Advanced

If Option A is chosen, the script needs only two changes: a typed connection string and a single explicit error handler. The base structure that the original post showed can be kept; the multiplexing pattern using a UDT element and a case structure is still the recommended way to walk a dynamic array on a WinCC runtime because the script host does not support variant arrays of HMI tags.

' VBScript - WinCC Runtime Advanced V15
' Runs on Windows 10 IoT, full ADODB available
Const adOpenStatic      = 3
Const adLockOptimistic  = 3
Const adCmdText         = 1

Dim objConn, objRS, i, strSQL
On Error Resume Next

Set objConn = CreateObject("ADODB.Connection")
If Err.Number <> 0 Then
    HMIRuntime.Trace "ADODB create failed: " & Err.Description & vbCrLf
    Exit Sub
End If
On Error Goto 0

objConn.ConnectionString = _
    "Provider=SQLOLEDB.1;" & _
    "Data Source=PLANTSVR\SQLEXPRESS;" & _
    "Initial Catalog=Production;" & _
    "User ID=hmiscada;" & _
    "Password=Pa55w0rd!;" & _
    "Connect Timeout=5;"
objConn.Open

For i = 0 To SmartTags("ArrayLog.PartFinished")
    Select Case i
        Case 0
            HMIRuntime.Trace "Tag[" & i & "] = " & SmartTags("ArrayLog.Val0") & vbCrLf
        Case 1
            HMIRuntime.Trace "Tag[" & i & "] = " & SmartTags("ArrayLog.Val1") & vbCrLf
        Case 2
            HMIRuntime.Trace "Tag[" & i & "] = " & SmartTags("ArrayLog.Val2") & vbCrLf
        ' ...continue to N
    End Select
    strSQL = "INSERT INTO dbo.PartLog (Idx, Value, T) VALUES (" & i & ", '" & SmartTags("ArrayLog.Val" & i) & "', GETDATE())"
    objConn.Execute strSQL, , adCmdText
Next

objConn.Close
Set objConn = Nothing

The case structure is the correct workaround for the "smarttag + int index" error message; the WinCC runtime evaluates a dynamic index against a UDT element only through an explicit branch. The pattern generalizes by replacing the Case N branches with a generated table at compile time or with a tag prefix and the SmartTags("prefix." & i) lookup when the runtime is configured to expose the array as a flat tag prefix.

8. Rewriting the Sink for the PLC-Buffer Pattern

If the panel stays in place and the database is moved to a Windows host, the panel is reduced to writing to PLC tags, and a small VB .NET / C# worker replaces the panel script. The recommended DB layout is a staging table with three columns and a MERGE into the production table.

-- SQL Server staging table
CREATE TABLE dbo.PartLogStage (
    Idx        INT            NOT NULL,
    PartTag    NVARCHAR(64)   NOT NULL,
    Value      NVARCHAR(128)  NULL,
    T          DATETIME2(3)   NOT NULL,
    CONSTRAINT PK_PartLogStage PRIMARY KEY CLUSTERED (T, Idx)
);

CREATE TABLE dbo.PartLog (
    Idx        INT            NOT NULL,
    PartTag    NVARCHAR(64)   NOT NULL,
    Value      NVARCHAR(128)  NULL,
    T          DATETIME2(3)   NOT NULL,
    CONSTRAINT PK_PartLog PRIMARY KEY CLUSTERED (T, Idx)
);

-- Merge every minute
MERGE dbo.PartLog AS T
USING dbo.PartLogStage AS S
ON  T.T  = S.T
AND T.Idx = S.Idx
WHEN NOT MATCHED THEN
    INSERT (Idx, PartTag, Value, T)
    VALUES (S.Idx, S.PartTag, S.Value, S.T);

TRUNCATE TABLE dbo.PartLogStage;

9. Connection String Reference

10. Performance and Timing Notes

On a TP1500 Comfort, the VBScript scheduler runs scheduled scripts at a configurable interval (default 1 s). Each For iteration with one SQL insert over a 10 ms LAN typically takes 4-6 ms. A 200-record batch therefore completes well within one second. A 1 000-record batch approaches the 1 s budget and begins to starve the alarm subsystem. On a Comfort panel, the recommended batch is therefore between 50 and 250 records per cycle, and the cycle period between 2 s and 10 s, regardless of which solution is chosen.

On a WinCC Runtime Advanced IPC, the bottleneck shifts from the panel scheduler to the SQL Server. A SqlBulkCopy at 1 000 rows per batch achieves approximately 15 000 rows per second on a local network and is the preferred sink.

11. Common Errors and Codes

12. Multiplexed HMI Tag Notes

The original post's multiplexing pattern with a UDT element and a case structure is the documented workaround for the limitation that SmartTags("ArrayLog.Val" & i) cannot be evaluated against a UDT array index. To make this pattern work reliably, configure the multiplex in the HMI tag properties as follows:

1. Open the HMI tag editor and create one HMI tag per UDT element (for example ArrayLog_Val_0 through ArrayLog_Val_31).
2. Set the Multiplexing property of each tag to the same index variable (for example ArrayLog.Index).
3. Use the case structure inside the script to dereference the index back to a specific element for logging, or to read the multiplexed value into a local copy with SmartTags("ArrayLog_Val_0").
4. Avoid writing the StoredInSQL flag back to the UDT from inside the same read cycle. The WinCC runtime buffers the read direction independently of the write direction, and a write inside the same cycle produces a one-cycle delay between two adjacent reads. Use a separate scheduled script to clear the flag.

13. Verification Procedure

1. On the engineering PC, open SQL Server Management Studio, run SELECT COUNT(*) FROM dbo.PartLog, and record the baseline.
2. Download the project to the runtime (panel, IPC, or Unified client) and start it.
3. Generate 50 distinct events at the panel (for example, toggle 50 different setpoints).
4. Run the same SELECT COUNT(*) query. The expected delta is at least 50 within 60 s.
5. Inspect the last 50 rows and verify that T is monotonically non-decreasing and that the Idx column maps back to the panel-set value.
6. Open the runtime log (HmiRTm.txt on Comfort, WinCCRTm.txt on Advanced) and confirm zero VBScript errors during the 60 s window.
7. On the panel, stop the runtime, restart it, and re-run the test. The pattern must reproduce without intervention.

14. Field-Proven Caveats

• Do not install the OLE DB provider on the engineering host and assume the same provider is on the panel. The Comfort image has no installer and no provider.
• Do not attempt to copy msado15.dll to the panel. The dependency chain on ole32.dll, oleaut32.dll, and the registry-resident class IDs cannot be reproduced on WinEC 7.
• If the panel must be on WinCC Comfort and a database sink is required, the only safe architecture is "panel → PLC buffer → middleware → SQL". The original panel-side script is discarded.
• If the project can be upgraded, move directly to WinCC Unified V18 and use the built-in SQL connector. The VBScript-on-panel pattern is effectively end-of-life with WinCC Comfort.
• For each S7-1500 firmware upgrade, re-validate the OPC UA server endpoint and security policy. CPU 1511-1 PN firmware V2.9 disabled SecurityPolicy None by default; the middleware must be reconfigured to Basic256Sha256 and a server certificate must be installed.

15. Summary

The "script works only in debug" symptom on a TP1500 Comfort panel is a deployment-environment symptom, not a script bug. The VBScript debugger runs on the engineering PC's Win32 user space; the panel runs Windows Embedded Compact 7 and does not ship the ADODB COM class. The fix is to move the database sink off the panel: either to a WinCC Runtime Advanced IPC, to a Windows service that reads the PLC buffer, or to WinCC Unified's built-in SQL connector. The script logic, the UDT structure, the multiplexed tag mapping, and the SQL schema can all be reused unchanged once the sink is moved.