The HMI software's event manager watches a dedicated PLC alarm bit and runs a sound action when the bit turns on. Prepare a short PCM WAV, feed the panel's audio output to an amplified speaker, and size that speaker 10 dB above the noise at the operator position. Keep the visual alarm independent.
When a fault needs to reach the operator's ears and not just the panel screen, the trigger path is already in the HMI software: the event manager watches a PLC condition and runs actions when the condition is met, and sound playback is one of those actions. Point one event at a dedicated alarm bit, hand it a short PCM WAV file, and feed the panel's audio output to an amplified speaker near the operator. The software side is half an hour of work. The part that decides whether the alarm works is loudness over floor noise, and that is arithmetic you can do before you buy anything. The panel may be a machine's own HMI or one of the shop-floor screens used as a status board; the audio path is the same either way.
How the trigger works
The panel's software documents an event manager: events watch conditions in the panel the whole time it runs, and when a condition is met, the actions attached to that event execute. Sound playback is one of the available action types, alongside the message and screen actions. The same condition-then-action pattern appears in PC-based packages too; one knowledge base on playing WAV sound files in SCADA alarm applications walks it in a SCADA alarm configuration.
Because the event lives in the project, the chime is not tied to the screen on display. The sound fires whether the operator is on the fault page or three menus away.
Give the event its own PLC bit. Write it from the alarm rung and reset it on operator acknowledgment. A dedicated bit keeps the sound separate from the process logic: the chime plays when you decide it should, and later edits to the event change nothing in the machine code.
One property decides how playback behaves: whether the sound action fires once per transition of the bit or repeats while the bit is held. Releases differ, so test both. Pulse the bit once and listen, then hold it on and listen; what you observe is what you have, and the release's help for the sound action should say the same in words.
The same event usually carries the on-screen message as well, and configuring operator text in HMI alarm event messages covers that side. Keep the existing visual alarm and the PLC interlocks exactly as they are. Sound is a second indication, and a muted speaker, a failed amplifier or a pulled jack must leave the operator with the alarm they had before. If the visual side needs work too, showing three alarm states with one HMI indicator is the compact pattern.
What you need
- An HMI panel whose software documents a sound action in its event configuration, plus its editor and your usual project transfer route.
- The WAV file: PCM, 16-bit samples, 44.1 kHz sampling rate, mono. That is the CD-audio format and any audio editor exports it directly. Mono halves the file size and an alarm tone carries no stereo information. Keep the tone 1 to 3 seconds: 44,100 samples/s × 2 bytes × 2 s = 176,400 bytes, about 176 kB, so there is no reason to compress.
- An amplified speaker for the panel's audio output. An output jack marked line level feeds an amplifier or a self-amplified speaker; a raw low-impedance horn cone needs power the jack is not built to supply. If the panel has no audio jack at all, adding an audio output to an HMI or shop-floor display walks that hardware step.
- A sound-pressure-level app on a phone, for the loudness check in the example below.
- A test bit in the PLC that runs nothing: a spare coil you toggle from the HMI, used with the machine in a safe state.
- A saved backup of the running project.
Configure the event and the sound
- Save a copy of the running project and open the copy. Keep the transfer route you already use, so rolling back is a single file transfer.
- Add the alarm bit in the PLC: a dedicated coil set by the alarm rung, reset by acknowledgment. Confirm its address and data type in the HMI's tag or device configuration before anything references it.
- Open the event manager in the editor and create one event for this alarm class. Set the condition to that bit turning on. Name the event after the fault so the next engineer finds it.
- Attach the sound action to the event and select the WAV file. If the action offers a volume setting, start at maximum and adjust only after the loudness check.
- Look for a loop or repeat option in the sound action's documented settings and decide the behavior now: repeat until acknowledgment, play a fixed count, or one shot per event. Where the release supports repeating, one knowledge base on looping a WAV alarm sound in a SCADA application shows the repeating case built out end to end.
- Transfer the project to the panel and let it restart into the new project.
- Toggle the test bit with the machine in a safe state. The file should play. Pulse the bit and then hold it on, and note which of the two matches the behavior the release documents.
Example: sizing the chime for an 85 dB(A) assembly bench
Inputs. Background noise at the operator's ear: 85 dB(A), read from a phone SPL meter during a working shift. That value is the common case for light assembly, because OSHA's hearing-conservation program starts at an 85 dB(A) eight-hour average. Speaker output: 92 dB(A) at 1 m, measured in the open aisle at full volume playing the actual WAV file.
Rules. First, alarms are specified to clear background by at least 10 dB at the listener's position; that margin is a standing rule in alarm design, and it is the number to hold. Second, sound from a point source falls about 6 dB for every doubling of distance in the open, by the inverse-square law. Walls, machines and ceilings reflect sound and slow the falloff, so 6 dB per doubling is the planning figure, and the reflections give back margin you should not spend.
Arithmetic. Target at the ear: 85 + 10 = 95 dB(A). The operator stands 2 m from the speaker, which is one doubling: 92 - 6 = 86 dB(A) at the ear. 86 dB(A) is 9 dB short of the 95 dB(A) target, so this speaker at this distance fails.
Result and decision. Moving the speaker in to 0.5 m gains one doubling the other way: 92 + 6 = 98 dB(A), which clears 95 dB(A) with 3 dB to spare. Bench-mount the speaker within 0.5 m of the operator and the setup passes as built. If the operator must stay 2 m away, the speaker has to produce 95 + 6 = 101 dB(A) at 1 m; specify a horn rated at least 101 dB(A) at 1 m for a 2 m position. The target moves with the floor: each 1 dB(A) of extra background raises it 1 dB, so a 90 dB(A) background pushes the 2 m requirement to 106 dB(A) at 1 m. The threshold to hold: a measured margin of at least 10 dB at the ear. Below that, shrink the distance or change the horn before the panel goes into service.
How to check it worked
Run the list once before the machine returns to production:
- Bit on: the file plays, once or repeating exactly as configured in step 5.
- Bit off and on again: the behavior matches what the release documents for repeat.
- Output: the tone plays at the set volume with no clipping or crackle; an overdriven amplifier input is the usual cause of a buzzing alarm speaker.
- Loudness: with production running, the SPL app at the operator's ear reads the target from the example, 95 dB(A) in that bench case.
- Machine: toggling the test bit started nothing, and no rung other than the alarm logic changed.
- Visual path: pull the speaker lead once and confirm the on-screen message or indicator still announces the fault. Sound fails quietly; the screen must not.
When the panel stays silent
Work one stage at a time, in this order: bit, event, output, ear. Record which stage fails before changing anything, because two fixes at once hide the real cause.
| Symptom | What it points to | Next check |
|---|---|---|
| Bit toggles, event never activates | Tag reference or data type mismatch, or the device link is down | Watch the live tag and the event state in the editor's online diagnostics; the event's configured tag must be the exact bit you toggle |
| Event activates, nothing audible | File absent from the project or a format the panel rejects; or no speaker on the jack | Reopen the sound action and confirm the selected file; plug a spare amplified speaker into the jack and replay |
| Audible at the panel, missed at the station | Distance and background noise ate the margin | Re-run the sizing arithmetic with measured numbers; a 6 dB drop per distance doubling explains most misses |
| Plays at the wrong time or keeps repeating | Level-driven playback on a latched bit | Pulse the bit instead of holding it, or add the acknowledgment reset to the rung |
| Plays but operators miss it under noise | Margin under 10 dB | Measure at the ear and close the gap with distance or a louder horn |
An event that activates with sound attached tells you the data path is good; what remains is the acoustic path, and the example section sizes it.
Recommendation: drive the alarm from a dedicated, latched PLC bit through one event-manager event, play a 2-second 16-bit mono PCM WAV at 44.1 kHz, and feed it to an amplified speaker mounted within 0.5 m of the operator; if the operator sits 2 m away, specify a horn rated at least 101 dB(A) at 1 m. Hold a measured margin of 10 dB at the ear, and keep the visual alarm and interlocks exactly as they were.
Questions
Does the alarm sound play when a different screen is on the panel?
Yes. The event manager is a project-level feature: its events watch PLC conditions while the panel runs, so the sound action fires no matter which screen is displayed. That is also why you can add the chime without touching any screen, and why the on-screen message and the sound are configured in different places in the project.
Why PCM WAV and not MP3 for the alarm file?
PCM WAV is uncompressed, so every audio stack plays it and no codec license is involved. MP3 support depends on the panel software, and a 1 to 3 second alarm is only a few hundred kB uncompressed, so MP3 saves nothing that matters. Convert any existing MP3 once to 16-bit 44.1 kHz WAV and use the copy.
How long can the WAV file be before it becomes a storage problem?
PCM mono at 44.1 kHz and 16 bits produces 88.2 kB of audio per second, since each sample is 2 bytes at 44,100 samples per second. One minute of alarm audio is therefore about 5.3 MB. Keep tones at 1 to 3 seconds anyway; a fault tone that runs a minute is an announcement design problem, not a loudness one.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.