PanelView Migration Paths: Which Upgrades Are Rebuilds

PanelView migration goes wrong for the same reason every time: the terminal is treated as hardware. Budget the software lineage, not the hardware generation. Two terminals that look interchangeable on a datasheet can be a two-day swap or a six-week rebuild, and what decides it is the tool the old application was built in. This page sets out which paths convert and which rebuild, what conversion really involves, and how to plan a terminal replacement.

The PanelView migration paths

From	To	What it is
PanelView Plus 6	PanelView Plus 7	Conversion. Same FactoryTalk View ME lineage. Application converts, screens largely survive
PanelView Plus 7 Standard	PanelView Plus 7 Performance	Conversion. Same lineage, more capability
PanelView Standard	PanelView Plus 7	Import plus rework. Different software lineage. Rockwell’s guide imports the application into View ME, then you resolve object mapping and unsupported features
PanelView Plus (any)	PanelView 5000	Rebuild in practice. View Designer cannot open an ME application; Rockwell’s display converter is a starting point only
FactoryTalk View ME	FactoryTalk View SE	Rebuild plus an infrastructure project. See ME vs SE

The PanelView 5000 case catches people. It is newer, it is well regarded, it browses Logix tags directly rather than requiring them to be mapped, and it is a completely separate toolchain. A plant with twenty PanelView Plus terminals that specifies a PanelView 5000 on the next machine now maintains two HMI design environments, two sets of skills and two libraries of screens. That may be the right strategic direction. It is never the right accidental outcome.

The PanelView Standard case is better than it was, and still not a swap. Rockwell’s migration guide imports the PanelBuilder32 application into FactoryTalk View ME and walks through a conversion log, object mapping and unsupported features, and warns that controller ladder logic may need changes too. It also notes that the new terminal’s higher resolution leaves an unresized application sitting in the top left of the screen, so every display needs layout work.

What “conversion” actually means

Even on the supported path, conversion is not free.

Screen resolution changes. Terminal sizes and aspect ratios differ across generations. Objects scale, but layouts designed for one geometry frequently need manual adjustment, and text that fitted no longer does.

Deprecated objects. Older applications sometimes use objects that no longer exist or behave differently. These surface at conversion, individually, and each needs a decision.

The communication path does not convert. The FactoryTalk Linx or RSLinx Enterprise shortcut is configuration on the terminal, not content in the application, and the ME user’s guide keeps separate design and runtime paths. It has to be rebuilt and pointed at the controller, and getting this wrong is the single most common cause of an HMI that tests clean and fails after download. See the failure section on the visualization page.

Firmware and software version alignment. The terminal firmware, the FactoryTalk View version that built the application, and the runtime on the terminal all have to be compatible. A terminal arriving with newer firmware than the site’s design software supports is the same class of problem as the Studio 5000 firmware coupling.

Planning a terminal replacement

Realistic sequence for a like-for-like generation upgrade:

1. Inventory the terminals, by catalogue number, firmware, application version and what each one talks to. This is usually where the surprises are
2. Find the editable source. A PanelView Plus runs a compiled .mer runtime file, and the ME guide lets its author allow conversion back to an editable application, protect it with a password, or never allow it. If the only copy is a locked runtime file, that terminal is a rebuild
3. Convert offline and resolve every conversion warning individually
4. Rebuild the communication path on a bench terminal and prove it against the real controller
5. Test on the bench with the machine running, if the network allows a second client. Most path faults appear here rather than at the desk
6. Swap during a window, with the old terminal kept on site until the new one has run a full production cycle
7. Keep the old application archived and openable, which means keeping the software that opens it

Step seven is the one plants skip and regret. A terminal replaced two years ago whose original application can no longer be opened is a machine that can no longer be rolled back.

A worked example (illustrative). A plant has twelve PanelView Plus 6 terminals and four PanelView Standards across two lines. The inventory finds that three of the Plus 6 units hold runtime files built with conversion never allowed, and no source in the archive. Those three are rescheduled as rebuilds and drawn against the site’s screen standard. The other nine convert, two per weekend, after their shortcuts are proven on a bench terminal. The four Standards are imported, reworked for the higher resolution, mounted in the old cutouts with adapter kits, and swapped during the shutdown already planned for the SLC 500 they talk to, because that migration repoints their tags anyway.

When to replace rather than migrate

Sometimes the right answer is not to carry the application forward:

• The screens were built for a different machine. Twenty years of modifications to a layout designed for a process that no longer exists
• The graphics are imported artwork. Rendering slowly, scaling badly, and worth redrawing as native objects
• The alarm model is per-screen and inconsistent, which is a rebuild whether or not you call it one
• Operators route around it. The clearest signal. If the operators keep a paper sheet next to the terminal, the terminal is not doing its job and conversion will faithfully preserve that

What goes wrong

• The terminal is swapped and the shortcut is not rebuilt, so the new screen shows stale or missing values on the first shift
• A PanelView 5000 arrives on one OEM machine and the site gains a second HMI toolchain by accident
• The runtime file is the only copy, and nobody finds out until a change is needed
• Layouts are not resized, so operators get a small application in one corner of a larger screen
• The old terminal leaves site on day one, removing the only fallback if the new one fails

Checklist before you order terminals

• Each terminal classified as conversion, import plus rework, or rebuild
• Editable source located for every application, not only the runtime file
• FactoryTalk View version and terminal firmware checked for compatibility
• Communication paths documented, and a bench terminal available to prove them
• Mounting checked: same cutout, adapter kit, or a new door
• Old terminals and archives kept until the new ones have run a full production cycle

What we do

We inventory the estate against lifecycle status, classify each terminal as conversion or rebuild before any budget is committed, and rebuild communication paths properly rather than debugging applications that were never broken. Where a rebuild is warranted we design screens against ISA-101 selectively, applying it where it earns its keep on the equipment in question rather than wholesale. It is usually one workstream within a wider control system modernization.

---

Related: FactoryTalk View SE vs ME · HMI and Visualization · Rockwell Automation hub · PLC-5 and SLC 500 migration