Run reset logic when an HMI pop-up closes by any path

Why does the red X close a pop-up without running its reset logic?

Because the reset hangs on the push button object. The window's close and minimize controls shut the pop-up without ever running that button. The fix is to hang the resets on the pop-up's own state change instead of on one control.

Your "close panel" button is a panel object with a press event, and the reset actions live inside that event. The red X and the minimize control belong to the window frame; either one disposes of the window, and no panel logic runs on the way down. A pop-up carrying your button has 3 exit paths, and logic wired to one path runs on one path.

What each symptom points to:

• The button closes and resets everything; the red X closes and resets nothing. The reset is coupled to the button's press event and to nothing else.
• The window is gone but the base screen stays in its panel-open state, entry field still enabled, ladder still inhibited. The state writes ran on open and on the button press; nothing runs on a window close.
• The minimize control hides the window and the ladder stays inhibited. Minimize is a third exit path with the same gap.
• The pop-up springs back the instant it is closed or minimized. A reactivate is holding it on screen; the reset has still not run, and the hold hides that.

The shape of the fault:

Can the close button be hidden or covered on an HMI pop-up?

Some design tools let you switch the close button off in the pop-up's properties, but you cannot cover it with a plate. Panel objects will not sit on the pop-up's task bar, and hiding the X leaves the real fault in place anyway.

A log-in level that hides the menu bar and title bar hides the frame of the main window. The pop-up's task bar, the strip carrying the X, is not one of the bars a log-in level hides. The routes tried next, and their results:

• A plate or button drawn over the X. The placement is refused: objects sit on the panel's drawing area, and the task bar belongs to the window frame above it.
• Sliding the pop-up up until the bar sits outside the visible area. The X leaves the screen with it, the window can be moved back, and the reset gap is untouched.
• Switching the close button off in the pop-up's properties. Some design tools print exactly that property on a pop-up, and where your package has it, that is the supported route. On windows built by script the X comes from the window frame, and where the creation call offers no switch for it, the X stays.

Removing the X narrows the exits from 3 paths to 2, your button and the minimize control. Only a trigger on the pop-up's state covers every path, so treat removal as a policy choice, not the repair. If the window itself is still being assembled, start from building a pop-up screen with a screen window.

How do you prove which close paths run the reset?

Close and reopen the pop-up once by each of the 3 exit paths, the custom button, the red X, and the minimize control, and record which reset outputs change after each close. The pattern tells you which paths carry the logic.

Run this with the line idle, so a tag left set by a skipped reset cannot move the machine:

1. Open the pop-up and write down the state of every tag the close is supposed to reset: mode, field enable, inhibit flag, whatever your list holds.
2. Close it with the "close panel" button. Record which of those tags changed.
3. Reopen it and close it with the red X, then reopen it and close it with the minimize control. Record the tags after each close.

If the button path resets everything and the other 2 reset nothing, the logic is coupled to the button, which is the fault this page fixes. If even the button path misses actions, the reset logic itself is broken; trace the value path of the tags first, because rewiring a broken reset onto a new trigger produces a broken reset on the new trigger.

What signal changes when a pop-up closes, whatever closed it?

Use the pop-up object's active member: a state flag that reads 1 while the pop-up is displayed and falls to 0 when it closes, whichever of the 3 controls the operator used. A single falling edge covers every exit path.

The drop comes whether the operator pressed your button, the red X, or the minimize control, so one falling edge replaces three separate button checks. Firing an event on a tag's true-to-false transition is standard edge triggering; event triggering on a falling edge shows the same pattern in a desktop SCADA runtime.

Not every package names it an active member. Look for a window-state property, a visibility tag on the pop-up, or the current screen number, where the reset runs when the number leaves the pop-up's screen; the HMI current screen number tag covers that variant. Before you hang ladder resets on the member, repeat the 3 closes with it in the watch list and confirm 1 while open, 0 after each close, on the running panel.

How do you trigger the reset from that signal?

Create one trigger on the active member's falling transition, move every reset action the "close panel" button runs today into that trigger, and reduce the button's job to closing the pop-up. Then all 3 exit paths land on the same logic.

1. Write down every action the "close panel" button runs today: each tag, each value written, each side effect. The list becomes the acceptance test.
2. Open the pop-up object's member list and find the active member. Confirm 1 with the window open, 0 after each of the 3 closes.
3. Build one trigger on that member's falling edge. Where the editor offers transition triggers, pick falling edge. Where it offers value triggers only, build the detector in logic: this scan reads 0, last scan read 1. Rising and falling edge pulse generation is the same building block.
4. Move the reset actions from the button's press event into the trigger. All of them; the resets live in exactly one place.
5. Reduce the button's press event to one action, closing the window. How a button closes a pop-up depends on the package: one route is a Close method on the window object, another is a pair of script functions, with names like OpenScreenInPopup for opening and ClosePopup for closing. Use the call your package documents.
6. Save, download to the runtime, and run the acceptance test below.

Resetting a screen full of state from one control is the pattern in one demo button that turns every simulated light off; here the control is the pop-up's own state, so it fires with no press at all.

Why does the reset fire twice on the button path after the change?

Because the button still triggers the reset and the pop-up deactivating a moment later triggers it again. The repair is one trigger point, the falling edge, with the button doing nothing but closing the window.

The double fire happens when the reset actions stay on the button and the falling-edge trigger is added as a second source. The press fires one copy, the window closes, the member falls, the trigger fires the second copy: 2 executions of the same writes a few scans apart. The tag values read correct either way, because both executions write the same zeros. The double shows in side effects that accumulate: a close counter 1 high, 2 lines in the event log, a message queued twice. The worked example catches it with exactly such a counter.

The structural cure is one trigger point: every reset action on the pop-up's falling edge, and a single action, closing the window, left on the button. Where other logic reuses the button's press event, leave the shared parts on the button and move only the resets. The opposite fault also exists: the trigger fires on the first close and stays silent on the second, because the edge detector latched and never saw the member return to 1 on reopen. That is the same class of fault as a screen-change tag that will not fire twice. The repair sits in the reset path, the procedure in checking the reset path of a one-shot event.

Should the pop-up be kept open instead of resetting on close?

You can, by programming the pop-up to reactivate as soon as it is closed or minimized, which keeps it displayed on top. That is a display hold that leaves the reset unrun, so treat it as a stopgap only.

The reactivate route watches the pop-up and activates it again the moment it closes or minimizes, so the window never leaves the screen. It solves a different problem, keeping the operator's eyes on the panel. On its own it runs none of your resets, and while it holds the window you cannot tell from the screen whether the reset ran.

Once the resets hang on the active member, the two combine: every close attempt runs the resets, then the window comes back for the next attempt. That suits an alarm faceplate that must stay in view until its acknowledgment button is pressed, the pattern in showing an alarm as a pop-up message box. For a data-entry pop-up like a recipe screen, let the window close; forcing it open trains operators to fight the panel.

Worked example: filler-line pop-up closed 6 times in 10 minutes

A filler line recipe pop-up with 3 reset tags and 1 close counter, closed 2 times by each of 3 paths, should end the test with all 3 tags at 0 and the counter at 6 counts. Any other number names the fault.

Scenario: a filler line recipe pop-up. Opening it writes 3 things: a mode tag to 1 (manual), an entry-field enable to 1, and a panel-open inhibit flag to 1, which the ladder reads to block starts. The old "close panel" button writes the 3 tags back to 0 and adds 1 count to a close counter the shift report reads. 4 actions, 1 button. Before the fix, 1 of the 3 exit paths runs them: the red X and the minimize control run 0 of 3, and the inhibit flag stays at 1 with the window gone until someone reopens the pop-up and presses the button. After the fix, the 4 actions live on the member's 1 to 0 transition, and the button's only action is closing the window.

Acceptance test: 2 closes by each of 3 paths, 2 + 2 + 2 = 6 closes, run in about 10 minutes of idle-line time. After each close, read the 3 tags: 6 closes × 3 tags = 18 tag reads, each expecting 0. Read the counter once at the end: 6 closes × 1 count per close = 6 counts.

Reading failures from the numbers:

• One tag still at 1 after a red X close: an action stayed on the button; the action list moved across incomplete.
• Counter at 8 counts: the button path double fired. Its 2 closes each ran the actions twice, 2 × 2 = 4, plus 2 + 2 from the other 2 paths, 4 + 2 + 2 = 8.
• Counter at 6 counts but the second close by the same path stays silent: the edge detector latched; the repair is in the reset path, two sections up.

Recommendation: trigger every reset from the pop-up's active member falling from 1 to 0, and reduce the "close panel" button to a single action, closing the window. Commit to that wiring whenever more than one control can close the pop-up. Switch the close button off in the pop-up's properties only where the package documents that property and the procedure demands one visible exit, and keep the falling-edge trigger even then, because the minimize path remains.

Questions