Save the log to the computer and open the saved copy. A trend log that looks mixed when opened straight from the panel's FTP server is the viewer's rendering, not the logger: one row per sample, time, date, then one value per pen. The worked check below confirms it from the timestamps.
A data log that looks scrambled when you open it straight from the panel's FTP server is usually fine. Save the file to the computer first, then open the saved copy in a plain-text editor. The rows are already in order: one row per sample, a time of day, a date, then one value per trend pen. The mixed look is how the remote view lays the text out, and it goes away once the same file is read from the local drive.
This article gives you the five-minute version of that check: what each symptom points to, how to read a row, a worked example on a 14-row hourly log, and the exact point where the fault really is the logger.
What the mixed view is telling you
Work down this list. The first four are viewing problems and only the last one is a logging problem.
- Rows run together when the file is opened from the FTP location. The remote view is one program's rendering of the transfer. Save a copy to the local drive and judge that copy instead.
- The same saved file reads cleanly in a plain-text editor and jumbles in a word-processor-style editor. The second editor is re-wrapping long rows to its window width, which breaks the columns apart. Use the plain-text editor.
- Most rows read 0 0 0 0 and one pen picks up values partway through the day. That is a signal that moved, which is data. Compare the nonzero times with the trend on the panel for the same time of day.
- Rows step at an unusual interval, such as one row per second or one per hour. That is the interval the trend was configured to log at, and different trends log at different rates.
- The saved copy itself has rows out of time order, gaps, or rows with different field counts. Now the logger or its configuration is worth opening.
One file, two views. The gap between viewers is ordinary: a screen that fits on its local panel can scroll when the same view opens in another browser. Treat the FTP window as a preview and the saved copy as the log.
Save the file before you judge it
Do this in order:
- Leave the FTP window as it is and note the file name, so the original stays untouched.
- Download the .txt file to the computer's hard drive. Do not judge the log from the remote preview; that is the path that produced the mixed look.
- Open the saved copy in a plain-text editor, the kind that shows one line per row with no formatting.
- Read three rows: the first, one in the middle, the last. Each should carry a time, a date and one value per pen, and the times should ascend.
- If the saved copy reads cleanly, stop. The logger did its job.
Copy to USB when the panel is not on the network: write the log to a drive and read the file on the computer. Logs written to USB normally break into a new file at midnight, so pull one file per day for a shift's history; how a trend log file rolls over at midnight on USB covers that. A copy that stops after one day is a different fault, usually the copy button releasing when it should hold; that fix is written up separately.
The step worked when the saved file opens from the local drive and the timestamps still ascend.
Read a row as fields
The layout repeats on every row:
- Field 1: time of day as hours:minutes:seconds, for example 00:53:45.
- Field 2: date as month, day, year, for example 11-08-2009.
- Field 3 onward: one value per pen on that trend, left to right in pen order, separated by spaces.
There is no header line. The first line of the file is the first sample. A four-pen trend writes 6 fields per row, so counting the fields on any row tells you the pen count. Zeros are values: a pen that sits at zero at a sample time logs 0.
Judge the interval from the timestamps, because it is whatever the trend was set to. Rows stamped 09:37:36, 09:37:37 and 09:37:38 were logged at a 1 s interval; rows stamped 00:53:45 and 01:53:45 were logged hourly. A file that fills too fast is an interval choice, and a 10-minute interval for switch states is the usual answer when on/off states flood a log.
If you read logs in a terminal, the fold and fmt utilities wrap each long row at a width you set. Useful for scanning, and the saved file stays exactly as the panel wrote it.
Example: a 14-row hourly log with four pens
Inputs, from a log saved off a panel's FTP server, the kind of file this article is about:
- 14 rows. First timestamp 00:53:45 on 11-08-2009; last timestamp 13:53:45 the same day.
- 6 fields per row: a time, a date, then 4 pen values.
- Values: pens 1, 3 and 4 read 0 on all 14 rows; pen 2 reads 0 on rows 1 through 12, then 16 at 12:53:45 and 57 at 13:53:45.
The rule in words: a saved log is in order when every row carries the same field count and every timestamp lands exactly one sample interval after the row before it, with a row count equal to the number of intervals plus the first row.
The arithmetic:
- Interval: 01:53:45 minus 00:53:45 = 1 h 0 min 0 s. Spot-check the last gap: 13:53:45 minus 12:53:45 = 1 h 0 min 0 s. The log is hourly.
- Span: 13:53:45 minus 00:53:45 = 13 h. Expected rows: 13 intervals + 1 first row = 14 rows, and the file has 14.
- Fields: 2 (time and date) + 4 pens = 6 per row. Counted on the first and last rows: 6 and 6.
- Pen 2: 12 zeros + 16 + 57 = 14 values, one per row. The step from 0 to 16 at 12:53:45 is a signal leaving zero at midday.
Result: the file passes all three checks, so the rows are ordered and complete at the configured hourly rate.
Decision, with the threshold that flips it: while every row holds 6 fields and every timestamp steps exactly 1 h forward, the fault was the viewer, so keep the saved copy and drop any cleanup program. The first row with 5 or 7 fields, a timestamp that steps backward, or a missing hour moves the fault to the logger, and the trend configuration becomes the next stop.
Import into a spreadsheet to see the columns
A spreadsheet is a presentation step, and worth it once the saved copy has passed the checks:
- Copy the rows from the plain-text editor, or open the saved file through the spreadsheet's text import.
- In the import preview, set the delimiter to space so the time, the date and each pen value land in their own columns.
- Compare one spreadsheet row against the same row in the text file, field by field, before trusting the sheet.
If the preview pushes two fields into one cell or splits a value in two, change the import settings. The fix lives in the import dialog, not in the panel project. Keep the untouched .txt file as the reference if you save the sheet in another format.
A conversion program earns its place only when a downstream system needs a different file format, and only after the saved copy has passed the checks above. Run it on a copy of the file. No program can recreate values that were never logged, so the source file is always the evidence.
When the saved copy itself is wrong
Now it is a logging fault, and the file shows which kind:
- Timestamps skip an interval with no rows in between. Samples were not written. Power dips, a full log buffer and a removed USB drive are the usual causes; log buffer memory full errors on one screen have their own fix.
- Rows out of time order. Confirm in a plain-text editor first, because a wrapped view can imitate disorder. Two editors that agree the order is wrong point to the trend configuration.
- Field counts that differ between rows. A pen added or removed partway through the log, or a damaged line. Check the pen count you configured against the timestamps where the count changes.
For each of these, compare the logged values with the trend on the panel at the same times before changing the project. The saved file is the evidence.
The decision
Recommendation: save the .txt log to the computer and judge only the saved copy in a plain-text editor. If every row holds the same field count and the timestamps step by exactly one interval from the first row to the last, the logger is healthy, the FTP view was the fault, and no cleanup program or configuration change is needed. Open the trend configuration only when the saved copy itself breaks one of those two checks.
Questions
Why does the same log file look right in one editor and jumbled in another?
A plain-text editor shows each row as one line with single spaces between fields, which is how the panel wrote it. A word-processor-style editor re-wraps lines to fit its window and adds its own spacing, so a long row folds at an arbitrary point and the columns stop lining up. Neither view changes the file on disk. Judge the log from the plain-text view or a controlled spreadsheet import.
Should I write a small program to clean up the log?
Only when a downstream system needs a different file format, and only after the saved copy passes the checks in this article. If the rows are ordered, a cleanup program adds a step that can corrupt good data. Run any conversion on a copy and keep the original .txt as the reference. No program can recreate values that were never logged, so missing samples stay missing whatever the script does.
How do I know which sample interval a log used?
Read it from the file: subtract one timestamp from the next. Rows one second apart were logged at a 1 s interval; rows an hour apart were logged hourly. The interval is set per trend in the panel project, so two trends on one panel can log at different rates, and a new project can log at a different rate from the old one. Check each new log instead of carrying over the last one's rate.
Why are most values in the log zero?
Each pen logs the value of its signal at the sample time. A signal that idles at zero fills its column with zeros, and the value appears only for samples after the signal moves. In the worked example, pen 2 carried zeros for 12 rows and then read 16 and 57 on the final two. To check whether a zero is real, open the trend on the panel for that time of day and compare.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.