Make an HMI button beep once with a PLC timed pulse

Why does an HMI button beep for as long as it is held?

The button's beeper option ties the sound to the button bit, and the bit stays on while the panel sees the contact closed. A 2 s hold therefore produces a 2 s beep. The only way to shorten the sound from the button is to shorten the press.

The beeper option on a screen button has no duration setting of its own. The panel sounds the beeper while the button bit reads on, and the bit reads on while the touch or the contact is held. A bit that hangs on after release is a separate fault; how many PLC scans an HMI momentary button bit stays on covers what the panel sees during a short press.

So the cure lives in the PLC. Give the sound its own request bit and time the request there. The button stays a plain input and the beeper follows the pulse.

What does each symptom point to?

Split the complaints before touching the program. A beep that runs while the button is held is a button-driven beeper. A beep that keeps sounding after release is a bit stuck on. A panel that stays silent has the beeper disabled or the sound path idle.

• Beep runs exactly while the button is held, stops on release. That is the button-driven beeper. Apply the timed pulse below.
• Beep keeps sounding after release. The trigger bit is stuck on. Check the input circuit and the function-key latch; HMI function key bit stays on after a short press walks that fault.
• Beep keeps sounding no matter what you press. A PLC-side control bit for the sound has been left on. Several panel families hold an alarm sound until the PLC control bit drops, so check the mapped control address first.
• The bit toggles on a watch table but the panel stays silent. The beeper is disabled in the panel settings or the beep bit maps to the wrong address.
• You want no beeps at all. Turn the beeper off in the project settings; turn off the touchscreen beeper in HMI project settings shows that path.

Where do you find the PLC-to-panel beep bit?

Open the panel project's setup screens and look for the page that maps panel functions to PLC addresses, often labeled as a PLC-to-panel setup. It exposes the beeper as one discrete bit that you assign to a PLC address, and that bit becomes the momentary beep request.

Panel families put the control in different places and name it differently, so check the panel manual for the exact model before you edit. Assign the bit to a spare PLC address, write the address into the project notes, and save copies of the panel project and the PLC program before you download anything. If the setup screens show no PLC-to-panel beeper bit at all, do not borrow an unrelated bit; compact panel families sometimes leave the control out, and the model's documentation or the panel vendor's support line settles it.

If the beeper in your project is driven through the panel's alarm system instead of a plain bit, watch the tag type. Many panel alarm systems take discrete alarms from a Word or Int tag with the bit selected inside it, and they reject a lone bool tag.

What PLC logic turns the beep into one short pulse?

Give the beep request bit a timed pulse. Energize a timer on the rising edge of the trigger, drive the beep bit with trigger AND NOT timer done, and set the preset to 500 ms so every press sounds once and the request clears when the trigger drops.

Two rungs do it. The tag names are mine for this page: Trigger and BeepReq are BOOL, Tone is a timer-on instance, TON in IEC 61131-3 style, and Tone.DN is that timer's done bit.

Rung 1 | Trigger --[TON]-- Tone         (PT = T#500ms)
Rung 2 | Trigger --[/]-- Tone.DN --( )-- BeepReq

A press raises Trigger, Tone accumulates, and BeepReq drives the panel's beep bit. When Tone.DN goes true at the preset, BeepReq drops, and it stays off until the next rising edge. A release before the preset drops Trigger, resets Tone, and drops BeepReq with it.

Keep the pulse well above one communication cycle of the panel link. The panel reads PLC data on its own cycle, so a pulse shorter than one read can fall between reads and never register. That is the same mechanism that drops short PLC-triggered messages on a slow serial link, which fixing dropped PLC-triggered messages on a serial HMI panel covers in detail. A one-scan pulse is never enough.

An operator who taps lighter than about 100 ms cuts the beep short, because release ends the request at whatever the timer has reached. If taps run that short, latch the request so every beep completes:

Rung 1 | Trigger rising edge --(S)-- Hold
Rung 2 | Hold --[TON]-- Tone          (PT = T#500ms)
Rung 3 | Tone.DN --(R)-- Hold
Rung 4 | Hold --( )-- BeepReq

Hold is BOOL, set on the rising edge and reset by Tone.DN. Every beep then runs its full length regardless of press duration, at the cost of the drop-with-the-press behavior.

What does the worked example give?

The worked example: an acknowledge button on a machine gate, a timer preset of 500 ms, a PLC scan of 8 ms and an operator who holds the button for 2 s. The arithmetic gives one beep of that length with the request off by 508 ms.

Walk the numbers:

• t = 0 ms: the operator presses. The PLC sees the rising edge within one scan, so by 8 ms Tone is accumulating and BeepReq is on, and the beep sounds inside one communication cycle after that.
• t = 500 ms: Tone reaches its preset. Tone.DN goes true and BeepReq drops within the next scan, so the request is off by 508 ms. The beep has lasted the full preset, not the 2,000 ms the button was held.
• t = 2,000 ms: the operator releases. Tone reset long before, nothing latches, and the logic sits ready for the next press.
• A quick tap changes the outcome: release at 120 ms ends the beep at 120 ms, too quick to register as a notice, so that station gets the latch variant.
• Over a shift: 40 acknowledges at the preset each is 20 s of sound in an 8 h shift, so the beeper is nowhere near a load worth managing.

How do you test that the beep stops?

Put Trigger, Tone.DN and BeepReq on a watch table and press the button five times with each hold at least 1 s. A passing test shows five beeps at the preset length, BeepReq low between presses and low within one scan of each timer expiry.

Then check the edges:

• Release mid-pulse: BeepReq follows Trigger down with the plain two-rung version and holds to the preset with the latch version, so know which variant is loaded before you judge the trace.
• Press again inside a pulse: the second press adds nothing, because the request is one bit. One rising edge, one beep.
• Re-trigger after expiry: the next press beeps. A press that stays silent after an earlier one points at logic that never reset; Tone.DN and any latch should read low between presses, and a PLC flag that triggers an HMI event once: checking the reset path is the same fault shape.
• BeepReq toggles but the panel never sounds: fix the beeper enable or the address mapping first, and only then touch the timing.
• Beeps drop out occasionally on a serial link: lengthen the preset so the pulse always spans a communication cycle.

When should the pulse run longer?

Lengthen the pulse when the notice has to beat shop noise or a plant rule sets the sound. 250 to 500 ms covers a plain key acknowledgment. 750 ms to 1 s covers a loud cell. Any duration the site's audible-notification requirement demands wins over both.

A panel beeper is a notice and a convenience. Where a machine standard requires a horn or a stack light to sound until acknowledged, that sound keeps its own output and its own acknowledge logic, so do not fold a required alarm into the beeper pulse.

Recommendation: drive the PLC-to-panel beep bit from a 500 ms timer pulse as the default for any button or PLC notice that must not drone. Keep 250 ms as the floor on a healthy link. Move to 750 ms to 1 s in a loud cell or where the site's audible-notification rule asks for it, and load the latch variant when operators tap under 100 ms.

Questions