Display the current user on an HMI with PLC-managed login state

Check for a built-in current-user value first

Search the manual for your panel model before you build anything. Many HMI software packages expose a current-user value once a user-management system is configured, and some also keep a security log that records who signed in, when and from where. If your software documents a current-user value, use it, and keep the who-did-what record in its security log. If it documents none, build the PLC-managed login below.

What you need

• A Panel to PLC area with three items: a login request bit, a numeric entry for the employee number, and a masked entry for the PIN so it shows as dots or asterisks on screen.
• A PLC to Panel area with three items: a session state word, a numeric ID tag, and a heartbeat counter the panel increments.
• A roster in the PLC holding employee numbers 1000 to 9999, which gives 9,000 usable IDs, with 0000 reserved to mean no session.
• A heartbeat pace: the panel adds 1 to its counter every 1 s, and the PLC times that change.

One caution, once: a credential carried on an ordinary tag is readable by anyone who can open the project or watch the network. Where the machine's risk assessment demands protected credentials, use the panel's own user management and its security log for that machine.

Build it in this order

1. Fix the state word: 0 logged out, 1 request pending, 2 authenticated, 3 rejected. Display logic and screen access both read this one word.
2. Build the entry objects: a numeric entry writes the employee number and a masked entry writes the PIN into the Panel to PLC tags, and the login button sets the request bit for one scan.
3. Write the validation rung. On a rising request bit with the state at 0, the PLC moves the state to 1, compares the number and PIN against the roster, the same check as verifying HMI employee login numbers against a PLC roster, and on a match copies the number to the ID tag and moves the state to 2.
4. Count the failures: each mismatch adds 1 to an attempt counter, the third mismatch moves the state to 3 and starts a 10-minute lockout timer that refuses every request until it finishes, and a successful login resets the counter to 0.
5. Gate the screens with the same word: a protected screen is reachable only while the state reads 2, the pattern in locking HMI screen navigation while a bypass tag is on. Gate the commands behind the screen in the PLC as well, because the screen is only a window.
6. Add the heartbeat: a PLC timer with a 5 s preset resets on every change of the panel counter and, when it finishes, moves the state to 0 and zeroes the ID. Five missed writes at a 1 s pace trip it, so a dead link clears the session within 5 s; a 2 s panel pace moves the preset to 10 s.
7. Handle logout and start-up: a logout bit moves the state to 0 and zeroes the ID, the same zeroing runs whenever the PLC starts, and the panel project begins with the state word at 0 so no session survives a restart.
8. Record the identity where it matters: copy the ID tag into the event record at the moment of the action, the pattern in operator identity in HMI alarm records.

Example: a filling line with three operators

Three operators hold numbers 1042, 1077 and 1099, each with a 4-digit PIN.

The PIN space decides the guessing math. Four digits give 10,000 combinations, and the 10-minute lockout allows 3 tries per window, so a day holds 24 h at 6 windows per hour, or 144 windows, and guessing is bounded at 3 x 144 = 432 tries per day. Covering all 10,000 combinations at that rate takes 10,000 / 432 = 23.1 days. A 6-digit PIN moves the space to 1,000,000, and the same rate then needs 1,000,000 / 432 = 2,315 days, about 6 years. PIN length is the lever, and the lockout is what holds the rate to 432 per day.

Operator 1042 signs in at 10:02. The request bit rises for one scan, the state runs 0 to 1 to 2, the ID tag reads 1042, and the display object shows 1042 for exactly as long as the state reads 2. She logs out at 10:31, the PLC zeroes the ID, and the screen empties.

At 10:45 the panel's network cable is pulled. The last counter change arrives at 10:45:00, the 5 s timer finishes at 10:45:05, the state drops to 0 and the ID to 0, so the display clears within 5 s of the break. No request is honored until the link returns and a fresh login passes.

Recommendation: Use the panel's own current-user value wherever the software documents one, and keep the record in its security log. Where it documents none, run the login through the PLC with the tag map above, show the ID only while the session state reads 2, and set the heartbeat timer to five panel write cycles, which is 5 s at the example's 1 s pace.

How to check it worked

Run these six as pass or fail before operators get the panel:

• Valid login: 1042 with the correct PIN moves the state to 2 and the display shows 1042.
• Rejected login: a wrong PIN three times moves the state to 3, the display stays empty, and every request is refused until the 10-minute timer finishes.
• Logout: the ID returns to 0 and the display empties within one panel write cycle.
• Lost link: pull the cable and time the screen; it clears within the heartbeat preset, 5 s in the example.
• Restart: power-cycle the panel, then the PLC; the state word begins at 0 and no name shows.
• Protected access: with the state at 0, the protected screen does not open and the commands behind it do not fire.

A name that updates on screen is not a release test; the state word is. The decision in one line: a documented current-user value means use it, and no such value means the PLC owns the login while the panel shows only what the PLC returns. More login and screen patterns for shop-floor panels sit in the factory screens and andon boards section.

Questions