Recipe data does not stream to the card as you edit. It reaches the card at the panel's save points: the project download that fills the Recipe Folder, the exit from an edited recipe sheet, or a manual export to a .csv file. Know which rule your panel follows, commit each edit at its save point, and check the card before you treat it as the recovery copy.
A CompactFlash card parked in slot 1 of an operator panel is a common insurance policy: if the panel fails, the card is supposed to carry the recipes to the replacement. The policy only pays if the card is current. Recipe edits do not stream to the card while the operator types. Every panel family writes recipe data at defined save points, and between those points the card still holds the old values. This page walks through the save points documented across panel families, shows with worked numbers what a power failure does to each, and gives the checks that make the card safe to trust.
The short answer
The card updates when a documented save point fires, and at no other time. Panel documentation names three save points:
- The project download. On families that keep recipes in a Recipe Folder on the card, the folder is populated when the project is downloaded with the card already in the slot.
- The exit from an edited recipe sheet. On the same families, the new data is written when the operator exits the sheet that was edited through the Call Recipe object.
- The manual export. Recipes export as .csv files to a USB stick, an external memory card or the project files folder, on families that support the export.
Which points apply to your panel depends on the family, and some panels use two of the three. The practical consequence is the same either way: a card that was current last week can be stale today if someone changed a recipe without hitting the save point.
The three save points, and what each costs in a power cut
| Save point | What the documentation says | Card becomes current | Power cut before it fires |
|---|---|---|---|
| Project download | The Recipe Folder on the card is populated when the project downloads with the card installed | At the download | The folder never receives the recipe sheets |
| Exit from the recipe sheet | The sheet edited through the Call Recipe object writes its new data on exit | On the exit | The edit is not on the card |
| Manual export | Recipe data exports as .csv to a USB stick, a memory card or the project files folder | When the export runs | The card keeps the previous export |
The exit is the one operators miss. The save is bound to leaving the sheet, not to changing a value on screen. An edit that is still open on the panel exists only in the panel's working memory, and typing it has put it nowhere else.
One family adds a timer that helps the panel but not the card. To spread wear on the panel's own flash memory, its documentation has the system save recipe data to the panel automatically every 1 minute. That minute is the window in which a power cut can lose the newest edits from panel memory. It does nothing for the card: after the timer fires, the panel holds the edit and the card still waits for the exit or the export. For the Recipe Folder family no automatic interval is published, so treat every un-exited edit there as unsaved.
The same rule reaches past recipes. Some operator-interface families document that online edits reach the disk only through a copy step, so storage updates on the action, not on the keystroke.
Why the card has to be in the slot at the download
On a Recipe Folder panel, the card is not a passive target that fills itself over time. The documented behavior ties the folder's contents to the download: card in slot 1 during the project download, recipe sheets in the folder afterward. A card that went in after the download, or a card whose history nobody remembers, has no claim to hold the current sheets. That is why the first recovery question is not what is on the card but whether the card was in the panel at the last download.
Panels with two card slots split the job: one slot carries the system image, the other carries user data, and recipes and logs belong on the user-data side. The manual names which physical slot that is. If the same slot also holds a logging card, recipe exports and log files share it; the notes on choosing the safe CF card slot for HMI data logging cover how to keep that card in the right slot. And because the folder is a download product, the download is also the moment to capture the recipes; see backing up HMI recipe files before a project download for that procedure.
Example: one recipe edit, two panels, power failure at 90 s
Inputs. An operator opens a recipe sheet, changes a mix time at t = 0 s, checks a second field, and exits the sheet at t = 70 s. The power fails at t = 90 s. The 70 s and 90 s are illustrative shift times; the documented values are the 60 s auto-save interval for the timer family and the save points themselves. Panel A follows the Recipe Folder rule, with the card installed in slot 1 at the last project download. Panel B follows the timer rule: recipe data saves to panel flash every 60 s, and the card updates only when an export runs.
Rule in words. The card is current only after its own save point has fired. The timer save point updates the panel, not the card.
Arithmetic.
- Panel A: the exit fires at t = 70 s. The failure lands at t = 90 s, which is 90 s − 70 s = 20 s after the save. The exit save ran, so the card holds the new mix time.
- Panel B: the timer interval is 60 s, and 90 s > 60 s, so at least one automatic save wrote the edit to panel flash before the failure. The panel comes back with the new mix time. The card received nothing, because no export ran and no exit save exists on this rule.
Result. After the same failure, Panel A's card matches the panel and works as a recovery copy. Panel B's card holds the old recipe, and nothing on the floor shows the difference until someone opens the folder or runs the export.
Decision. The threshold is the save point, not the clock. On the Recipe Folder family, the card is current one exit after the edit and stale before it. On the timer family, the panel is current once 60 s have passed, and the card is current only after an export. Either way, run the card check after the save point fires.
Check the card before you call it the recovery copy
Run these checks in order:
- Pin down the card's history first. Ask whether the card was in the slot at the last project download. If nobody can say, treat the folder as unverified and plan to repopulate it.
- Read the folder or run one export. Open the Recipe Folder through the panel's file access, or export to a USB stick or memory card and open the .csv on a PC. Compare the recipe name and two or three representative values against the sheet on the panel.
- Check after every committed change. The verification is minutes of work; a stale card costs a shift. After any project download, check the folder again, because the download is what wrote it.
- Plan the replacement path. The card carries the recipe sheets. The project, the screens and the panel settings come from the project download, so keep the master project copy where a technician can reach it; keeping a master copy against upload protection covers the copy discipline, and checking the firmware revision before a project transfer covers the match the spare panel has to meet.
- One safety rule. Before you pull a card or swap a panel, have the operator exit any open recipe sheet and power the panel down normally. A hard power cut loses every edit that had not reached its save point.
What this changes on the floor
The recipe card is a copy with a known refresh event, not a mirror. Build the refresh into the job: exit the sheet after every edit, run the export when the recipe is meant to be kept, and check the folder before the card's contents matter. Recovery then becomes a procedure: master project download, card in the slot, one sheet checked against the master, production back.
Recommendation: treat the card as current only after its save point has fired. On a Recipe Folder panel, have the operator exit the recipe sheet after every edit and check the folder before you rely on the card; on a timer panel, run the .csv export after every recipe change that is meant to stick. Keep the master project copy separate from the card, and rehearse the recovery once on a spare panel before a failure puts the recipe on the line. If the same cabinet or line also needs a standalone notice or status board for the crew, that is a separate screen with its own player; see our shop-floor displays.
Questions
Can I move the CF card straight into a replacement panel?
The recipe sheets on the card travel with it, but the replacement panel also needs the project downloaded, and the project expects a matching panel model and firmware revision. Download the master project first, then confirm the card's Recipe Folder contents, then load one recipe into a screen and check the values against the master. Treat the card as one input to the recovery and the master project copy as the other.
What format should the CF card be?
Panels that take CompactFlash cards usually read FAT-format cards. The filesystem's own specification caps a FAT16 volume at 2 GB and a FAT32 volume at 2 TB. Use the format and the card size the panel's manual names, because some runtimes read only FAT16, and format the card on a PC before the project download rather than trusting a card that some other device formatted.
How often should I check the card copy?
After every recipe change the operator commits, after every project download, and before you rely on the card for recovery. The check is quick: open the Recipe Folder on the card, or run one export to a PC and open the .csv, then compare the recipe name and a few values against the sheet on the panel. If the folder shows values the panel does not have, repopulate it with a fresh project download and check again.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.