Book a consultation

PanelView and FactoryTalk View: Rockwell HMI and Visualization

PanelView Migration Paths: Which Upgrades Are Rebuilds

Which PanelView upgrades are application conversions and which are full rebuilds, why the software lineage decides it, and how to plan a terminal replacement without surprising the schedule.

Vladimir Romanov


The mistake in every under-scoped HMI upgrade is the same: 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.

The paths

FromToWhat it is
PanelView Plus 6PanelView Plus 7Conversion. Same FactoryTalk View ME lineage. Application converts, screens largely survive
PanelView Plus 7 StandardPanelView Plus 7 PerformanceConversion. Same lineage, more capability
PanelView StandardPanelView Plus 7Rebuild. Different software lineage entirely
PanelView Plus (any)PanelView 5000Rebuild. View Designer cannot open a FactoryTalk View ME application
FactoryTalk View MEFactoryTalk View SERebuild 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.

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. 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.

How an HMI resolves a controller, and where it breaks A four stage chain: HMI application, named shortcut, FactoryTalk Linx, controller. The shortcut and Linx stages are highlighted as where failures occur. Causes listed are controller firmware flash, chassis slot change, new IP address, and a server restored from a different machine. HMI application screens and tags Named shortcut e.g. "PLC_Line3" FactoryTalk Linx resolves shortcut to a path Controller chassis, slot, IP The application is almost never the problem everything that breaks an HMI lives in these two boxes Controller firmware flash · chassis slot change · new IP address · server restored from a different machine Each invalidates the shortcut and leaves the application untouched.
This is why an application tests clean on the desk and fails after download. Start at the shortcut, not at the code.

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. Convert offline and resolve every conversion warning individually
  3. Rebuild the communication path on a bench terminal and prove it against the real controller
  4. 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
  5. Swap during a window, with the old terminal kept on site until the new one has run a full production cycle
  6. Keep the old application archived and openable, which means keeping the software that opens it

Step six 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.

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 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.


Related: FactoryTalk View SE vs ME · HMI and Visualization · Rockwell Automation hub

← HMI and Visualization

Have a project that needs technical ownership?

Send us the situation. If it is not something we should take on, we will say so.