Export an HMI tag database to CSV when you change panels

What moves and what has to be rebuilt

Split the job in two before you open either software package.

What the CSV carries: the tag names and their database entries. Every tag the new screens reference already exists, with the controller address it had on the old panel.

What the CSV leaves behind: screens and graphics, the object-to-tag wiring on those screens, alarm definitions and texts, recipes, password levels, screen navigation, and the communication settings for the new panel.

Two conclusions follow. First, write down what the operator interface actually does, from the running machine, before you build anything: what each screen shows, what the operator enters, which alarms matter. Second, know the difference between this job and a version change. Opening an old project in a newer release of the same software has a conversion path with its own checks; see how to convert an old HMI project in new software safely. A move to a larger panel of the same family can convert directly too. Between families there is no conversion, and the rebuild discipline is the same one you need when you move a project to a smaller panel.

What you need

• The old project file, and the old panel still mounted and powered as the reference.
• The old panel's software installed on your engineering PC, for the export.
• The new panel's software, with a new project created for the new panel and its PLC driver selected.
• A spreadsheet application, to read the exported .csv and count its rows.
• A test connection to the PLC, so rebuilt screens can be exercised against live values.

Capture what the CSV cannot carry

The .csv file is one of five things to save. The other four have no import path, so capture them as documents:

• The alarm list: every alarm text, its trigger tag and its order in the old list.
• The screen list: one line per screen, with its name and what the operator does there.
• The communication setup as configured in the old project: protocol, station number, baud rate.
• Any recipe or password structure the operators rely on.
• The project backup file, kept in the same folder as the .csv you are about to export.

A printed screen list sounds primitive, but it is the checklist you tick off during the rebuild, screen by screen.

Export the tag database to CSV

1. Open the old project in the old panel's software.
2. Run the export for the tag name database. In this software family the command sits under the File menu; if your version hides it, search the help for export tag name database.
3. Save the file as .csv into the folder that holds the project backup, named for the machine and the date.
4. Open the .csv once in a spreadsheet to see what you have: one row per tag, with the tag name, controller address and data type in the columns. Note the row count, then close the file without saving. The import wants the file exactly as the old software wrote it, so keep the spreadsheet from editing and re-saving the original.

Import the CSV into the new project

1. Create the new project in the new panel family's software and select the driver that matches your PLC and protocol.
2. Choose File > Import > Tag name database.
3. Browse to the exported .csv and open it. The import fills the new project's tag database.
4. Compare the tag count in the new database with the row count you noted from the CSV. The two numbers must match before you go further.
5. Only then start rebuilding screens. An import that came up short will waste an afternoon of object wiring, so reconcile it first.

If the imported count is short

Sort the CSV by tag name in a spreadsheet, sort the imported list the same way, and walk down the two columns side by side. The first name that appears on one side only marks where the import skipped or stopped, and that name usually shows the cause: a duplicated row in the file, or a character in the name the new software does not accept. Fix the names in the old software, re-export, and import again, then re-count.

How to check the imported tags

A matching count says the file arrived complete. It is not proof the entries survived intact, so spot-check before you wire objects. Pick the first tag, the last tag and ten names spread through the middle of the sorted list, and open each in the new database. Compare three fields per tag: the name, the controller address and the data type.

Data types deserve a second look when the two families differ in what the panels support. If a numeric object later shows a shifted or clipped value, the tag's data type in the new project is the first place to look, and changing a tag's data type can be done without rebuilding every object that uses it. Counting first and comparing fields second is the same habit used when you import a PLC tag file into an HMI project and verify it.

Worked example: 84 tags off a 6-inch panel

The old panel is a 6-inch unit from the small-panel family, running the interface on a packaging machine. Its tag database holds 84 tags: 60 PLC register tags for values and statuses, 16 alarm bits and 8 screen-change tags.

Retyping that database by hand means four entries per tag, name, address, data type and scaling note: 84 × 4 = 336 typed fields. At about one minute per field, typed and double-checked, that is 336 minutes, or 5 hours 36 minutes of keyboard work, and each field is one more chance to mistype a controller address. The export and import does the same work in two commands.

After the import, the new database lists 84 names. The count check closes: 60 + 16 + 8 = 84, so nothing was dropped. The spot-check of 12 tags, first, last and ten through the middle, shows matching addresses and data types on every one.

The screens are another matter: the old project had 9 screens, and each is rebuilt by hand in the new software. The imported tags mean every object you place can be wired to a tag that already carries the right address. The tag move turned a retype-and-rebuild job into a screen-rebuild job, which is exactly what it should do.

Rebuild, test, then swap

Rebuild the screens one at a time with the old project open beside you. After each screen, exercise it against the live controller: values update, inputs produce the machine response the old panel produced, alarms trigger and clear with the right texts, and navigation returns to the main screen. Tick each screen off against the screen list you captured.

Before the swap, run the full check: every screen opens, displayed values agree with what the PLC actually holds, every operator input behaves as before, and the new panel recovers cleanly from a power cycle. Do the changeover in a planned stop, with the old panel still mounted, and run the check again on the new hardware before production resumes; a machine should never run from a half-checked interface, and if the HMI is the only view of its state, the old panel is your rollback until the new one has passed on the real machine.

Recommendation: Export and import the tag database before you draw anything. Capture the alarm list, screen list and communication settings first, export the .csv from the old software, import it through File > Import > Tag name database, and wire no objects until the imported tag count matches the CSV row count and the 12-tag spot-check has compared names, addresses and data types. Keep the old panel mounted and powered until the rebuilt project passes the full check against the running machine.

If the rebuild is also the moment you add a shift-target board or a downtime counter beside the machine, that is a separate screen with its own mounting, brightness and power decisions; the shop-floor screens section on this site covers that side of the job.

Questions