Fix an HMI project restore that fails after reboot

Why does a restore that reports success still fail at reboot?

The package was damaged after the export, and the step to suspect is the one that made the ZIP: if the memory-copy folder was compressed with Windows' built-in compression, the restored files arrive damaged in a way that shows only when the panel restarts into its runtime.

The sequence shows three green lights before the red one. The export reports success. The restore itself reports success. Each of those clears its own stage, and the failure lands after the last of them, at the restart, with the stick recognized in between. That timing puts the damage in the gap between your computer and the panel's boot, and when an update travels by e-mail or download, compression is the operation that fills that gap.

So the first move is not a new stick or a new panel. It is a new archive, built by a different tool from the untouched exported folder. In the pattern behind this article, the Windows-built package failed the boot every single time, and a package built from the same folder with 7-Zip restored cleanly.

Which symptoms point to the archive and not the panel?

Count the symptom as an archive problem when every stage reports success and the failure appears only at the restart: export success, stick recognized, restore success, then a runtime error on boot is the archive signature, and a repeatable one.

Run down this list and the branch usually names itself:

• Export reports success and the memory-copy folder appears on the PC. The export stage is clean; nothing here implicates the panel.
• The panel recognizes the stick and offers the restore. The stick reads, and the folder layout is accepted at the recognition stage.
• The restore runs to its own success message, then the panel errors during the reboot. This is the archive signature. Rebuild the package before anything else.
• The same package fails identically on every attempt and on every panel. A repeatable packaging fault, not a marginal stick or a flaky panel.
• A different, freshly exported project boots fine on the same panel and stick. The hardware is cleared; the fault travels with this one package.
• The panel never offers a restore at all. Different branch: stick format, media fault or folder layout. The archive fix does not apply.
• The error appears during the restore, before any reboot. Transfer stage: the folder was not extracted, the wrong folder was copied, or the copy was interrupted.

The first four together are the case this article fixes. The last three send you down a different path, covered at the end.

What should you record before you rebuild anything?

Record four things before you touch the package: the exact panel error in a photo, the utility and operating system that made the archive, the exported folder's file count and total size, and the USB stick's format.

1. Photograph the exact error text on the panel. A boot-time runtime error and a restore-time error lead to different branches, and the vendor's support channel will ask for the wording.
2. Write down the utility and operating system that compressed the folder, by name. The entry 'compressed on Windows with the built-in compressed-folder tool' is the one that flags this fix.
3. Read the exported folder's file count and total size from its Properties page on Windows. These two numbers are what the rebuilt package must match.
4. Note the stick's format. Panel sticks are commonly FAT32, and the FAT32 filesystem caps any single file at 4,096 MB, so the largest file in the export has to sit under that cap.

The count has a second use. Windows Explorer's extractor has a documented large-archive failure: extracting an archive of more than 15,000 files, Explorer can declare the compressed folder invalid and refuse to finish. An export anywhere near that size needs its extraction tested before it ships.

One more reason to write the numbers down: a success message from the export step, by itself, says nothing about what the archive step did to the folder afterwards.

Does the built-in Windows zipper really damage a restore package?

Windows' built-in zipper has documented failure modes, and the tell is repetition: an archive it created fails the restore at the same point every time, while the same folder archived with another tool restores cleanly, so change the tool and keep the folder untouched.

The public documentation backs the suspicion. The Explorer extraction failure just above shows the built-in ZIP path misbehaving on real archives. The ZIP format itself explains why implementations differ: the original format caps an archive at 65,535 entries and 4,096 MB unless the writing tool adds ZIP64 extensions, and archivers handle those extensions in their own ways. An HMI export is the awkward case for any zipper: thousands of small files in a deep folder tree, with binary content that has to arrive byte-exact or the runtime will not load.

The restore pattern adds the decisive half. The Windows-built package fails the boot every single time, and a rebuild from the same exported folder with 7-Zip restores cleanly. Whatever the low-level cause turns out to be, the branch does not change: the archive is the one item you can replace in minutes without touching the protected project, so replace it first.

Do not spend effort moving the extraction step as well. The failures concentrate on creation, and an archive made by 7-Zip extracts fine with Windows' built-in unzip when the archive itself is well formed.

How do you rebuild the package without touching the project?

Rebuild from the original exported folder, never from anything you unpacked out of the failed archive: create the ZIP with a third-party archiver, verify the extracted file count and size against the export, and only then copy the folder to a FAT32 stick for the restore.

1. Start from the folder the programming software exported. Never recompress a folder you unpacked from the failed archive; a rebuild begins at the original export.
2. Create the archive with 7-Zip or another third-party archiver, plain ZIP output, and write the tool and version into the project notes.
3. Send the archive with a one-line transfer note naming the tool, so nobody at the far end rebuilds the package with Windows' built-in compressor.
4. On the receiving side, extract the archive and compare numbers: the extracted file count must equal the export's count exactly, and the total size should match to the megabyte.
5. Copy the extracted memory-copy folder, not the ZIP, onto a FAT32-formatted USB stick. FAT32 rejects any single file over 4,096 MB, so check the folder's largest file against that cap first.
6. Seat the stick before the panel powers up: stick firmly in place before power, then open the panel's system menu. From there, follow the panel's own restore prompts.
7. Let the panel finish the reboot and reach its normal runtime screen. Treat the reboot as the acceptance test; the restore's success message only clears the transfer.

One warning belongs here: never cut power during a restore, because an interrupted write can leave the panel with no bootable project at all.

Recommendation: Route every remote HMI update through a third-party archiver such as 7-Zip. Build the ZIP from the original export, name the tool in the transfer note, verify the extracted file count and total size against the export, and only then put the folder on the stick. If a Windows-built archive has already failed a restore, rebuild it this way before any panel setting is touched.

Scenario: what does a clean remote update look like?

A 3,420-file export of 96 MB that fails three restores in a row from a Windows-built archive comes back clean after one rebuild with 7-Zip, and the arithmetic that clears it takes two minutes. The numbers here are illustrative; run your own export through the same checks.

The folder the programming software wrote holds 3,420 files totalling 96 MB, the largest single file, the runtime image, is 38 MB, and the stick is FAT32. The first package was zipped with Windows' built-in compressed-folder tool. The far end extracted it, restored it, and the panel errored at boot; the same archive failed a second panel the same way. Three identical failures decide it: rebuild.

The rebuild and its arithmetic:

• New archive in 7-Zip, plain ZIP. The recipient extracts with Explorer. The count sits far below the documented Explorer trouble zone: 3,420 ÷ 15,000 = 0.23, so the export sits at 23% of the 15,000-file level where the invalid-folder failure was recorded.
• Verification against the export: 3,420 − 3,420 = 0 files, and 96 MB − 96 MB = 0 MB. The package arrived intact.
• FAT32 check on the biggest file: 38 MB against the 4,096 MB cap is 38 ÷ 4,096 ≈ 0.01, about 1% of the cap, so the copy proceeds.
• The folder goes onto the stick, the restore runs, and the panel reboots into its runtime with no error.

Close out by keeping the 7-Zip archive with the project as the known-good package, tool and version written in the notes. Every later release repeats the same path from a fresh export.

When is the archive not the cause?

Treat the archive as innocent only when no compression step ever touched the folder, or when a third-party archive still fails at boot; then the exact panel error text, photographed, is what the HMI vendor's support channel needs from you.

Three situations send you elsewhere:

• No compression step ever touched the folder. If the export was copied straight to the stick, the archive is out of the picture entirely. Work the media branch: try the stick in another PC, reformat it FAT32, re-export, recopy.
• A third-party archive still fails the boot. Stop repeating the restore. Packaging is cleared, and the photographed error text plus the packaging history (tool, file count, sizes) is exactly what the vendor's support channel asks for. No public source names a specific damaged file inside such an archive, so file-level repair is guesswork.
• The project file itself was damaged before the export. That is a different job with its own procedure: recovering a corrupt CODESYS project file after a crash has the steps.
• The PC reads the stick and the panel does not. Media branch again. The same pattern, a file set that reads fine on the desk and misbehaves in the device, shows up with video files too; USB video playback troubleshooting for signage displays walks that path.

Each branch ends in a decision: rebuild when a Windows tool built the archive, escalate with evidence when a third-party package still fails, and leave the panel hardware for last.

Questions