Resolving MTP700 Multi-Button Press Issues on WinCC Unified V17

The SIMATIC HMI MTP700 Unified Comfort Panel is part of Siemens' second-generation Unified Comfort Panel product line. Unlike the legacy Comfort Panels that ran WinCC Comfort / Flexible Runtime, the MTP700 family runs WinCC Unified Runtime on a Linux-based real-time image, supports capacitive projected multi-touch (PCAP) sensing, and is engineered around a modern gesture stack. TIA Portal V17 is the engineering environment that produces both the panel image and the runtime project; it is also the place where the touch behavior described in this article is configured and verified.

Engineers moving from WinCC Comfort to WinCC Unified often assume that any multi-touch capable panel can register two simultaneous button presses as two independent events. The Unified Runtime does not work that way. This article documents the precise behavior on the MTP700, the underlying dispatcher model, the one official exception (two-handed operation with an enable button), and a field-proven workaround chain that lets two buttons cooperate in a controlled sequence. Reference documentation for the broader panel family is available in the official Unified Comfort Panels operating instructions on the Siemens Industry Online Support portal.

Problem Statement: Two-Button Press Behavior

A typical MTP700 project contains a screen with several Button screen objects. When the operator places one finger on button A and a second finger on button B at the same instant, the runtime registers only the press event of button A. The press of button B is suppressed for the duration of the simultaneous contact. The same suppression occurs in the reverse order, and it is independent of whether the buttons are configured for Press, Release, or Click events, independent of the HMI tag wiring, independent of any script attached to the event, and independent of the visibility and appearance of the buttons themselves.

Symptoms commonly reported in field engineering notes:

• My second button only fires if I release the first one first.
• Two-handed start buttons do not work even though I configured two separate buttons.
• Pressing two operator-acknowledge buttons at the same time only acknowledges one.
• My jog+ / jog- buttons only allow one direction at a time even though the panel is multi-touch.

The behavior is by design and is consistent across the entire Unified Comfort Panel line. The MTPs (Multi-Touch Panels) do support multiple concurrent touches at the sensor level, but those touches are routed by the runtime to a single ownership context, and the screen object model only consumes the first context for standard buttons.

Root Cause: Unified Runtime Touch Event Model

The Unified Runtime is built on a single-focus touch input model. Internally, the touch driver reports a stream of touch down, touch move, and touch up events, each tagged with a finger ID. The dispatcher assigns the first touch down to a screen object and grants that object exclusive ownership of the touch context. Every subsequent touch down from a different finger ID is delivered to the gesture stack, but the button event pipeline only forwards the first object that responded.

Three downstream consumers compete for the additional touch points:

1. Screen-level gesture zones (Swipe, Zoom, Pan) consume their own touch context when configured over a region of the screen.
2. Two-handed operation elements are the only screen objects that are allowed to subscribe to a second touch point, and only while the first touch point is held on a paired enable element.
3. Internal diagnostics consume any remaining touch points for trace logging but never forward them to user-level events.

The one-event-per-object rule exists for reasons that mirror the way two-hand control circuits are implemented in hard-wired relay logic and in IEC 62061 / ISO 13849 PLe category 3/4 machinery circuits. A single button press should not be able to mask or amplify a second, unrelated command, and the dispatcher enforces that guarantee centrally so that individual screen objects do not have to.

The Two-Handed Operation Exception

Siemens ships the two-handed operation pattern because it is the standard operator-safety interlock for two-hand control on presses, bending machines, shears, and other equipment where both of the operator's hands must be on a control before a dangerous motion can be initiated. The Unified Runtime allows a second button to become active only after an enable button has been pressed first, and the second button must be configured as a two-handed operation trigger. Both buttons must be on the same screen.

Note that the order matters. The enable button must be the first one contacted, and the trigger button must be the second one contacted while the first is still held. If the operator crosses the hands or reverses the order, nothing fires — that is the correct fail-safe behavior for a two-hand circuit and is what the dispatcher enforces.

Configurable Properties

When a button is flagged as a two-handed operation element, the following properties become available in the Properties inspector of TIA Portal V17:

• Two-handed operation — checkbox in the General section. Once checked, the button is removed from the standard button event pool and is routed through the two-handed dispatcher.
• Enable button — internal tag that the runtime writes TRUE while the paired enable button is held, FALSE otherwise. Use it in scripts or animations to give the operator visual feedback on the handshake state.
• Confirmation time — optional monitoring window in milliseconds. If the second touch does not occur within this window after the first, the runtime aborts the two-handed handshake. Typical values are 500 ms to 2000 ms; 0 ms disables the timeout.

Workaround: Explicit Button-Tie Activation Chain

When two-handed operation does not fit the operator workflow — for example when the two buttons are not a safety interlock but a normal Acknowledge + Confirm sequence — the alternative is to introduce a logical gate on the PLC side. Button A is wired as a normal press. Button B is wired as a normal press as well, but its Events > Press script first checks a gate tag and only fires the downstream action if the gate is set. Button A sets the gate on press and the same flag is cleared after Button B has been acknowledged. This is the explicit-tie pattern: have one button activate the second, and the second triggers the events desired.

The advantage of the explicit-tie approach is that the operator is not forced to keep the first button pressed; both buttons can be tapped sequentially with the same hand or with two hands. The disadvantage is that the chain is not a true two-hand safety circuit and must not be used to satisfy ISO 13849 two-hand control requirements. For any safety-related function, use the native two-handed operation pattern described in the previous section.

PLC Logic Sample (SCL / Structured Text)

// Tags
//   HMI_BtnA_Press   : BOOL  -- press event from button A
//   HMI_BtnB_Press   : BOOL  -- press event from button B
//   BtnA_Armed       : BOOL  -- gate flag (TRUE once A has been pressed)
//   BtnA_Released    : BOOL  -- debounced release of A
//   Combined_Action  : BOOL  -- downstream action that needs both presses

IF HMI_BtnA_Press AND NOT BtnA_Armed THEN
    BtnA_Armed    := TRUE;
    BtnA_Released := FALSE;
END_IF;

IF NOT HMI_BtnA_Press AND BtnA_Armed THEN
    BtnA_Released := TRUE;       // A has been released; arming still valid
END_IF;

IF HMI_BtnB_Press AND BtnA_Armed AND BtnA_Released THEN
    Combined_Action := TRUE;
    BtnA_Armed      := FALSE;    // disarm after successful handshake
END_IF;

HMI-Side Script Sample (JavaScript, Unified)

// Attach to Button B's Press event
export function Button_B_OnPress(item) {
    let armed = Tags('BtnA_Armed').Read();
    if (armed === false) {
        // Button A was never pressed; do nothing
        return;
    }
    // Forward the press to the PLC
    Tags('HMI_BtnB_Press').Write(1);
    // Optional: reset arming tag after a short delay
    HMIRuntime.Timer.SetTimeout(function() {
        Tags('BtnA_Armed').Write(0);
    }, 250);
}

Step-by-Step Configuration in TIA Portal V17

The following procedure configures a pair of two-handed operation buttons on a MTP700 panel in TIA Portal V17. The procedure assumes that the project already compiles and downloads successfully and that the HMI tags involved are defined at the PLC and exposed through the HMI connection.

1. Open the TIA Portal V17 project. Expand Devices & Networks and select the Unified Comfort Panel (for example, HMI_1 [MTP700]).
2. In the project tree, expand Screens and double-click the screen that contains the two buttons. The WinCC Unified editor opens.
3. Click the first button (the enable button). In the Properties inspector, scroll to the General section and tick the Two-handed operation checkbox. The button is now classified as an enable element.
4. Click the second button (the trigger button). In the same way, tick the Two-handed operation checkbox. The button is now classified as a trigger element.
5. For both buttons, confirm that the Press event has a target — either an HMI tag bit or a script. If the buttons are only graphical placeholders, the runtime will not log the press even if the touch is registered.
6. If you want the runtime to abort the handshake when the second touch is delayed, configure Confirmation time in the trigger button's properties. Leave it at 0 ms if you want an unlimited window.
7. For a sanity check, set the panel's Runtime settings > Services > Trace to record the touch events. Compile the project with Project > Compile > Software (rebuild all) and download to the panel.
8. On the panel, run the runtime, open the screen, and follow the verification procedure in the next section.

Verification and Runtime Testing

After the download, perform the following tests on the MTP700 panel itself — not in the TIA simulation, because the simulation does not always reproduce the multi-touch dispatcher behavior of the production runtime.

1. Tap the enable button only. The Press event should fire, the Enable button tag should go TRUE for the duration of the touch, and the trigger button should remain dark or otherwise inactive.
2. Press and hold the enable button. While holding it, tap the trigger button with a second finger. Both Press events should fire. The Enable button tag should still be TRUE.
3. Reverse the order: press the trigger button first, then press the enable button. Neither Press event should fire. The handshake is aborted.
4. Press the enable button, then wait longer than the configured Confirmation time before pressing the trigger button. The trigger press should be suppressed and the runtime should reset the handshake.
5. Open the project's Online > Watch & Force view in TIA Portal and confirm that the Enable button tag transitions match the touches within 50 ms.

If steps 1 and 2 fire the events but step 3 also fires them, the buttons are not actually configured as two-handed operation elements. Return to the Properties inspector and verify that the checkbox is ticked; merely renaming the buttons to Enable and Trigger is not sufficient.

Related Runtime Constraints and Edge Cases

Several other Unified Runtime behaviors interact with the two-button press question. Engineers should be aware of them when designing screens that mix gestures, modal windows, and two-handed operation.

Gesture Zones Consume Touches First

If a Swipe, Zoom, or Pan gesture zone overlaps one of the two buttons, the gesture dispatcher wins the touch context and the button press is suppressed. The two-handed handshake cannot proceed because the second touch is owned by the gesture, not by the trigger button. Place buttons outside gesture zones, or reduce the gesture zone to a region that does not overlap.

Modal Screen Windows

A button that opens a screen window on press creates a modal context. The runtime forwards the press event, but for the duration of the modal window the underlying screen is blocked. The second button on the underlying screen cannot receive a touch. To use two buttons across a modal boundary, place both buttons inside the screen window instead of on the parent screen.

Overlapping Hit Areas

When two buttons are placed so that their hit rectangles overlap by even a few pixels, the dispatcher picks the topmost object in z-order. The second button is effectively unreachable at the overlap. Use the layout tools in the Unified editor to align buttons on a grid and to maintain a minimum 8 px gap between hit areas.

Long-Press vs. Press

Both buttons in a two-handed pair can be configured for long-press behavior (hold the button for N seconds before the event fires). The long-press timer is per-button and runs in parallel; the handshake is not affected as long as both timers complete within the Confirmation time window of the trigger button.

Multi-Language Screen Variants

If the project uses language switching, the button labels change but the button IDs and the two-handed configuration do not. Engineers sometimes believe the configuration has been lost after a language switch because the labels look different; the actual event behavior is unchanged.

External Keyboard and Mouse

When an external USB keyboard or mouse is connected to the MTP700, the runtime can route the keyboard space bar or a mouse click to a focused button. In that case the touch dispatcher is not involved and the two-button limitation does not apply. Use this for engineering or maintenance access only, never for normal operator control, because the safety assumptions change.

Firmware and Version Considerations

The two-handed operation feature is implemented in the WinCC Unified Runtime image that ships with the panel. TIA Portal V17 projects compile against a specific image version; if the panel's image is older than the project expects, the runtime refuses to load the project and reports a version mismatch on the panel's diagnostic page. The recommended workflow is:

1. Confirm the panel's current image version under Control Panel > System > About on the device, or in TIA Portal under Online > Accessible devices.
2. Cross-reference the TIA Portal V17 readme and release notes for the minimum Unified Runtime image version that supports two-handed operation. The feature is present in the V17 line; if you are running a pre-release service pack, upgrade to the latest available service pack before deploying.
3. Use Online > HMI Device Maintenance > Update operating system in TIA Portal to flash a matching image if needed.

Field Notes and Lessons Learned

Across multiple MTP700 deployments the following patterns have been observed and verified by acceptance testing:

• The term multitouch in product brochures refers to the touch sensor's ability to detect multiple finger IDs, not to the runtime's ability to fire multiple button events. Always confirm the application-level behavior with a runtime trace, not with marketing material.
• Some operators find two-handed operation awkward when the two buttons are vertically stacked. Place the enable button on the dominant-hand side and the trigger button on the non-dominant side, both at the same vertical height. This mirrors the layout of certified two-hand control devices and reduces accidental crossed-hand presses.
• When a project mixes operator-safety two-hand control with normal Acknowledge + Confirm workflows, mark the safety-related pair with a yellow border or a visible 2H badge. Operators and auditors can then tell at a glance which pairs are safety-critical.
• The runtime's touch trace is invaluable for debugging. Enable it under Runtime settings > Services > Trace before any acceptance test, and save the trace log to a USB stick for the test report.
• When porting a project from a Comfort Panel (single-touch) to a MTP700, audit every screen for implicit two-finger workflows. Operators sometimes developed a habit of pressing two buttons at once on single-touch panels to trigger an interlock, and the habit transfers to the new panel where the dispatcher suppresses the second press.
• If the project includes a faceplate or library that is reused on both single-touch and multi-touch panels, the two-handed operation properties travel with the faceplate. The library is the right place to enforce the configuration rather than relying on each screen author to enable it.

Frequently Asked Questions