The panel starts one new .txt file for each trend graph every midnight, named for the screen, the graph and the date, inside the LOG folder on the USB stick. The folder itself never rolls over, so a history that looks missing is usually a wrong destination, a misread date token or a wrong panel clock, checked in that order.
A trend log that seems to vanish at day's end has usually gone nowhere. The panel writes one new .txt file for each trend graph every midnight into the LOG folder on the USB stick, and every filename carries the screen, the graph and the date. The folder itself never rolls over, so yesterday's data sits in yesterday's file, under the same name, all month and all year. When a history looks incomplete, the cause is almost always one of four things: the files are on a different stick or path, the filename was read as something it is not, the panel clock is wrong, or the graph's logging is off. This page covers what the panel writes each night, how to read the filename, a worked count for a full month, and the order to check when a log comes up short.
What happens at midnight
The event that repeats is a file, not a folder. At midnight, 00:00 on the panel's own clock, the panel software creates a new .txt file for every trend graph with logging enabled. Each graph gets its own file, so a panel with three logged graphs creates three files at that moment. The LOG folder on the stick stays as it is: no new folder appears daily, weekly or on any other schedule. There is no folder rollover to configure and none to wait for.
Old files keep their names and their places, so the daily rollover overwrites nothing. Tomorrow's filename carries tomorrow's date, and that name does not exist on the stick until midnight creates it. The date in each new name is the panel clock's date at the moment of creation, which is why the clock turns up again in the checks below.
What the filename tells you
A filename has three parts in a fixed order: the name of the screen the graph sits on, the name of the trend graph object, and a six-digit date token. A file from a working panel looks like this:
103 TEMP-GAS LOG_LineTrendGraph1_080812.txt
Read it from the front. 103 TEMP-GAS LOG is the screen. LineTrendGraph1 is the graph object on that screen. 080812 is the creation date, two digits each of year, month and day: 08, 08, 12 is August 12, 2008. The extension is .txt, so a plain-text editor opens the file and a spreadsheet imports it.
Year-first ordering has a practical payoff: the folder sorts itself. Sorted by name, one month's files from one graph run 080301, 080302, 080303 and upward to 080331, year then month then day in order. One month's files share a four-digit prefix, 0803 for March 2008, so a month of logging lifts out of a year-long listing as one block.
Example: one graph through a 31-day month
The case: a six-inch panel with one log trend graph on one screen, and a USB stick that stays in all month. March has 31 days.
Inputs, and where each comes from:
- 1 trend graph with logging enabled: the project setup behind the sample filename above
- 31 days in the month: the calendar
- 1 new .txt file per graph per day at midnight: the rollover behavior described above
- filename pattern, screen name plus graph name plus six-digit token: the naming shown above
The rule: expected files for the month equals graphs times days, and every file from that graph shares the same screen and graph prefix, differing only in the token.
The arithmetic: 1 graph × 31 days = 31 files. Tokens run 080301 through 080331, one per day, no gaps.
The result: with March over, the stick's LOG folder should hold 31 files named 103 TEMP-GAS LOG_LineTrendGraph1_0803 followed by the day token, 01 through 31, and the .txt extension.
The decision: count the files that match that prefix. At 31 of 31, writing, naming, rollover and the clock all work, and a history that looks missing is a reading problem, so start at the filename and the panel clock. Below 31, the first missing token is the day logging stopped, and that date is where the checks begin: was the stick out of the panel that day, and was the graph's logging still switched on?
Why a log looks short, checked in order
Destination first. Pull the stick from the panel itself and open the LOG folder on a computer. A file browser sitting at the stick's root shows only the folder, and it is easy to call the data gone one level too early. If the stick is the right one and the folder holds dated files, you are looking in the right place. Readers who move logs onward have one more stop: when a scheduled job on a PC copies the stick to a server, a missing destination folder is the usual reason copies fail without a word, and copy destination paths and missing folder fixes walks that failure through.
Filename second. Two misreads cause most phantom gaps. The first is expecting a new folder each day, when the daily event is the file inside the one folder. The second is reading the token in the wrong order, scanning for tokens that start with 03 for March when every March 2008 file starts with 08, the year. Then match the screen and graph names: a second trend graph on another screen writes its own files under its own prefix, and counting one graph's files against the other graph's month makes a full month look half empty.
Panel clock third. The token is the panel clock's date, so a clock set wrong stamps every file wrong and a search for the right date finds nothing, even though every day got its file. Compare the newest token with the date the panel itself displays. When the two disagree, fix the clock first; files written while it was wrong keep the wrong names. A clock that drifts or jumps by whole months is its own fault with its own fix, covered in Fix an HMI clock that rolls back months.
Logging setting last. A trend graph writes only while its logging is on. On this panel family, logging hangs off the trend objects, the line trend graph and the PID faceplate trend, each with its own Save Log Data setting, and even a graph with logging on writes nothing while the stick is out of the panel. If the first missing token lines up with a maintenance day, this is the answer.
An overnight test before you touch the project
- Read the panel's date and time off its screen and write both down.
- Confirm which stick is in the panel. If the panel has been writing to a stick nobody has pulled, finding it is the first result.
- Change nothing: leave the trend graph, its Save Log Data setting and the stick as they are, and let the panel cross midnight.
- The next morning, open the stick's LOG folder on a computer and sort by name.
- Look for a new .txt file whose token matches the new day and whose screen and graph names match your chart.
A file dated that morning ends the question: writing, naming, rollover and the clock all work, and the missing history is on the reading side. The newest token still showing an older date means the chain stopped, and the four checks above, in order, tell you where.
Recommendation: run the overnight test before editing anything in the project. If the stick shows a file dated that morning, leave the trend graph alone and fix the way the files are read, named or collected. If it does not, correct the panel clock or the logging setting, repeat the test once, and only then change the project.
What this changes about keeping histories
The daily count is small, one file per graph per day. The pile is not, because nothing rolls over or clears itself. Pull and archive the stick on a schedule that matches your retention rules; a month is the natural unit, because one month's files share a four-digit prefix and lift out of the folder as one block. Label the archive with the span the tokens cover, not the day you pulled the stick: the tokens are the only record of which days are inside.
The overwrite risk lives elsewhere on the stick. The daily log file is safe by construction, because each day's name is unique, but screen captures written to USB have their own overwrite habit, and Save HMI trend screen captures without file overwrite covers it.
Keep the trend file apart from the panel's other records. The graph's on-panel history buffer is a different thing from the file on the stick, and when the buffer fills, the trouble looks like a frozen panel, which HMI panel freezes when trend history fills panel memory explains. Alarm histories are separate again, with their own record limit on the panel, and save alarms beyond 64 to USB covers getting them off.
None of this touches the trend graph itself. The chart keeps logging the way it was built. What changes is that you can predict what the stick should hold on any morning and prove it within one midnight.
Questions
How many files does a year of trend logging create?
One trend graph produces 365 dated .txt files in a full year, because the panel writes one file per graph per day. Four graphs logging every day produce 1,460 files in the same period. File size is a separate matter: it depends on how many tags the graph logs and how often, and no figure for that is published here. Judge stick capacity by opening a few real files and reading their sizes.
What happens if the panel loses power in the middle of a logging day?
The documented event is the new file at midnight, and what happens to a file during a power cut later in the day is not covered here. The stick still tells you where you stand: every day that began with the stick in place and logging enabled has its own token, so the newest filename shows the last day a file was created. Any day the panel is running at midnight gets its file as usual.
Do alarm history records roll over the same way at midnight?
No. The alarm history is a separate feature with its own record limit on the panel, and it does not share the trend log's daily file. Treat the two as different jobs: the daily rollover belongs to trend graphs, while alarms keep their own history and need their own route off the panel once the on-panel records fill.
What is inside the .txt file?
The logged samples from that graph for that day, in plain text. The exact row layout depends on the panel software and on how many tags the graph records, and this page does not document it. Open the newest complete file in a text editor first and keep its column layout as the template for any spreadsheet import you build on top of it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.