Touch Panels

About 11 min read

On touch screen HMI panels and industrial PCs the operator works with a finger, often with gloves; there is no mouse pointer and no tooltip on hover. On these screens 2WinScada makes controls larger and marks controls that cannot act for the signed-in user. For panel PC setup and the kiosk address, see Panel PC and Kiosk.

Touch mode

Touch mode is not a setting; it turns on by itself when:

• The device has a touch pointer. This includes industrial PCs that report a mouse next to the touch screen.
• The page is opened with the kiosk address (?kiosk=1). A kiosk screen runs in touch mode even when a mouse is attached to the panel.

In touch mode the acknowledge and paging buttons of the Alarm table and the buttons and fields of the Manual entry table grow to at least 44 pixels. On screens used with a mouse these tables stay compact. Page content and saved settings do not change.

Size rules

When you design a page for a touch screen, use these minimums:

Control	Minimum
Every touch control (Switch, selector, Value input, drop-down)	44 pixels high
Command and navigation buttons (Button, Push button)	48 pixels high
Between two controls side by side	12 pixels

Where operators wear gloves, prefer 64 pixels for main commands and 16 pixels between them. The physical size depends on the panel's resolution and scaling; on a 15.6 inch 1920×1080 panel, for example, 48 pixels are about 8.6 mm. Try a new design on the real panel.

The ready-made blocks follow these rules: Control panel and the navigation blocks come with 48 pixel buttons, a 44 pixel switch and at least 12 pixels between controls; the manual control blocks (motor start/stop, jog, pump, valve) use larger push buttons. See Templates and Blocks. Pages built from blocks before 2.11.0 do not change; enlarge their button heights in the editor if needed.

Do not shrink the gap when you place opposite commands such as Start and Stop next to each other; mistaps happen most often on adjacent buttons.

Locked controls

At runtime a control that cannot act for the signed-in user is dimmed and shows a small lock in its top-right corner. Touch screens have no not-allowed cursor, so the operator sees before touching that the control is not available. The locked look applies to the Button, Toggle button, Switch, Value input, Push button, Three-state selector, Rotary switch and Potentiometer widgets.

A control is shown locked when:

• Read only is bound to a tag whose value is true. An interlock (permission) condition is built with this binding; the lock goes away by itself when the condition clears.
• The user does not have the role in the widget's Authorization field.

A control is not shown locked when:

• Read only is on as a fixed setting. Such a control is used as an indicator (for example a switch that shows a state) and keeps its normal look; the user's permission does not change this.

• A potentiometer whose Setpoint is not bound to a tag only displays a value and keeps its normal look.

• Buttons that only open a link (navigation buttons) and buttons that write and open a link: the tap still opens the link.

• Toggle buttons with a local (tag-less) state.

• Controls with event code, while they are not read only: event code also runs for users without write permission.

The locked look exists only at runtime; in the page editor controls look as usual. For a user without write permission the Value input is read only, and its plus/minus buttons do not change the shown value. If such a user still taps a button, a "no write permission" message appears; when a lock reason is set, the lock reason appears instead.

Lock reason

The eight widgets with the locked look have an optional Lock Reason field in their Behavior group. Enter a short text that tells the operator why the control cannot be used, for example "Interlock: door open". The field can also be bound to a text tag in the Bindings (Rules) section.

• When the control is locked and the operator taps or clicks it, or presses Enter or Space, the lock reason appears as a short message. On the same control the message appears at most every 2 seconds.
• The lock reason is also shown as the control's tooltip.
• For a user without write permission the lock reason replaces the "no write permission" message; the operator does not get two messages.
• If the field holds a locale key, the text is translated into the interface language.

The lock reason is not shown while the control is not locked. An empty field keeps the default behavior.

Safety

The locked look is a usability hint. The server always checks write permission; no button on a screen replaces machine safety.

Confirmation

A control with Needs Confirmation opens a confirmation dialog before it writes. The dialog is the same for every write with this option:

• The dialog title and the confirm button carry the name of the action. On the Button, Toggle button and Push button this is the button caption; on the Switch it is the title and the label of the state it moves to (for example "Pump 1 – ON"). The message reads "“Pump 1 – ON” will be applied. Continue?".
• Controls without a caption use the generic texts: the title Confirmation, the question Are you sure you want to proceed? and the Yes button.
• The other button is Cancel. When the dialog opens, Cancel has the focus, so Enter cancels the action. Escape and a page change also cancel.
• In touch mode the dialog buttons are 48 pixels high with space between them; on screens used with a mouse they keep their normal size.

Behavior change in 2.11.0

Before 2.11.0 the dialog buttons were Yes and No, and Enter confirmed. Now Enter cancels; to confirm, tap or click the button with the action name.

On the Push button the confirmation is only asked in Maintained (latching) mode, not in Momentary or Pulse mode. In those modes use enough size and spacing against mistaps, or turn on Two-Step Apply in Pulse mode.

Two-step apply

A button with Two-Step Apply does not act on the first press; it only arms. A second press shortly after applies the action, so a single mistap cannot write a critical command. The option is in the Behavior group and works on these widgets:

• Button: on buttons that write to a value tag. It is not used on buttons that only open a link or have no bound value tag.
• Push button: in Pulse and Maintained (latching) mode. It is not used in Momentary mode; if the option is on in that mode, the settings show a note.

How it works:

1. The first press arms the button: its outline pulses and "Press again to apply" replaces the caption (on the Push button the caption plate shows "Press again").
2. A second press within Second Press Window (s) (1–10 seconds, default 3) applies the action: the value is written, and the Button's click code and link run. With Needs Confirmation also on, the confirmation dialog opens after the second press.

A press within 350 ms after arming is ignored and the button stays armed, so a double tap or double click cannot apply the action in one gesture. When the window runs out, or on a press elsewhere, a page change, when the window loses focus or when the page is hidden, the armed state ends without writing.

The button's press and release event code (onMouseDown, onMouseUp) is not affected by this option and also runs on the first press.

Button badge

The Badge field in the Labels / Icons group of the Button shows a small number in the top-right corner of the button. The field is usually bound to a tag; for example, on the button that opens the alarm page, bind it in the Bindings (Rules) section with a Direct binding to the @NOP::__activeAlarmCount system tag.

• An empty value or 0 hides the badge; numbers above 99 show as "99+". Text that is not a number shows at most 4 characters.
• The badge uses the theme's error color with white text and is readable in the light and the dark theme. For another color, add a class in the Badge Class field of the Appearance group (for example bg-orange-500).
• Next to the lock the badge moves a little to the left so that both stay visible.

Buttons with an empty badge field look as before.

Newest alarm

Five system tags show the newest alarm on a panel screen: __latestAlarmId, __latestAlarmText, __latestAlarmType, __latestAlarmTime and __latestAlarmAcknowledged. Their values and binding types are listed under Tag Selector. Like the other system tags they are bound with @NOP::.

The "newest alarm" is the first row of the Alarm table with its default Active filter: of the alarms the user can see that are not locked, the one that changed last. Acknowledging does not change the alarm's time; the acknowledged alarm stays shown and __latestAlarmAcknowledged becomes 1. Without an active alarm the id, text and time are empty, and the type and acknowledged state are -1.

Expressions in bindings are evaluated with mathjs; write and, not &&. For example, to show an acknowledge button only while the newest alarm waits for acknowledgement, bind the button's visibility with a Boolean binding to this expression:

'@NOP::__latestAlarmId' > 0 and '@NOP::__latestAlarmAcknowledged' == 0

In the button's event code, this.srt.ackSingleAlarm(this.srt.tagValue("@NOP::__latestAlarmId")) acknowledges only this alarm; it needs an alarm role (see Event Code). The Alarm Banner block does the same without event code.

Ready-made alarm banner and operator panel

The Alarm Banner block (in the Blocks section) shows the newest active alarm in a one-row Alarm table with its time, message and state. The acknowledge button in the row acknowledges only the shown alarm and is visible only to users who may acknowledge alarms. Next to it are a severity pill (alarm or error, warning, no alarm) and the counts of active and unacknowledged alarms. The banner covers every alarm the user can see; acknowledging all alarms stays on the alarm page. The block contains no event code, so any designer can save a page that uses it.

The Operator Panel (Touch) starter template (in the Starter category) is an operator page that works on panel PCs and in desktop browsers:

• at the top an equipment name band and below it the alarm banner,
• in the middle content cards that wrap with the screen width: equipment status, motor start/stop, speed setpoint, safety and interlocks,
• at the bottom large navigation buttons: home, alarms with a badge for the active alarm count, trends, run/stop and a detail page.

After inserting the template, bind the card tags and select the target of the detail page button in the Navigation (To) section. Connection and device status are shown in the app header, and in kiosk mode in the strip at the bottom of the screen. See Templates and Blocks.

Status colors

Status pills in the ready-made blocks (for example Running, Stopped, Fault, Manual and the interlock conditions) use text tones that stay readable in small text. Colors in newly inserted blocks (including the gauge, tank, target and value card blocks and the conveyor blocks) come from the theme, so the blocks are readable in the light and the dark theme. Blocks inserted earlier and pages built from them do not change; insert the block again for the new colors.

The Theme colors group of the class list in the editor has new classes for this:

• Readable success text (small text) and its counterparts for warning, error/alarm and info: for small text on pills with a soft background.
• A background and a text color for each of six equipment states (Running, Stopped, Fault, Manual, Interlocked, Maintenance), for example Running state soft background and Running state text color. On a pill, pick the background and the text from the same state.

Event code on touch

The press (onMouseDown) and release (onMouseUp) event code of the Button, Toggle button, Switch and Button group widgets also runs on touch screens:

• The press code runs when the finger lands. The release code runs once when the finger lifts, when the press is canceled (for example when the window loses focus or the page is hidden) or when the page changes. Code that writes 1 while pressed and 0 on release therefore also works on a panel.
• The release code runs even if the control turned read only during the press.
• Only the first finger counts; a press with a second finger at the same time runs no code. For commands operated with two hands, use the Push button.

Mouse and pen operation is unchanged: a pen works with mouse events as before.