Yes. The revision-suffixed files are snapshots saved at each upgrade; the working project is the separate file you open and edit. Record the active file's full path, save and open one backup, then delete the old copies in batches of 10 and reopen the project after each batch.
Every HMI software upgrade offers to save a copy of the project with the old revision number added to the filename. Say yes a few times over a few years and the project folder fills with them. You can delete those copies; the working project is the separate file you open and edit. The order of operations decides whether the cleanup is boring or expensive: identify the file you actually open, save one backup you have verified, then remove the old copies in small batches and reopen the project after each batch. For the folder in the worked example below, the whole routine is three batches of 10 files and one backup on a network share.
Can I delete the old revision project files after an HMI upgrade?
Yes, delete them once you have written down the active project's full path and saved one backup you have opened, because each suffixed file is a snapshot the software made at the moment of upgrade, and the working project opens from its own file.
When the software upgrades a project it writes a copy with the old revision number at the end of the filename. Declining the prompt once changes nothing about the next upgrade: the question belongs to the upgrade event, so one yes per upgrade leaves one rollback copy per upgrade. Deleting those copies is a housekeeping decision. The two real risks are deleting the working file and deleting your only path back to a version that ran, and the routine in the rest of this article removes both.
Which file is which in a folder full of revision copies?
The folder's modified dates, filename suffixes and open prompts point to specific causes, so sort the folder by date modified and read it top to bottom before you touch a single file.
- A save-a-copy prompt at every upgrade, even after you declined the previous one: the prompt belongs to the upgrade event, so each yes adds one rollback point.
- Filenames ending in an old revision number, with dates stepping back weeks or years: accumulated upgrade copies, safe to remove once the working file is confirmed.
- One file with the newest modified date and no suffix: the file you open and edit. Confirm it by its recorded path.
- Two files identical except for the revision number: two generations of the same project; the older one is the rollback.
- A missing-project prompt when you try to open the project: the working file has been moved or deleted. Stop the cleanup and restore from backup first.
How do I identify the active project file before deleting anything?
Open the project you edit and read its full path from the software, then write that path down, because the active file is identified by location and modified date, never by a suffix.
The development software shows the open project's full path in its project information; read it while the project is open and write the complete filename and folder into the maintenance log. Cross-check the modified date against the date of your last download to the panel: they should agree. Record the software version the project was last saved in at the same time. If two files claim the newest date, or the path cannot be read, treat every file as unknown and clean nothing until that is resolved.
How do I save one backup I can actually trust?
Save the project, copy the file to a second location such as a network share or USB stick, then open the copy from that location, because a backup counts as verified only after it has loaded.
The two-copy habit is the same one behind backing up and restoring an HMI panel project the safe way. Open the copy from the share, and check its size and modified date match the original. A name in a folder listing is not proof a usable backup exists; the open test is. Copies that came off old discs can carry a read-only flag that blocks a later restore, and clearing a read-only flag on an HMI backup is a short job of its own. Write the panel's IP address, the software version and the date into the log next to the backup. The purge rule that plant data software follows applies here too: delete an archive only when a verified copy stands behind it.
What does a safe cleanup look like in a worked example?
A line-3 folder holds the working project file at 4.2 MB plus 30 old revision copies averaging 3.8 MB, so the folder totals 118.2 MB and 114.0 MB of that is deletable copies.
- Copies: 30 × 3.8 MB = 114.0 MB
- Folder total: 4.2 MB + 114.0 MB = 118.2 MB
- Backup: one copy of the working file, 4.2 MB, on the network share outside the folder
- Batches: 30 copies deleted as 3 batches of 10, with the project reopened after each batch
The cleanup leaves one file of 4.2 MB in the folder and frees 114.0 MB. The project has been reopened 3 times, the backup has opened once from the share, and the working file has never been touched.
How do I delete the copies without touching the working file?
Move the candidates to a holding folder first and work in batches of 10, reopening the project after each batch, so every step stays reversible until the last one.
A batch of 10 keeps any mistake recoverable to 10 files and still clears the example folder in three passes.
- Write the active project's full path into the maintenance log.
- Save the project, copy it to the second location, open the copy to verify it, and record the panel's IP address, software version and date beside it.
- Sort the folder by date modified and move the 10 oldest revision-suffixed files to a holding folder. Rename nothing on the way.
- Reopen the project from the recorded path and confirm the screens load with no missing-project prompt.
- Repeat steps 3 and 4 for the next 10 files until the folder holds only the working file.
- Leave the holding folder in place for one full week of production, then empty it.
One caution: start no batch while the software is mid-save or mid-upgrade; finish the running operation first.
How do I check the cleanup did no damage?
Reopen the project from the path you recorded, confirm it loads with no missing-project prompt, and compare the file count in the folder against what you expect, which is one working file and nothing else.
Three checks close the job. The project opens from the recorded path. The folder holds the count you expect: one working file and nothing else. The backup on the share still opens. While the project is open, note the software version and the panel's firmware revision for the log; checking the HMI firmware revision before a project transfer is the companion habit that keeps the next upgrade uneventful.
The next upgrade will offer a fresh copy. Answer yes: that copy becomes the rollback for the new version until the upgraded project has run and been backed up.
When should I stop deleting and call the software vendor?
Stop at the first missing-project prompt, at any folder where you cannot tell the working file from its copies, or at a project that will not open after a batch, and take the question to the HMI software vendor's support line.
Send support the full filenames, the folder paths, the exact wording of the prompt and the software version, and let them guide the recovery; improvised fixes in system folders turn a recoverable mistake into a lost project. If the deleted file was the working copy and no verified backup exists, say so plainly: recovery then depends on the vendor's tools and on what still sits on the panel.
One habit prevents the whole situation: keeping a master copy of the HMI project outside the working folder means the working file is never the only copy of itself.
Recommendation: Before any cleanup, record the active project's full path and save one backup you have opened from its second location. Delete the old revision copies in batches of 10, reopening the project after each batch, and keep the holding folder for one week of production before emptying it. At the next upgrade, answer yes to the save prompt and treat the fresh copy as the rollback until the upgraded project has run and been backed up.
Questions
Will the software ever stop asking to save an old copy at upgrade?
No. The save prompt belongs to the upgrade event, so the next upgrade asks again even if you declined the last one. Answering yes creates one rollback point per upgrade, which is what you want before a version change. Let the prompt make the copy, then fold it into the same cleanup routine: verify the upgraded project, back it up, and remove the copies you no longer need.
How long should the most recent old revision copy stay on disk?
Keep the newest copy until the upgraded project has run one full week of production and the verified backup has opened cleanly. After that week the copy's only remaining job is comparing behaviour between versions, so keep it only if you actually make those comparisons. Older copies have no job left and belong in the delete batches.
Can I rename an old revision copy to reuse it as the working file?
Renaming changes only the label. The contents stay whatever they were, and a file that looks like the working project but holds an older revision is a trap for the next person who opens the folder. To run an older version, copy it into its own clearly named folder, open it from there, and confirm the screens match the machine before downloading anything to the panel.
Does deleting these files change anything on the panel itself?
No. The copies sit on the engineering computer; the panel runs whatever project was last downloaded to it. Deleting folder files changes nothing the panel displays until you download a project again. That download step is where the verified backup earns its keep, and where the firmware revision check from the upgrade routine matters.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.