Save the finished HMI project as a protected project and it can only be written from the PC to the panel, never uploaded back. Keep an unprotected master in 3 places under the 3-2-1 rule, prove 1 refused upload before release, and control who holds the protected file, because anyone with the file can load more panels.
When a customer pays for custom machine screens, the question arrives with the purchase order: can anyone pull those screens off the panel and reuse them? For an HMI panel, the documented answer is the protected project, a save option in the programming software. It works as a transfer-direction lock: the protected file goes from the PC to the panel, and the panel never sends it back. That one behavior decides the whole release workflow, because the panel stops being a source and a backup in the same moment. This article walks the sequence end to end: save a master you can still edit, save the protected copy as a separate file, write it to the panel, prove the upload is refused within one attempt that takes under 60 seconds on a 100 Mbit/s Ethernet link, and control every copy of the protected file afterwards.
Can you stop someone uploading an HMI project from the panel?
There is no separate upload-disable switch on the panel. The control the software gives you is to save the finished project as a protected project. The panel accepts it as a download from the PC and refuses to send it back as an upload.
The protection is a property of the project file, applied when you save on the PC. There is nothing to enable or disable later on the panel hardware. Your software's help file carries the protected-project topic and the exact menu path for the version you run; follow it, because menu names move between versions. Once the protected copy is on the panel, an upload attempt returns no project you can open or edit, and the screens on the machine stop being a source anyone can pull.
What does a protected project do at transfer?
A protected project supports exactly one transfer direction: the PC writes it to the panel, and the panel never sends it back to a PC. Nobody can pull your screens off the machine and reuse them.
Treat it as a direction lock, not merely an edit lock. The panel runs the screens normally and the PLC link works; the programming software simply gets nothing back when you ask it to upload. That upload is the ordinary panel-to-PC read shown in Upload an HMI panel project to your PC, so the two behaviors pair cleanly: an unprotected panel reads back, a protected one does not. Descriptions that say a protected project still uploads and is only blocked from editing are out of date; rely on one-way transfer and test it before release. If your own documentation states something different, follow your documentation and stop there.
What do you need before you protect anything?
You need a finished, tested project saved unprotected, the programming software version written down, master storage that follows the 3-2-1 backup rule (3 copies, 2 kinds of media, 1 off site), and the panel reachable over your normal transfer path.
Protection is one-way, so everything the panel will never give back has to exist somewhere else first. Assemble this before you save anything as protected:
- The finished project, tested against the PLC: every screen runs and the tags read live values. Fix problems now, because the protected copy is not the place to edit.
- Master storage on the 3-2-1 backup rule: 3 copies, on 2 kinds of media, with 1 copy off site. Refresh the backups within 24 hours of every release, so a copy is never more than 1 day behind the shipped project. The rule exists because any single copy dies with its device: a failed drive takes the laptop copy, and a panel project can vanish in a power cycle, as HMI panel loses its project after a power cycle documents.
- A record to keep with the master: programming software version, panel model, project name, date.
- A panel reachable over your normal transfer path, Ethernet or USB as your software uses.
If you have just inherited a machine whose panel still runs an unprotected project, read the project off the panel once and file it as your starting master; Read an HMI project from the panel before editing walks through that read. After the protected copy goes on, that path is closed for good.
How do you save a master and then the protected copy?
Finish and test the unprotected project first, store the master in 3 places, then save a separate protected copy under a different name. The master stays editable and only the protected file ever goes to a panel.
- Save the tested project unprotected. This file is the master and the only editable source from now on.
- Copy the master to the server share and to offline media, so it exists in 3 places. Check that each copy actually opens: backups that arrive marked read-only refuse to open until the flag is cleared, which HMI project backup from CD-R will not open: clear read-only explains.
- Record the software version, panel model and project name beside the master.
- Save the protected version with the protected-project save option, under a different file name. Never save the protected copy over the master.
- Check before you go further: the master still opens and edits, and the protected file is a separate file. Every later change goes into the master; a fix means edit the master, save a fresh protected copy and send it again.
How do you load the protected project and prove upload is refused?
Write the protected file to the panel over your normal transfer path, confirm the screens and PLC values run, then make exactly 1 upload attempt from the panel to the PC and expect it to produce no editable project. On a 100 Mbit/s Ethernet link the attempt itself takes under 60 seconds, plus the 30 seconds or so the panel needs to boot into the project.
- Connect the programming PC to the panel the way you normally transfer, and send the protected file. If the PC link is the problem, HMI programming link dead while the PLC link still works covers the panel that talks to its PLC but not to the PC.
- Let the panel boot and run the project, and confirm the screens and the live PLC values.
- Start 1 upload attempt from the panel to the PC. The expected result is a refusal, or a transfer that produces no editable project. If an editable file lands on the PC, stop: take the panel out of service and escalate; the FAQ below carries the full checklist.
- Write the result and the date into the master record.
Check it worked: after the attempt, no editable project file exists anywhere on the programming PC, the panel still boots and runs the protected screens, and the master record carries the dated refusal.
Example: which copies survive when the programming laptop dies after 2 years?
With the 3-2-1 master discipline, a dead laptop removes 1 of your 3 master copies and 2 survive. With panel-only storage the recoverable count is 0, because a protected project transfers to the panel and never back.
Say a systems shop releases a packaging machine and supports it for a 5-year period. At release the project exists as 3 master copies (programming laptop, server share, offline USB) and 2 protected copies (release folder, machine panel).
In year 3, the laptop drive fails. Master copies left: 3 - 1 = 2, so the screens stay editable and a controls change in year 4 is normal work on the master file. The off-site copy was refreshed within 24 hours of release, so it matches the shipped project exactly.
Now run the same failure against a shop that skipped the master discipline and shipped the only project inside the protected panel. Copies that come back off the panel: 0, because a protected file transfers PC to panel only. That shop rebuilds every screen by hand, against the running machine.
The same count decides handover: 1 protected file in a customer's inbox can be written to every panel of that model the customer ever buys. The distribution list carries 1 named owner per copy, and the customer who only needs the machine receives the panel.
What does project protection still leave open?
Protection stops the upload and it stops edits of the file. It does not stop duplication, because anyone holding the protected file can write it to additional panels of the same model.
The protection locks the screens; it leaves the file itself free to move. Three rules close that gap:
- Keep the protected file under the same access control as the master, on the release share, with 1 named owner per copy.
- Hand over the panel, not the file, when the customer's concern is copying. The machine arrives with screens that cannot be uploaded or edited, and that is what the protection promises.
- When the customer must be blocked from running the application on more panels, protection alone does not do it. Handle it in the contract, or through a licensing mechanism you verify with the panel manufacturer before you promise it.
Then list every location where the protected and unprotected files sit. Every copy on that list needs a named owner, because an unowned copy is the one that turns up on a second machine.
What do you record before the machine ships?
Ship with a release record that shows where every copy of the master and the protected file sits, who owns each, and the dated refused-upload test, with the software version and panel model on file.
Master
- 3 copies: laptop, server share, offline media; each opens and edits.
- Software version, panel model, project name and release date recorded with it.
Protected file
- Separate file name, saved with the protected-project option, never written over the master.
- Distribution list with 1 named owner per copy; the end customer receives no copy unless the contract says so.
Panel and proof
- Protected project written and running; screens and live PLC values confirmed on the machine.
- 1 upload attempt refused, no editable file left on the PC, result dated in the master record.
Recommendation: Protect every HMI project you release. Keep the unprotected master under the 3-2-1 rule, write only the protected copy to panels, run the refused-upload test before the machine leaves your floor, and hand the customer the panel, never the protected file, unless the contract gives them the right to load more panels.
Questions
What if an upload from a protected panel still returns an editable project?
Stop and take the panel out of service. Record the panel model, the exact programming software version, the project name and the date of the attempt, then contact the panel manufacturer's official technical support through its documented channels. Do not release the machine until support confirms in writing how the protected-project feature behaves in your software version. A refusal that fails once is a fault to resolve with the maker, never a setting to retry on the next machine.
Can I read the project back off the panel as a backup before I protect it?
Yes, while the panel still runs an unprotected project: a panel-to-PC upload produces a file you can open and edit, and reading it once before you change or protect anything is a legitimate recovery. That window closes permanently once a protected project is written to the panel, so from that point the master files on your PC and media are the only backup.
Who should hold a copy of the protected file?
Only the people on your release list: typically the engineer who owns the master and the panel builder who loads machines. Give every copy a named owner and record where it sits. Hand the customer the panel, not the file, unless the contract gives them the right to load additional panels; when the file does leave, record to whom and when.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.