HMI parameter edit password that opens every screen at once

6 min read · Published November 6, 2026

Give operators number displays tied to each parameter, and make the number-entry objects visible only while a shared edit-enable state is true. The supervisor signs in once with the HMI password feature, the state goes true, and every entry object on every screen appears. A lock button, an inactivity timeout or a restart sets it false again.

Give operators a read-only number display for every parameter they watch, and keep the number-entry object for that same parameter hidden until a supervisor password turns one shared edit-enable state true. One sign-in then opens the entry objects on every screen at once, so the supervisor never types a password at each field, and no keypad pops up when an operator only wants to read a value. The steps below build the pattern, and a 60 Hz drive reference walks the full cycle: locked, open for editing, edited, relocked.

How the pattern separates viewing from editing

Two object types do the work. A number display reads a tag and shows the value; a touch has no keypad and no write. A number entry shows the same value, but a touch opens the keypad and writes the typed number back to the tag. That write-to-tag behavior is the documented job of a numeric input object, and it is the same path an HMI uses when it changes a PLC timer preset from a screen.

The gate is the visibility connection most HMI editors give every object: a tag or expression that shows the object while it is true and hides it while it is false. One editor labels the property Visibility Tag. Put display and entry object on the same tag, in the same screen position, and feed every entry object's visibility from one project-wide boolean. Operators see the value either way. Only the entry object appears and disappears.

Two routes set that state:

  • Role route: connect visibility directly to the signed-in user's role. Many HMIs publish the signed-in user as a system tag; one calls it Current User. No extra tag is needed, but each object's condition mentions the role.
  • Tag route: create one boolean, set it true from the sign-in action for the supervisor account, and point every entry object at it. One tag feeds every object, which is what makes one password open every screen.

Screen-level role rules are a different layer. Screen access control covers that layer; this pattern gates objects inside a screen.

What you need

  • The parameter list: every tag operators watch but may not change, taken from the machine's parameter table.
  • One number display and one number-entry object per parameter, both connected to the same tag.
  • One boolean tag for the whole project. The example below calls it Edit_Enable, type BOOL, power-up value FALSE.
  • The supervisor account and the password or user feature of the HMI software, usually under users, roles or security in the project tree.
  • A lock action: a button that writes FALSE, plus the session or inactivity timer if the software has one.
  • The drive or controller nameplate range for each parameter, and the original tag values written down before the first test.

Build it in six steps

  1. Give every operator screen a display per parameter. Put a number display on the parameter tag wherever operators only watch the value. If a number entry sits in that spot now, leave it where it is; step 2 turns it into the hidden edit control. The operator keeps the value and loses the keypad. Keep the display-and-entry pair identical everywhere, so several machines sharing one panel design behave the same.
  2. Gate the entry object. On each parameter, set the number entry's visibility connection to Edit_Enable, visible only while the tag reads 1, in the same position as the display. Give the entry object a distinct border or color so a supervisor sees at a glance which fields are live.
  3. Create the edit-enable tag. BOOL, power-up value FALSE. The power-up value is what relocks every screen after a restart, before anyone has signed in.
  4. Set it true at sign-in. If the HMI software documents an action or script that runs at sign-in, wire it to write TRUE once for the supervisor account. If the software only publishes the signed-in user, use the role route and put the role comparison in each object's visibility condition. Test both outcomes before anything else: a valid password shows the entry objects; a rejected one leaves the screen untouched.
  5. Relock on demand and on timeout. Add a lock button that writes FALSE, and set the inactivity timer if the software has one. Fifteen minutes covers a changeover with room to spare; 5 minutes suits cells where an edit is a single correction. Without a timer, a PLC rung that clears the tag after 15 minutes without a keypad touch does the same job.
  6. Search every write path to each tag. The gated entry object is one writer. Search the project for each parameter tag and gate or remove every other writer: recipe fields, scripts, other screens, controller code that copies into the tag.

Example: one password opens a 60 Hz drive reference on four screens

Scenario: a packaging line with four operator screens, all showing mixer speed. The drive takes its reference as an integer in tenths of a hertz, so the HMI field carries one decimal and multiplies by 10. Nameplate range: 10.0 Hz minimum, 60.0 Hz maximum, and 60.0 Hz on the 4-pole motor is about 1800 rpm.

Tag Type Power-up value Job
Speed_SP_raw DINT 450 drive reference in tenths of a hertz
Edit_Enable BOOL FALSE edit-enable state for all screens

The tag names are yours to choose; the types and power-up values are what make the pattern relock itself.

Locked. Each screen shows 45.0 Hz from the number display. Touching the value does nothing, because the entry object is hidden and the display has no keypad.

Open for editing. The supervisor signs in on screen 2 with the supervisor account. The sign-in action writes Edit_Enable TRUE, and the entry objects on all four screens appear at the same time.

Edited. The supervisor types 60.0 on screen 2. The entry writes 60.0 x 10 = 600 to Speed_SP_raw, the displays on all four screens follow the tag and show 60.0 Hz, and the drive ramps from 45.0 Hz to 60.0 Hz, about 1350 rpm to about 1800 rpm. A typed 65.0 arrives as 650 and the clamp rung holds the tag at 600; a typed 8.0 arrives as 80 and the clamp holds it at 100. A clamp rung in the controller holds every write inside the nameplate range.

Relocked. The supervisor taps the lock button, Edit_Enable goes FALSE, and the entry objects vanish from all four screens while the displays keep showing 60.0 Hz. The inactivity timer reaches the same result with no button.

Rejected password. The state stays FALSE, nothing appears, and the screens are unchanged.

Restart. The HMI powers up with Edit_Enable FALSE, so every screen comes up locked, showing 60.0 Hz.

Record the original tag value, 450, before the first live test, and make the first change a value the machine tolerates, such as 46.0 Hz.

How to check it worked

Run the five states in this order and write down what each screen shows:

  1. Locked: all screens show the values, no entry object is visible, and no touch opens a keypad.
  2. Wrong password: nothing appears on any screen.
  3. Valid password: the entry objects appear on all four screens at once, not only on the screen where the sign-in happened.
  4. One edit, one tag: change one value and confirm only that tag moved; the other parameters still show their recorded originals.
  5. Lock, timeout, restart: each one removes the entry objects everywhere while the displays keep the last values.

If a state fails, put the machine back at its approved operating value and fix the access path before operators get the screens back.

Which pattern to choose

Recommendation: use the display-plus-gated-entry pattern with one shared boolean when operators need to watch values on the screens where they work, which is the common case on a machine HMI. Build a separate set of supervisor screens, entry objects included, when the plant wants edit rights tied to a place, such as a panel in the maintenance office. Whichever you pick: edit-enable tag FALSE at power-up, a relock on inactivity, and every other write path to the tag gated or removed before you call the parameter protected.

Values that change only at shift start, such as target count or batch number, are watched values but not edit targets. Those belong on a shop-floor status screen the whole cell reads from a distance.

Questions

Should the edit-enable state live in the HMI or the PLC?

Either works. In the HMI it is quick to build and disappears at restart, which relocks the screens at power-up. In the PLC it survives an HMI restart, so controller logic has to clear it: on timeout, on a fault, or at shift change. If the PLC holds the state, have the HMI write it at sign-in and let one controller rung own every condition that clears it, so the relock rule lives in one place.

What else can change a parameter after I gate the entry object?

Recipe fields, scripts, a second screen you missed, and controller code that copies into the tag all write it without any keypad. A recipe download usually writes a whole block at once, so gate the download button or the recipe screen with the same state. A programming tool bypasses the HMI completely, so its access is handled at the controller, with the controller's own user or source protection.

What if the HMI editor has no visibility property on objects?

Fall back to the second pattern: a separate set of supervisor screens holding the entry objects, protected by the software's screen or user access control, with number displays only on the operator screens. Check the editor's object and screen security settings first; per-object visibility is a standard feature, but some editors gate at screen level only.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote