Give each operator an individual HMI account and keep one shared screen of nine tank buttons. Configure the alarm or event history to store the account name, the button tag and the timestamp together. Do the capacity math before day one: a history capped at 64 events that takes 20 presses a day holds about three days, so export on a schedule that beats it.
You do not need 45 buttons, and you do not need a second password, to put an operator's name on a tank selection. You need three things working together: one account per operator in the panel's user management, one shared screen with nine tank buttons, and an event history that stores the signed-in account, the button tag and the timestamp in one record. A log entry with a tag and a time but no account answers the question of who pressed it with nobody. A second password prompt hides that gap, because a prompt is not an identity the log can carry. Set the three pieces up in the order below, run the two-operator test before the first shift, and every press lands with a name on it.
One sign-in, one screen, one log
Identity and permission are two different decisions. The account answers who pressed the button; the group answers what that account may do. Five machines with up to five operators each means up to 25 accounts across the line and five per panel, all sitting in one permission group while every operator may draw from every tank. If the group cap your manual prints is eight, this design fits under it: one group for full control, a second only when a tank gets restricted.
The screen follows the same arithmetic. Nine tanks need nine buttons. One row per operator multiplies 9 x 5 to 45 buttons that all write the same nine tags, and an operator-select button that reveals one row changes what is visible without changing what a press writes. Set the three designs side by side:
| Screen design | Objects on screen | What the record can name | Prompts per press |
|---|---|---|---|
| One row of 9 tank buttons per operator (9 x 5) | 45 | Tag and time; an operator only if each button also writes a number | One password |
| Operator-select button reveals one row of the 45 | 45 built, 9 visible | Tag and time; a screen selection is display state, so no account | Two passwords |
| One sign-in, one shared row of 9 buttons | 9 | Account, tag and time from the event history | One sign-in |
The third design is the one that logs, because the account travels with the session and the history can read it.
What you need
- The two numbers your manual prints: the alarm or event history capacity in events, and the group cap in user management.
- User management in the HMI software that accepts one account per operator, and an alarm or event history whose records can carry the user, as a field or through a writable user tag.
- Nine tank select tags in the controller plus a press bit per tank, so each press is a discrete event the history can catch.
- An export path the manual documents for the log: the panel's USB port or a network path.
- Five employee numbers per machine and a password chosen for each.
Setup steps
- Create one account per operator. Five accounts per machine, each with its own password. Put every account in the same permission group for now.
- Cut the array down to one row. Keep the nine tank buttons and delete the other four rows. Each button writes its tank number to the tank select tag and pulses its press bit.
- Put the tank screen behind sign-in. Signed out, the panel shows the sign-in screen; signed in, it shows the tank row. This gives the crew one obvious session at a time. The enforcement is step 6.
- Add nine events to the alarm or event history. One event per press bit; the history stamps the date and time on each event automatically. Type the machine number and the tank number into the event message text, so an exported line reads Machine 2, Tank 7 with no cross-checking, and switch on the user field if the history offers one.
- Switch logging on and test the download path before day one. A history that was never logging downloads nothing; the article on why an HMI alarm history downloads only if logging was on is the trap that eats the first week of records. One press then lands as one record with one timestamp, the same pattern as recording job completion times with an alarm history.
- Enforce the selection at the controller. Accept the tank select write only while a session is open and the account's group allows that tank; the article on a PLC password that blocks HMI button presses covers the controller-side check.
- Set the export schedule from the capacity math. Retention in days equals capacity in events divided by presses per day, and the export interval is half of that. The worked example below runs the numbers, and the article on saving more than 64 alarms from an HMI history to USB covers the export itself.
Example: how long a 64-event history lasts
Machine 2 runs two shifts with five operators, and each operator draws from a tank about four times per shift. Presses per day: 5 x 4 = 20 events. Take 64 events as the stand-in for the capacity your manual prints.
Retention = 64 / 20 = 3.2 days. The history holds three full days and starts dropping the oldest records on the fourth, when the full history discards oldest first; the manual states which filling behaviour applies, and the article on a circular event buffer with separate pointers shows the bookkeeping that keeps PLC-side dropping predictable.
Half the retention is 3.2 / 2 = 1.6 days, so Machine 2 exports its log every day at shift end. The arithmetic is the whole decision: retention = capacity / presses per day, export at half of it. At a 200-event capacity and the same 20 presses a day, retention runs 10 days and the half rule puts the export at every 5 days.
How to check it worked
Run these on each machine with the crew's real accounts, before the first shift:
- Identity test. Sign in as employee 104, press Tank 7, sign out. Sign in as employee 212 and press Tank 7 again. The history shows two records with the same tank tag, two different account names and timestamps seconds apart. Both records under one account name means the user field is not wired into the event; fix that before the log earns any trust.
- Download test. Export to the USB stick or the network path and open the file on a PC. The exported record count matches the count on the history display.
- Rejection test. With no session open, force the tank select tag from the controller side and watch the interlock reject it; a hidden button rejects nothing. Run this one with the pumps idle, because a tank write is a process command.
When the three pass, the record answers who, what and when on every press. If the same wall also needs a tank status board the crew reads from across the room, that is a job for a separate shop-floor screen, not a second window on the HMI.
The decision
- Every operator may draw from every tank: one account per operator, 25 across the five machines, all in one group; one shared row of nine tank buttons; the event history storing account, tag and time; exports on the schedule the capacity math sets.
- Some tanks restricted: a second permission group plus the acceptance check in the controller. The screen stays one row of nine; visibility steers navigation only.
- Small history capacity: retention = capacity / presses per day, export at half of it, and when the interval drops under one shift, move the record to the file-based log the manual documents, because a history emptied every few hours is no record at all.
Recommendation: Give each of the 25 operators an individual account in one permission group, keep the single nine-button tank screen, and configure the event history to store the account, the tank tag and the timestamp on every press. Read the history capacity from the manual, compute retention as capacity divided by presses per day, and schedule the export at half the retention; at 64 events and 20 presses a day that is an export every day. Run the two-operator identity test before the first shift, and enforce any restricted tank in the controller.
Questions
Does the alarm history survive a power cut?
That depends on the panel, and the manual's alarm history section states it. Some runtimes keep the log in volatile memory and clear it on power loss; others write each event to storage. Test it before you rely on the log: fill the history with a dozen test events, switch the panel off and on, then count what is left. Set the export interval for the worse of the two documented behaviours.
Can the employee number work as the user name?
On runtimes whose user management accepts free-text user names, yes, and it keeps the record readable, because the log shows the number the crew already knows. Keep the password separate from the number. A badge number is visible to the whole floor, so it carries no secrecy; the password is the credential, and the number is just the name the record prints.
The event record has no user field. What now?
Check whether the runtime can write the signed-in user's name or number into a tag when a session opens, and add that tag to the fields the event stores or to its message text. Log the sign-in itself as well, so every run of entries between two sign-in events belongs to one operator. Verify the linkage with two accounts before the first shift.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.