A USB restore updates a panel's firmware only when the stick carries the system files and the technician selects System at the restore screen. A project-only stick loads the application and leaves the firmware version untouched. Build sticks with the programming software's complete output, then verify with a version read before and after.
A USB stick can deliver a firmware update to an installed HMI panel, and it does so only when two conditions hold: the stick was built with the panel's system files on it, and whoever runs the restore selects System on the panel's restore screen. A stick that carries the project alone loads the application and leaves the firmware version where it was. That gap explains a familiar field report: the new project runs, the panel behind it still reports the old firmware, and nobody can say why.
This page gives you the two stick builds that carry the system files, the restore selection that applies them, the version check that confirms the update took, and the point at which the programming software is the better tool. It is written for OEMs and maintenance teams that ship sticks to sites instead of carrying a laptop to every panel.
Will a USB stick update the firmware on a panel with an older version?
Yes, if two things are true: the stick carries the panel's system files together with the project, and the person running the restore selects System on the panel's restore screen. Leave either one out and the stick updates the project only, so the firmware version stays where it was.
A panel runs two layers. The project is the application: screens, tags, alarms, recipes. The system layer is the panel itself: boot code, runtime, drivers. A stick can carry both layers or one, and the restore screen reflects what the stick carries. One panel vendor's support FAQ puts the rule plainly for its backup flow: PROJECT and also SYSTEM must be selected for the backup to include the OS and firmware.
Ask how the stick was built before you put it in a box. The version of the programming software and the contents of the stick are separate facts; software new enough to write any project can still produce a stick with the project alone on it.
What has to be on the stick before it can update firmware?
Two content sets: the project files for the application and the system files, labeled OS or FW on most panels, for the panel itself. A stick with both is a complete package. A stick with the project alone loads the application and cannot touch the firmware version.
| Stick build | What it carries | Updates firmware? |
|---|---|---|
| Panel backup with PROJECT and also SYSTEM ticked | Project plus OS and firmware | Yes, when System is selected at the restore screen |
Send to External Memory Device from the programming software |
OS, FW and project in one output | Yes, when System is selected at the restore screen |
| Panel backup with PROJECT only | Project files | No |
| A copied project file on a blank stick | One project file | No |
Only the first two rows ship as firmware updates. When nobody can name the method that built a stick, rebuild it by one of those two before it travels, and get the build method in writing when a machine builder supplies the media.
How do you build a stick that carries the system files?
Two documented builds work. First, back up a current panel and tick both PROJECT and also SYSTEM, which pulls the OS and firmware into the backup. Second, run Send to External Memory Device from the programming software, whose single output carries OS, FW and project to the stick.
A 16 GB stick is ample for one project package; a project-plus-system output is typically a few hundred megabytes, so do not buy large media for this job.
Method 1: backup from a current panel
- Pick a panel you control that already runs the firmware version you want to spread.
- Open its setup menu and find the backup function. One vendor documents the path as the SYSTEM screen, then
MEMORY >> BACKUP >> CF1 >> NEXT, four items deep; your panel's manual prints the equivalent path and the storage it writes to. - Tick PROJECT and also SYSTEM, then run the backup to completion. Those two tick boxes are the whole point: SYSTEM is what brings the OS and firmware along.
- Move the finished package to the stick you will ship, and keep a second copy at the bench.
Method 2: build from the programming software
- Open the project in the panel vendor's programming software on a PC.
- Plug in the shipping stick and run
Send to External Memory Device. The function writes OS, FW and project in one output, so nothing else needs ticking. - Eject the stick cleanly.
Label both sticks the same way: build method, the system version shown on the source panel's information screen, project name, date. Panels are particular about media, so check the guidance on HMI panel USB drive compatibility before you buy a batch of sticks.
What do you select on the panel when the stick arrives?
System, every time the restore screen offers it, plus Project when the application changes with this update too. A System choice on the restore screen means the package carries the system files; selecting it is what starts the firmware update, and skipping it leaves the version where it was.
- Read the version first. Open the panel's system information screen and write the firmware string on the job sheet. If no one on the crew has done this before, the walk-through on reading an HMI panel firmware version for field maintenance shows where panels keep it.
- Back up the panel's current project and keep the copy off the panel, following the safe way to back up and restore an HMI panel project.
- Plug the stick into the panel's USB port and open the restore function from the setup menu. The separate walk-through of a restore from a USB drive covers the mechanics step by step.
- Select System, and Project as well when this trip also loads a new application.
- Start the restore and let it run to the panel's own completion message. Feed the panel from a stable supply and leave the stick in place until it finishes; cutting power during a system restore is the one mistake that can turn a working panel into a paperweight.
Plan on about 15 minutes on site per panel, including the two version reads and the project backup. Most of that is waiting for the restore to finish.
How do you check that the firmware actually updated?
Read the version twice and compare. Take the first string from the panel's system information screen before the restore and the second from the same screen after; the update happened when the two strings differ and the after string matches the version on the panel that built the stick.
Judge the system on the version string and the application on its screens. A project that runs confirms the application loaded; the version read confirms the firmware moved. Both strings go on the job sheet, which leaves the site a two-line record per panel.
If the after string matches the before string, the restore loaded project content only. Before you leave, check the stick's build method and whether the restore screen offered System at all. That is the same reason reading the firmware revision before a project transfer belongs in every trip plan: the version number is the fact you can hold the stick to.
Example: one stick ships to twelve panels on old firmware, so what updates?
The first stick holds the project only, so twelve panels take the new application and zero of them move off the old firmware: 12 projects updated, 0 firmware versions changed. One rebuilt stick with OS, FW and project aboard, plus a System selection at each panel, closes the gap.
You maintain twelve installed panels for a machine builder. A stick arrives built by a panel backup in which only PROJECT was ticked. You test it at the nearest site: version read before the restore, project loads and runs, version read after the restore, and the two strings are identical. Two reads have told you the stick updates 0 firmware versions, and you never needed to visit the other eleven sites to learn it.
Back at the bench you build a replacement with Send to External Memory Device, label it with the source panel's system version, and ship it. The second pass visits each panel with the same routine: read the version, select System and Project, restore, read the version again. Twelve panels times two reads is 24 version strings on the job sheets, each after-string matching the source panel. At about 15 minutes per panel, the fleet update takes roughly 3 hours of site time in total, and the whole run uses 2 sticks, one of them wasted.
When is the programming software the right tool instead?
Use the programming software when the restore screen offers no System choice, when the restore aborts, or when the version string will not move after a correctly selected restore. Panel vendors document an OS update run from their software over USB or Ethernet, and that path writes firmware directly.
The update function lives in the programming software itself, so that route needs a PC connected to the panel by USB or Ethernet. That is the honest trade: the stick route spares the laptop but still needs someone at the panel to pick System; the software route moves the firmware without depending on restore-menu choices. When a panel cannot take a bench visit, one documented workaround sends a remote HMI panel backup by email for a USB restore at the site, and even that ends with a local selection on the restore screen.
Two failures have their own pages if you meet them: a restore that stops with an unsupportable hardware version message after a USB restore, and a project transfer that fails on a newer Windows PC when the software side is the problem. If an OS restore from a service stick fails outright, the cause is usually the stick or the selection; a write-up on industrial OS service stick restore failures lists the common failure modes and the fixes that clear them.
And when the job leaves room for a separate screen, one that shows shift notices, counts or status next to the machine, look at shop-floor signage displays built for plant conditions. Those units are offline signage screens, not HMI panels, and they do not replace the panel this page updates.
Recommendation: Build every stick you ship with Send to External Memory Device, so OS, FW and project travel together; have the site technician select System and Project whenever the restore screen offers those choices, and take the two version reads at every panel. Where System never appears or the version will not move, put the programming software on a laptop and run the vendor's OS update over USB or Ethernet.
Questions
Can a USB stick update the firmware without anyone visiting the panel?
The stick carries the files, but the System selection happens on the restore screen at the panel, so a person on site starts the update. The programming-software route over USB or Ethernet also needs a connection to that same panel. Plan one short visit per panel and use the two version reads as your confirmation that the job is done.
Does sending the same project stick again update the firmware eventually?
Repeating a project-only restore writes the application again and leaves the system layer untouched, so the version string reads the same after the tenth pass as after the first. Rebuild the media once with the system files included, by a panel backup with PROJECT and also SYSTEM ticked or by the programming software's complete output, and select System at the restore screen.
What should the stick label say before it goes in the post?
Write the build method, the system version shown on the source panel's information screen, the project name, and the date it was built. The site technician then reads the panel's information screen before and after the restore and checks both strings against the label, which turns two version reads into the paper trail for the whole fleet.
Should the panel's current project be backed up before a system restore?
Take a backup of the running project first and keep a copy off the panel. If a site needs to roll back after the update, a backup that includes System, taken before the change, is what rebuilds the panel to its previous state; the safe backup and restore procedure sets out the steps worth following.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.