Transfer an HMI project to a smaller panel by rebuilding it

Can you convert an HMI project instead of rebuilding it?

No. A project written for a full-size panel does not transfer to a small-panel family by conversion. The target, the object set and the project format all differ. The job is a deliberate rebuild, sized by the inventory you take first.

The tools state this themselves. Where a vendor offers a migration path between its own panel generations, the tool has you define, before the move, how each screen's contents adapt to the new format. Objects the target device does not support cannot be pasted into a screen at all: the tool asks you to select a supported object or build a new one. A converter, where one exists, moves data. The judgment about layout, object choice and screen density stays with you.

Rule the shortcuts out now, while they are still cheap. Renaming the project file changes a filename and nothing else; the target inside still describes the old panel. Opening the old project in the small panel's software and downloading it hands the panel a project it was never built to run. You are not the first to face this: there is a published walkthrough of rebuilding screens from an older operator-terminal line for its replacement worth ten minutes before you set your own sequence. Keep the original project untouched throughout; it is the specification for the rebuild and the fallback if the small panel comes up short.

What do you need before you start the rebuild?

Gather five things before you touch the new project: a backup of the original file, the software version that built it, the PLC model with its connection settings, a screen capture of every screen, and the small panel's object and driver list.

Backup first. Copy the original project somewhere it cannot be overwritten during testing, and record the exact software version that maintains it. Panel families use separate programming environments, so expect to keep both installed until the replacement is signed off.

Record the PLC side next: controller model, communications method, connection settings, and every address or tag the HMI touches. That list is the ground truth for the rebuild; screen labels are suggestions, not documentation.

Capture every screen while the old panel still runs. The method in capturing HMI screens for operator manuals produces clean images, and the same captures double as your acceptance checklist at the end. Note on each capture the navigation path, numeric formats, units, button actions and alarm behavior while it is still fresh.

Last, read the small panel's documentation and list the objects and PLC drivers it supports. Every mismatch you find here is a plan change; every mismatch you find after building is rework.

How do you inventory screens and PLC tags in the old project?

Walk the old project screen by screen and record, for every object on every screen, the PLC address, the data type, the scaling and whether the object reads or writes. That count is the size of the rebuild and the length of your sign-off sheet.

Fill one row per object:

Then split the list with the operators: what they read every shift and what they press to run the machine is must-have, and the rest is decoration, the first thing to go when a small display runs out of room. While you are in the PLC logic anyway, write down each address's data type and scaling there too, so the mapping check later compares two independent records instead of the panel against your memory.

How do you build the new project on the smaller panel?

Create a fresh project with the small panel selected as the target, configure the PLC connection from your recorded settings, and rebuild the screens in priority order, mapping each object to the address on the inventory sheet as you place it.

1. Create a new project with the small panel as the target. Build from an empty file. A renamed copy of the old project carries the old target into every screen you touch.
2. Prove the PLC connection before building screens. Enter the recorded settings and confirm live data with a PLC heartbeat counter, so a communications fault never masquerades as a rebuild fault.
3. Rebuild the must-have screens first, in the priority order from the inventory. The machine comes back on runnable screens; decoration waits.
4. Use only objects the target supports. When a dense screen cannot fit the small display, split it into two screens with navigation buttons, and carry titles and unit labels across so nothing loses context.
5. Map every object to its inventoried address. Confirm data type, scaling and engineering units against the PLC logic, and set read or write intent to match. A data type mismatch is the classic garbage read: nonsense numbers from a BCD analog register is what it looks like at runtime.
6. Rebuild any screen-change handshake from the PLC. If the program writes a screen number to a register on the panel, recreate that exchange (a screen number written from the PLC) and make the screen numbers you assign in the new project match the values the program sends.
7. Compile, fix what the tool reports, save a separate working copy. Name the copy with the panel model and the date so versions cannot be confused on the bench.
8. Bench test before the panel goes back on the machine. Watch every display follow PLC state and press every command once. For any command that changes machine state, put the machine in a safe state under lockout/tagout practice first, and check the panel's key switch before trusting a write: write errors with reads still working usually trace to the key switch, as in fixing HMI write errors when PLC reads still work.

How do you verify every register mapping first?

Confirm every tag against the PLC program itself, not the screen label. Each tag is one check of address, data type, scaling and read or write direction, and the rebuild is finished when the count of unverified addresses is zero.

Work the inventory sheet with a check column added. For each display object, open the PLC instruction that owns the address and confirm the panel points at the same register with the same type. For each setpoint, type a value such as 50.0 °C at the panel and read the raw register: it must arrive in the logic as exactly the scaled value the program expects.

Then press the commands. For each write object, watch two things at once: the indication on the panel and the value in the PLC. They move together or the mapping is wrong, and only the intended register may move. A clean compile is not proof of correct behavior; the press test is. Where the installation procedure allows it, drop the communications link once and watch what the panel displays and how it recovers, because operators will see that behavior eventually and it should not be a surprise on a running machine.

Sign-off is arithmetic: every row on the sheet checked, unverified count zero. Scan the finished sheet into the project folder next to the new file.

Example: how long does a 6-screen, 20-tag rebuild take?

A 6-screen, 20-tag rebuild fits in about 8 hours: 1 hour to back up and inventory, 2 hours for the new project and PLC connection, 4 hours to rebuild 6 screens at 40 minutes each, and 1 hour to verify the 20 tags.

Picture the job. The old panel runs 800 x 480; the replacement runs 480 x 272. The new display offers about a third of the pixels: 480 x 272 = 130,560, 800 x 480 = 384,000, and 130,560 / 384,000 = 0.34, so roughly 34% of the area. Two of the six screens filled the old display, so each becomes two screens on the replacement, and the budget lands here:

The arithmetic: 6 screens at 40 minutes is 240 minutes, 4 hours; 20 tags at 3 minutes is 60 minutes, 1 hour; 1 + 2 + 4 + 1 = 8 hours. The estimate assumes the driver for the PLC exists in the small panel's software, the screens were captured while the old panel still ran, and one PLC on one link. What moves it: each unsupported object that must be redesigned adds time, a split beyond the 2 planned adds about 15 minutes each, and a missing driver does not stretch the day at all; it stops the job, which is the decision below.

Recommendation: Rebuild, do not convert, whenever the replacement is a different panel family, and budget one controlled working day for a project of about 6 screens and 20 tags. If the small panel's software lacks the PLC driver or a must-have object, stop before commissioning and fit a supported replacement in the same size class instead.

When should you keep the bigger panel instead?

Keep the larger panel when the shrink would hide information operators use every shift. If the small target drops a required object, a PLC driver or most of the screen area, fit a supported replacement panel in the same size class instead.

Two paths beat a stripped rebuild. A replacement from the same panel family as the original reopens the existing project as it stands, and the job becomes a swap; ask for the model the current software version supports. A newer panel in the same vendor's line may carry a documented migration path, with settings that define how each screen adapts to the new format; use it where it exists, then verify every migrated object against the inventory sheet before sign-off, because a migrated file is a starting point.

And check the job itself. If the small screen's real work is a notice or status board fed with pages you publish, not live machine control, that is a signage job: our shop-floor screens are built for it, with offline playback or your own Android app, and the HMI rebuild rules on this page do not apply to them.

Questions