Check first whether the logger overwrites or appends: a 60-second test and the file size tell you which. If one file per run is needed, type a new name before each run or build a time-stamped name from a documented time function such as now(), then prove the scheme with two short runs that leave two files.
A data log that puts every run into the same CSV behaves in one of two ways, and the right fix depends on which one you have. Check first whether the logger overwrites or appends. A logger that appends leaves every run in one growing file, and that may already be what you want. When you do need one file per run, there are two ways to get it: type a new name before each run through a text entry, or build a time-stamped name from a documented time function such as now(), evaluated fresh for every run. Either way, finish with two short test runs that must leave two files, each holding only its own rows. The sections below give the check, both methods, and the arithmetic that identifies the behavior from the file sizes.
Confirm append or overwrite first
The test takes about two minutes and changes no configuration:
- Stop logging. Write down the CSV's full path, its size in bytes and its row count.
- Start logging, let it collect 60 seconds at 1 sample per second, then stop.
- Compare the same file. New rows following the earlier ones and a bigger size mean the logger appends. A file holding only the latest run's rows means it overwrites.
Inspect a copy of the file, and never delete the only copy of logged data to make a test easier to read.
If the logger appends and one growing file is acceptable, you are done: keep the static name and tell operators that is the intended behavior. Give every row its own time stamp so reporting can filter runs by time; adding column headers to an HMI trend log file on USB keeps a merged export clean. If the logger overwrites, or job records need one file per run, use one of the two methods below.
What you need
- Access to the logging configuration and its object reference, the page that documents the file name input and any time functions.
- The output folder path, and room on the drive or USB stick for two small test files.
- A text entry object on a screen the operator already uses, if runs are started manually.
- The documented time and string functions, if names are built automatically.
- A file manager's details view, to read sizes in bytes.
Method 1: type a new name before each run
- Bind a text entry object to the file name the logger reads, on an operator screen.
- Before logging begins, type the name for the coming run. A job number or a run number works:
run-041is easy to say over a radio and sorts cleanly. - Keep the folder and the
.csvextension exactly as they are, so existing reporting and backup steps keep finding the files. - Start logging, run the job, stop logging.
- Enter the next run's name before the next start.
The order is the whole method: the name goes in before logging starts, every time, because that is also the sequence operators will follow on the floor. The typed name has one more advantage: it is visible on screen before the run begins, so a missed entry is caught before data collection, never after.
Method 2: build a time-stamped name
Automatic naming suits runs that start from a schedule or a machine signal, where nobody types anything.
- Find the time function your logging reference documents; a common one is
now(), which returns the current date and time. - Format that value into a name the PC accepts. A pattern in the form
YYYYMMDD_HHMMSSgives 15 characters, sorts chronologically, avoids the colon that Windows refuses in a file name, and sits well inside the 255-character file name limit Windows sets. - Confirm the expression is evaluated when each run opens its file. If every run produces the same string, the expression is being evaluated once, and the pattern to look for in the reference is a pulse timer feeding the time function, so a fresh event fires for every run and the string changes with it.
- Add a run counter to the name when two runs can begin in the same second: second resolution makes names unique only for runs that begin at least 1 second apart.
- Keep the folder and extension from method 1.
One naming rule can collide with another. If the logger also opens new files on its own schedule, how an HMI trend log file rolls over at midnight on USB explains what that logger writes, and per-run names need to fit inside that scheme.
Example: two 60-second runs and three outcomes
Say the logger writes one row per second with three fields: a 19-character time stamp, a 4-character temperature value such as 72.5, and a 1-character status digit. With a 2-byte line ending, each row is 19 + 1 + 4 + 1 + 1 + 2 = 28 bytes. The header row time,temp_c,run is 15 characters plus the same line ending, so 17 bytes.
Run A begins 07:42:05 and runs for 60 seconds at 1 sample per second: 60 rows plus the header, 61 lines, 17 + (60 × 28) = 1697 bytes. The time-stamped name built from the begin time is 20250314_074205.csv. Run B begins 07:45:00, collects the same 60 rows, and takes the name 20250314_074500.csv.
After run B, the sizes tell you which behavior you have:
| What the logger does | What you see | Lines | Size |
|---|---|---|---|
| Overwrites a static name | one file with only run B | 61 | 1697 bytes |
| Appends to a static name | one file with both runs | 121 | 1697 + 1680 = 3377 bytes |
| Unique name per run | two files, one per run | 61 each | 1697 bytes each |
The append case grows by exactly run B's contribution, 60 × 28 = 1680 bytes. So one file at 1697 bytes means overwrite, one file at 3377 bytes means append, and two files at 1697 bytes each mean the per-run naming works.
How to check it worked
Run the exact restart sequence operators will use, twice, then check three things:
- Two files exist at the expected full paths, and their sizes match the example's numbers for your row size.
- Each file holds only its own run: open a copy and check that the first and last time stamps sit inside that run's window, 07:42:05 to 07:43:05 for run A and 07:45:00 to 07:46:00 for run B.
- The names differ at the full path. The same base name in two folders is two files; the same full path is one file, whatever the configuration screen shows.
Screen captures fall into the same trap when every capture is written to one name; saving HMI trend screen captures without overwriting files covers that case.
If two runs still land in one file
Three causes cover it, and each has a test that separates it from the others:
- The name was entered after logging started, so the run opened its file under the old name. Test: check what the name field held at the moment logging started. Fix: make the entry step come before the start step, every run.
- The time expression is evaluated once, at download or startup, so every run reuses one string. Test: two runs minutes apart still produce the same name. Fix: drive the time function from a pulse timer so it sees a fresh event per run, as the object reference describes.
- Two runs began within the same second, so the formatted time matched. Test: compare the two begin times. Fix: add a run counter, which increments per run regardless of the clock.
More files also fill the drive faster. If the stick runs out mid-shift, work through the rollover check before blaming the naming: HMI USB log drive full: confirm oldest-file rollover first walks through it.
Pick the method and test it
Recommendation: Use the typed name when an operator starts every run, because the job number travels with the data and a missed entry is visible before logging starts. Use the time-stamped name when runs start from a schedule or a machine signal, with the YYYYMMDD_HHMMSS pattern and a run counter whenever two runs could begin in the same second. Keep the folder and the .csv extension unchanged under both methods, and put the scheme through the two-short-runs test before it carries production data.
Questions
My logger only accepts a fixed file name. What then?
Then the naming cannot change per run from inside the logger, so work with one growing file. Confirm it appends with the 60-second size test, give every row its own time stamp, and filter runs by time in your reporting. If the file must be split per run, look in the object reference for a string or tag input for the file name; where one is documented, a variable works even when the setup screen shows a fixed field.
How many runs fit on the drive before it fills?
With the numbers in the example, one 60-second run writes 1697 bytes, so a 1 GB drive holds about 589,000 runs of that size before it fills. Naming one file per run does not change the total bytes; it spreads them across more files. If the drive still fills mid-shift, your runs are longer or more frequent than the example, and the fix is rollover or regular archiving, not the file name.
Should the time stamp come from the PLC clock instead of the panel clock?
Either clock works, because the name only has to differ from one run to the next. Use whichever clock your logging reference exposes to the file name expression, and keep one clock for both the name and the rows. If the panel and PLC clocks differ, rows stamped from one clock and names built from the other disagree by the offset, and matching a file to its rows gets harder during an investigation.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.