The on-screen alarm history is a 64-entry display buffer, not an archive; the 65th alarm overwrites the oldest. Tick Save file to USB on each alarm event in the Event Manager Event Edit window so every event also writes to a stick, then verify the file path with a controlled test that includes a 65th event rolling off the screen.
An alarm history that stops at 64 entries is working as designed: the on-screen list is a display buffer, and the 65th alarm overwrites the oldest. The display count is fixed; the answer is a second retention path on removable storage. In the Event Manager, open the Event Edit window for each alarm event and tick the "Save file to USB" checkbox. The screen keeps its 64-entry behavior; the memory stick accumulates a record for every ticked event. Tick the box on every alarm that must be kept, save the project, then verify the file path with a controlled alarm test that includes a 65th event. Once the file path is confirmed, the stick is your alarm archive and the raw material for daily logs.
Why the list drops the oldest entry
The screen list holds the newest 64 entries and no more. Alarm 65 pushes entry 1 out, alarm 66 pushes entry 2 out, and the list length never changes. That fixed capacity is a ring buffer: a set number of slots and a write pointer that wraps to the top. It is sized for what an operator needs during a shift, and it was never an archive.
If you want a count you choose, move the log to the PLC and keep it in a circular event buffer with separate read and write pointers; the setup is in the article on logging PLC alarms to a circular event buffer. A buffer you size yourself also sidesteps the display limit, because the panel's list is no longer the record that matters.
Symptoms and what each points to
- The newest entries are right, the oldest vanishes, and the list stays at 64. The display buffer is full and doing what it was designed to do. The fix is file saving, not a display setting.
- An alarm never appears even among the newest entries. The event is missing from the Event Manager or its PLC input is not changing state. A file setting archives only events the panel receives, so check the event definition and the input state first.
- Records vanish after a power cycle as well as when the list fills. That is a second retention problem, and trend data behaves the same way; the external-archive method is covered in the article on archiving HMI trends after a power cycle.
- The stick is connected but no file appears. Either the checkbox is missing on that specific event or the stick itself is unreliable. The article on testing a USB drive an HMI panel cannot read covers the drive side.
Turn on file saving for each alarm event
- Open the Event Manager in the panel's design software and open the Event Edit window for the first alarm that must be kept.
- Tick Save file to USB.
- Repeat step 2 for every alarm event that must be archived. The checkbox is per event: one ticked event writes its own records, and an unticked alarm keeps rolling off with the rest.
- Save the project and download it to the panel with your normal workflow.
- Insert the memory stick, trigger a known alarm, and confirm a new record appears on the stick before you rely on the archive for anything.
The screen list keeps its 64-entry behavior after this change. The file path runs alongside it: the display shows what the operator needs this shift, and the stick keeps what maintenance needs next month. The same alarm bit that drives the event can drive other event actions too, such as the event-triggered screen change from a PLC alarm bit.
The same job on other panels
One design tool documents an event command that exports the alarm history, with the destination set to USB or SD card in the command's Destination box. Another documents a Backup History switch in the alarm page of its common settings menu, with a Mode tab that controls the saved file. A third keeps archived alarms in a historical data alarm log that an alarm view displays. The names differ; the shape is the same: a documented switch or command that sends alarm records to removable storage while the on-screen display keeps its own count. Whichever panel you have, the verification below applies unchanged.
Prove the archive with a controlled alarm test
Trigger test alarms only on conditions you control, never by forcing a real alarm input while the line is running.
- Note the time and the identity of the alarm you will trigger.
- Trigger it once, confirm it appears in the on-screen history, and confirm its record on the stick.
- Trigger a second configured event as well. This catches the most common mistake: ticking the box on one event and assuming the rest are covered.
- Generate 65 alarms in total, for example by toggling a test input 65 times, then confirm the first record is still on the stick after its entry has rolled off the screen. That one check separates the file archive from the display buffer, and it confirms the archive holds what the screen no longer does.
- Open one file from the stick and read it, so you know the format before anyone builds a report on it.
Example: how quickly 64 entries turn over
Say a packaging line raises about 30 alarms per 8-hour shift and runs three shifts a day, so about 90 alarms a day. The screen list covers 64 ÷ 90 = 0.71 of a day, about 17 hours. Over a 30-day month the line raises 90 × 30 = 2,700 alarms. After that month the stick holds all 2,700 records, and the screen still shows the newest 64, which now represents only the last 17 hours of running. Any alarm older than 17 hours exists only in the file archive. Turnover scales with alarm rate: at 10 alarms a day the same 64 entries cover 64 ÷ 10 = 6.4 days. Divide 64 by your daily alarm count to get your own turnover time in days.
Keep the file archive trustworthy
- Pull files on a fixed schedule. The example line adds 90 × 7 = 630 records a week, so a weekly pull keeps each transfer small and the routine predictable.
- Remount the stick only while no alarm is being written, so a pull never interrupts a record.
- Keep a second, formatted stick ready, so a failed or suspect stick can be swapped without hunting for media.
- If a record fails to appear, check in this order: the checkbox on that exact event, the event's appearance in the on-screen history, then the stick itself. The first two are configuration; the third is media.
Recommendation: Leave the 64-entry display alone, tick "Save file to USB" on every alarm event that must be kept, and run the 65-event roll-off test before you treat the stick as an archive. After that, pull the files on a fixed schedule and only while no alarm is being written.
Questions
Does the saved file come out as a CSV?
The documentation checked for this setting names the destination, a USB stick, and leaves the file format to the panel. CSV is common: one panel family documents CSV output from its Backup History switch. Open the first file your controlled test writes and confirm the format before you build a report or import routine on it.
Can I raise the 64-entry display limit instead?
No documented setting raises the on-screen count, so the panel keeps showing the newest 64 entries while the stick accumulates every ticked event. If operators need longer on-screen coverage, move the log to the PLC and keep it in a circular buffer of your own size, then display that buffer on the screen. That also frees you from the fixed count entirely.
What happens when the USB stick is full or missing?
Treat stick removal, a full stick and a write interrupted by removal as unknown behavior; the checked documentation covers the setting, not those failures. Design around it: size the stick well above a month of records, pull files on a fixed schedule, and remount the stick only when no alarm is active. The 65-event test tells you within minutes whether writes are landing.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.