A panel reads a daily recipe file only in the format its own software exports. Export one recipe sheet to get that format, convert each day's list on the master computer, push it to every panel by FTP, and verify the values on one panel before the remaining panels get the file.
A day of saw cut lists is one file per panel, written once on the master computer and delivered before the shift that uses it. The catch is the format. Recipe sheets follow a format and syntax the panel's own software defines, and a file outside that format can load with erroneous values, so renaming an ordinary CSV to a recipe file name does not make it one.
The reliable route is to let the panel software show you the format, build each day's file to match it, and push the file to every panel over FTP. Verify the values on one panel before the file goes to the rest.
How a panel takes a daily recipe file
The documented mechanism is file replacement. The panel project stores each recipe sheet as a file, the panel software exports that file, and a copy with the same structure replaces the sheet on the panel. Delivery is therefore a computer job: the master computer writes the day's file to each panel over the network, and the panel handles it as one of its own sheets.
The export decides the structure. A spreadsheet's default save is not the authority, because the recipe sheet's format and syntax are specific to the panel software, and a file outside them can load with erroneous data even when the transfer completes. How the replaced file becomes active, whether at once or when the recipe screen next opens, is stated in the panel software's documentation; confirm it on the pilot panel.
A PLC that calls the computer for a file is a separate design. It needs a transfer function both sides document, a trigger, a completion check and a retry rule, and it is built and tested on its own.
What you need
- The panel project, open on the master computer, with the recipe structure as the panels run it.
- One exported recipe sheet from that project, kept untouched as the template.
- The day's list as data: saw identity, the values, and the recipe name each saw expects.
- FTP access to each panel: address, account and recipe folder, from the panel's documentation. Connecting an FTP client to an HMI panel over Ethernet covers the first connection.
- A mapping of panel address to saw, one line per panel.
- A known-good copy of every panel's current recipe file, held on the computer. The habit behind it is the same one that carries a panel through a project download: back up HMI recipe files before any file work.
Build the daily file from the panel's own export
- Open or create a representative recipe sheet in the panel software, with the fields the saw recipes really use, and export it.
- Open the export in a spreadsheet and read it: header row, delimiter, quoting, column order. Leave this copy untouched; it is the template.
- Map each field of the daily list to a template column by name. The header is the contract, because column order can shift between exports.
- Fill a copy of the template with the day's values and save it as CSV in the same form the export used. The format must survive the round trip: different quoting or a different delimiter reads as different columns on the panel.
- Put the finished file beside the template and compare line by line before anything transfers.
- When a detail is unclear, search the panel software's Help for its recipe editing topic; that documentation shows how the exported sheet is edited and saved back.
Push the file to each panel over FTP
- Read the mapping and pick the first panel.
- Download that panel's current recipe file to the computer as the known-good copy for the day.
- Send the day's file into the panel's recipe folder and confirm arrival by file size in bytes. If the delivery script writes a directory listing to a file, avoid the FTP quirk that turns a directory listing into an empty file on some panels; the size check skips it.
- Move to the next panel and repeat, one transfer per line of the mapping.
- Log each transfer: date, panel address, saw, file name, size, complete.
On the computer side this is a scheduled job: one file per panel, sent on a fixed clock, with a completion check before the job logs off. Schedule it to finish at least 30 minutes before the shift that runs the list, so a failed value still leaves time to rebuild and re-verify. The configuration used to run FTP services for daily automated file transfers is the same pattern.
Example: one computer feeding 24 saw gauges each day
The inputs, and where each comes from:
- One master computer writes the day's lists. That is the setup the question starts from.
- 24 panel screens, one on each saw gauge. That is the fleet size in the case this article answers.
- 1 recipe file per panel per day. Each gauge gets its own list for the day.
- 1 pilot panel, verified before release. That is the rule this article recommends.
The rule in words: one panel checks the day's format, and the release to the rest follows that check.
The arithmetic:
- 24 panels x 1 file each per day = 24 files per day, so 24 transfers per day.
- The pilot is panel 1, which leaves 24 - 1 = 23 panels for the release.
- Total transfers for the day: 1 pilot + 23 release = 24.
The result: the day's format is checked and confirmed on 1 of the 24 panels before the other 23 see it.
The decision: when panel 1's values match the approved list field by field, the same file format goes to the remaining 23 the same day. When panel 1 loads with wrong values, fix the master file and re-pilot. The gate is one verified panel, and nothing ships before it.
How to check it worked
- Open, on the panel, the recipe the saw will run, and compare every value against the approved list, field by field.
- Check identity against the mapping. A correct transfer to the wrong saw is still a production error.
- Run the machine's normal controlled validation before the list governs production. That is the safety gate: a completed transfer confirms delivery; it does not confirm content.
- If any value fails, restore the panel's known-good file and stop the rollout until one panel passes.
When values come out wrong
- Old values after a completed transfer: the file went to a folder the project does not read, or the panel reads the recipe only when the recipe screen next opens. Check the folder against the project's documentation, then open the recipe screen and look again.
- Values shifted between columns: the saved CSV drifted from the export in delimiter or quoting. Rebuild from the template, re-save, and compare line by line.
- Erroneous data in the recipe: the structure or syntax left the export's format. Restore the known-good file and rebuild from the untouched template.
- Rows missing at the end of the list: the recipe table was sized for fewer rows than the day carries. Check the HMI recipe table row limit before the change ships.
Recommendation
Recommendation: Export one recipe sheet from the panel project and build every daily file to that export's exact format. Send the day's file to one panel, verify its values field by field, and release to the rest only after that check passes. For a fleet this size the pilot costs one extra transfer a day and keeps a format mistake off every saw at once.
Questions
What happens if I rename my spreadsheet export and send it as the recipe file?
Structure is what the panel reads: the header row, the delimiter, the quoting and the column order of the exported sheet. A renamed file carries none of that unless it was built from the export, and a file outside the recipe sheet's format and syntax can load with erroneous values even when the transfer completes. Build from the export, then check one panel first.
When should the daily push run?
Before the shift that uses the list, and early enough that one failed value still leaves time to rebuild the file and re-verify. A schedule that finishes 30 minutes before the shift gives you that margin on a 24-panel fleet. Keep each panel's previous file on the computer until that panel's recipe has been checked, so a bad day costs one restore per panel instead of a rebuild.
Do all panels expose an FTP server for recipe files?
No. FTP access is a feature of particular panel software, and the address, account and recipe folder come from that software's documentation and project. A panel without an FTP service still fits the workflow: export the sheet, build the file to match, and deliver it by the transfer method that panel does document, such as a USB stick or the project software's restore function.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.