HMI audio overlap when a second alarm message fires

Why does a second alarm audio message cut off or go missing?

Most HMI panels drive one audio output path, so when a second alarm clip is requested while the first is still playing, the panel does one of four things: cuts off the running clip, drops the new request, queues it, or mixes both clips into the speaker.

A cut-off message destroys a warning mid-sentence, and a dropped one is worse because the operator hears nothing at all. Queueing exists as a documented behavior in some alarm software, where notifications play one after another in sequence, and some alarm systems re-trigger queued messages after an acknowledgment, so a queued design can still repeat itself. The result can also differ between a trigger bit held on and a one-scan pulse, which is why the bench test runs both. When the trigger reaches the panel over a serial link, requests can vanish at the link before playback is even considered; the article on fixing dropped PLC-triggered messages on a serial HMI panel covers that side.

What do you need on the bench before you start?

You need the panel and its project software, two WAV clips with clearly different lengths, a PLC with two spare bits and one timer, and a stopwatch or the clip properties dialog, all on the bench before the panel goes anywhere near the running machine.

• Clip A, a 2.0 s spoken message, and clip B, a 5.0 s message with different wording, so your ear tells them apart instantly.
• The panel, its project software, and the manual or help file for the audio or sound action.
• A PLC with two spare bits, one timer per message, and a programming device to force bits.
• An external speaker and amplifier if the built-in speaker is too quiet for the cell; the write-up on adding an audio output to an HMI or shop floor display covers the wiring.
• The live project saved under a different name, so testing never touches the running screen.

How do you bench-test what the panel does with two clips at once?

Trigger clip A, then trigger clip B about one second into A's playback, and write down which of the four behaviors you hear; repeat the run ten times and with the trigger bit held on as well as pulsed, because the result can change between the two.

1. Build a test project with two audio actions, each on its own PLC bit, and load it into the panel.
2. Force bit A on and let clip A start.
3. About 1 s into A's playback, force bit B on and listen.
4. Record the outcome against the table below, then repeat the whole run 10 times.
5. Run it again with bit A held on for 10 s, and again with each bit as a one-scan pulse.
6. If the panel queues, add a third clip and force all three bits at once to find how deep the queue goes.

Whichever row you land on is the behavior to design around, and the timer method in the next sections works with all four.

Does the panel have a playback-done bit you can use?

Search the panel manual and your project software's help for a playback or audio status bit; operator panel manuals document status bits the controller can read, and that documented list is where a clip-done bit lives when a maker exposes one.

Found: map the bit to a PLC tag and bench-check it. Run clip A ten times and confirm the bit rises at clip start and falls at clip end on every run; a flag that only marks the request accepted stays high even after the clip ends, and pairing a 2.0 s run with a 5.0 s run shows the difference on the first trial.

Missing: skip the hunt for undocumented registers and use the timer method. A panel with no completion flag still sequences correctly when the PLC owns the timing, which is the point of the next three sections.

How do you stop a held alarm bit from restarting the same clip?

An alarm bit that stays on for the whole fault re-fires a level-triggered sound action over and over, so fire each clip from a one-shot: use the documented turn-on edge in the sound action, or build the pulse in the PLC and drive the audio action from that pulse.

HMI development packages document the trigger for their sound action, and the common selection plays the sound after the tag turns on or after it turns off; pick the turn-on side. Where the package offers no edge choice, a one-shot in the PLC produces the pulse, and the raw alarm bit keeps driving the alarm banner. Let the operator's acknowledge set a PLC bit so the sequencer knows the event is closed; the article on mapping an HMI alarm acknowledgment to a PLC bit shows the mapping. Debounce an alarm that chatters near its setpoint with a 0.5 s off-delay in the PLC, or a drifting temperature input will re-request the clip every scan.

What timer preset releases the next message?

Preset the gate timer to the measured clip length plus the measured overrun from the bench: run each clip 10 times, take the longest observed start-to-end time, subtract the file length, and add a 0.2 s allowance for scan time and the gap between clips.

The file length comes from the clip properties dialog. The overrun is panel start latency plus decode delay, and it is a measurement, so it gets ten runs and the longest value wins. If the bench test found a real done bit, release on the bit and set the same timer as a watchdog at the calculated preset, so a bit that sticks high cannot freeze the sequencer. Store the preset in a retentive tag: if it reads zero after a power-down, the article on an HMI timer preset that resets to zero in the PLC walks the checks. A panel that cannot open a clip at all reports a clip-creation error instead of silence; the page on unable-to-create-audio-clip errors names that symptom.

What does the timer preset example give for a 4.0-second clip?

For a 4.0 s clip whose longest bench run came back at 4.3 s, the preset works out to 4.5 s, and the sequencer releases the next message 4.5 s after the play trigger.

The scenario: a high-temperature message with a 4.0 s clip, ten timed bench runs on the panel, and one gate timer in the PLC. The ten runs came back at 4.1, 4.2, 4.3, 4.2, 4.1, 4.3, 4.2, 4.1, 4.2 and 4.3 s, so the longest observation is 4.3 s. The arithmetic:

• Overrun: 4.3 s - 4.0 s = 0.3 s
• Allowance: 0.2 s for scan time and comms
• Preset: 4.0 s + 0.3 s + 0.2 s = 4.5 s

In a timer block with a 0.1 s time base the entry is 45; with a 0.01 s time base it is 450. Run the same bench method on the 2.0 s clip and enter its own preset: one measured preset per message, never a copy. These run times are example numbers from a bench session; your panel gives you your own.

How do you build the PLC audio sequencer, step by step?

The sequencer grants the panel one trigger at a time: each message gets a request bit and its own measured preset, the running grant holds until its timer done bit, and every other request waits in the PLC until then.

1. Give each audio message a request bit and a priority, and write the order down where the panel project can be checked against it.
2. Enter each preset from its own bench measurement, sized as in the example.
3. Fire the panel's play trigger only from the sequencer's grant, one grant at a time, highest priority first.
4. Start the gate timer when the grant fires, and release the next request on its done bit, or on the documented done bit with the timer as a watchdog.
5. Set repeat behavior: re-announce only after the clip has finished plus a 30 s repeat interval, and clear the request when the alarm clears.
6. Force all request bits on and confirm the highest-priority clip plays completely before the next grant closes.

Recommendation: Gate every next clip with the PLC timer at its measured preset, 4.5 s in the example, whenever the panel documents no playback-done bit; when a real done bit is documented and bench-checked, release on the bit and keep the same timer as the watchdog so a stuck bit cannot lock the audio path.

How do you verify the sequencer under worst-case overlap?

Force every request bit on at once, then confirm the highest-priority clip plays end to end and the rest follow in order with no clip cut off; a sequencer that passes that run holds up through a real shift of stacked alarms.

• Set a low-priority request while a clip plays and confirm it waits its turn.
• Set a high-priority request during a low-priority clip and confirm the behavior you chose; the bench result from the table decides whether an interrupt is even possible.
• Clear an alarm while its request is still queued and confirm the stale message never plays.
• Power-cycle the panel mid-clip and confirm the watchdog timer, 4.5 s in the example, recovers the grant on its own.
• Watch the visual side: the banner and any beacon stay independent of the panel speaker, and the article on showing three alarm states with one HMI indicator covers a compact status display.

Keep the horn or beacon on its own output, because many operators already wear hearing protection at noise levels near the 85 dBA 8-hour action level used in occupational noise limits, and a panel speaker is a supplement to the warning, never its carrier. If the cell also needs a separate notice board that plays its own saved messages next to the HMI, that is a second screen doing a different job; our shop-floor signage category is where those displays live.

Questions