Replacing the zenon Login Dialog with a Custom Login Screen

In zenon 6.51 SP0 Build0, the built-in login dialog appears whenever an operator presses a function above the current authorization level. That dialog belongs to the temporary login feature, which is on by default. You can replace it with your own screen of screen type Login, but three problems are common. The runtime refusal message fires before your screen opens. The custom login does not re-execute the refused action. The operator lands on a blank display if the Login screen shares a frame with the process screen.

What is each runtime message telling you?

Each of these symptoms points to a specific setting. Two families of fault apply. Binding faults mean the custom screen never opens: a missing system variable, limit, or function link, or temporary login still active. Authorization faults mean the screen opens and the login succeeds, but the action is still refused.

Which login mechanism fits: the temporary dialog or a custom Login screen?

Two configurations work in 6.51. They behave differently, not just visually.

Recommendation: use a custom Login screen when operators work in sessions, such as a shift login that stays active and is ended by logout or auto-logout. Keep the temporary login when the use case is a one-off authorized action, such as a supervisor approving a single command. Only the temporary login executes the refused action and drops the rights afterwards.

In 6.51 you cannot combine a user-defined screen with temporary login functionality. A reserved-screen-name mechanism for a custom temporary login screen was planned for a later version, similar to the reserved names used for keyboard screens. Check the online help (F1) of your installed version before you design around this limit.

How do you build the Login screen so it doesn't leave a blank display?

Every runtime screen is displayed in a frame. The frame sets its size and position. On a single monitor, a frame shows only one screen at a time, so two screens visible at once need two frames.

A Login screen closes itself once the login succeeds. If it was opened into the main frame, it replaced the process screen, and closing it leaves the frame empty. If it was opened into its own frame, the process screen underneath becomes visible again.

1. Create a dedicated frame for the login. It can be full-screen resolution or a smaller popup frame positioned over the process area.
2. Create a new screen, set screen type to Login, and add the default control elements (user name, password, confirm).
3. Assign the new screen to the login frame, not to the frame used by your process screens.
4. Design the layout freely. The detailed element reference is in the online help under Manual → User administration → Operating during Runtime → Screen type Login.
5. Create a screen-switch function that opens this Login screen. You will link it to the no-authorization variable next, and you can also put it on a dedicated Login button.

How do you route a refused action to your custom Login screen?

With temporary login active, zenon always shows its own dialog, whatever else you configure. Turn it off, then use the runtime's no-authorization signal to open your screen.

1. In project properties, category User administration, deactivate temporary login. The standard login mask no longer appears when a user lacks the level for a function, or when no user is logged in.
2. Create a system driver variable of type BOOL from the Project info category. It is named "no authorization to execute function" (sometimes described as "invalid user authorization"). The runtime sets it when an operator triggers a function without the required level.
3. On that variable, configure limit value Limit [2] as a maximum of 1. Link the screen-switch function that opens your Login screen.
4. In project properties, category Runtime settings, section Runtime messages for, deactivate erroneous input. This stops the "You are not entitled to execute this function" message from appearing ahead of your screen.
5. Compile the runtime files, transfer them, and reload the runtime.

Step 4 involves a tradeoff. The same checkbox also suppresses the "Invalid Password" dialog, so a mistyped password produces no visible response.

• If operators need explicit wrong-password feedback, leave erroneous input enabled and accept the refusal message before the custom screen.
• Otherwise, disable it and make the result obvious on your Login screen and the screens behind it. For example, display the logged-in user and active levels so the operator can see whether the login took effect.

Train operators on the changed behavior. After a successful login through the custom screen, the protected button must be pressed again. The user then stays logged in until logout or auto-logout.

Why is a level 10 user refused on a level 0 function?

Each zenon authorization level stands on its own. A user holding level 10 has level 10 only, not levels 0-9. Consider a project where the default state is level 0, a button requires level 10, and a user is granted only level 10. That user passes the level 10 button but can be refused anything restricted to a lower, ungranted level.

• Grant every level a user needs, explicitly, in user administration.
• An administrator can only assign levels that the administrator holds. If a level cannot be assigned in runtime, check the administrator's own level list first.
• User administration data can be changed in runtime. Treat it as runtime-changeable data: when you transfer new runtime files from the Editor, check whether the transfer overwrites users and passwords changed in runtime, or is overridden by them.

How do you move or resize the default temporary login dialog instead?

If the temporary login behavior is required and only the dialog placement is the complaint (for example, it covers process values), keep the feature enabled. Reposition the dialog in zenon6.ini:

[BEFEHLSGABE]
POSITION=0.020, 0.799, 0.635, 0.764

The four values are, in order: x position left, x position right, y position top, y position bottom. The example uses fractional values, so the dialog is placed relative to the screen area. Adjust them on the target panel and check the result at the runtime resolution. This option changes position and size only; the dialog's look stays the zenon default.

What can you do when a user password is forgotten?

zenon cannot recover a forgotten password; security design prevents it. Reset the password instead, at the level where you still have access.

1. In the zenon Editor, open the project that owns the user. In a multi-project, work in the correct subproject. Assign the user a new password.
2. Recompile the runtime files.
3. Transfer the new runtime files to the runtime computer, taking the runtime-changeable data behavior into account so the transfer actually replaces the user data.
4. Reload the runtime and log in with the new password.

How do you confirm the custom login works end to end?

1. Start the runtime with no user logged in, at default level 0.
2. Press a button that requires a level the current state does not hold. Confirm the standard zenon dialog does not appear. If it does, temporary login is still active.
3. Confirm that no "You are not entitled to execute this function" message appears (if erroneous input was disabled). Confirm that your Login screen opens in its own frame. If nothing opens, check the system variable, its Limit [2] maximum of 1, and the linked screen-switch function.
4. Enter a wrong password and note the feedback. With erroneous input disabled, there is no "Invalid Password" dialog; confirm this is the behavior you chose.
5. Enter the correct credentials. The Login screen should close and the process screen should remain visible behind it. A blank frame means the Login screen is still assigned to the main frame.
6. Press the protected button again and confirm the function executes. If it is refused, check that the user holds that exact level.
7. Log out, or wait for auto-logout. Press the protected button once more and confirm the Login screen opens again, which proves the rights were dropped.

FAQ