Why an HMI popup inside a popup fails and what to design instead

Why does a popup inside a popup fail?

It is a design limit. On the HMI runtimes that refuse nested popups, a popup command fired from inside an open popup has no effect, and the second window never appears. No change to the trigger, the timing or the window size makes it appear.

The limit sits in the runtime layer that draws screen windows, so editing the second popup's trigger type, its delay or its window rectangle changes nothing. Your platform's manual is the contract: it either documents one popup layer per screen or documents how the runtime manages several popup windows, and the release notes for your build say which one you have. When the manual is silent and the screen refuses the second window, design for one popup layer and move everything else onto separate layers with their own visibility logic.

What do the symptoms point to?

Three faults look alike, and each has its own check: a window that never appears anywhere is a trigger or address fault, one that opens alone but never from inside the parent is the nesting limit, and one that outlives the parent is missing state logic.

• The second window never appears, even from a plain screen. Work the trigger and its address first; the order to check is the same one behind a numeric display that shows nothing.
• The window opens on its own screen but never from inside the first popup. That is the nesting limit. Stop tuning the trigger and move to the separate-layer design below.
• The window opens with the parent and stays after the parent closes. Its visibility follows its own trigger, so tie it to the parent's state as described further down.
• A popup from an earlier screen shows up where it was never called. That is leftover state, the same family as a password popup that appears on screen change, and the cure is the same: find what sets it and clear it on every path.

How do you test the second display on its own first?

Copy the second display onto a plain test screen and give it its own trigger before concluding anything: if it opens and closes there, the display, its tag and its trigger all work, and the only remaining fault is the nesting limit itself.

1. Save a copy of the project under a new name so the production screen set stays untouched.
2. Copy the second display, with its objects, tag and trigger unchanged, onto an unused screen.
3. Download the test project to a test panel or offline runtime and fire the trigger twice, once to open and once to close.
4. Read the result. It opens here: the display is sound and nesting is the fault. It stays blank: the fault is in the trigger or its address, and the redesign would have been built on a broken display.

What do you design instead of a nested popup?

Keep the first popup as the operator's parent window, and give the secondary content its own layer or dedicated screen controlled by one boolean state bit: the bit is set in the same logic that opens the parent and cleared in the same logic that closes it.

Remove the nested popup call from the parent; the parent keeps its own open and close actions and nothing else changes. Name the bit once, for example parent_popup_active, and make it the single switch every object in the secondary content binds to. If your platform exposes the parent popup's active state directly as a condition source, bind to that and skip the extra bit; the manual lists what a visibility condition may reference. Edit and download from the editor, and put the revised project on the panel only when the line is stopped or in a state that tolerates a screen change.

How do you tie the second layer to the first popup's state?

Bind the child's visibility condition to the state bit as a level, and set and clear that bit in the same logic that opens and closes the parent popup, so the child's visible time is exactly the parent's visible time.

A visibility condition follows a value that holds, so a level works; a pulse that lasts one scan can come and go between screen updates, which is why an R_TRIG pulse never shows on the HMI screen even when the logic behind it is correct. If the editor applies visibility per object, group the child's objects or repeat the condition on each one; your editor's manual says which. If the child needs its own dismiss button, add that choice as a second term in its visibility condition so the parent bit can still hide it.

What does a working example look like?

A packing line needs a reject-detail popup with a scrap-reason panel. On a 1024 by 768 pixel panel, an 800 x 600 pixel parent popup and a 400 x 300 pixel reason panel share the screen through one boolean tag, and the panel disappears the moment the popup closes.

Side by side, the two windows need 800 + 400 = 1200 pixels of width, more than the screen's 1024 pixels, so the reason panel sits on top of the parent's area instead of beside it. The centered parent leaves (1024 - 800) / 2 = 112 pixels of margin on each side and (768 - 600) / 2 = 84 pixels above and below. The 400 x 300 pixel panel fits inside the parent's 800 x 600 pixel rectangle with room to spare.

The tag is a boolean named parent_popup_active with an initial value of false. The parent's open logic sets it; the parent's close logic clears it; the reason panel's visibility condition is the tag alone. The result: the panel is visible exactly while the popup is, and closing the popup hides the panel with it.

The same one-bit pattern runs a fault banner and its detail panel on shop-floor screens and andon-style boards, anywhere two layers have to live and die together.

How do you prove the fix in both directions?

Run two tests, open and close, three times each: opening the parent must show the child layer, closing the parent must hide it, and the third pass exists to catch a stale state that survives a reopen.

1. Fire the parent's trigger. The popup opens and the child layer appears with it.
2. Close the parent with its own control. The child layer disappears on the same screen update.
3. Repeat both steps until you have run them three times. A pair that fails on the second open has the stale-state fault from the symptom list, not the design.
4. Close the parent from every path the design offers, including a screen change and a fault reset if the design has one. The close logic must clear the bit on every path, because the child follows the bit, never the window.
5. Land on the base screen and confirm neither layer is visible before operators take the line back.

Recommendation: retire the nested popup for good: one parent popup, one separate child layer, one boolean bit that the parent's open and close logic drives on every path, and a three-pass open and close proof on a test panel before operators see the screen. Keep a temporary restore, where the nested call is removed and operators reach the second display from the base screen, only until the tagged design is downloaded and passes that proof.

When should you stop editing and ask the vendor?

Stop editing and write to the HMI vendor when the second display fails even on its own trigger, when no visibility condition can reference a tag or another window, or when editor and panel runtime versions differ, and send the version, build and the sequence that reproduces the failure.

The editor's Help or About menu shows the software version and build; attach the saved project and ask one question: does this release open a popup from inside another popup. Where the release notes document nested popups as supported, follow their documented pattern. Where they refuse it, the separate-layer design on this page is the repair.

Questions