Gate HMI button visibility on a PLC timer done bit

6 min read · Published November 6, 2026

Gate the button's visibility property on a PLC authorization bit: a correct password entry latches the bit, a timer clears it when the window ends, and the button draws and accepts touches only inside the window. The example window runs 6 minutes. Put the same bit in the command rung so the PLC rejects any request that arrives after it closes.

A protected pushbutton does not have to demand the password at every press. Bind the button's visibility property to an authorization bit that lives in the PLC: one correct password entry sets the bit, an on-delay timer clears it when the window closes, and the button draws and accepts touches only while the bit is high. The example window below runs 6 minutes after a single entry. Keep the same bit in the command rung too, so the PLC rejects any request that arrives after the window closes. The hidden button is the convenience; the rung is the protection.

How the visibility property carries the window

Almost every HMI editor gives each object a visibility input bound to a tag. Tag 1, the object draws; tag 0, it hides. Some editors bind a whole INT or WORD tag and let the PLC set the individual bits inside it, so one tag drives several objects at once. No script is involved: it is a property on the object, set once in the editor and downloaded with the project.

Clear two traps before you build. Leaving the visibility field empty means the object is always visible; the static image is a separate tool in the editor's drawing menus, and a static image reads no tag, so it cannot open or close a window. Then check that a hidden object also drops its touch target: place a throwaway button, bind it to a spare bit, toggle the bit online and watch the button come and go. If the invisible object still sends its command, the command rung in step 6 is what stands between the operator and the machine.

What you need

  • The panel's protection feature and the tag that goes true after a correct password entry. Read it online to find it. If the panel exposes no such tag, the window has nothing to key off, and you stay with the per-press protection it already has.
  • A non-retentive on-delay timer in the PLC (TON in IEC-style ladder).
  • An authorization bit, a timer done bit and a preset register. The example calls them AuthOk, WindowDone and WindowPreset; use your project's own names.
  • The pushbutton object with its visibility property. Some editors enforce a minimum object size tied to the touch cell, 40 x 40 pixels on the panel class this design came from, so place the button at that cell size and take it out of view with the visibility property when the window closes.
  • A stopwatch, to time the real task before you set the preset. To show the time left on the screen, bind a numeric field to the timer's accumulated value; displaying a PLC timer on the panel walks that.

Build the window in the PLC

  1. Verify the password tag. Enter a wrong password and watch it online: it must stay 0. Enter the correct one: it goes to 1.
  2. Latch AuthOk on the rising edge of the password tag. The latch makes the window a length of time; feeding the bit straight from the prompt ties access to the prompt instead.
  3. Run the on-delay timer from AuthOk with WindowPreset set to the window; the example below sets it on a 0.1 second timebase.
  4. Reset AuthOk from the done bit: when WindowDone goes to 1, reset the latch on the rung after the timer. The timer then resets itself, and the next entry starts a fresh window. The latch matters here because a non-retentive timer's done bit falls when its rung goes false, so an unlatched enable drops the window early; why a TON done bit never stays on covers that behavior. If WindowPreset keeps falling back to zero on its own, write the preset value into the register every scan from a constant rung, or from the program's initialization routine, so nothing else in the project writes zeros into it.
  5. Bind the pushbutton's visibility property to AuthOk in the object's settings, save and download to the panel.
  6. Put AuthOk in the command rung, so the action executes only while the window is open. This is the safety note for the whole design: every path to the command, including a second button or a maintenance screen, crosses this rung. To protect every control on a screen, screen access control for a protected operator view applies the same idea at screen level.

Worked example: a 6 minute window on a 0.1 second timer

Inputs: the window is 6 minutes, the length of the settings-change sequence this design serves; the timer timebase is 0.1 s, the base of the example PLC's timer; the trigger is one correct password entry, which latches AuthOk.

Rule: preset equals the window in seconds divided by the timebase.

Arithmetic: 6 min × 60 s/min = 360 s. 360 s ÷ 0.1 s = 3600. Enter 3600 in WindowPreset.

Result: from the moment of entry, the button draws and the command rung accepts for the full 6 minutes. When the timer reaches the preset, WindowDone goes to 1, the rung after the timer resets AuthOk, the button disappears and a new request is rejected at the PLC. Scan time moves the edges by milliseconds; the stopwatch check reads the window length either way.

Decision: measure the longest protected sequence with a stopwatch and set the preset to it. A 10 minute sequence on the same base is 10 × 60 = 600 s, 600 ÷ 0.1 = 6000. If a task outgrows the window, one new password entry restarts the full window, so a 12 minute task becomes two entries of 6 minutes each.

Check it worked

  1. Wrong password: no button appears and AuthOk stays 0.
  2. Correct password: the button appears within a scan or two of the entry.
  3. Run a stopwatch from the entry: the button disappears at the end of the 6 minute window.
  4. Press the button inside the window and confirm the action runs. Let the window expire, press where the button was, and watch the command rung stay false; the PLC rejects the request.
  5. Leave AuthOk at 0 and press the button's old spot: if the editor keeps an invisible object active, this catches it, and the command rung is what stops the machine.
  6. The editor's simulate function exercises the graphics only. The bits in the PLC are the state that matters; watch them online while you test.

When the editor cannot bind visibility to a button

Some editors offer the visibility property on shapes and bitmaps only, not on pushbuttons. Use one of the two supported designs: keep the panel's protection feature and accept the password at each press, or move the protected controls onto a screen with its own access control, so the whole screen opens for the window. Do not build the gate from a static image; a static image draws all the time and reads no tag, so there is no window in it. If entering the password on the panel keypad is the clumsy part, a pop-up screen window can carry a numeric entry pad that opens on demand.

The decision

Recommendation: latch the authorization bit in the PLC at each correct password entry, run the window timer from the latch, reset the latch from the done bit, bind the pushbutton's visibility property to the latch, and put the same bit in the command rung. Set the preset to the longest protected sequence you have timed with a stopwatch; the example's settings-change task lands at 3600 on a 0.1 second timebase.

If your editor binds visibility on pushbuttons, that is the build. If it binds only on shapes and bitmaps, use per-press protection or screen-level access control. Either way the PLC rejects the command outside the window; the visibility binding only decides whether the operator sees the offer.

Questions

What is the preset on other timer timebases?

The 6 minute window is 360 seconds, and the preset is the window divided by the timebase: 360 on a 1 second timer, 3600 on a 0.1 second timer, 36000 on a 0.01 second timer. Whichever base your timer uses, enter window divided by timebase and the done bit arrives at the same moment.

Can several protected buttons share one window?

Yes. Bind every gated button's visibility property to the same AuthOk bit. The PLC sets it once at the password entry and clears it once at expiry, so the buttons appear and disappear together and one timer serves them all. Time the whole sequence of presses across all buttons when you measure the window, since they share one countdown.

Why keep the password prompt if the window hides the button?

The prompt creates the event the window keys off. Without a correct entry, the PLC has nothing to latch AuthOk from and the window would be open to anyone who walks up. The prompt stays; the timer removes the repeat prompts inside the window, so one entry covers the whole sequence of protected presses.

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