Converting a legacy HMI project when the converter rejects the format

Why did the converter take the .ezt files and refuse the .ezp file?

Because the converter was built for the older project format of that panel family: it imported .ezt projects and refused the .ezp file saved by the source programming software at Version 5.4.

The same panel model was sold under two software lines over the years. The converter follows the software line, so the model number on the housing says nothing about the format inside the file. The .ezp format arrived with the later versions of the source software, and the converter in this job accepted the older .ezt files only.

Renaming the extension does nothing. The extension is a label on the outside of the file; the converter reads the structure inside. A renamed .ezp file fails the same import, and a forced import of a mismatched structure would leave you checking a damaged project screen by screen.

So the check is cheap and it comes first. Read the extension, then find the software name and version that last saved the project. The version usually sits in the About box, on the splash screen, or in the project's own properties. In this job the pair was .ezp plus Version 5.4, and that pair answered the question before any import was attempted.

What facts decide whether a conversion is possible?

Four facts, and the first two decide the path: the project's file extension, the name and version of the software that last saved it, the source panel model, and the target panel model.

What you need on the bench:

• The original project file, and a working copy. Keep the original untouched; every import attempt and experiment runs on the copy. The discipline is the same one described for backing up and restoring an HMI panel project the safe way.
• The software name and version that last saved the project.
• Both panel model numbers, so you can check the target panel's driver list against your controller.
• The target software's current import documentation, read for that exact source format.

If the original file is gone, check whether your panel model supports a project read-back before you count on recovery; why a legacy HMI project cannot be uploaded from the panel explains the common limit.

How do you test the converter without wasting days?

One attempt on a copy, then the simulator: the documented demo limits allowed converting an existing project, verifying it in the simulator, and saving the converted project exactly once.

1. Copy the source project and work only on the copy.
2. Open the target software and run its documented import or conversion function on that copy.
3. If the converter refuses the file or does not list its extension, stop. The format sits outside the documented path, and repeating the import changes nothing.
4. If it imports, save the converted project to a new file immediately; a demo build may allow that save once.
5. Run the converted project in the simulator before anything goes near the panel.

What each result tells you:

The one-save limit shapes the demo's role. It is enough to learn whether your format imports and how the result behaves in the simulator. The production work, with its repeated saves and the download to the panel, belongs on a licensed copy of the target software.

When do you stop converting and start rebuilding?

The moment the documentation and the import attempt both say no: the source project then stops being a convertible file and becomes your specification, and the job is measured in working days.

Collect the specification before you build: the screen list, every tag reference, the navigation paths, the alarms and status displays, and every operator action. Compare each function the source project uses against the target software's documentation, and confirm the replacement behavior in the simulator. Keep every function until you have checked it; dropping one on a guess about compatibility costs more than carrying it.

For the wider workflow, convert an old HMI project in new software safely covers the opening and conversion sequence; this article stays on the refused-format path. When the target panel is a different size, rebuilding an HMI project for a smaller panel shows the layout work a converter cannot do for you. Before the replacement panel is ordered, check the PLC serial protocol before replacing a legacy HMI: a rebuilt project still needs a panel that speaks to your controller.

How long does a worked example of 150 screens take?

About 3 days of building plus half a day of verification for 150 screens on an 8-inch panel, which is 50 screens a day; at that pace a 137-screen project is 2.7 days of building, so plan 3 days plus the half day of checks.

The scenario: one controller handling 24 zones, every zone carrying the same variables, Temperature Z01 and Temperature Setpoint Z01 at zone 1, running to Z24 at zone 24. The project held 150 screens, and the zone screens were one layout repeated with a shifted index.

1. Zone 1's screen was built by hand: labels, tag references, scaling, navigation, and the write behavior of every control.
2. A macro recorded in a Windows macro tool replayed that build and incremented the zone index in each tag, so Temperature Z01 became Temperature Z02 on the next screen.
3. Zones 2 through 24 were generated with the macro: 1 hand-built screen plus 23 generated screens covered all 24 zones.
4. The remaining 126 screens, 150 minus 24, were built by hand or by macro where the layout repeated.
5. All 150 screens were then verified.

The arithmetic behind the figures: 150 screens in 3 days is 50 screens a day. Verification at 2 minutes a screen is 150 times 2 minutes, which is 300 minutes, or 5 hours: the half day the job actually took. For a 137-screen project, 137 divided by 50 is 2.74, so plan 3 days of building and half a day of checking, 3.5 working days for one person. Over five years of use on this class of work, one report put the macro tool's saving at about 60 percent of programming time.

Recommendation: When the converter refuses your project's format, stop retrying the import and commit to the rebuild. Budget one working day per 50 screens plus half a day of verification. Use the tag-increment macro only on screens that repeat a layout already verified in the simulator. Keep the original panel in service until the rebuilt project passes on the machine. A 137-screen project lands at about 3.5 working days for one person on that plan.

How do you generate repeated screens without carrying tag errors forward?

Build one zone screen by hand, prove it in the simulator, and only then let the macro copy it: a macro repeats a wrong tag mapping exactly as fast as a right one, so the template must be correct before anything is generated.

1. Build zone 1's screen and list every displayed value and every operator entry with its intended tag.
2. Prove that screen in the simulator: labels, scaling, navigation, and the write behavior of each control.
3. Record the macro on the zone 1 to zone 2 step, so it captures only the increments: tag index, screen number, screen title.
4. Generate zones 3 through 24 with the macro.
5. Check every generated screen against a zone-to-tag list: each displayed value and each write target must belong to that screen's zone.
6. Build exception screens by hand; a screen with a different job deserves its own build.
7. Keep a cross-reference of source screen, new screen, and tag group. A shifted zone index shows up in that list during review, and maintenance keeps the map after cutover.

How do you check the rebuilt project before it goes on the machine?

Simulator first, panel second, machine last: open every screen, exercise every operator control, confirm the PLC tag behind each one changes and the machine answers, and run the machine tests in a state where a wrong write cannot hurt anyone.

• Every screen opens, and navigation works in both directions.
• Every control writes the tag you intended, at the boundary values the application defines, not only at midrange values.
• Alarms and status displays change state when their conditions change.
• Each generated zone screen is checked on its own tags; a shifted index hides exactly there.
• The source panel stays in service until the new project passes, and the swap happens on a planned stop with the old project archived beside the cross-reference.

The rebuild is finished when the last zone screen has been checked against its own tag list, not when it looks right.

Questions