Controllers and panels leave the maker with firmware only, so a program already inside a new unit was loaded by whoever assembled the machine. Record what each device runs, save an upload of both projects before any download, and hold every download until the assembler's own source files arrive. A worked example shows the numbers.
A PLC or an HMI leaves the maker with its operating firmware and an empty user program area. If a unit you were told is new already runs a program, a person loaded that program on purpose, and in most cases it was the company that assembled the machine or the control panel. That program is the machine's live configuration, so protect it before you change anything. This article lists the readings that tell you what you are looking at, works one case through with numbers, gives the checks in order, and ends with the fix for each way the case can go.
What each reading points to
- The PLC starts in RUN with outputs mapped to real terminals. That is a complete machine application written for that panel's I/O. Demo projects belong to training kits, and they do not ship inside production controllers.
- The HMI opens onto built screens with tags, alarms or machine graphics. An HMI project lives in the panel, separate from the PLC project, so programs in both devices mean two separate loads, and the two may not form a matched pair.
- The programming software reports a project identity and a firmware revision as soon as you connect. Someone commissioned the device after the maker's firmware went on.
- The software asks for a password or refuses to read the project. Whoever loaded the program set access protection. Stop there; the legitimate way past is the machine owner running the vendor's documented transfer procedure.
- The panel starts with a prompt about a missing user program. That one device is genuinely empty, the factory state, the same situation as a panel that boots with no user program on a blank card.
Why a program inside means it was loaded after the factory
Firmware and user program are different things in the same box. The firmware is the operating system the maker installs; it is what lets the device boot and communicate. The user program is the ladder logic, the screens and the alarms written for one machine. New units carry the first and none of the second.
User programs are written to non-volatile flash, the memory class specified to hold data at least 10 years without power. The program reaches that flash over a programming cable, from someone holding the software and the access rights. So a program you find was put in deliberately, and shelf time had nothing to do with it. The purchase records and the assembler's written answer decide what shipped with the unit; the program's presence tells you a person with access was involved.
Example: a panel stored 8 months that already runs a program
Inputs: a PLC and an HMI delivered as new, both found running applications, the case this article answers; 8 months between delivery and installation, read off the delivery paperwork; flash retention of at least 10 years unpowered; 2 devices to back up, one project file each.
Rule in words: a program in flash outlives any realistic shelf period, and the maker ships the user area empty. A program present means a person wrote it in after the factory. A program absent is the factory state.
Arithmetic: 8 months ÷ 12 = 0.67 years in storage. A tenth of the 10-year retention floor is 1 year, and 0.67 years sits below that, so the flash contents on install day are the contents from the day the device was packed. Backups: 2 devices × 1 project file = 2 project files; 2 copies of each, one in the panel shop and one in the office, gives 4 files in all.
Result: the unit was programmed before it reached you, most likely during assembly by the panel builder.
Decision: keep both programs in place, save the 2 project files as 4 copies, and hold every download until the assembler identifies the source projects. If nobody in the purchase chain claims the load, escalate to the machine owner with both serial numbers before anyone downloads or erases anything.
The checks, in order
Work down the list. The first two steps need no cable.
- Read both labels. Take the model number and serial number from the PLC and the HMI, matched against the purchase order and the delivery paperwork.
- Name the assembler. If the devices arrived built into a machine or panel, ask the builder or integrator whether they loaded programs at assembly. The purchase records should name them.
- Record before you change anything. Connect the model's programming software and write down, for each device, the project or application identity, the controller mode and any active faults, the HMI runtime status, and the firmware revision. The article on checking the HMI firmware revision before a project transfer covers that reading.
- Save a backup of both projects. Attempt a read or upload of the PLC project and the HMI project once the machine owner has approved it and it cannot disturb operation. Save them as two separate files, label each with the device, the project identity and the date, and keep two copies of each. The method is the one in reading an HMI project from the panel before editing and backing up and restoring an HMI panel project the safe way.
- Stop at any password prompt or failed read. Order the source projects from the assembler. If the upload comes back unusable or incomplete, stop there too and ask for the source.
The fix for each situation
| What you find | What it means | The fix |
|---|---|---|
| The assembler says they loaded both projects | Programs installed at assembly | Get their source files, check the project identities against what the devices run, then plan any download under your change process |
| Upload succeeds and opens editable | You hold a usable snapshot | Keep the 2 files with 2 copies each; still request the source, because an upload is a snapshot and may lack the original documentation |
| Upload refused or unusable | The loader protected the device, or the source was never stored in it | Order the source projects from the assembler; leave the running program in place meanwhile |
| No records, assembler unreachable | Provenance unknown, and the running program may be the only copy | Preserve both devices untouched and escalate to the machine owner with the model and serial numbers |
| The panel boots to a no-user-program prompt | That device is factory-fresh | Safe to build on; back up the programmed device beside it first |
Until the source arrives, leave the running program in place and run the machine on it. Do not load a sample or generic project to see what happens. It will not match the installed I/O, the machine sequence or the HMI screens, and it overwrites the only copy on site.
When the source arrives, have the assembler verify the files against the machine revision, back up the current contents once more, and download under your site's change-control process. Afterward, check that both devices start without new faults, the HMI communicates with the PLC, the displayed values match the machine, and an authorized operator completes the normal operating checks.
Recommendation: Treat a program found in a new-to-you PLC or HMI as the machine's live configuration from the first minute. Get the machine owner's approval before you connect programming software, read the project identity and firmware revision from both devices, and save an upload of each project before anything changes. Download only after the assembler's own source files arrive and match what the devices run; if nobody can be identified as the loader, leave both programs untouched and escalate with the model and serial numbers.
Questions
Can a PLC program disappear while the unit sits on a shelf?
The user program sits in non-volatile flash, the memory class specified to hold data at least 10 years without power, so months or a few years of storage leaves it intact. What can go flat is the battery or capacitor that keeps the real-time clock and some retentive register ranges alive on many controllers. A dead clock battery does not erase a flash-stored program; it resets the clock and can clear retentive data. Check the manual for the battery type when you inventory a spare.
Does an upload give back the project the builder wrote?
Sometimes only in part. An upload reads the compiled application the device holds, so it can leave out comments, documentation and other source material that lives only in the builder's project file. Keep every upload you can get; it is your snapshot of the machine as found. Then ask the assembler for the source project too. If the device blocks the upload, stop and order the source; the vendor's documented access-transfer procedure, run by the machine owner, is the only legitimate route.
Could the program have shipped as a factory demo?
No. Controllers and operator panels leave the maker with firmware and an empty user area, so an application you find was written to the device after the plant. Loading a firmware update uses the same cable and access rights, so a unit carrying a firmware version newer than its build date has been touched as well. The practical question is who had programming access between the maker and you: the panel assembler, an integrator at commissioning, or a colleague. Purchase records and the assembler's own answer settle it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.