Configuring F1 Shortcut for WinCC HMI Horn Reset Operation

Problem Statement

In WinCC Professional (TIA Portal) and the WinCC Comfort/Advanced runtimes, operators routinely request a single-key horn-acknowledge action so the audible alarm can be silenced without lifting a hand from the keyboard. The natural choice is the F1 key, but several of WinCC's default behaviors work against this requirement:

• The configured horn-acknowledge push button only receives Keyboard Press and Keyboard Release events while it actually holds the screen focus.
• A normal push button does not take the focus when an operator is editing a different object, such as an analog setpoint I/O field, on the same screen.
• Calling Set_Focus() on the acknowledge button from a script solves the event-dispatch problem but immediately makes the previously focused object (e.g. an analog setpoint) un-editable until the focus is programmatically returned.
• Multiple buttons that share the same hotkey collide: WinCC only fires the first one it finds in the object tree.

This article documents four distinct implementation paths that exist in WinCC, isolates the precise root cause for each failure mode, and recommends the configuration that delivers focus-independent horn acknowledgement with zero impact on other I/O objects.

Root Cause: The WinCC Focus and Event Model

WinCC's runtime treats the keyboard as a per-focus input device. The event delivery rules are:

1. Mouse events on a button (Mouse Click, Mouse Down, Mouse Up) are dispatched regardless of focus, but they only fire when the operator physically uses the pointing device.
2. Keyboard events (Keyboard Press, Keyboard Release) are delivered to the object that currently holds the runtime focus, identified internally through the WinCC object model's focus chain.
3. A ShortCut property (found under Miscellaneous) on a button object is the one keyboard-related property that does not require focus. WinCC's input dispatcher intercepts the configured F-key at the screen level and routes it to the configured Mouse Click event of the owning button.
4. Calling Set_Focus() from a C or VB script transfers focus to the target object and keeps it there. It is not a transient operation; the focus remains with the target object until another Set_Focus() call or a mouse click moves it.
5. Picture windows opened with the @ prefix (e.g. @HornQuit.pdl) are children of the parent picture. A hotkey collision between an object in the picture window and an object in the parent picture will silently disable the lower-priority binding with no error message.

Understanding these rules makes it clear why the simplest implementation (just drop a button, assign a script, and expect F1 to work) fails in practice, and why each of the four documented workarounds addresses a specific symptom rather than the underlying cause.

Method 1: Set_Focus C Script (Use with Caution)

The Set_Focus C function is the legacy approach used in WinCC V7 and remains available in WinCC Professional under TIA Portal V16/V17. It is called from a global C script, commonly from the Open Picture event of a screen that should respond to the horn-acknowledge hotkey.

Example C action bound to a screen's Open Picture event:

// C action: Force focus to the horn-acknowledge button when the screen opens
#include "GlobalDef.h"

void OnOpenPicture(char* lpszPictureName, char* lpszObjectName)
{
    // Tag name and button name are project-specific
    Set_Focus(lpszPictureName, "BtnHornAck");
    return;
}

Failure mode this triggers: once BtnHornAck holds the focus, the Keyboard Press event fires correctly on F1. However, every other input object on the screen loses the ability to receive the cursor. Operators can no longer change an analog alarm setpoint, edit a recipe parameter, or click into a date picker until the focus is moved back manually.

This is the reason the original report states: "when you make enable Set_Focus for a Push Button you can't change anything else."

If Set_Focus must be used, the focus must be programmatically released on every Mouse Click of any other input object. The maintenance cost of this approach makes it unsuitable for screens with more than two or three input fields.

Method 2: Keyboard Polling with getchar()

Because Keyboard Press events require focus, the second workaround reads the keyboard directly from a global C action triggered by a tag change. WinCC's C runtime exposes the standard C library function getchar(), which reads one character from the stdin stream of the runtime process.

This method is implemented as a scheduled C task bound to a global internal tag (e.g. HornActive) that toggles whenever an alarm is raised. The task body is approximately:

// C action: Scheduled task, 100 ms cycle, on HornActive rising edge
#include "GlobalDef.h"
#include <stdio.h>

void PollHornAck(void)
{
    static DWORD dwLastChange = 0;
    DWORD dwNow = GetTickCount();

    if ((dwNow - dwLastChange) < 200) return;       // debounce 200 ms
    if (getchar() == 0) return;                      // no key available

    int c = getchar();
    if (c == 0 || c == EOF) return;
    if (c == 0x3B)                                   // VK_F1 == 0x3B
    {
        SetTagBit("HornQuit", 1);                   // pulse the ack tag
    }
    dwLastChange = dwNow;
    return;
}

Drawbacks:

• getchar() in WinCC Runtime blocks on the runtime's stdin; in Web-Client and Softnet deployments it can return EOF immediately and silently no-op.
• The polled approach consumes CPU cycles and scales poorly with additional hotkeys.
• Operator input captured by an I/O field may be swallowed by the polling task before the I/O field can process it, depending on the input focus model of the deployed runtime.

This method is retained for diagnostic purposes but should not be the production solution.

Method 3: Shortcut Property (Recommended)

The correct, focus-independent implementation is to assign the F-key to the button's Shortcut property. This is the property that WinCC's input dispatcher monitors at the screen level, and it does not require the button to hold focus.

The mechanism is implemented as follows:

1. Select the horn-acknowledge push button (e.g. @BtnHornAck inside @HornQuit.pdl).
2. In the Properties pane, expand Miscellaneous.
3. In the Shortcut field, click the small key icon and press the desired function key. WinCC records the virtual key code (F1 = 0x3B, F2 = 0x3C, ..., F12 = 0x42, plus modifiers 0x10 for Shift, 0x11 for Ctrl, 0x12 for Alt).
4. Bind the C action or VB script that resets the internal horn tag to the button's Mouse Click event. The Mouse Click event is invoked by the dispatcher whenever the configured Shortcut is intercepted, regardless of focus.

This delivers exactly the behavior the operator expects: F1 acknowledges the horn, and the previously focused object (analog setpoint, recipe value, date picker) remains editable.

Method 4: Event-Driven I/O Field Script

For applications that already maintain a global alarm-active tag (e.g. HornActive), a C or VB script can be bound to the Event → Input/Output value trigger of an off-screen I/O field. The script reads the keyboard state when the tag transitions and pulses the acknowledge bit when F1 is detected.

Configuration steps:

1. Create an internal tag HornActive (Bool) that the alarm logic sets to 1 on raise and resets on acknowledge.
2. Add an I/O field bound to HornActive; place it off-screen or in a hidden layer.
3. On the I/O field's Event → Output value property, configure a C action:

// C action: Bound to I/O field "HornActive" Output value change event
#include "GlobalDef.h"

void OnHornActiveChanged(void)
{
    if (GetTagBit("HornActive"))
    {
        // Block briefly and probe keyboard state
        short sKeyState = GetAsyncKeyState(0x3B);     // VK_F1
        if (sKeyState & 0x8000)
        {
            SetTagBit("HornQuit", 1);
        }
    }
    return;
}

Caution: GetAsyncKeyState is a Win32 API and is only available in WinCC Professional C scripts when the Windows API set is included via #include <windows.h>. In WinCC Comfort Panel runtime (WinCE-based), the function is not available, and Method 3 is the only portable path.

Method Comparison

Step-by-Step: Implementing the Shortcut Method

The following procedure delivers a focus-independent horn-acknowledge hotkey on a WinCC Professional (TIA Portal V16/V17) runtime. The same procedure applies to WinCC Comfort V16/V17 panels with one additional constraint: Shortcut support on Comfort panels is limited to the alphanumeric keys and F1-F12; combinations with Shift/Ctrl/Alt are restricted to certain firmware revisions (V15.1 and later).

1. Create the internal acknowledge tag. In the project tree, open PLC tags → Show all tags → Add new tag. Name it HornQuit (Bool), address %DB100.DBX0.0 or the equivalent internal address. The horn-acknowledge script will pulse this tag for one PLC cycle.
2. Create the horn-acknowledge picture window. In the project graphics, create a new picture named @HornQuit.pdl. Drop a push button named @BtnHornAck on it. Size the picture to 1 x 1 pixel and place it off the visible area, or open it as a picture window from a parent screen and keep its visibility off.
3. Bind the C action to the button. On @BtnHornAck, open Properties → Events → Mouse → Click. Add a C action:

// C action: BtnHornAck OnClick
#include "GlobalDef.h"

void OnBtnHornAckClick(char* lpszPictureName, char* lpszObjectName)
{
    SetTagBitWait("HornQuit", 1);            // pulse 1 PLC cycle
    SetTagBitWait("HornQuit", 0);
    return;
}

4. Assign the F1 Shortcut. On @BtnHornAck, open Properties → Miscellaneous → Shortcut. Click the key icon and press F1 on the keyboard. WinCC writes the virtual key code 0x3B to the property.
5. Compile and download. Compile the HMI project, transfer the runtime files to the operator station, and start the runtime.
6. Verify uniqueness. Right-click the project root, choose Cross-reference → Shortcut to list every object that uses a Shortcut in the project. Resolve any duplicates by reassigning one of the conflicting buttons to a different F-key (F2-F12) or to a Ctrl/Alt combination.

Verification

After implementation, run the following test sequence to confirm the configuration:

1. Start the runtime. Navigate to a screen that contains at least one editable I/O field (analog setpoint, recipe value, or numeric parameter).
2. Click into the I/O field and confirm the cursor is visible inside it. Do not press Enter or Tab.
3. Trigger a horn-active alarm from the PLC (set the relevant alarm bit in the PLC tag table, or use the WinCC simulator's Alarm → Trigger menu). Confirm the horn sounds.
4. With the focus still inside the I/O field, press F1 on the keyboard. The horn must silence within one PLC scan cycle.
5. Without clicking anywhere, type a new value into the I/O field and press Enter. The new value must be written to the PLC without re-triggering the horn. If the horn re-triggers or the value is rejected, focus has been stolen by the acknowledge button and Method 1 is in use by mistake.
6. Repeat steps 2-5 with the I/O field configured as a date picker, dropdown, and slider. The Shortcut method must not interfere with any of them.

Common Failure Modes and Resolutions

Virtual Key Code Reference

To bind a combination such as Ctrl+F1, enter the modifier virtual key code first followed by the function key code in the Shortcut editor's "Extended key sequence" field. WinCC V16/V17 supports up to four modifier keys per Shortcut binding.

Best Practices

• Prefer the Shortcut property over any C-script-based focus manipulation. It is the only mechanism that delivers a true focus-independent hotkey and is supported across all WinCC runtime targets.
• Centralize the acknowledge button in a single picture window (@HornQuit.pdl) that is opened globally at runtime start. This makes duplicate-Shortcut detection easier to audit.
• Avoid using F1 for horn-acknowledge on systems where F1 is conventionally bound to online help. Reserve F1 for help context and use F2-F12 for operational hotkeys.
• Document every Shortcut binding in a project-level table (screen, object, Shortcut, action) and check it into the engineering repository. This is the only reliable way to detect hotkey collisions before commissioning.
• Test under the same runtime that will be deployed (WinCC Professional, WinCC Comfort, WinCC Advanced). The Shortcut dispatcher behaves identically across all three, but the helper APIs (GetAsyncKeyState, getchar) do not.

References in Configuration

For the authoritative specification of the Miscellaneous → Shortcut property and its runtime behavior, consult the TIA Portal WinCC Professional online help and the Siemens Industry Online Support portal. The Shortcut dispatcher is implemented in the WinCC runtime's input manager and is documented under "Configuring operator input → Keyboard operation" in the WinCC Professional system manual.