Tie a work order number to trend log files

Can the panel write the work order into the trend file name?

In the default case, no. The trend file name is fixed when the project is built, so assign the work order on the archive PC and treat the panel's names as staging names. Most panel projects fix every trend log's name at design time, one name per trend screen. The runtime has no field where a work-order tag could flow into it.

Spend 20 minutes on the bench on the one exception worth testing. If your project documents a runtime field that feeds the file name, try it with an ordinary order number and open the file that lands on the PC before you trust it. If the documentation shows no such field, stop renaming at the source.

Editing a display label or the message text leaves the file name untouched, because the logger assigned the name when it wrote the file. The fixed staging name still tells you which trend screen wrote the file. The work order, the part the name cannot hold, joins it on the PC.

What do you need before the first live run?

You need four pieces in place before the first live run: a completion message that carries the work order in its text, an FTP drop folder on the archive PC, a script triggered by that message, and one bench run that exercises the whole path.

The message is the identity carrier. It already goes out when the profile finishes and it already names the work order in its body, so the script reads the order from there. Have the message carry the run-start time as well. If the finish stamp should come from the panel's alarm history instead, the article on logging job completion time with an alarm history shows how to record it against the batch.

The drop folder receives every upload under its original panel name, and nothing inside it gets renamed. The script owns all renaming, combining and deletion. The bench run confirms the message text, the upload and the trigger line up before a real batch depends on them.

What should one run be called on the archive PC?

Name every folder and combined file after the work order plus the run's start time, in the pattern WO-2417_2026-01-14_2220. An order number alone repeats when the same product runs again, and a timestamp alone says nothing about what was made. Pair the two values and the name is unique per run and readable a year later.

Take the start time from the operator's start action, never from a file's creation date, because the panel clock and the PC clock can disagree. Write the time zone into the manifest if the two machines are set differently.

The same run string appears in exactly three places: the folder name, the combined file name and the manifest line that lists the original panel files. Searching the archive for WO-2417 then returns one folder per run, each holding all of that run's parts.

Which characters can a work order keep in a folder name?

Strip a work order down to letters, digits, the hyphen and the underscore before it becomes a folder name. The nine characters file systems reserve for paths and wildcards would break the path. Desktop file systems reserve < > : " / \ | ? *, and one stray slash in an order number would split the path and drop the run into a different folder.

Sanitize in the script, in one place: trim spaces, upper-case letters if that is the house style, and replace any other character with a hyphen. Keep the operator's original entry in the manifest, so a sanitized folder name never loses what was actually typed. If operators append suffixes such as REV B, decide once how the space is handled and apply the same rule to every run.

What are the steps on the archive PC?

The archive PC runs one script each time a completion message arrives. The script works through the same six steps for every run, whether the panel produced one trend file for it or three.

1. Read the work order and the run-start time from the message, sanitize them, and form the run string, for example WO-2417_2026-01-14_2220.
2. Create the run folder under Completed/ and move the run's files into it from the drop folder, each under its original panel name.
3. Hold any file whose run string has no completion message yet; a partial log sent while the profile still runs stays staged until the finish message arrives.
4. Check each file's size twice, 60 seconds apart, and accept two identical byte counts as a finished upload.
5. Combine the parts in time order into one file named with the run string, and require the combined data-row count to equal the sum of the parts' rows, minus one header row per part if every part repeats the header.
6. Write the manifest with the original panel file names and sizes, the work order as typed, the run string, the finish time and the combined row count, and leave the original parts in the folder.

The bench run at the end of setup confirms the whole chain in one pass: message parsed, folder created under its run name, row count matched, panel trend folder empty after the delete. Two references cover the hardest step in detail. A walkthrough of consolidating midnight-split log files into one combined sheet works the same arithmetic on a comparable set of files. The article on combining daily HMI log files into one CSV covers ordering and column handling when several files merge.

When is a transfer finished and safe to combine?

A transfer counts as finished when the file's byte count is identical on two checks 60 seconds apart. A run counts as closed only when its completion message has arrived. The two conditions are separate events.

Reading the message as the end of the transfer is how half a run gets lost: the message can arrive while the last file is still moving, so each file clears the size check on its own. Make the gap between checks several times the trend's sample interval, so a finished file sits still between them. The 10-second sampling in the example below clears that bar with room to spare.

Match files to runs through the run string parsed from the message, and keep a file staged until its run's message has arrived. A byte count that grows between checks sends the file to the next pass.

Scenario: what does a run that crosses midnight look like?

A run can cross two calendar dates, produce two panel files and still end as one archive. This example spans 10:20 p.m. to 12:42 a.m., rolls at 12:00 a.m., and lands in a single folder named for the run.

Work order WO-2417 begins a ramp/soak profile at 22:20 on 14 January, and the trend samples oven temperature every 10 seconds. At 12:00 a.m. the panel rolls the log and opens a second file, the behavior covered in the article on how an HMI trend log file rolls over at midnight. The profile finishes at 00:42 on 15 January and sends the completion message with WO-2417 and the run start 2026-01-14 22:20 in its text.

Part 1 covers 22:20 to 24:00, which is 3 h 40 min, or 13,200 s, so it holds 13,200 / 10 = 1,320 samples. Part 2 covers 00:00 to 00:42, which is 2,520 s, so it holds 2,520 / 10 = 252 samples. The first size check reads part 2 at 15,120 bytes and the second check, 60 seconds later, reads 15,120 bytes again, so the upload has finished. The script combines the parts and expects 1,320 + 252 = 1,572 data rows; the combined file shows 1,572, so the run passes and moves into Completed/WO-2417_2026-01-14_2220/. The manifest lists both original panel names, the 15,120-byte part 2 and the 1,572-row total. A search for WO-2417 now finds one folder, whatever the calendar did between the start and the finish.

When can you delete the panel's trend files?

Delete the panel's copies only after the combined file exists, its row count matches the sum of the parts and the manifest is written. Until those three checks pass, the panel's files are the only copies that exist. The deletion makes room for the next batch, and it is also the one step that can destroy a finished record. Send the delete per file with its exact staging name, then list the panel's trend folder again and confirm it is empty before the next profile starts.

Two storage behaviors belong in the same plan. If the panel's storage fills, the logger may stop writing or roll files in a pattern you did not choose, and the article on confirming oldest-file rollover when the log drive fills shows how to check which file goes first. A power cycle can also clear trend data held in the panel, which is the risk behind the archive routine in the article on archiving trend data externally after a power cycle.

From the moment the first file lands on the archive PC, that PC is the record.

How do you stop a duplicate completion message from running the job twice?

Make the trigger idempotent. The script checks first whether Completed/WO-2417_2026-01-14_2220/ already exists and stops if it does, so a repeated or forwarded completion message cannot create a second archive or fire an early delete.

Rules-and-alerts triggers fire on every matching message and mail systems resend, so an archived run will eventually receive a second copy of its own message. Log each firing with the message time and the action taken, so a quiet double-fire shows up as "folder exists, skipped". The same gate protects the panel, because the delete command travels only on the first successful pass and every later pass stops at the folder check.

Recommendation: Keep the panel's trend name fixed and assign the run identity on the archive PC as work order plus run-start timestamp whenever one profile can cross midnight or produce more than one file. Gate each combine on the completion message plus two matching size checks 60 seconds apart, and send the panel-side delete only after the combined row count equals the sum of the parts.

Questions