Most HMI editors will not tell you when the panel's project differs from the file on your PC. Read the project back with the editor's documented read-from-panel command, save it under a baseline filename, and edit only a working copy. A failed experiment then takes one download to reverse.
Before you experiment on an HMI panel, get a copy of exactly what is running on it. The editor's read-from-panel command copies the project from the panel to your PC; the documented example is Start a Project → Read from Panel. Save that read-back under a baseline filename, edit only a second working copy, and a failed experiment takes one download to reverse. This page walks through the read step, the three files to keep apart, a worked example on a packaging line, and the download that puts the original back. One property of your editor decides how much the read-back is worth: on some HMI families the upload returns an editable project, on others only a runtime backup. The workflow below covers both, and it assumes no automatic comparison, because most editors have none.
Can you read the project back from an HMI panel before you edit it?
Yes on most panel families: the editor's read or upload command copies the running project to your PC, and the documented example this workflow comes from is Start a Project → Read from Panel, saved straight to a new filename.
A read is a panel-to-PC transfer: the panel is the source, your PC is the destination, and the project lands in a file you name. Where the command lives depends on the family. Two documented examples: one panel software puts it under Start a Project → Read from Panel, another puts the same job under Project → Transfer → Upload. Your editor's transfer menu names the direction, and read or upload always means panel-to-PC.
What differs by family is what lands in the file. Some editors reopen it as a full project with screens, tags and scripts. Others return a runtime backup that can go back to the panel but will not open for editing. Either way you get a restore point; only the first kind also gives you source. The check section below shows the one test that tells you which kind your editor produces.
Does the editor warn you when the panel project differs from the PC file?
Plan on no warning: most HMI editors open a transfer connection without comparing the panel project against your PC file, and the documented answer for the software family behind this workflow was that no comparison feature existed.
Treat the read-back copy, reviewed screen by screen in the editor, as the difference check. If a later release of your software has grown a compare or difference command in its project menu, use it as an extra; the workflow here works with no compare feature at all.
The risk is one-sided. Downloading a mismatched file replaces the panel project in one step, and a connection that opens cleanly says nothing about whether the two copies matched. That is why the baseline read-back comes before any edit session, and why the transfer dialog gets read twice: once for direction, once for the target panel.
What do you need before you connect to the panel?
You need the editor on a PC that reaches the panel over its transfer link, the panel powered and at its runtime menu, and three details written down: the machine identity, the PC file you have open, and the panel identity.
- The editor installed on a PC with a working transfer path to the panel: the serial, USB or Ethernet link your software supports.
- The panel powered and at its runtime menu, with the line in a state where a few minutes of your attention will not surprise anyone.
- Three details on paper: the machine or line identity, the name and folder of the PC project open in your editor, and the panel identity from its label or setup screens.
The written details earn their keep the moment both a PC file and a panel project exist. A transfer in the wrong direction replaces the panel project, and the records settle which copy is the source for this session.
How do you read the project from the panel, step by step?
The job is one read and two saves: retrieve the project with the editor's read-from-panel command, save it under a baseline filename that names the line, then save a working copy and edit only that.
- Write down the three details: the line or machine identity, the PC project file open in your editor with its folder, and the panel identity from its label.
- Note the panel's firmware revision before the first transfer; checking the HMI firmware revision before a project transfer shows where the number lives and why a mismatch matters.
- Connect the PC to the panel and open the editor's project-start or transfer menu.
- Choose the read or upload command that names the panel as the source. Start a Project → Read from Panel and Project → Transfer → Upload are the two documented examples.
- Save the retrieved project under a new baseline filename that carries the line, the panel and the date you read it, in its own folder. Save nothing over the PC project you had open.
- Reopen the baseline file from disk to confirm it loads, then save a second copy as the working file. From here on, edit only the working copy.
If the software shows an unclear transfer direction or cannot identify the panel, stop before you confirm anything. A transfer is a poor way to find out what is connected.
Which copies do you keep, and which one do you edit?
Keep three files: the read-back baseline that never gets edited, the working copy that carries every change, and the original PC source project if one exists, each in its own dated folder.
| File | What it holds | Rule |
|---|---|---|
| Baseline read-back | The project exactly as the panel runs it today | Never edited, kept in its own dated folder |
| Working copy | The file that carries your changes | Every edit lands here |
| PC source project | The editable master, if one exists | Keep it even when the read-back opens for editing |
Name the files so the history reads itself: line3-baseline-2024-03-08 and line3-work-2024-03-08 leave no doubt about which copy came from the panel and which one you are allowed to change.
If the change you are planning is really production status, an andon notice or a message board, put it on a separate shop-floor display and leave the HMI project as small as the machine needs.
What does an example run look like on a packaging line?
A Line 3 panel runs a 12-screen project and you want a reject counter on screen 4: the whole session takes about 50 minutes at the panel, and undoing a failed experiment takes 2 + 5 = 7 minutes.
The PC folder holds a file from two years ago that nobody trusts, so the panel is the only honest source. The session:
- Read from the panel and save line3-baseline-2024-03-08 in its dated folder.
- Reopen it to confirm it loads, then copy it to line3-work-2024-03-08 and build the counter display in the working copy: 40 minutes.
- Download the working project to the panel: about 2 minutes for a project this size, the window the article on an HMI panel project download that takes 2 minutes traces minute by minute.
- Verify: cycle all 12 screens and watch the counter increment, about 5 minutes.
The edit session takes 40 + 2 + 5 = 47 minutes at the panel, plus a few minutes for the read at the start. Now suppose the counter overlaps the alarm banner on screen 4 and hides active alarms. Reopen the baseline, confirm the dialog shows PC-to-panel, download: 2 minutes. Cycle the 12 screens again: 5 minutes. 2 + 5 = 7 minutes, and the panel is exactly what it was before the experiment. Redrawing 12 screens from memory, with tag names and recipes guessed, is a half-day job at best. The baseline file is what turns a bad experiment into a 7-minute rollback.
How do you check the read-back before you edit?
A good read-back shows three things: the new file reopens from disk, the panel still runs its original screens because a read moves data panel-to-PC only, and your records tie the baseline filename to that panel.
Reopen the baseline from its own folder with nothing else open in the editor. Two outcomes:
- The editor opens screens, tags and scripts: your family uploads editable projects, and the read-back can serve as the base for future edits.
- The editor refuses to open it for editing: your family uploads a runtime backup. The file stays valuable as the restore point, and the editable master stays the PC source project.
On the panel side, a read writes nothing: the panel still runs the screens it ran before you connected, and the operators see no change. Last, write the baseline filename and folder against the panel identity in your maintenance record. That line is what you, or the next engineer, will look for in a year.
How do you put the original project back after a failed experiment?
Restoring is one controlled download: reopen the baseline file, confirm the transfer dialog shows the PC as source and the panel as destination, send it, and verify the screens at the machine before the line runs again.
- Direction and firmware: use the firmware revision you noted at step 2 of the read; a project written for one revision can misbehave on another.
- Time: about 2 minutes of transfer for the 12-screen project above, then 5 minutes of screen checks.
- What keeps running: while the panel is offline for the download, the PLC keeps running its schedules and the line keeps producing; what stops is alarms, messages and setpoint entry on that panel. The article on keeping PLC schedules running when the HMI panel is offline covers the split.
- No PC at hand: if your family documents backup to external storage, the panel may also have a load-from-storage function that returns a project backed up on external storage, which restores the baseline without the PC.
- Power cut during editing: a panel can come back from a power cycle with no project at all, and the fix is one download from your baseline file. The article on an HMI panel that loses its project after a power cycle covers that recovery.
After the download, cycle every screen the operators use, exercise the alarm banners and the setpoint screens, and check each machine function the panel interacts with at the machine before you release the line. Operators act on what this panel shows, so that check is a safety step.
Recommendation: Before any experimental edit on a panel whose project you could not rebuild, run the documented read-from-panel step, save the result as a dated baseline file, and edit only a working copy. Restore with a download only after the firmware revision and the transfer direction check out, and keep the baseline file untouched until the new project has passed a screen-by-screen check at the machine.
Questions
Does the read-from-panel step disturb the screens the operators are using?
No. The read copies the project from the panel to the PC while the panel keeps running its loaded project, and the operators keep their screens the whole time. The transfer that takes the operator interface down is the download, which runs PC-to-panel and overwrites the panel project in one step. That is why the direction shown in the transfer dialog is the one detail to read before you confirm.
Why will the project my editor read back from the panel not open for editing?
On those families the upload returns a runtime backup, and the documented rule is that an editable copy only exists where the project file was downloaded along with the runtime. Keep the PC source project as the editable master and send every change down from there. The read-back is for restore only, and any future upload hands back another backup, never a source file.
Does the HMI edit session require stopping the line?
Usually no. Editing happens on your PC while the PLC keeps running its schedules, including while the panel is offline for a transfer. What the line loses during the download is the operator interface on that panel: alarms, messages and setpoint entry. Plan the transfer for a gap in operator need, verify every screen at the machine afterwards, then release the line.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.