HMI voice message playback completion before a button action

How do you know when an HMI voice message finishes playing?

Check the audio object's properties and help page for a playing, busy or done status tag, and gate the button on that tag; when the help shows no status signal, enforce the time yourself with a PLC on-delay timer set to the longest measured play plus a 20% margin.

A status tag is the panel reporting the end of playback, so it is the exact signal and the first thing to look for. The timer is an estimate with a known error band, so it is the fallback, and the rest of this page is about making that estimate honest. Work the checks in order: status bit, measurement, retrigger behavior, rung, proof.

What do you need on hand before you start?

You need the panel project software with the audio object configured, a PLC with one spare on-delay timer and two spare BOOL bits, a stopwatch, and the voice file in its final form, because any later file change invalidates the measurement.

Gather these before touching the ladder:

• Msg_Request (BOOL): the rising edge that fires the clip. Set it up the way Play a WAV alarm on an HMI from a PLC event drives a sound from a PLC event.
• Msg_Busy (BOOL): the gate bit this job creates. Both names are illustrative; keep your project's convention.
• One on-delay timer instance, IEC 61131-3 style (TON in most software), preset entered in the timer's own time base.
• A stopwatch; the margin absorbs human timing error.
• The panel running its real firmware and power-up routine, so the measurement matches the floor.

Before measuring anything, prove the panel link writes and triggers the way you expect; Operator panel PLC link setup: test writes before motion gives the test order.

Does the audio object expose a playing or done status?

Open the sound or audio object in the panel software, read its property tabs and its help page, and look for a status tag, a playing or busy bit, or a completion event; what you find there decides the rest of the job.

Every vendor names the signal differently, so the honest search is inside the object list and the help of your own editor. At least one HMI editor's reference manual documents a dedicated player object that provides the interface for playing audio in a project, which is the pattern to look for in yours. If the help offers only a trigger action with no state, no project setting will create one. That is a feature request to the panel vendor, and the timed gate in the sections below is the production answer meanwhile.

How do you measure the real playback time on the panel?

Play the message on the target panel five times, time each play from trigger to the last audible sound, and keep the longest reading; the file length on your PC is not the number you need, because panel decode and audio start-up lag sit on top of it.

Five plays are enough to expose stopwatch noise: a person timing a sound lands within about ±0.2 s either side of true, so readings inside a few tenths of each other describe a consistent panel. Write the five numbers, the date and the file name into the rung comment. Readings that spread by more than 0.5 s are beyond stopwatch noise, which means the panel retriggered or interrupted something mid-play; Fix dropped PLC-triggered messages on a serial HMI panel sorts out the link-side causes before you measure again. On a consistent panel, the longest of the five readings is the time base for the whole gate.

What does a second trigger do while the clip is playing?

Trigger the message once, trigger it again at about half the measured play time, and listen; the panel restarts the clip, ignores the second request, or cuts the first clip off, and each outcome sets a different rule for the gate.

Then confirm what drives the sound. An audio object fired by a tag level replays while the tag stays true and can replay again when the screen reloads, so drive it from a one-shot edge or a short pulse. The pulse width that actually reaches the panel is a scan-count question; How many PLC scans an HMI momentary button bit stays on works that arithmetic out.

How do you build the busy-bit gate that holds the button?

Latch Msg_Busy on the rising edge of Msg_Request, start the on-delay timer at the same edge with preset = longest measured play + 20% (1 s minimum), clear Msg_Busy on the timer done bit, and enable the button action only while Msg_Busy is false.

1. Put a normally closed Msg_Busy contact in series with the button's action coil or output, so the action executes only while the gate is open.
2. Put the same normally closed contact in series with Msg_Request itself; that is the retrigger inhibit the listening test called for.
3. On the rising edge of Msg_Request, latch Msg_Busy true and start the timer with preset = longest measured play + margin.
4. On the timer done bit, unlatch Msg_Busy. The gate opens one preset after the request, whatever the audio path did in between.
5. Comment the rung with the five readings, the margin rule and the date, so the next technician re-measures instead of guessing.

Msg_Request one-shot edge -> latch Msg_Busy, start TON (preset = longest play + margin)
TON.done -> unlatch Msg_Busy
Button_Action enable = NOT Msg_Busy
Msg_Request rung carries NOT Msg_Busy in series (retrigger inhibit)

The whole gate lives in the PLC, so the block is seated the same scan the request edge arrives; small PLCs commonly scan in 1 to 10 ms, which is instant next to a gate measured in seconds. While the gate is closed, show the wait on the panel itself; Display a PLC countdown timer on an HMI panel covers the timer-to-screen side.

What does the worked example look like with a 9.6-second message?

An assembly bench speaks a torque-and-check instruction; five timed plays on the panel read 9.1, 9.3, 9.4, 9.5 and 9.6 s, so the gate preset is 9.6 s + 20% = 11.6 s, entered as 11600 on a 1 ms timer.

• Measured longest play: 9.6 s.
• Margin: 9.6 s x 0.20 = 1.92 s, rounded up to 2.0 s, which clears the 1 s floor.
• Preset: 9.6 s + 2.0 s = 11.6 s = 11600 ms.
• Timeline: request at t = 0, button blocked until t = 11.6 s, last word at about t = 9.6 s, so the operator waits about 2 s after the voice stops.
• The listening test, triggered again at t = 5 s (half of 9.6 s, rounded), showed the clip restarting, so the request rung carries the Msg_Busy inhibit and a double press never reaches the audio object.
• If the message is re-recorded at 14 s, the preset becomes 14 x 1.2 = 16.8 s after a fresh measurement; scaling the old preset without re-measuring is how a gate drifts.

How do you prove the gate holds before it meets an operator?

Run five abuse tests on the bench: press during the clip, press repeatedly through the whole gate, double-trigger, power-cycle mid-message, and swap in a longer file; the button must stay dead until the preset expires in every one of them.

• Press at t = 1 s on the 11.6 s gate: no action. Press again at t = 11.5 s: still no action. The gate ends on the timer, not on the sound.
• Rapid presses across the whole gate: blocked on every scan.
• Double trigger: whatever behavior the listening test recorded, and Msg_Busy never clears early.
• Power-cycle the panel mid-message: playback stops with the panel, so a non-retentive Msg_Busy that comes back false at power-up matches what the floor heard. Keep the bit non-retentive; the failure you want is a button available one message early, never a button locked until a maintenance call.
• Swap in a longer file without re-measuring: the button frees before the voice ends. That visible early release proves the gate tracks the file, and the preset now needs the new measurement.

When is the timed gate the wrong answer?

Never gate a motion start, a press stroke or any safety-relevant action on this estimate; the timed gate sequences a workflow around an announcement, and keeping people safe belongs to the machine's own designed interlocks, never to a stopwatch number.

The limit cuts the other way too, when the button action must genuinely wait on the audio, as in a training station whose next step opens only after the instruction finishes. There, ask the panel vendor whether your model and software version report playback state; the answer is either a documented status tag or a feature request, and no amount of timer tuning turns the estimate into a report.

Recommendation: Check the audio object's help for a playing or done status tag and use it when the panel offers one; when it does not, run the timed gate with preset = longest measured play + 20% (1 s minimum), carry the Msg_Busy inhibit in the request rung, keep the bit non-retentive, and re-measure on every audio file change.

Questions