A project built for a small panel runs unchanged on a larger panel of the same family. Back up the running project, test it in the simulator, download the untouched copy, and check communication and touch on the machine. The old graphics arrive scaled up, so judge text and touch spacing at the panel before planning any screen edits.
A small operator panel is due for replacement, and the larger unit in the same family is the chosen replacement. The question that decides the whole job: does the programming carry over, or does every screen have to be rebuilt for the bigger glass? It carries over. What the size change does alter is how the original graphics look, because the screens were drawn for a lower resolution and now display enlarged. This article walks the swap in the order you meet it: the backup, the simulator check, the download, the checks on the machine, and the decision on screen edits.
Will a project built for a 3-inch panel run on a 6-inch panel of the same family?
Yes, a project written for the 3-inch screen loads on the 6-inch screen of the same family without edits, and the original graphics arrive as an enlarged image of the 3-inch screens. The swap does not ask for a rebuild.
Panels in one family share a project format, a driver set and a simulator, so the software treats the 6-inch unit as the same kind of device with a bigger canvas. Most project software documents a device-copy or change-panel-type step for exactly this move; where yours has one, that is the supported path. A move across families is a different job: different software, different drivers, and usually a screen-by-screen rebuild, so keep the two jobs separate in your planning.
The shared canvas is also why the graphics survive: a family keeps one layout in pixels across its sizes. We explain that in why two HMI panel sizes share one layout in pixels.
What do you need before you touch the running panel?
Gather four things before the machine loses its screen: an untouched backup of the running project, a working copy for the 6-inch target, the software and version that opened the original, and the transfer route to the panel, normally an Ethernet cable. None of this happens at the machine; the whole preparation runs on your PC while the 3-inch panel keeps operating.
- An untouched backup of the project that is running today. This is the rollback copy, and nobody edits it.
- A second working copy, named for the 6-inch target, that carries any changes.
- The project software and version that opened the original. If the backup refuses to open on the shop PC, the usual cause is a version mismatch, which we cover in a project that will not open after moving PCs.
- The transfer route the old panel uses, normally an Ethernet cable and an address, plus the driver and node or IP settings written down so the replacement can take them over.
If the running project cannot be backed up, stop there and fix that first. A swap without a rollback copy turns a small upgrade into a rebuild you did not plan.
How do you test the project in the simulator first?
Run the untouched working copy in the simulator before the swap; it is the fastest way to see how the scaled screens will look and whether anything fails to load, without wiring anything. Families that ship a simulator document it as a pre-transfer check, so this stage costs no downtime.
- Open the working copy and set its target device to the 6-inch panel, using the documented device-copy or change-panel-type step.
- Start the simulator and run the project with no edits.
- Walk every screen an operator uses: navigation, numeric entry, alarm displays, and the screens with the smallest text.
- Note any screen that reads poorly or any control that is hard to identify. That note is the edit list for later, if you need one at all.
- Close the simulator and leave the project exactly as it was.
To judge text size at a desk, you can also show the HMI screen on a larger monitor while you walk the screens. The simulator shows project behavior, not controller traffic or real touch, so the on-machine checks later in this article still apply.
Worked example: what does a 320 x 240 project look like on an 800 x 480 panel?
A 320 x 240 project fills an 800 x 480 screen only as enlarged pixels with borders, or stretched: the width would need 2.5x scale and the height 2.0x, and one canvas cannot do both at once. The arithmetic decides what your operators will see, so run it once.
The two resolutions carry different aspect ratios: 320 / 240 = 4:3 and 800 / 480 = 5:3. One scale factor cannot fill both axes of a wider screen.
- Scale to fit the height at 2.0x and the project renders 320 x 2.0 = 640 px wide. The screen is 800 px wide, so 800 - 640 = 160 px of width sits empty as borders.
- Scale to fit the width at 2.5x and it renders 240 x 2.5 = 600 px tall, so 600 - 480 = 120 px of height overflows and has to be cropped or squeezed.
Whichever way the runtime fills the screen, the result is enlarged pixels, blank borders, or a non-uniform stretch that turns circles into ovals.
The physical sizes work in your favor. Estimate from the nominal sizes: a 3-inch 4:3 active area is about 2.4 x 1.8 in, so the pixel pitch is 2.4 in / 320 px = 0.0075 in, about 0.19 mm. A 6-inch 5:3 active area is about 5.15 x 3.09 in, so the pitch is 5.15 in / 800 px = about 0.0064 in, about 0.16 mm. A character 16 px tall measures 16 x 0.0075 = 0.12 in on the 3-inch panel; scaled 2x it renders 32 px, about 0.21 in on the 6-inch. Text comes out roughly 1.7 times taller. Touch targets grow the same way: a 24 px square button spans 24 x 0.19 mm = 4.6 mm on the 3-inch panel and 48 x 0.16 mm = 7.7 mm on the 6-inch.
So the swap magnifies the original design. The only open question is whether the magnified result reads and touches well at the panel, which is what the remaining checks decide.
How do you load the project onto the replacement panel?
Download the untouched working copy to the replacement panel over the route the old one used, normally Ethernet, and let the panel start at its normal operating screen. The target device was already set to the 6-inch panel before the simulator run, so the copy you download is the copy you proved in simulation.
Where the family documents a change-panel-type or copy-device step, follow it as printed; that is the supported route, and it carries tags, screens and controller connections across intact. When the software asks you to pick the new model, match the replacement panel's identification exactly as printed on it, not the old panel's.
If the download stops with a message, work in this order: note the exact wording, confirm the target device and the panel identification agree, and confirm the software version supports the larger panel. Keep the old panel connected until the download succeeds; it is the machine's working screen until then.
Check: the replacement accepts the project and starts at its normal operating screen, showing the enlarged 3-inch graphics.
What do you check on the machine before it goes back to service?
Bring the machine to a state where the screen can be exercised safely, then check five things: values update, representative controls act, alarms trigger and clear, screen navigation works, and the worst screen still reads from the operator's normal position, about 1 m away at a typical machine station. The simulator could not run these, because it has no controller attached and no real touch hardware, so this stage is the first true test of the swap.
Exercise operator actions only when the machine can respond to them safely; a wrong press during commissioning moves a machine, not a picture. Then work the list:
- Values update against the controller, which shows the driver and the connection path run on the new hardware.
- A representative control acts, and the machine does what the screen said it would.
- An alarm triggers and clears, so the alarm list, banner and colors survived the scale-up.
- Navigation reaches every screen the operators use.
- The worst screen reads cleanly from about 1 m, the operator's normal standing distance.
Compare against the old panel's behavior or the untouched backup while you go. Keep the backup project and the old panel within reach until every line passes; that is the rollback if anything surprises you.
When does the swap justify editing screens after all?
Leave the project alone at first. If, after a shift or two on the real panel, operators report unreadable text or a control that is hard to hit, edit those screens only, keep the tested copy as the rollback, and work down the worst screens first. The example numbers explain why patience pays: the scale-up already made text roughly 1.7 times taller and buttons about 7.7 mm across, so most layouts drawn for the small canvas improve on the larger panel without any work.
The screens that usually earn edits are the dense ones: alarm lists that filled the small canvas, small numeric keypads, and screens that crowded the 320 x 240 grid. If you edit, the spare width is the prize. At the 2.0x fit, 160 px of width sits unused, enough for a persistent alarm banner or a trend window on the screens operators watch most. Keep the tested project as the rollback, edit one screen, test it at the panel, and continue down the list you made in the simulator.
If the upgrade comes with a request for a shift-target or status board beside the machine, that is shop-floor signage, a separate display that plays your own image and video files from a memory card. It is not an HMI and has no video input, so it cannot stand in for the operator panel.
Recommendation: for a size upgrade within one family, download the project unchanged: back up the running copy, set the target to the larger panel, pass the simulator, pass the on-machine checks, and hold every screen edit until operators have worked with the larger panel for a shift or two. Then edit only the screens that fail, from the list you noted in the simulator.
Questions
Can I prepare the new panel while the old one keeps running?
Yes. The backup, the working copy and the simulator run on your PC, so the machine keeps its screen the whole time. Plan the outage for the download and the on-machine checks only, and keep the old panel as rollback hardware until those checks pass. Most of the swap happens at a desk, not at the machine.
What are the usual causes when the project will not download to the replacement?
Two, in this order: the target device set in the project and the replacement panel's identification do not match, and the software version on the PC predates the larger panel and needs an update before it can address it. Note the exact message first, then fix the version, then the target. Recreating screens to force a download destroys the baseline you are trying to establish.
Does the move change how the project talks to the controller?
The driver, tag addresses and protocol settings travel inside the project, so the controller sees the same requests from a new panel. Check the physical and network details that belonged to the old unit: its IP address or node number, the serial port it occupied, and the cable. Enter those on the replacement, then check that values update before the machine returns to service.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.