Password popup on screen change after passwords deleted

Where the leftover requirement lives

The password list holds the credentials. The requirement to enter one is a property of the object guarding the move: the destination screen can carry a security option in its own settings, and each screen-change pushbutton can carry its own Password setting. Removing all passwords from the list empties the credentials but leaves those properties in place. The confirmed case ended exactly there: every password definition was deleted, and the buttons still demanded one.

So audit objects, not the list. Open the project, list the pushbuttons whose action changes to the screen that prompts, and check two things for each path: the button's Object properties, then Password, and the destination screen's screen option.

Symptoms and what each points to

• The password entry box appears on entry to one screen, on every attempt, with no passwords left in the project: a leftover gate on a pushbutton that reaches it, or in the screen's own screen option.
• One button prompts and the other buttons into the same screen do not: that pushbutton's Password property is still set.
• You deleted every password definition and the prompt stayed: the requirement sits on the object, so work through the buttons and the screen option.
• A prompt appears when someone edits a parameter, and one password then opens every screen at once: that is a different fault, covered in HMI parameter edit password that opens every screen at once.
• A press is refused outright, with no prompt at all: check the controller side before the panel; the PLC password that blocks HMI button presses case covers that pattern.

Clear the pushbutton's Password property

1. Open the project and go to the screen that holds the pushbutton used to reach the screen that prompts.
2. Right-click that screen-change pushbutton and open Object properties.
3. Select Password and remove the setting from the button.
4. Repeat on every screen that holds a pushbutton leading to the guarded screen.
5. Download the project to the panel once, then retest each path.

If the pushbuttons themselves are new to you, Set up HMI screen navigation with change screen buttons walks through the button side first.

Check the screen's own security option

Right-click the screen in the navigator and select screen option. Inspect its security setting and clear it if a requirement is still enabled there. The order matters for speed, not for correctness: the confirmed case ended at the buttons, so check them first. The screen option is the one remaining point when every button path comes back clean.

Screen gate or button gate: choose the scope on purpose

To the operator the two gates look the same: navigation stops until a password is entered. The difference is scope. A screen option requirement guards the destination, whatever route the operator takes to reach it. A pushbutton Password guards that one control only. Choose by what you want covered: screen option when the restriction belongs to the screen itself, button property when only one entry point should be restricted. If a project uses both, both have to be inspected, because clearing one leaves the other in place.

If what you need is navigation that locks under plant conditions without a password at all, Lock HMI screen navigation while a bypass tag is on covers the tag-driven version.

One safety point: if the screen guards settings that affect machine safety, keep a gate somewhere on the path and record who holds the password. Removing the last gate from a parameter screen is an access decision, not only a convenience fix.

Example: a 6-screen project where one screen still prompts

Inputs: the panel project has 6 screens, an illustrative size for a small line panel, chosen to make the count concrete. One screen prompts on every entry, which is the documented symptom. Three screen-change pushbuttons lead to it: 2 on the main menu, 1 on a diagnostics screen. The documented check names 2 configuration points per destination: the Password property of each path's pushbutton, and the screen option security setting of the screen itself. Walking 3 paths, checking 1 property each, plus the screen check fits comfortably in the 15-minute budget above.

Rule: a leftover requirement can only sit in a Password property on one of the 3 path pushbuttons, or in the screen's 1 security option. The audit is therefore 1 property check per path button plus 1 screen check.

Arithmetic: 3 paths x 1 Password property = 3 button checks. 1 screen x 1 security option = 1 screen check. Total: 3 + 1 = 4 checks. Inspection finds Password still set on the 2 main-menu buttons; the diagnostics button and the screen option are clear. Settings to clear: 2.

Result: clear those 2 button properties, download the project once, retest all 3 paths within the same 15 minutes, and the count of password prompts on entry is 0.

Decision: with every button property on every path clear, the threshold is simple. Any prompt left on entry means the requirement sits in the screen's own option, 1 setting remaining, in screen option. A clean button that still prompts is the signature of the screen-level gate.

Retest, then hand it over

Download the edited project once, then walk every navigation path that used to prompt: press each pushbutton in normal run mode and count the prompts. The target is 0 on every path. Test any alternate buttons into the same screen too, because a second route with its own leftover Password property will bring the box back on that route only.

Recommendation: clear the Password property on every screen-change pushbutton that reaches the prompting screen before touching the screen's own option; if the prompt survives a full set of clean buttons, clear the security setting in screen option as well, and keep a gate in place on any screen whose settings affect machine safety.

Questions