Whether an HMI panel pushes the oldest log file off a full USB stick is documented behavior of the exact model and firmware. Confirm it, size the stick for twice the upload interval if rollover is documented, and pull the logs at the half-full point if it is not.
A USB stick that fills during data logging fails in the worst direction: logging stops, the old files stay, and the newest records, the ones you were waiting to upload, are the ones that never get written. Whether the panel pushes the oldest file out at that point is a documented behavior of the specific model and firmware revision, so confirm it before you trust the log. Then handle the stick one of two ways: size it for twice the upload interval if rollover on full is documented for your combination, or pull the logs at the half-full point if it is not. This page gives the checks, the sizing arithmetic, and a spare-stick test that settles the question before production records are at risk.
What a full stick does to the log
A logger writing to a USB stick has two possible full-condition behaviors, and they leave opposite fingerprints on the file list:
- Stop at capacity. The logger halts when the stick is full. The oldest files stay, the newest records are missing, and the gap grows until someone pulls the stick. With uploads every few months, the lost window is the last weeks before the pull.
- Replace the oldest file on full. The logger keeps writing after the stick is full by displacing the oldest file first. The newest records always exist, and the stick works as a rolling window whose length is usable capacity divided by the daily file size.
The first case looks like a logging fault, but the logger and the machine are fine: the destination ran out of space. Match what you see on the stick to a cause:
- Stick at capacity, oldest files intact, newest records missing: the logger stopped when full. Rollover is not active on this panel and firmware, or it was never confirmed.
- Stick at capacity, newest records present, earliest files gone: rollover is active. If a file you expected is already gone, the retention window is shorter than you planned, so redo the arithmetic.
- Files disappear while free space remains, or a new file appears at midnight: a separate file schedule is at work, and the midnight log file rollover on USB explains the daily boundary.
- The newest file's timestamp stops advancing while free space remains: logging stopped for another reason. Check log buffer memory full errors first, then test the USB drive with a known-good stick.
Confirm the behavior for your model and firmware
Write down the panel model and the firmware revision it reports before you change anything. The revision is also the first thing to check before a project transfer, and where to find the HMI firmware revision shows the way to read it.
Then open the data logging section of the documentation for that exact model and look for one statement: what the logger does when the storage destination is full. The useful answers are stop-at-capacity and replace-the-oldest-file-on-full. If the manual is silent for your combination, ask the panel maker's technical support with the model, the firmware revision, and the logging configuration in hand, and get the answer for your exact combination.
Two rules keep the confirmation honest. Tie the answer to the model and firmware actually installed, because families differ and the rollover behavior arrived with later firmware on some families. And do not put a firmware update on a running production panel just to gain the feature; schedule the update in a maintenance window with the maker's documented procedure, and verify the new behavior on a spare stick afterwards.
Size the stick for twice the upload interval
The rule: usable capacity ÷ daily file rate = retention in days, and retention should be at least twice the upload interval. Twice covers a completely missed upload, because the next successful pull still reaches back over the skipped interval.
Measure the daily rate instead of estimating it. Pull the stick once, count the days of logging the files cover, and divide the used space by that count. A logger that starts a new file each day makes the count easy, and per-day files are small enough that no single file grows to a size that challenges the stick's file system limits.
Plan on about 90 percent of the printed capacity as usable, the rest going to formatting overhead and the slack space each file occupies, and read the real number off the stick after formatting. Then buy the next common size above the result. A stick that fills on the morning of the upload has no margin, and the margin is the whole point.
Worked example: 20 MB per day, uploaded every 90 days
A food plant logs one file per day. A pull after 30 days shows 30 files totalling 600 MB, so the daily rate is 600 MB ÷ 30 days = 20 MB/day.
The upload interval is 90 days. One interval of data is 20 MB/day × 90 days = 1,800 MB, or 1.8 GB. The rule asks for twice that: 2 × 1.8 GB = 3.6 GB usable. With the 90 percent planning allowance, the stick needs 3.6 GB ÷ 0.9 = 4.0 GB printed, and the next common size up is 8 GB.
The 8 GB stick delivers 8 GB × 0.9 = 7.2 GB usable, so retention is 7,200 MB ÷ 20 MB/day = 360 days, four full upload intervals. Two consecutive missed uploads still leave every record on the stick.
If rollover is not documented for this panel and firmware, run the same stick differently: pull at the half-full point. Half of 7.2 GB usable is 3.6 GB, and 3,600 MB ÷ 20 MB/day = 180 days between pulls. A pull that slips a month past its date still finds room on the stick, and nothing has been lost to a full destination.
Test the behavior on a spare stick
Run the confirmation once, on a spare stick, before production records depend on the answer:
- Copy every file off the production stick to a PC and open a few of them to confirm the copies are good. Leave the production stick unchanged until the copies check out.
- Format a spare stick the way the panel's documentation directs and put it in place of the production stick during a maintenance window.
- Write down the date, the files present, and their timestamps.
- Let the logger run until the stick is full. At the example rate, a 1 GB spare fills in 1,000 MB ÷ 20 MB/day = 50 days. If the project software allows a faster logging interval for the test, the full condition arrives sooner; restore the production schedule afterwards.
- Pull the full spare and read the file list. Newest records present with the oldest file gone is rollover working. Oldest files intact with the newest records missing is stop-at-capacity.
- Compare timestamps against your notes to confirm the displaced file was the oldest and the middle files were untouched, then label the spare and put the production stick back.
The test also measures the true usable capacity, because you watched the stick fill.
The fix, for each case
If replace-oldest-on-full is documented for your exact model and firmware: size the stick for twice the upload interval, run the spare-stick test once to see the pattern with your own files, and keep the upload on its schedule. Rollover is capacity insurance for a missed upload; it does not remove the upload, because a displaced file exists nowhere else.
If the behavior is not documented for your combination: plan on stop-at-capacity. Size the stick for one upload interval, pull at the half-full point, and keep a second formatted spare at the panel so the swap takes a minute. If you copy logs through the panel's own USB copy function and it stops after a day, the USB log copy hold setting covers that separately.
And when a failure does happen, pull the stick before anyone restarts or clears anything. The stick holds the record of what the machine was doing, and it is the only copy.
Recommendation: confirm the full-condition behavior in the documentation for your exact panel model and firmware before relying on the USB log. If replace-oldest-on-full is documented, size the stick for twice the upload interval, verify the pattern once on a spare stick, and keep the scheduled upload. If it is not documented, size the stick for one interval, pull the logs at the half-full point, and keep a formatted spare stick at the panel.
Questions
Does deleting old files by hand fix a full USB log stick?
Manual deletion frees space once, and the logger runs until the stick fills again and stops, so the condition returns at the next capacity date. Deleting by hand also creates no rolling window. Treat deletion as part of the recovery after a missed pull, with the files copied and verified first, and let the sizing rule keep the stick ahead of the schedule instead.
Should the upload happen more often than the sizing arithmetic says?
The arithmetic sets the longest safe interval, not the best one. Anything that changes fast on the floor, alarms, batch records, process faults, is worth pulling weekly or after every shift that had a problem, because the value of a log decays with the memory of the people who can explain it. Size for twice the interval and pull sooner when the data matters.
Can the logging stick also hold panel project backups?
Keep one stick for logs only, and label it. Backups sharing the stick make the full condition arrive earlier than the arithmetic says, and sorting out which files matter gets harder during a failure investigation. Give project backups their own labeled stick, and keep the log stick with the panel so whoever responds to a fault pulls the right one.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.