Build an HMI pop-up screen with a screen window

How do you create a pop-up screen when the HMI software has no pop-up function?

You build it with a screen window: a container on the host screen that displays a second, smaller control screen inside it, opened by an Open-in-screen-window action on the trigger graphic and shown or hidden through one Boolean visibility tag.

The host screen stays active behind the window, so the operator never loses the process view. The child screen is an ordinary screen in the project; the window decides where it appears and whether it shows. That is the whole mechanism, and it is why the click action matters so much. An action that navigates to the child screen replaces the host. An action that opens the child in the window overlays it. Swapping top-level screens with keys or buttons is a different job, covered under function key screen navigation; this page handles only the overlay.

What do you need before you start?

You need a host screen that stays open, a child control screen sized to the window, one screen window object, one Boolean tag for visibility, and a trigger graphic with a click event; nothing else changes on the controller side.

Build the control screen before you wire the trigger, and keep the simulator open, because every check below is a forced tag and a click.

How do you build the control screen that goes inside the window?

Build it as a small dedicated screen the exact pixel size of the window, holding only the controls the operator needs for that one task, with a close button when the operator must dismiss the window from inside it.

1. Create the screen and set its size in pixels to the window size, 400 x 300 in the example below, so the layout matches the container exactly.
2. Add only what the task needs: setpoint fields, indicators, one accept button, one close button.
3. Wire every command to the same process tags it would use on a full screen. The window changes presentation; the data path stays the same.
4. Put the close button inside the child when the operator dismisses the window from its own content.
5. Leave host navigation buttons out of the child. A navigation action inside the child turns your pop-up into ordinary screen changing.

If a command in this dialog starts motion or writes a setpoint with consequences, keep the confirmation and the interlock in the controller. The window is presentation only.

How do you place and size the screen window on the host screen?

Place the screen window object on the host, set its position and its display area in pixels, and assign the control screen to it; a fixed assignment is right whenever the window always shows the same content.

1. Insert the screen window object and set its position and size in pixels. Keep at least 20 px of clear space to the panel edges so the window reads as a dialog.
2. Assign the control screen with a fixed assignment. Use tag-driven selection only when several control screens share one window, and give that selection its own tag.
3. Configure the tag updater under the window's event settings only for the tag-driven case. Selection and visibility are separate functions; skip tag-driven selection when you only need to show and hide one window.
4. If the host runs in portrait, settle HMI portrait panel fit before you commit the layout, because window coordinates follow the panel orientation.

If this host panel is also going into a cabinet door, the physical opening is a separate job; flush mount and real cut-out sizes covers it.

How do you open the pop-up from a button?

Give the trigger graphic a click action of Open in screen window and point it at the screen window object on the host, never at the control screen itself; that one setting is the difference between a pop-up and plain navigation.

1. Select the trigger graphic on the host.
2. Under its click event, choose Open in screen window.
3. Point the action at the screen window object by name.
4. Set the visibility tag in the same action, or let the action switch it, then run it once in the simulator.

Most failed builds land in this table:

How do you close the pop-up and reopen it later?

Drive one Boolean visibility tag: the open button sets it, the close button clears it, and the screen window's visible property is bound to it, so open, close and reopen all work through a single observable state.

A script is optional. If you use one, keep it to two lines, set the window visible on open and clear it on close, and take the property names from the help installed with your exact software version, because identifiers differ between product lines and versions. When a property refuses to set, diagnosing popup window property scripting walks that failure.

Reopening needs no extra logic: the fixed assignment reloads the same control screen. Keep selection, visibility and process commands as three separate items, so each state can be forced and tested on its own.

One limit to plan for: the window is not modal. The host stays live behind it, so an operator can still touch host controls while the dialog is open. If the task requires the host to be locked, enforce that with HMI screen access control or in the controller.

Worked example: how does a 400 x 300 pixel window fit a 1280 x 800 panel?

A recipe edit pop-up on a 1280 x 800 panel works with a 400 x 300 pixel window placed at x = 800, y = 400, which leaves 80 pixels to the right edge and 100 pixels to the bottom.

Run the arithmetic before you draw anything:

• Window edges: 800 + 400 = 1200, so 1280 - 1200 = 80 px to the right edge; 400 + 300 = 700, so 800 - 700 = 100 px to the bottom.
• Interior: a 40 px title bar carrying a 40 x 40 px close button, and 20 px of margins, leaves 400 - 20 = 380 px of width and 300 - 40 - 20 = 240 px of height.
• Rows: 240 / 40 = 6 rows of controls at 40 px each. Two setpoint fields, one start button and one status line take four rows, with two spare.
• Text: 24 px capitals on a 96 px per inch panel are 0.25 in tall, which reads to 0.25 x 30 = 7.5 ft at the FHWA planning figure of 30 ft per inch of letter height. Call it 7 ft, comfortable for an operator standing at the panel.

The same arithmetic in reverse sizes smaller dialogs: three control rows plus the title bar need 40 + 20 + 3 x 40 = 180 px, so a 400 x 200 window carries them with room to spare.

How do you check the finished pop-up end to end?

Run five checks with the visibility tag forced both ways in the simulator: the host content stays active, the window opens with the right content, each child control moves its tag, close hides the window, and reopen shows the same screen.

1. Force the tag false and open the host. The process display runs, no window shows.
2. Force the tag true. The assigned control screen appears inside the window boundary.
3. Operate each child control. Its process tag moves through its normal logic.
4. Clear the tag. The window hides and the host never navigates.
5. Set the tag again. The same control screen returns with no stale content.

Recommendation: use a fixed screen assignment plus one Boolean visibility tag whenever the window always shows the same content, and reserve tag-driven selection for windows that must swap between several control screens; keep selection, visibility and process commands separate so each state can be forced and tested on its own.

When the plant also wants a notice board that runs without the machine, shop-floor screens are a separate and simpler job.

Questions