WinCC GSC Diagnostics: Viewing C and VBS Script Trace Output

Overview

Siemens WinCC provides GSC (Global Script C) Diagnostics as a built-in runtime tool to capture and display trace output from C and VBS scripts. When configured correctly, the diagnostics view shows the chronological sequence of printf calls from C actions and HMIRuntime.Trace calls from VBS actions, each prefixed with a runtime timestamp. The most common failure mode is that operators see only a tabular list of executing global scripts and not the action trace text, because the Print Job control template is set to GSC Run Time instead of GSC Diagnostics. This article walks through the exact configuration, the C and VBS trace syntax, the alternate toolchain (ApDiag.exe) for offline analysis, and a troubleshooting matrix for the issues that appear most often in field deployments.

Background: GSC Runtime vs GSC Diagnostics

WinCC exposes the script trace stream through the Graphics Designer → Controls toolbar → Print job / Script diagnostic control. The same COM/ActiveX control can be configured with two distinct templates that change the entire rendering pipeline:

When the Template is set to GSC Run Time, the control renders a tabular list of executing global scripts with a fixed column layout. The trace text from the script bodies is not displayed in that table — it is captured by an internal aggregator but routed to a different sink. Switching the Template to GSC Diagnostics replaces the tabular view with a grey background, scrollable text area that prints each printf and HMIRuntime.Trace line as the script emits it, prefixed with a runtime timestamp of the form HH:mm:ss.fff. Per the official TIA Portal V20 documentation, the GSC Diagnostics view outputs the trace instructions of the scripts to the diagnostics view in the chronological order of their call.

Prerequisites

Before enabling GSC Diagnostics, verify the following on the engineering station and the target RT computer:

• WinCC V7.3 SP3 or later (or WinCC V7.4 / V7.5 for current service packs) for classic HMI systems.
• WinCC RT Professional V16 / V17 / V18 / V20 for TIA Portal projects.
• WinCC Explorer is open with the project activated in Runtime on the target computer.
• A graphics screen containing the Print job / Script diagnostic control (inserted from the Controls toolbar in Graphics Designer).
• Read/write access to the project directory for the RT computer user (script compiles to disk and writes debug symbols to <Project>\GraCS\<Screen>.pas for C actions).
• For C actions: the action must compile successfully (no entries in the Compile / Check output window of WinCC Explorer).
• For VBS actions: the HMIRuntime object is available — standard for local VBS actions on RT Professional and on WinCC V7.x RT.

Step-by-Step Configuration

1. Insert the Diagnostics Control

In the Graphics Designer:

1. Open the screen where the trace output should be visible (typically a service or maintenance screen accessible only to administrators).
2. From the Controls palette, drag Print job / Script diagnostic onto the canvas. The control appears with a default template of GSC Run Time.
3. Resize the control to occupy a meaningful area — typical dimensions for a service console are 480 × 280 px; minimum 80 × 60 px is required for the scrollbar to render.

2. Configure the Control Properties

Open the configuration dialog of the inserted control (right-click → Configure). Set the following properties:

Save and close the configuration dialog. If the Template field is greyed out, the control is showing an older COM wrapper — delete and re-insert the control from the Controls toolbar in the active Graphics Designer version. The same Template selector is documented in the TIA Portal V20 GSC diagnostics (RT Professional) help page.

3. Add Trace Statements in C Actions

In a C action (WinCC V7.x global action or TIA RT Professional C script), use the standard C printf function. The output is captured by GSC Diagnostics only if the action is compiled, scheduled, and triggered in runtime.

#include "apdefap.h"

void OnClick(char* lpszPictureName, char* lpszObjectName)
{
    printf("GSC: OnClick fired on %s / %s\r\n", lpszPictureName, lpszObjectName);
    printf("GSC: Tag value = %d\r\n", GetTagWord("Motor1_Speed"));
    printf("GSC: Setpoint reached, dwell = %.2f s\r\n", GetTagFloat("Dwell_Time"));
}

Notes on C printf in GSC:

• Use \r\n as the line terminator. WinCC's text view does not auto-wrap single \n on all Windows regional settings, which leads to concatenated lines.
• Each printf becomes a single line in the diagnostics view. There is no implicit line break between calls.
• printf calls in C global actions do not appear in the GSC Runtime table; they appear only in GSC Diagnostics.
• Buffer size of the formatted string is 1024 bytes. Longer strings are truncated at the receiving end.
• For WinCC V7.x, the C compiler is a custom Microsoft C build. Some GCC-specific format specifiers (e.g., %zu) are not supported — use %lu or %d with explicit casts.

4. Add Trace Statements in VBS Actions

In a VBS action, use HMIRuntime.Trace. The method routes the string to the same diagnostics stream as the C printf calls.

Sub OnClick(ByVal Item)
    Dim nSpeed
    nSpeed = HMIRuntime.Tags("Motor1_Speed").Read
    HMIRuntime.Trace "VBS: OnClick fired, tag = " & nSpeed
    HMIRuntime.Trace "VBS: Operator = " & HMIRuntime.Environment.UserName
End Sub

For RT Professional (TIA Portal V20), the equivalent form is also HMIRuntime.Trace for local actions. Per the official TIA Portal V20 documentation, you enter the trace instruction in the form HMIRuntime.Trace <Output> and the Print job / Script diagnostic object then displays trace outputs from both C and VBS actions.

For VBS-specific syntax notes:

• VBS uses & for string concatenation. + is treated as numeric addition when both operands are numeric — use & to avoid silent type coercion bugs.
• The HMIRuntime.Trace method is synchronous from the caller's perspective; the actual write to the diagnostics buffer happens on the same thread.
• Variant types are accepted: HMIRuntime.Trace 42, HMIRuntime.Trace True, HMIRuntime.Trace Now() all work.
• To write structured log lines, use a leading prefix (INFO:, WARN:, ERR:) so log parsers downstream can categorize.

5. Activate Runtime and Trigger the Scripts

1. Save the screen (Ctrl+S in Graphics Designer).
2. Open WinCC Explorer, right-click the computer name and select Activate.
3. Once the project is in Runtime, navigate to the screen containing the Print job / Script diagnostic control.
4. Trigger the button, tag-change, or timer event that calls the action.
5. The trace lines should appear in the diagnostics control with a leading timestamp.

Verification

Confirm the setup with the following checks:

1. Timestamped lines appear. Each printf / HMIRuntime.Trace shows a runtime timestamp (typically HH:mm:ss or HH:mm:ss.fff format) on the left and the trace text on the right.
2. Order matches execution. Triggers fired later appear lower in the stream; the ring buffer appends to the bottom and discards the oldest entries when the buffer fills.
3. Both C and VBS streams merge. A C action and a VBS action triggered in sequence appear in the same window, distinguished only by the prefix you embed (e.g., "GSC:" vs "VBS:").
4. No silent failures. If only the timestamp appears without text, the action body is executing but the trace call has not fired — verify the action compiled, the trigger event fires, and no early return or Exit Sub skipped the trace.
5. Errors surface. A script with a runtime exception (e.g., a tag that does not exist) shows an error line in the diagnostics view prefixed with the error number and the script GUID.

Alternate Tool: ApDiag.exe

For deeper script diagnosis, Siemens ships the ApDiag.exe utility, located in the WinCC installation directory (typically C:\Program Files (x86)\Siemens\Automation\WinCC\bin on a 32-bit installation or C:\Program Files\Siemens\Automation\WinCC\bin on a 64-bit installation). It logs:

• Script start and end events (with timestamps and GUIDs).
• Compilation errors (with line numbers for C actions).
• Runtime errors (with stack trace on unhandled exceptions).
• The same printf / HMIRuntime.Trace text as GSC Diagnostics, plus metadata that the diagnostics control does not expose.

Launch from a command prompt with write access to the log path:

ApDiag.exe /log:"C:\Temp\ApDiag.log" /start

Trigger the script under test, then stop the log:

ApDiag.exe /stop

The log file contains the same printf text and additional metadata (script GUID, action type, trigger source, thread ID) that GSC Diagnostics does not show. Use ApDiag when:

• The diagnostics control is empty even though scripts run.
• You need the GUID of a specific action for cross-reference in the project file.
• You are chasing an exception that crashes the action thread before the trace call.
• You need to inspect a script that runs on a different RT computer that does not have a screen with the Print job / Script diagnostic control.

For development workflows, ApDiag integrates well with Microsoft's .NET EventSource trace collection and viewing tutorial for engineers who need to correlate WinCC script traces with .NET component events on the same RT host.

Troubleshooting Matrix

Performance Considerations

• The diagnostics view writes to a ring buffer in memory. At 2000 lines × 80 characters the memory footprint is ~160 KB per control — negligible compared to the typical 2–4 GB RT process working set.
• Each printf and HMIRuntime.Trace call marshals a string to the diagnostics aggregator thread. Avoid calling them in tight loops (e.g., inside a 100 ms cyclic action executing thousands of times per hour) — instead, gate behind a debug flag that you enable only on a service screen.
• Disable the diagnostics control in production screens that are not used for service. The aggregator still runs even when the control is hidden, but the rendering cost goes to zero when the screen is closed.
• Do not use printf inside hot paths of C actions that fire on every tag change. Aggregate to a circular log structure in memory and flush every N events instead.

Migrating from WinCC V7.x to TIA WinCC RT Professional

The GSC Diagnostics concept is preserved in WinCC RT Professional. The same HMIRuntime.Trace and printf calls work unchanged. The major differences are:

• The control palette in TIA contains the Print job / Script diagnostic under HMI Controls. The exact position is HMI Controls → Diagnostic Tools.
• The Template property values are GSC Run Time and GSC Diagnostics — identical to V7.x.
• ApDiag.exe is replaced in some RT Professional versions by the TIA trace viewer; the trace outputs land in the project's diagnostic log under <Project>\Logs.
• For panels (Comfort Panels, RT Advanced), HMIRuntime.Trace is supported, but the diagnostics viewer is the panel's own system diagnostic screen rather than the Print job / Script diagnostic control. RT Advanced does not have an on-screen Print job / Script diagnostic control; traces are emitted to the project log file instead.
• The C compiler on RT Professional is a Clang-based build, not the legacy Microsoft C compiler. Some advanced C features (inline assembly, MSVC intrinsics) are not supported. Format specifiers follow Clang conventions.

Notes on Timestamp-Only Entries

If the diagnostics control shows timestamps without any associated script text, the entries are not from WinCC's C or VBS script process. Common sources include:

• Internal WinCC housekeeping messages (picture open/close events on the same screen tree).
• Alarm logging state transitions when the control is configured to mirror the alarm buffer (a common misconfiguration when the same control is reused for alarm logging).
• Print job spool events (if the same control has print job monitoring enabled and a print job is active in the background).

To isolate, temporarily remove all printf and HMIRuntime.Trace calls from your scripts and confirm the timestamps remain. If they do, route only the GSC Diagnostics source into the control by clearing the alarm logging and print job monitoring flags in the control's properties dialog.

Security and Access Control

The GSC Diagnostics control exposes runtime internals that may be sensitive in a production environment. Best practices:

• Place the diagnostics screen under a separate picture that is only loaded for users in the Service user group (configured in User Administration).
• Disable screen-change navigation to the diagnostics screen from the standard operator navigation.
• Do not log HMIRuntime.Trace lines that include operator credentials, password fields, or personal data — the trace buffer is in clear text in process memory.
• On a multi-user RT station, restrict the WinCC project directory on the file system to the WinCCUser account; the trace ring buffer is not persisted, but the project file contains the screen design and may be reverse-engineered.

Field-Proven Caveats

• On WinCC V7.3 SP0 (no service pack), the Template property does not persist correctly across project deactivation/activation cycles. Apply at least SP3 before relying on GSC Diagnostics in a 24/7 plant.
• On multi-monitor RT stations, the diagnostics control must be on the primary monitor to receive focus and render the scrollbar correctly. Place it on screen #1, not the auxiliary screens.
• When using SetTagXxx inside a C action that is itself called from a VBS action, the trace lines can interleave non-deterministically across the two threads. Use a thread-id prefix in the trace text to correlate.
• On 64-bit WinCC installations (WinCC V7.5+), ApDiag.exe is shipped in the WOW64 directory. Use the explicit path C:\Program Files (x86)\Siemens\Automation\WinCC\bin\ApDiag.exe from a 32-bit command prompt, or the 64-bit path from a 64-bit command prompt.

Related References

• Siemens TIA Portal V20 — GSC diagnostics (RT Professional)
• Siemens TIA Portal V20 — Example of configuring a diagnostics output via a trace (RT Professional)
• Microsoft Learn — Collect and View EventSource Traces (.NET)

FAQ