Back up HMI recipe data before a panel update

Back up the project first

• Copy the current project file to the programming laptop and to one other place, and label it with the panel and the date.
• Where the panel sits at a remote site, a remote panel backup sent by email for USB restore gets the file back to you without a trip.
• Write down which recipe number is loaded right now. On panels that show the loaded record's name, note that too; reading the loaded recipe and data record names covers where that name comes from on one line of panels.
• A project backup carries the screens, the buttons and the tag definitions. The runtime values sitting in the internal tags need their own capture, and a program download is the moment they are most at risk. Read where HMI internal tag retention survives power off and download before you count on the panel keeping them.

Capture the values screen by screen

• Budget about 2 minutes per screen, so 49 screens take roughly 98 minutes; with the loaded-record check and re-checks, plan a 2-hour block for the capture.
• Build the spreadsheet first: one row per recipe, one column per field, in the order the fields sit on the screens. This layout needs 30 value columns plus a column for the recipe number.
• Walk the 49 screens in order and transcribe every value shown. Where a tag is not displayed on its screen, read it from the development software's online view of the internal tags, and confirm on the first screen that the online view agrees with what the screen displays.
• Capture all 49 rows, including recipes the operators say they never use. A record nobody loads can still hold values someone entered years ago, and a blank row costs nothing to keep.
• Check the method on the loaded recipe. The PLC holds that record's 30 values in its destination registers: read them and compare against your row. All 30 have to match. That is the one record the panel and the PLC both hold, so it is the test that tells you the capture reads the right tags.

Open the export and count it

• Run whatever recipe save or export the panel offers, to a USB stick; 1 GB is more than enough for a file of this size.
• Open the file on a computer before the panel is touched, and count the rows and the columns.
• A data backup for this project shows 49 rows of 30 values. A file with one column of tag names is a definition list: useful for column headers, useless as values.
• The tag database export from the development software is names and addresses too. Use it to build the mapping table; exporting the HMI tag database to CSV when you change panels covers getting it out cleanly.
• Recipe management on several panel lines documents a CSV export to a USB stick, a memory card or the project folder. Those exports work because the records sit in a recipe structure the software knows about. Plain internal tags scattered over 49 screens have no such structure, which is why a save on this design can hand back names instead of values.

Worked example: counting the capture for 49 recipes

Inputs, from the project as built: 49 recipe records; each record holds 1 alphanumeric text field, 2 digital on/off fields and 27 BCD number fields; the PLC retains only the record that was loaded. The capture session is planned at 2 minutes per screen, so about 98 minutes of screen time.

The rule in words: fields per record are the sum of the field types. Values in the panel are records times fields per record. Values that exist nowhere else are all records except the loaded one, times fields per record.

The arithmetic:

• Fields per record: 1 + 2 + 27 = 30
• Values in the panel: 49 records × 30 fields = 1,470
• Values in the PLC: 1 record × 30 fields = 30
• Values that exist only in the panel: 48 records × 30 fields = 1,440
• Capture sheet: 49 rows × 30 value columns = 1,470 cells, plus the recipe-number column
• Capture time at 2 minutes per screen: 49 screens × 2 minutes = 98 minutes
• Full readback audit after migration: 1,470 comparisons; the minimum audit is the loaded record's 30

Decision: an export that holds 49 data rows with 30 value columns is the backup. Anything short of that fails the count, and the hand-captured spreadsheet stands as the backup of record for the update.

Move the records into a recipe sheet

• On the new program, define one recipe structure with the same 30 fields and 49 records, and one load object in place of 49 Load buttons.
• Build the mapping table first: each field, its data type, its PLC destination address. The tag database export supplies the names and addresses.
• Keep the operators' layout where you can. The sheet can sit behind a selector that presents the records in the old screen order, and naming recipes on an HMI panel with no text entry solves the record names if the panel has no keyboard.
• Keep the old project and the capture sheet until the new records pass comparison.

Test one record before you migrate the rest

1. Enter one known record from the capture sheet into the new recipe sheet.
2. Load it to the PLC with the machine in a safe state: drives inhibited or the machine offline, so a wrong value cannot move anything.
3. Read back all 30 destinations in the PLC and compare against the sheet, field by field. Read the 27 BCD fields as numbers; a swapped BCD interpretation comes back as plausible nonsense, the same fault behind why a BCD recipe value breaks PLC ladder math.
4. Load a second record and confirm no field keeps the first record's value. With 30 fields per load, a missed destination shows up as a leftover, and that is the symptom to watch.
5. Enter the remaining 47 records only after both test loads pass; the two test loads take about 15 minutes together, so run them before the bulk entry, not after.

Check the full set after the update

• Export the finished recipe data from the new program to a USB stick or the network location the platform documents, and keep that file with the project. From this update on, backups start from a real export.
• Load a spread of records: the first, the last, one from the middle, and the record with the widest spread of values across the field types. Compare the PLC readback against the sheet each time.
• Keep four things in the update package: the old project backup, the capture spreadsheet, the verified recipe export and the mapping table. That package turns the next update into a load-and-verify job instead of a capture job.

Recommendation: treat the hand-captured spreadsheet as the backup of record whenever recipe values sit in internal tags and the PLC holds only the loaded record, and finish the capture before the program download. Rebuild to a recipe sheet in the same shutdown once the project holds more than about 10 records; at 49 records the rebuild pays for itself the first time the export runs, because no one hand-copies again.

Questions