Unsupportable hardware version after USB restore: fix it

8 min read · Published November 9, 2026

A panel that restores its own backup but refuses a new project with an unsupportable hardware version message is telling you the stick carries the project without the system files. Rebuild the stick from the engineering software's external-device load, then restore system and project at the panel in one pass, which updates the OS, firmware and project together.

You send a new project file to a panel at a distant site, the customer copies it to a USB stick, and the panel answers with unsupportable hardware version. The odd part: the same stick just made a backup and restored it. So the stick and the port both work.

The message is about a mismatch between the project package and the panel's installed system files. It has a documented fix: rebuild the stick from the engineering software's Load to External Device operation, then restore the system and project together at the panel.

This page explains why a backup stick fails a new project, walks through the steps that build a stick the panel accepts, lists what to record before and check after, and says when to stop and ask the panel maker for a recovery package. The same steps apply to any shop-floor screen that takes its project from USB.

What does the "unsupportable hardware version" message mean?

The message means the project file was built for a hardware version the panel's installed system does not support. The panel refused the load at its version check. The stick, the port and the backup workflow keep working.

A project built on newer software records a hardware version the panel's older system does not recognize. The load is refused and the panel keeps running the project it had.

The message prints no version number, so there is nothing in the text to match. That is why the repair rebuilds the stick with the right contents instead of decoding the words on screen. Read the message as a contents problem first: in this workflow the panel's own backup and restore has already shown the panel, the port and the stick are healthy.

Why does a USB backup restore fine while the new project fails?

The two operations build different sticks. A touchscreen backup writes the panel's current project alone, one set of files. A deployment must carry two sets: the project and the system files. The error is the second set missing.

A touchscreen backup exists to save the panel's current project so a damaged panel can be brought back. It restores cleanly to the same panel because the system installed on it already matches the project it wrote. Nothing needs updating.

A deployment stick exists to move a panel to a new project. The engineering software's Load to External Device operation writes the Project and System Files to the pen drive. A new project can carry a hardware version the panel's installed system does not know yet, so the system files ride along and the restore can bring the system up to match.

What each symptom points to:

  • Only the transferred project fails, and the backup still restores: the stick and the port are fine; the new package needs system files the stick does not carry.
  • Every load fails, including the old backup restore: suspect the stick or the port first, and test the drive itself on a computer.
  • The rebuilt stick still gives the message: confirm the software wrote the intended project, then use the maker's recovery package, covered at the end of this page.

The visible difference between a backup stick and a deployment stick is not the file size; it is whether the system files are on board. No quick look at the files tells you that, so build the stick by the workflow the job needs.

Example: one panel, two sticks, why does only the second load?

Monday. The customer backs up the running project with the touchscreen backup on a 16 GB stick and restores it to the same panel. It works, and it shows the stick and the USB port work. The stick carries 1 of the 2 sets the next job will need, because a backup writes the project for the panel whose system already matches it.

Thursday. Your new project file arrives, a 300 MB package, and is copied onto the same stick. The load returns unsupportable hardware version. Count the gap: the stick still holds 1 of 2 sets. Copying a project file onto a backup stick adds a project and adds no system files, so the panel compares the new project's hardware version with its installed system, finds the mismatch and refuses the load.

The rebuild. Load to External Device writes the Project and System Files for the new project onto the stick, 2 of 2. Restoring the System and Project then writes all 3 layers, OS, firmware and project, in one operation. The panel boots into the new project and the message is gone. Nothing about the panel's hardware changed; only the contents of the stick did.

How do I prepare a USB stick the panel will accept?

Build the stick from the engineering software's Load to External Device operation with the pen drive selected. That operation writes the Project and System Files to the drive in one pass, which is exactly what the panel's restore needs.

  1. Open the intended project in the engineering software and confirm it is the project for that panel: right name, latest saved changes.
  2. Use a clean stick big enough for the package; the workflow, not the size, decides whether the panel accepts it.
  3. Choose Load to External Device and select the pen drive.
  4. Let the software write the Project and System Files, and let the write finish before you pull the stick.
  5. Label the stick with the project name and the build date, and keep it apart from any backup stick.

Size matters in two places, both set by the hardware and the filesystem, not by the panel. FAT32, the filesystem most project-transfer sticks use, cannot hold a single file larger than 4,294,967,295 bytes, the limit written into the filesystem itself, and any stick above 32 GB may come formatted as exFAT instead, so check what the panel's manual allows. Write speed only changes how long the pass takes: a USB 2.0 port moves 480 Mbps, a USB 3.0 port 5 Gbps, so the same 300 MB package writes in seconds either way. Wait for the software to report the write complete before you pull the stick.

How do I restore the system and project at the panel?

Restore the System and Project from the prepared stick in one operation. It updates the OS, the firmware and the project together, so the panel's system and the new project arrive matched.

  1. Write down the system or firmware version the panel displays before you change anything; the habit of checking the firmware revision before a project transfer exists for exactly this moment.
  2. Put the prepared stick in the panel's USB port.
  3. Run the restore that takes the System and Project from the stick.
  4. Leave the stick in place until the panel reports the restore complete and reboots; pulling it midway risks a panel with no working system.
  5. Confirm the intended project is on screen and the operator inputs respond.

A stick built by the external-device load already carries the system files, so the panel's restore system button can bring the OS and firmware current from that same stick. The combined System and Project restore stays the single pass that leaves system, firmware and project aligned, so use it unless the panel's own procedure says otherwise.

Should you update the firmware from a laptop and skip the stick?

Only when the panel's installed system is the only part out of date and the software supplies the matching system file. A firmware update from the engineering computer has cleared this message in the field, but the stick restore pairs the right version with the project in one pass.

The stick path is the default because the system version arrives in the same package as the project, so the two cannot drift apart. A firmware-only update needs the correct system file for that panel, and if you cannot name that file, you are guessing. Do not collect firmware files from old jobs and try them one after another. When the panel rejects the file itself, work from what to do when the firmware load says not a supported file and stop there.

What do you record before, and check after, the restore?

Record one number before you touch the panel, the system or firmware version it displays. Record four things if the restore fails: the exact message, that version, the project name and how the stick was built. Then stop and get the maker's recovery package.

Before the restore, keep with the job sheet:

  • the system or firmware version the panel displays
  • the project name and the date the package was built
  • how the stick was built: touchscreen backup or external-device load
  • the original backup stick, labeled and stored apart, so a failed attempt still has a way back

After the restore, run four checks in order:

  1. The panel starts without the unsupportable hardware version message.
  2. The intended project is the one displayed.
  3. Operator inputs respond the way the project expects.
  4. The machine side answers: run one or two operator actions and confirm the connected equipment responds. The restore validates the panel, so give the field side its own test; if the panel came up but the link to the equipment went quiet, start from a panel that stops communicating after a firmware update.

If the rebuilt restore still fails, stop loading files. Note the exact message, the version you recorded, the project identity and how the stick was built, keep the original backup safe, and ask the panel maker's support channel for the compatible recovery package for that panel and project.

Recommendation: when a panel takes its own backup restore but refuses your project with the unsupportable hardware version message, rebuild the deployment stick with Load to External Device and run the System and Project restore in one pass; keep the touchscreen backup on its own labeled stick for safekeeping, and go to the panel maker's recovery package only if the rebuilt restore still fails.

Questions

Can I tell how a USB stick was built by looking at the files on it?

File size tells you nothing about whether the system files are on board, which is the distinction that decides this error. If a stick has no label, treat it as unknown: rebuild it with the external-device load for the project you are deploying, then label it with the project name and the build date. A rebuild costs one pass of the software and removes the guess.

Does the restore need both sets on the stick, or can I load the project alone?

Loading the project alone is the path that raises the message in the first place when the panel's installed system is older than the project expects. The system-and-project restore takes both sets from the stick the external-device load prepared, so the panel's OS, its firmware and the project all update in one operation and stay matched.

Which workflow should I use for routine project updates once the panel is current?

Build every deployment stick with the external-device load, even when a plain project load worked last month; the operation writes the system files too, so the next project that needs a system update still goes in with one restore. Keep the touchscreen backup for safekeeping on its own labeled stick.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote