Autosave in HMI programming software keeps the current project and a single .BAK file, one autosave interval old. A shorter interval buys freshness, not depth. For history deeper than one interval, make dated manual checkpoints before risky edits and verify any recovered copy before it becomes the working project.
Autosave in HMI programming software is a one-copy rotation, not a version history. It keeps the project file you have open plus a single backup copy, and that copy is exactly one autosave interval old. Set 10 minutes and your whole recoverable history is 10 minutes deep; a state from an hour ago exists only if someone saved it to a separate file. On the floor, that difference decides whether a bad afternoon of edits costs a 10-minute rollback or a rebuilt project. This page explains the rotation model, works the numbers for a realistic absence, and gives the checkpoint habit that builds real history: dated manual saves before risky edits, and a verification pass before any recovered copy goes back on the panel.
What autosave keeps: one current file and one .BAK
The autosave design documented for one long-established HMI editing package works by rename. At every autosave the previous project file becomes the .BAK copy and a fresh current file is written. Two files survive, one interval apart, and earlier states are simply overwritten. The autosave frequency and its folder are set from the project options dialog, File > Project Option in that documented version. Both settings change when a save happens and where it lands; neither changes how many copies survive. Moving autosave to a bigger disk changes nothing about depth: a 500 GB drive holds the same two files a 32 GB drive does.
Some PLC and HMI packages do autosave into a numbered sequence, project.001.bak, then project.002.bak, one number per save. Where your software has that feature, its Help states how many copies it keeps, and free disk space becomes the only limit on depth. Check your own Help before assuming either design; the two look identical until you need yesterday's work.
What the autosave interval changes
A shorter interval puts less unsaved work at risk: with a 5-minute interval a crash costs at most about 5 minutes of edits. It does not deepen history; the rotation still keeps one copy. A longer interval means the current file drifts further from your last edit before each save, and interruptions arrive less often.
Interval also sets how often the save pause arrives. Very large projects can take 10 to 20 seconds to write, and typing into the editor while the file is being saved risks a corrupted save. Treat the save as a pause: hands off until it finishes. If that pause fights a heavy editing session, raise the interval and lean on dated checkpoints. Switching autosave off removes your only automatic recovery point, so if you do switch it off, replace it with deliberate manual saves at the end of every change set.
Example: a 10-minute autosave across a 1-hour lunch
Inputs. Autosave interval 10 minutes, the value you set in the project options dialog. You leave at minute 0 with a saved project. A second engineer edits the project at minute 5. You return at minute 60.
Rule. Single-copy rotation: each autosave overwrites the one .BAK, so the oldest recoverable state is one interval old.
Arithmetic. Autosaves fire at minutes 10, 20, 30, 40, 50 and 60: 60 min ÷ 10 min = 6 rotations.
- Minute 10: first autosave. Current file = post-edit project, .BAK = your pre-edit project.
- Minute 20: second autosave. The pre-edit .BAK is overwritten with a post-edit state. Both files now contain the edit.
- Minute 60: you return. Current file = the minute-60 state, .BAK = the minute-50 state. Nothing older exists.
Result. Six rotations leave exactly two states, and the deepest is 10 minutes old. The pre-edit project survived 10 minutes as the .BAK and was gone by minute 20, 40 minutes before you walked back in.
Decision. With a single-copy autosave the oldest state you can recover is one interval back, 10 minutes here. Any state older than 1 × interval must already exist as a separately named checkpoint made before the edit. History deeper than one interval is manual territory.
Build history with dated checkpoints
The habit is simple: before any edit session you might want to walk back from, use Save As to write a dated copy under a naming convention that sorts, for example Plant2-HMI-2026-03-14-before-tag-rename. Finish a change set, save again, and write the next checkpoint before starting another. Checkpoint again before handing the file to another engineer or before a software upgrade.
Set the spacing from how much work you could afford to rebuild. Fifteen-minute spacing across an 8-hour shift is 32 files, and project files are small enough that hundreds of them cost nothing on a modern drive. Keep checkpoints in a folder autosave never writes to, and keep a one-line note saying which file is the approved baseline.
Two traps put holes in checkpoint history. First, if the panel has been edited directly and the paperwork is thin, read the project back from the panel before you edit, so your baseline matches the machine: see read an HMI project from the panel before editing. Second, some editors let you change a connected panel online while the project on disk still holds the old program; one package documents exactly that, where its online edits reach the disk only via a Copy Program As step (online edits reach the disk only via Copy Program As). On a package like that, your checkpoint before walking away is that explicit copy step.
Verify a recovered copy before it becomes your working project
- Copy the candidate, current file or .BAK, to a new name first. Never recover over your only known-good copy.
- Open the candidate and confirm it loads without file errors. A copy that came off an old disc can carry a read-only attribute that blocks opening or saving; clear it first, as in HMI project backup from CD-R will not open: clear read-only.
- Check the contents that matter for the change under review: the screens, tags and alarms you expect, with the values you expect. A filename and a timestamp alone are not proof of the right revision.
- If your package ships a program-comparison tool, run it against your approved baseline; its Help entry states what it compares and what differences it reports.
- Save the verified candidate under your working name and note in your log which file was recovered. Only then plan the panel transfer, and check the panel's firmware revision before that download, as in check the HMI firmware revision before a project transfer.
Recommendation
Recommendation: keep autosave on at a 10 to 15 minute interval for crash recovery, and treat anything older than one interval as manual territory: write a dated checkpoint before every session that touches screens, tags or recipes, keep those checkpoint files in a folder autosave never touches, and verify a recovered copy against your baseline before it goes back on the panel. If a very large project makes each save pause editing for 10 to 20 seconds, move the interval up to 15 or 20 minutes and take the depth from checkpoints instead of switching autosave off.
Questions
Does a bigger autosave folder or disk deepen the backup history?
No. Folder and disk size change where the two files sit, not how many survive. A single-copy rotation overwrites its one backup at every autosave, so history stays one interval deep on a 32 GB drive and on a 1 TB drive alike. Depth comes only from separately named checkpoint files that the rotation never touches.
What autosave interval should I set on a large HMI project?
Start from how much editing you can afford to redo. A 10-minute interval risks the last 10 minutes of work; a 5-minute interval risks 5. Then weigh the save itself: if a very large project takes 10 to 20 seconds to write, any interval from 5 minutes up leaves room, and you pause typing while each save runs.
Do I need change-management software for HMI projects?
Not for one panel. Dated checkpoint copies in a protected folder cover a single project and a small team, and nothing needs installing. Change-management software earns its keep at fleet scale, when many machines, outside contractors and multiple sites must share approved program versions with an audit trail. The checkpoint habit is the bridge until then.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.