Industrial · Worked Example

Shift Bells, Safety Drills and Tea Breaks

Multilarm on the shop floor · 6 min read

Illustrative worked example — a representative scenario showing how Multilarm is configured, not an account of a specific customer.

A manufacturing plant’s audio needs look simple on paper: ring a bell at shift change, ring another at break, ring a siren for drills, and occasionally let a supervisor talk over the PA. In practice, the bells need to reach every workshop, the workshops have different background noise levels, and the schedule has to survive power cuts. Multilarm covers all of it from one config.

The site

A small light-manufacturing plant with three workshops (machining, assembly, dispatch), a canteen, and an outdoor loading bay. Each space already had its own powered speaker and amplifier — different installers, different eras, all perfectly functional. What was missing was a single brain telling them when to sound and what to say.

Hardware

Zone mirroring

The hinge is the same one every multi-zone deployment uses: MirrorDevices. One alarm fires; five devices play it in lock-step. The relevant settings, straight from Multilarm.config.xml:

<MAConfig><PlaybackDevice>2</PlaybackDevice></MAConfig>
<MAConfig><MirrorDevices>3|4|5|6</MirrorDevices></MAConfig>
<MAConfig><RecordDevice>7</RecordDevice></MAConfig>

Device 2 drives the machining workshop (loudest environment — gets the primary). Devices 3–6 cover assembly, dispatch, canteen and loading bay. Device 7 is the supervisor microphone.

The Ctrl+O console dump is how you pin each dongle to its workshop: label the dongle, plug it in, run Multilarm, hit Ctrl+O, see the device name in the table, commit the index. If a dongle is ever swapped, running Ctrl+O shows whether the index shifted before the next shift starts.

The schedule

Shift work is regular. Writing it out is the easy part — one row of daily times paired with one folder index per slot:

<MAConfig><RecurEveryDay>True</RecurEveryDay></MAConfig>
<MAConfig><DateAndTimeData>6:00|10:00|10:15|12:30|13:00|14:00</DateAndTimeData></MAConfig>
<MAConfig><AlarmPath>C:\Bells\ShiftStart|C:\Bells\BreakStart|C:\Bells\BreakEnd|C:\Bells\Chimes|C:\Bells\ShiftEnd</AlarmPath></MAConfig>
<MAConfig><AlarmIndexData>1|2|3|4|3|5</AlarmIndexData></MAConfig>
<MAConfig><AlarmFileFormat>mp3</AlarmFileFormat></MAConfig>

Each position in DateAndTimeData maps through AlarmIndexData to a folder in AlarmPath. Slot 1 (06:00) → index 1 (ShiftStart); slot 6 (14:00) → index 5 (ShiftEnd), which is also Shift B’s start because a single bell does for both. Everything is a folder, not a file, so the bell tone evolves over time without anyone editing the schedule. Swap the contents of ShiftStart, the next shift start uses the new pool. No restart required.

Volume profiles for the loud and the quiet hours

Night shift runs skeleton crews. A full-volume lunch chime at 02:30 is both wasteful and irritating. One VolumeProfileRules setting, two semicolon-separated windows, covers it:

<MAConfig><VolumeProfileRules>06:00-22:00,volume=1.0;22:00-06:00,volume=0.65</VolumeProfileRules></MAConfig>

The dashboard surfaces the active window as volumeProfile in the status JSON and as Volume Profile in the UI. The supervisor can confirm at a glance whether the quiet-hours cap is currently clipping the schedule before an unusual event.

Voice Broadcast over the floor

The feature that removed the old handheld PA mic from the cabinet altogether. When a supervisor needs to call a colleague, announce an unplanned safety briefing, or tell the fork-lift driver to move out of the dispatch bay, the sequence is:

  1. Open the Web Remote on the office laptop or phone.
  2. Tap Record in the Voice Broadcast card. The factory PC starts capturing from the tabletop mic.
  3. Tap Stop, then Preview. The recording plays back quietly on whichever device is configured for preview.
  4. Tap Transmit. A confirm dialog appears; tapping through sends the clip out of every mirrored zone at broadcast volume.

If the supervisor fluffs their words, Discard throws the clip away and the floor hears nothing.

Why the confirm step matters: on a shop floor you are competing with drills, compressors, and conversation. A fat-fingered transmit of a dead mic is annoying; a fat-fingered transmit of “one, two, one, two” is worse. The deliberate {"confirm":true} gate on /api/voice/transmit is cheap insurance.

Drill day — and the “Test Alarm” button

Every quarter there’s a full-site evacuation drill. The file goes in a folder called Evacuation. On the day, HR opens the Web Remote, picks Evacuation from the folder dropdown, and hits Test Alarm. The siren hits every zone simultaneously, and the playlist log records exactly which file played at which timestamp — useful when filling out the drill report.

Keeping it running

A factory floor PC reboots whenever the electrician feels like it. Multilarm is launched from Windows Task Scheduler on boot (At startup → Run whether user is logged on or not). The only state that survives reboots is the XML config — everything else is either derived from the schedule or persisted to log files with AutoFlush enabled, so no playlist entry is lost to a power cut mid-write.

Off-site monitoring is handled with the Cloud Relay: the factory PC posts status to a tiny PHP endpoint every 30 seconds, and the operations manager’s laptop pulls that status from anywhere on the internet. No open ports on the factory firewall, no VPN.

Takeaways

This is the use case that most justifies the up-front investment in learning the XML. After setup, no one touches the PC for months. Try it before quoting another bell-scheduler appliance.