PLC CSV tags missing after HMI database import

Why does a PLC CSV full of tags import into the HMI as nothing?

The two checks that find it, in order, are symbol assignment and record format: the panel maker's import application note requires a symbol on each I and O address before it will import, and a reference export exposes every format difference a manual never lists.

A spreadsheet shows the rows because the export wrote them; the import reads each record against the pattern it accepts, and the two tests are different. Budget the job at about an hour: 20 minutes to count and name addresses in the PLC project, 15 minutes to build a three-tag reference export, and 15 minutes to compare and correct. Run the symbol check first because it is the documented requirement and the cheapest to fix. Keep the format comparison for a file that is fully named and still imports nothing.

What do the symptoms tell you before you edit anything?

Match the result to one of four patterns before editing anything, because each pattern points at a different fault: zero tags from a full file, a partial count, a good count with blank screens, or one address that refuses to come across.

• Full file, zero tags. The importer accepted no records at all. Start at the symbol check in the PLC project, because the application note makes symbol assignment a requirement for importing I and O addresses.
• Part of the file comes across, say 31 of 96 rows. The rows that imported differ from the rows that did not in some field. Compare a rejected row against an imported one, then against the reference export.
• The database count looks right but the screens stay blank. The import finished and the fault sits downstream: the tag is not bound to a display object, or the address typed on the object is wrong.
• One address refuses to import while its neighbors come across. That is a single-tag fault, not a file fault, and it has its own short checklist.

Do the I/O addresses have symbols assigned in the PLC project?

Open the PLC project's address database and count before you touch the CSV: the application note for this import names symbol assignment as a requirement for importing I and O addresses, so an unnamed address is the first suspect in a zero-tag import.

The symbols live in the same database you exported, so the check happens in the project, not in the file. In RSLogix 500, open the project's data files and read the symbol column for the address range the machine uses. A program written in raw addresses with empty symbol fields is the classic cause of a zero-tag import.

1. List the addresses the screens need and count them, for example 40 inputs and 56 outputs.
2. Check each address for a symbol and write down both counts: addresses needed, addresses named.
3. Name every address you want imported, exactly as the electrical drawings name the devices.
4. Save the project, export a fresh CSV and import that file. The export still sitting on disk from yesterday shows the project as it was before you named anything.
5. Compare the tag count in the HMI database with the address count: 40 inputs plus 56 outputs should come back as 96 tags.

The same discipline pays off outside the panel: a CSV tag list for OpenOPC built from a symbol export also starts from named addresses.

How do you build a reference export the HMI accepts?

Create two or three tags by hand in the HMI software, one per address type the screens need, and export them: that small file is the accepted format in your hand, and no amount of inspecting the PLC export substitutes for it.

Match the hand-made tags to the address types in the project: one input, one output, one word address if the screens use one. Open both files in a text editor, not a spreadsheet, because a spreadsheet hides the raw layout. Some tag importers never document their accepted columns in the manual, so this reference is the only accepted format you can hold.

Make one deliberate change per import attempt, on a copy, with the original export untouched. Re-importing an unchanged file settles nothing: records the importer refused the first time it refuses again.

How does the fix play out on a 96-address example?

A packaging line rebuild gives the numbers: the program uses 96 I/O addresses, the CSV holds 97 lines with its header, and the first import returns 0 tags, so the symbol check runs before anything else.

The program runs 40 inputs for sensors, gate switches and the e-stop chain, and 56 outputs for motors, diverters and the reject solenoid: 40 + 56 = 96 addresses. The RSLogix 500 export carries 97 lines: 96 address rows plus 1 header row. The project's data files show an empty symbol field on all 96, because the program was written in raw addresses.

Naming takes about 45 minutes with the electrical drawings open: 40 input names and 56 output names, entered exactly as the drawings call the devices. Save the project, export again, and the file still holds 97 lines. This import returns 96 tags, and the tag count matches the address count exactly. Spot-check 3 of the 96 against the drawings: addresses match and names are spelled as entered. The fault was project data, so the fix lives in the project and every future export imports cleanly.

Had all 96 addresses carried symbols on the first pass, the same counts would send the job to the reference comparison: 3 hand-made tags produce a 4-line file, set it beside the 97-line export, and correct the first difference you can point to, one change per import, on a copy.

How do you test a corrected file without losing the original?

Change one thing per import attempt and write the counts down before and after, for example 97 lines in and 0 tags out, then 97 lines in and 96 tags out, so every improvement traces to the one edit that caused it.

Copy the original export and edit only the copy; the untouched file is the fallback and the record of what the PLC project actually contained. Fix project-level faults in the project and format faults in the CSV copy, never both in one pass, so a working import tells you which correction mattered.

Recommendation: Run the symbol check first on every zero-tag import. Count the addresses the screens need, name every one of them in the PLC project, save, re-export and import before comparing a single column. If a fully named file still imports nothing, build the three-tag reference export and correct one difference per attempt.

After a clean import, check the tag count against the address count and open a few records to confirm each address and name against the PLC project before any screen goes live.

What if the import succeeds but one tag or one screen still misbehaves?

Split the fault by scope: a single address that will not import is a per-tag problem with its own fix, while a database full of good tags feeding a blank screen is an addressing or binding problem on the display side, and each has a shorter checklist.

When one address is locked or refuses to import while its neighbors come across, fixing an HMI tag whose PLC address will not import walks one address to ground. When the database is full and a numeric display still shows nothing, the next stop is the tag address on the screen object, the first check in fixing an HMI numeric display that shows nothing. When the panel took a download but the messages never appear, the panel that shows no messages after a download has the two checks that sort it.

Once panel and PLC agree, a separate shop-floor status screen keeps counts, alarms and shift messages in front of the whole crew without crowding the HMI screens; our shop-floor and andon-style display section covers those screens.

Questions