HMI login and logout buttons: build them without a session model

Why there is no login button to add

Two password designs sit behind this. In a session design, one login opens every protected object until logout or a timeout, so the software ships login and logout buttons as standard selections. In an object-password design, the password travels with the object: touch a protected object and the prompt appears, enter it and that one action proceeds. Authorization lasts for the action, so there is no session state for a logout button to clear, and none is offered.

Vendor documentation draws the same line. One package's example for configuring a button with access protection attaches the authorization to a button whose event is a screen change, which is the login half documented step by step. Another's support note answers the object half: a single display element has no direct password setting, and the element's visibility property, addressed to a PLC bit, is the documented way to show it only while the bit is on.

Both halves are all you need. The login is the gate, the logout is the route back, and neither exists until you build it.

Pick the login pattern

Match the pattern to what the authorization is for. Values that deserve a check on every single edit keep their own passwords. A stretch of setpoint work belongs behind one gate: prompt once at entry, and nothing prompts again until the operator leaves the protected set. Adjustments that must live on a screen operators otherwise use follow the enable bit, because the bit can turn on and off while the screen stays put.

What you need

• One protected screen holding every object the authorized task needs, or the existing screen whose objects will follow a visibility bit
• One entry button on the home screen, with the password or authorization attached to its screen-change event
• One return-to-home button, labeled as the way out, on each protected screen
• For the PLC pattern: one internal PLC bit the panel can write, and an on-delay timer sized to the access window
• Event log entries on the entry and exit screen changes, if anyone will ask who was in the setpoints and when

Build the login on a protected screen

1. Create the protected screen. Put every setpoint and data display the authorized task needs on it, including copies of any operator values the editor must watch while adjusting, so nobody exits and prompts again just to read a process value.
2. Add a screen-change button on the home screen that targets the protected screen.
3. Attach the password or access authorization to that button's screen-change event. The authorization rides on the button; the objects behind it stay open. Our article on password protecting an HMI setpoint screen at entry walks the button side in detail.
4. Leave the navigation buttons inside the protected set without passwords, so one prompt covers the whole task.
5. Keep every route into the protected set running through that one button. Any second path that arrives without a prompt is a hole in the gate.

Build the login with a PLC enable bit and a timed window

1. Create one internal bit in the PLC, of a memory type the panel can write, at an address you have confirmed in your project.
2. Add the entry button on the panel, attach the password to it, and make its press event set the bit.
3. Start an on-delay timer in the PLC from that bit and size the preset to the longest task the window must cover. The worked example below uses 300 s.
4. Wire the timer's done bit to reset the enable bit, so the window closes itself.
5. Address each adjustment object's visibility property to the enable bit. This is the documented substitute for an element password: the object shows while the bit is on and hides when the bit drops. Our article on gating HMI button visibility on a PLC timer done bit shows the same idea driven by the timer's done bit.
6. Give a second press of the entry button a rising-edge reset of the timer, so an operator can extend a window that is about to close.

Build the logout

The logout button is a screen-change button back to the home screen, labeled so operators know it ends the authorized period. Put it in the same corner on every protected screen and nowhere else, so the way out is the same motion every time.

With the protected-screen pattern, that return is the entire logout: the operator leaves the protected set, and the next protected action prompts again.

With the PLC pattern, add one step. Have the logout press clear the enable bit and reset the timer, so the visible adjustments disappear at once instead of waiting out the window. A second HMI-written bit, or the screen-change event itself, can drive that reset in the ladder.

Send both screen changes to the event log if anyone needs entry and exit times.

A logout that fires on its own after no input is a different build. It needs a signal or mechanism that detects inactivity and starts or resets a timeout, which our article on returning an HMI screen to home after an idle period covers. The fixed window above is not that: it closes when the timer expires even while the operator keeps touching the panel.

Example: a 5-minute adjustment window on a bottling line

Scenario. A bottling line's recipe screen holds eight setpoints that operators otherwise never touch, and the adjustments must stay on the screen operators already use, so you build the PLC pattern.

Numbers. The longest authorized task, a recipe change, takes about 3 minutes. Size the window to the longest task with margin and choose 5 minutes: 5 min × 60 s/min = 300 s. If the controller's timer runs on a 0.1 s time base, the preset is 300 s ÷ 0.1 s/count = 3000 counts; on a 1 s base it is 300.

Run-through. At 07:42 maintenance presses the passworded Adjustments button. The prompt accepts, the PLC sets the enable bit, and the eight setpoints appear, with the timer starting on the same edge. At 07:42 plus 300 s, which is 07:47, the done bit turns on, resets the enable bit, and the setpoints hide. Nobody was prompted after entry, and nothing stayed adjustable once the window closed.

Extension. If the recipe change runs long and maintenance presses the entry button again at 07:46, the rising edge resets the timer before the 07:47 expiry, so the setpoints stay and the window now closes at 07:51. The password was asked for once in total.

Check it before the line runs

Run the project simulation first, then repeat every check on the panel with the PLC connected.

• Press the entry button with a wrong password and confirm the protected screen never appears, then press with the right one and confirm it does.
• On the PLC pattern, watch the enable bit and the timer while you press. If the screen changes but the bit never sets, the fault is the tag mapping, so correct the address before touching anything else.
• Let a window expire with no second press and confirm the adjustment objects hide at the preset.
• Press the logout button, confirm the return home, and read the event log back: it should show the entry and the exit with times.
• Try to reach the protected set from a second screen: any path that bypasses the entry button must be closed off.
• Attempt a value outside the process limits while an adjustment object is visible. The PLC, not the panel, must enforce the limit and refuse it, because a hidden object is screen furniture and visibility is not a guard.

The decision

One boundary first: the login and logout logic belongs in the panel project and in the PLC. A notice or status board mounted beside the machine is a different screen with a different job, and that is the kind of display we build; the shop-floor screens and andon-style boards category is where those live.

Recommendation: build the login as one passworded screen-change button to a protected screen and the logout as a labeled return-to-home button in the same corner of every protected screen; that handles most setpoint work with a single prompt per task. Use the PLC enable bit with a 300 s window when the adjustments must sit on a screen operators stay on, and set the preset from your longest task the way the example does: 3 minutes of work gets 300 s. Keep per-object passwords for the rare value that deserves a prompt on every edit, and add inactivity detection only when an unattended panel has to walk itself home.

Questions