Yes: on panels that take program cards, you prepare the card at your shop, the customer installs it with panel power off, and the boot sequence copies the program into internal memory. Check that both panels run the same firmware, confirm recipe storage is safe, and verify the new revision before the line runs.
Changing the program in a customer's HMI usually means a trip. Panels that accept program cards offer a second path. You prepare the card at your shop, mail it, and the customer installs it in minutes. The panel reads the program from the card during boot and copies it into internal memory, so nobody at the site opens your configuration software. The method stands on three checks you finish before the envelope is sealed: firmware versions match on both panels, recipe data is out of reach or safely backed up, and the card is written the way the panel expects. This checklist runs those checks in order, gives the customer the install steps, and lists what goes in the box.
Can you send an HMI program update on a flash card?
Yes, on any panel family that supports program cards. You copy the project to the card at your shop, the customer powers the panel down and installs the card, and the panel reads the program at boot and copies it into its internal memory. The card carries the whole project, so the receiving end needs no programming software. The transfer routine is the one documented for loading a project from one HMI to another by card, between two HMIs of the same type. Treat the card as transport. Once the copy into internal memory finishes, the panel runs from its own memory and the card can come out and be reused for the next change.
Which firmware versions allow a card transfer?
The firmware on the panel that builds the card and the panel that receives it must match, so read both version numbers before anything is prepared; a mismatch is the one reading that stops the shipment outright. Read the version on each panel's system information screen. The menu name changes by model, so use whatever screen the manual lists for firmware or system details. Write both readings on the shipment sheet. The decision is binary. Equal numbers, the card can ship. Different numbers, hold it: the firmware upgrade is its own documented procedure at the panel vendor, and a program download should not be assumed to update firmware, so the mismatch would survive the transfer and cost a courier round trip.
Does the card update overwrite the customer's recipe data?
It can: the boot copy loads a whole program image into internal memory, and on panels that use stored recipes that copy can wipe recipe values the customer runs production on, so recipe risk decides whether you ship at all. Work the check in this order.
- Ask whether the program uses recipe storage. It does if operators load settings, batches or product presets held in panel memory.
- No recipe storage: record that on the shipment sheet and move on to the program checks.
- Recipe storage in use: export or back up the current recipes with the panel's documented recipe function before the card ships, and have the customer confirm the values after the update.
- Backup method unknown for the model: hold the shipment until one exists.
So the decision reads: no recipes, ship; recipes with a confirmed export, ship with the backup attached; recipes without a backup, the card stays in your desk. If you want the wider picture of what a panel keeps in its own memory, how an HMI panel stores PLC data for later retrieval covers the storage question.
How do you prepare the card so it boots on the customer's panel?
Build the card with the panel configuration software's own card preparation function, not by copying files or cloning an image. The tool writes the card the way the boot sequence expects to find it, and a plain image clone is the step that fails in the field. Match the card to the type and capacity the panel documentation names for program cards, and let the tool format and write it. The flow asks for the drive and the project file, and some versions also ask for a firmware file, which comes from the vendor's own distribution.
Cloning a working card by copying its image is where shipments go wrong. A documented field case could not image a 64 MB boot card onto a 512 MB card at all. Label the card with the panel model, the program revision and the date. If a spare panel of the same model sits on your bench, boot it once with the card before it ships; that one test catches more than any inspection.
How does the customer install the card at the panel?
Power the panel down, insert the card, then restore power. The program is read from the card during boot and copied into internal memory, so the card has to be seated before power comes up, and the customer needs no programming software. The steps for the install sheet:
- Stop the machine with the site's approved shutdown procedure so panel power can come off safely.
- Switch power to the panel off.
- Insert the card into the slot the documentation names for program cards.
- Restore power and let the panel boot without interruption.
- Wait for the copy into internal memory to finish; the model's documentation describes the completion indication, so wait for it.
- Remove the card only after the panel reports the new revision.
Families that confirm the transfer from a startup screen follow the same power-cycle routine: the card download runs from the panel's startup screen, and the documentation for your model gives that flow. If the panel fails to finish startup, stop, write down what the screen shows, and rework from your shop copy instead of cycling power repeatedly.
Example: sending a program card to a two-panel plant
This shipment works when three readings line up before the card is prepared: firmware 3.4 on your shop panel, firmware 3.4 on the customer's panel, and a program with no recipe storage. Your shop is 300 miles from the plant. The line runs two operator panels of the same model, both reading 3.4 on their information screens, and your shop panel reads 3.4 as well, so the versions match and the shipment can go ahead.
The new program is revision B, its project export is 4.7 MB, and you write it onto a 64 MB card, which leaves 64 MB - 4.7 MB = 59.3 MB spare. The project holds no recipe screens, so nothing on site can be wiped. The card ships Monday in a 2-day courier run and arrives Wednesday.
Thursday morning, maintenance stops the line, powers panel 1 off, installs the card and boots: panel 1 reports rev B. The card moves to panel 2 for one more power-off install, and panel 2 reports rev B too. Two panels, two boot cycles, one card, no travel. The card stays on site until both panels have been checked against the controller, and revision A stays archived in your project folder as the rollback.
How do you verify the update and keep a rollback path?
Verify before you release the line. The panel reports its program revision after boot, so confirm it shows the revision you shipped, then test the screens and the controller link that changed under the site's normal test conditions. What the panel shows tells you where you stand.
- New revision showing: test the changed screens and the controller link, then release the line.
- Old revision showing: the card did not take; recheck both firmware readings and rebuild the card with the preparation tool before a second attempt.
- Screens load but controller values are wrong: the fault is in the program or its addresses, and running the card again will not fix it.
- Recipe values missing: stop anything that depends on them and restore only from the export taken before the update.
A completed transfer means the panel accepted the program; it does not confirm the program behaves correctly on the customer's process, which is what the tests above are for. Keep revision A archived at your shop and leave the card on site until the new revision is confirmed. A power cycle can also empty a panel for reasons no card touched; why an HMI panel loses its project after a power cycle walks through that separate failure.
What do you send with the card?
Send four things with the card so the customer can install and confirm without calling you: a one-page install sheet, the firmware readings from both panels, the program revision the card carries, and a written recipe statement. Grouped for the packing list:
With the shipment:
- The card, labeled with the panel model, program revision and date.
- The install sheet: power off, insert the card, power on, wait for the completion indication.
- Both firmware readings, written out, so the installer can see they match.
- The recipe statement: storage unused, or a copy of the exported backup attached.
When the same job turns into an order for a spare panel or spare cards from the vendor, send the model, both firmware readings, the program revision and the card type, so what arrives matches the installed base.
Recommendation: ship the card when the firmware readings match, the recipes are absent or exported first, and the card is written with the panel's own preparation tool; hold the shipment and fix the version or the recipe backup first when any of those three fails.
A card-loaded HMI is one screen inside a machine. If the same line also needs a standalone notice or status board that switches images on command, switching memory card images with a serial command covers that as a screen of its own, and the shop-floor display category collects the screen choices for machine-side boards.
Questions
Can the customer install the card without the programming software?
Yes, and that is the point of the method. The card carries the finished project, so the receiving panel needs only power and its card slot, and no PC or network is involved at the site. Put a one-page install sheet in the box so the person on site knows the power-off routine and what the panel should show when the boot completes.
How long does a card update take at the panel?
One boot cycle per panel, with the copy running inside the normal startup sequence. The exact length depends on the program size and the model, so plan on the panel's usual boot time plus a few minutes of checks. Wait for the completion indication the model's documentation describes before touching the card.
The two firmware readings differ: can I still ship the card?
No. The card transport needs the two panels on matching versions, and a program download does not perform that upgrade. Arrange the firmware update under the vendor's documented procedure, re-read both information screens afterwards, and only then build the card. Shipping it anyway costs a courier round trip and can leave the customer's panel exactly as it was.
Can one card update several identical panels?
Yes, when the panels are the same model and their firmware readings all match the card. Move it from panel to panel with the same power-off routine, and confirm the shipped revision on each one before moving on. If a panel refuses the card twice, stop, write down what the screen shows, and rework from your shop copy.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.