An HMI panel writes an alarm history only while the project logs alarm events to a card or USB stick, with FTP access enabled when the project is downloaded. If logging was off, the file does not exist; here is how to check, how to switch logging on, and how to pull the file.
An alarm history file exists on the panel only if the project was writing alarm events to a memory card or USB stick while they happened. The alarm list the operator sees is panel memory, not a file. No PC connection turns it into one. This page separates the two, walks the checks in the order that finds the cause fastest, and sets up logging and FTP retrieval so the next alarm lands in a file you can open. It is a controls question that comes up wherever an HMI is the only record-keeper on the line.
Why won't my HMI panel give me an alarm history file?
The panel writes an alarm history only when the project was logging alarm events to a memory card or USB stick while they happened, with FTP access enabled at download time. The alarm list on screen is panel memory, not a file you can download.
The panel keeps two different things. The alarm list is a display buffer for the operator, with the cap covered in the article on saving more than 64 alarms from an HMI history to USB. The history file is a separate write path: the project logs each event, with a timestamp, to the medium selected in the project, and that write has to be configured and running while the alarm occurs. A stick inserted on Tuesday cannot hold Monday's alarms, because nothing on the panel was listening on Monday.
What do the symptoms tell you?
Match what you see to the cause before you change anything: alarms on screen with no file means logging was never active, a connect refusal points at FTP disabled at download, and an empty or short file means the medium was absent or logging started late.
- Alarms show on screen, no file on the PC. Logging was never active. The events lived in the display buffer and went with it.
- The FTP client cannot connect at all. The FTP server option was probably not enabled when the project was downloaded. Client settings on the PC will not change that.
- It connects, the folder is empty. The medium is missing, or the project logs to a destination other than the one you expected.
- The file exists but the oldest events are missing. Logging began after those events. Compare the file's first timestamp with the date logging was enabled.
- The log stops partway. The stick was pulled while the runtime was running with logging active, and the file ends where the stick left.
What do you check before you touch the PC?
Work through four checks in order: whether the project logs alarms, which medium it targets, whether FTP access was enabled when the project was downloaded, and whether the events you need fall inside the period logging was active.
- Open the project's alarm logging settings. If there is no logging configuration, the panel has no history to give, and no PC-side effort creates one.
- Match the destination to the hardware. Confirm the project's target medium is the one installed. A stick in the slot is not the same as logging aimed at the stick.
- Check the transfer settings the project was downloaded with. The FTP server option lives with the panel's download and transfer settings. If it was off at download, the panel refuses connections now.
- Compare event times with the logging period. An alarm from before logging started will not be in the file, however complete the file looks.
How do you turn alarm logging on for next time?
Fix it in the project, not the PC: select the card or stick as the alarm log destination, enable the panel's FTP server option in the transfer settings, download the project through your approved change procedure, then prove it with a forced test alarm.
- Choose the alarm log destination in the project: the card slot if the panel has one, otherwise the USB stick.
- Enable the FTP server option in the panel's transfer settings, in the same edit.
- Download the revised project and confirm the runtime is running it.
- Insert the medium before the runtime starts. The next section explains why the order matters.
- Force one known alarm, confirm a new record appears on the medium, and pull the file over FTP the same day. Pick a test input at changeover, or one that stops nothing, so the test cannot take the line down or mask a real fault.
- Write the enable date, the destination and the retrieval steps into the maintenance record. Every event before that date is a known gap.
Why must the USB stick be in before the panel starts?
Because the logging service mounts the medium when the runtime starts: a stick inserted after startup covers only the alarms from that moment, and the rule on one panel family is stick in before runtime start, stick stays while logging is active.
One panel vendor states this in its documentation on USB alarm data log storage: the drive should be plugged in before the runtime starts and must not be removed while the runtime is running and logging is active. That ordering is worth adopting on any panel. Plug the stick in during a planned stop, let the runtime come up with the medium present, and leave it there. Everything between startup and the moment someone walked over with a stick is unwritten, and pulling the medium mid-write risks the file itself.
How do you pull the alarm log off the panel?
Two documented routes exist, and the panel decides which one you get: FTP over TCP port 21 to browse the storage folders, or a built-in export from the settings screen once a card or stick is inserted. Check your project's transfer settings first.
FTP. Point an FTP client at the panel's IP address; the control connection uses TCP port 21. If the client connects but hangs on the directory listing, switch the client to passive mode before you suspect the panel. One panel family keeps its logs in \Storage Card SD\ and \Storage Card USB\, with data logs, alarm logs and audit trail files side by side in the same storage folders; browse in and take the alarm files.
Export. One HMI family documents alarm history export in its runtime help: insert the SD card or USB drive so the alarm log service can export, open the Settings screen and select Data Export.
Rollover. If today's file looks short, log files can roll over by date and start a new one; the article on an HMI trend log file rolling over at midnight on USB shows the pattern.
Example: how much storage does a year of alarms need?
Far less than any card you can buy: at 150 alarm events a day and 200 bytes per record, the line writes about 11 MB of alarm history a year, so a 64 MB card holds roughly 6 years and a 512 MB stick holds about 47 years.
Scenario: a packaging line running three shifts logs about 50 alarm events per shift, 150 a day: jams, faults, guard openings. Assume 200 bytes per record, which is a roomy plain-text line with a timestamp, a tag name and a message.
- Yearly events: 150 events/day x 365 days = 54,750 events.
- Yearly bytes: 54,750 events x 200 bytes/event = 10,950,000 bytes, about 11 MB.
- 64 MB card: 64,000,000 bytes / 10,950,000 bytes per year = 5.8 years, call it 6.
- 512 MB stick: 512,000,000 / 10,950,000 = 46.8 years, call it 47.
The decision: at alarm rates, capacity never binds, so pick the medium for durability and the size for your retention policy. The number that moves the answer is the event rate. A line writing a record for every rejected bottle at 1,000 records a minute produces 1,000 x 60 x 24 x 365 = 525,600,000 records, about 105 GB a year at 200 bytes, and that is data logging: a different tool and a different medium decision.
Should you log to a CF card or a USB stick?
If the panel has a card slot, use the card: a card is built for industrial socketed use, while a consumer stick is cheaper and bigger but handles shop-floor abuse badly, starting with static discharge measured in kilovolts.
The published ranges people quote for a person walking across a carpeted floor run from about 2 kV to 35 kV in dry air. A consumer stick handed around the shop can take a discharge through its shell or connector; sticks that lose everything after one zap are a familiar field story. A card is built for socketed industrial use and takes that treatment better. The stick's case is cost and capacity, and the example above shows capacity is not the deciding factor at alarm rates. Sticks can also drop writes under very high logging frequency, which alarm history at about 11 MB a year never approaches.
| CF card | USB stick | |
|---|---|---|
| Durability | Built for socketed industrial use; tolerates static and handling | Consumer build; static discharge and repeated insertion cycles are the weak points |
| Cost and capacity | Smaller and pricier per GB | Cheap and large |
| Fit for an alarm history | First choice when the panel has a slot | Fine at alarm rates if inserted before start and left in |
Recommendation: log to the card slot when the panel has one and enable the FTP server option in the same download; use a USB stick only where there is no slot, insert it before the runtime starts, leave it in while logging is active, and size the medium by your retention policy, because even a 64 MB card holds about 6 years of alarms at 150 events a day.
What can you still do when the old alarms are gone?
Treat the gap as closed history and build the record you wish you had: photograph the on-screen list before any power-down, check whether the PLC kept its own alarm registers, switch logging on now, and write the enable date into the maintenance log so the gap is documented.
Photograph or print the list during a planned stop, because a power cycle clears a display buffer. If the PLC has spare registers, a circular event buffer with separate read and write pointers keeps an event history independent of the panel. Once logging runs, the file starts earning its keep: job times, event counts and timestamps read straight out of it, as the article on recording job completion time with an alarm history shows. One boundary worth stating: a panel running your project is a poor wall notice board, and if the crew needs a board of its own, that is a separate shop-floor screen doing its own playback job.
Questions
What clock do the timestamps in an alarm history use?
The panel's real-time clock, so a drifting or reset clock moves every event in the file. Check the panel clock against the plant time source on the day you enable logging, and after any power-down or project download, because an event logged at the wrong time reads as if it happened in the wrong order against shift and batch records.
Does an alarm history file survive a power cycle?
Yes, once it is on the card or stick. The file is written as events happen, so it behaves like any file on removable storage and is still there after a power-down. The display buffer is the part that clears, which is why the list should be photographed before a planned stop if it holds events you need.
What format is the alarm history file?
Whatever the project was configured to write, most often comma-separated text or a plain text line per event that any text editor opens. There is no universal filename either: some families keep alarm logs beside data logs and audit trails in the storage folder, so check the folder listing instead of expecting a fixed name.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.