Resolving WinCC VBS Alarm Acknowledgment Type Mismatch Error

Problem Overview

Engineers maintaining or upgrading legacy WinCC HMI projects routinely encounter a Type mismatch runtime error when they attempt to acknowledge an alarm from a button's VBScript action. The call most frequently associated with the failure is:

Sub acknowledgeAlarms
    Dim returnValue
    returnValue = AXC_OnBtnVisibleAck("mainpage.pdl","alarmControl")
End Sub

The error fires immediately because the developer is invoking a function exported by the WinCC C API (AXC_OnBtnVisibleAck) inside a VBScript routine. The WinCC runtime binds the call to the VBS interpreter, cannot resolve the symbol, and aborts the script with an automation type mismatch. The alarm remains in the unacknowledged state and the button becomes effectively non-functional.

The same symptom also appears when engineers try to call any of the AXC_* or other documented C functions from a button's VBS action, or when they wrap a C function inside a VBS trigger expecting mixed-mode execution. Because the two scripting runtimes are not inter-operable, the only reliable path is to use the API exposed for the runtime that the script is actually written in.

Root Cause Analysis: The C / VBScript Boundary

WinCC supports two parallel scripting environments inside the Graphics Designer:

• C scripting — ANSI-C with WinCC-specific header includes such as apdefap.h, apbrowse.h, and the AXC_* alarm/messaging wrappers in apmdefap.h.
• VBScript — Microsoft VBScript running against the WinCC object model exposed through HMIRuntime.

The two runtimes are strictly isolated. A function compiled into the C runtime cannot be invoked from VBS and vice versa. The compiler and the runtime resolver keep separate symbol tables, and there is no built-in marshalling layer between them.

Two further constraints compound the issue in WinCC V6 and early V7 projects:

1. VBS in those versions cannot directly acknowledge an alarm — it can read the alarm object, change its State field, append a comment, or create a new alarm, but the runtime does not expose a method that toggles the operator acknowledgment flag in the same way the C alarm viewer does.
2. Documentation shipped with these versions is inconsistent about this limitation, and V6 example projects frequently contain the same misuse pattern, encouraging copy-paste errors.

Affected Versions and Components

Solution Path 1 — Use the Built-In Alarm Control Buttons

The simplest and most defensible solution in every WinCC runtime is to delegate acknowledgment to the AlarmControl's built-in buttons rather than to a custom VBS button. Siemens documents three standard acknowledgment operators:

1. Single acknowledgment — acknowledges the highlighted single message.
2. Group acknowledgment — acknowledges all currently visible/selected messages in the active list view.
3. Always-acknowledge (operator stationary) — acknowledges based on operator workstation regardless of which screen the message originates from.

Details on the three options (single acknowledgment, group acknowledgment, and the operator-station mode) are documented in Siemens Support Entry ID 7797013 — "How do you acknowledge alarm messages in WinCC?".

Implementation steps:

1. Open the WinCC Explorer project and open the Graphics Designer.
2. Insert a WinCC AlarmControl on the picture (e.g., mainpage.pdl).
3. In the AlarmControl Configuration Dialog, enable the toolbar elements Single acknowledgment and Group acknowledgment.
4. Optionally lock the toolbar (Operator authorization) so that ack authority is governed by user rights.
5. Select the row in the running view and click the toolbar button. The runtime sets the State bit hmiAlarmStateAcknowledged in the alarm record.

Solution Path 2 — VBScript With the HMIRuntime Write API

For projects that require a VBS-driven custom button (for example, a faceplate that lives outside the AlarmControl), the VBS object model exposes the alarm object and allows state/comment writes. The acknowledgment bit itself is restricted to the runtime; what VBS can do is modify the State and Comment fields, then trigger a follow-on alarm that has the desired "come + comment" semantics. The canonical example pattern is:

Sub OnClick(ByVal Item)
    Dim MyAlarm
    Set MyAlarm = HMIRuntime.Alarms(1)
    MyAlarm.State = 5         ' hmiAlarmStateCome + hmiAlarmStateComment
    MyAlarm.Comment = "MyComment"
    MyAlarm.UserName = "Hans-Peter"
    MyAlarm.ProcessValues(1) = "Process Value 1"
    MyAlarm.ProcessValues(4) = "Process Value 4"
    MyAlarm.Create "MyApplication"
End Sub

Field reference for this template:

The State = 5 line is a bitwise OR of 1 (Come) plus 4 (Comment). This is what produces the comment-annotated trigger entry you see in the archived message list. It does not toggle the acknowledgment state of a previous message; for that you must use Path 1, Path 3, or Path 4 below.

Solution Path 3 — Call the C Function From a C Action (Not VBS)

If the application logic requires the exact AXC_OnBtnVisibleAck semantics (visible-ack on a specific picture and AlarmControl), move the call into a C action on the same button. The legacy pattern looks like this:

// C action placed on the button's "Click" event
#include "apdefap.h"

void OnClick(char* lpszPictureName, char* lpszObjectName)
{
    AXC_OnBtnVisibleAck("mainpage.pdl", "alarmControl");
}

Procedure:

1. Open the button's Properties > Events > Click.
2. Select C action (not VBScript).
3. Paste the function above, adjusting the project path and control name to match your picture.
4. Recompile and download the runtime.

Solution Path 4 — WinCC Unified AcknowledgeAlarm

If the project is being modernized to WinCC Unified (TIA Portal V17 and newer), the runtime exposes a proper acknowledgment system function. Reference: TIA Portal Docs — WinCC Unified / AcknowledgeAlarm.

The system function can be called from a button's OnClick event. The configuration in the Unified Engineering is:

1. Open the HMI screen and select the button.
2. In the Properties > Events > Click handler, choose Add new function.
3. Pick AcknowledgeAlarm from the system function list.
4. Bind the parameters to a configured alarm instance, typically the active logging tag or the alarm name returned by the screen context.
5. Compile and test.

For Unified scripting, the equivalent JavaScript / C# call inside a global module is:

// JavaScript in a WinCC Unified button or scheduled task
import { HMIRuntime } from "HMIRuntime";
await HMIRuntime.Alarms.AcknowledgeAsync(alarmName, { userName: "Operator", comment: "Ack from script" });

Unified doesn't expose the obsolete AXC_* set, so cross-runtime confusion is removed entirely. New projects should target Unified where the runtime supports it.

Solution Path 5 — WinCC Script Connector (Legacy Bridge)

The WinCC Script Connector, distributed by the Siemens WinCC Competence Center Mannheim, is a free add-on that bridges C and VBS functions through a registration layer. When loaded, the connector surfaces a small set of C-side alarm helpers as registered Automation objects callable from VBS, including wrappers for the visible-ack buttons.

Practical caveats:

• It is a third-party (CC-Mannheim) tool, not part of the WinCC installation media.
• It must be installed on the engineering station and on every runtime station that needs the bridge.
• It is not guaranteed to remain compatible after major WinCC service packs; pin the WinCC version on every station before upgrading.
• The connector adds DLL load time at startup; budget an additional 1–2 s for HMI boot.

Use the connector as a stop-gap on legacy projects where restructuring to Solution Path 2 or 4 is blocked by certification or copy-paste-exact requirements.

Comparison: Which Path To Choose

Verification Steps

Regardless of which path you choose, validate it with the following sequence:

1. Compile clean. In the Graphics Designer, request a "Recompile all". C actions that reference unknown APIs (e.g., a typo'd AXC_OnBtnVisibleAck when the project is missing a required alarm optional package) will surface compile errors before download. VBS uses late binding, so errors only show at runtime.
2. Trigger a real alarm. Force a process value that drives a configured message priority class to the alarm-state threshold.
3. Watch the message frame. In the AlarmControl, the message must show the acknowledgment icon, the operator timestamp, and the comment text (where applicable).
4. Inspect the archive. Open WinCC TagLogging or the SQL archive view and confirm the StateChange row carries the new acknowledgment bit and the correct UserName.
5. Audit log. Verify in the alarm audit that the entry is attributed to the logged-in user, not to SYSTEM.
6. Operator-rights test. Log in as a non-privileged user and verify the button is disabled or hidden per the configured authorization level.

Troubleshooting Matrix

Engineering Recommendations

• Treat the C / VBS boundary as a hard architectural line and document it in your project programming guideline. New work should stay on VBS or move entirely to Unified, not both.
• Avoid the AXC_* family for new code; even on C actions, prefer the WinCC AlarmControl's internal acknowledgment API and surface that through a single, reviewed C function module.
• If a custom faceplate must trigger acknowledgment, build a small wrapper library of C functions and a parallel set of VBS stubs that perform the equivalent operation through legitimate channels; never let ad-hoc calls leak across the boundary.
• For TIA Portal migration projects, prefer WinCC Unified's native AcknowledgeAlarm system function. Reference: WinCC Unified — AcknowledgeAlarm.
• Add the Siemens Support article ID 7797013 to your team's bookmarked reference set. It is the canonical Siemens answer to "how do I acknowledge?" and is updated with each service pack.