Resolving Productivity Suite Tag Import and SystemID Errors

On this installation, a Productivity Suite 2.0.2.1 tag database import reported success, but every retentive flag and initial value stayed at FALSE and 0. A save, close, and reopen then reset the values to default, except for the first few members of the first structure. The fix was a PC restart. The machine had not been rebooted since the in-place upgrade from 2.0.1.3. Once rebooted, the same CSV applied every attribute to in-use tags as intended. The rest of this reference covers the other problems that come up with bulk tag work: SystemID assignment, structure members dropped on import, and generating repetitive logic without a mnemonic export.

Skip the quick fixes that burn the shift

Most of the first-response moves either do nothing or turn one problem into several. Check this table before touching the project.

Check 1: Read the software version and the last reboot time

Record the Productivity Suite version from the About dialog. Then read Windows uptime from Task Manager, Performance tab, Up time. Compare the uptime against when the software was last upgraded.

• Upgraded since the last reboot: restart the PC before anything else, then go to Check 2. The failing installation was upgraded from 2.0.1.3 to 2.0.2.1 without a restart. It showed this import symptom and other erratic behavior until the reboot.
• Rebooted since the upgrade: go straight to Check 2.
• Running a build older than the early-February 2016 updates: plan to update and reboot anyway, because the structure-import defect in Check 4 was resolved in those updates.

Why a reboot matters: an in-place installer replaces program files and shared components. Any component still loaded in memory, or locked by a running process, stays at the old revision until Windows restarts. The editor can then run a mix of old and new code. The import writes the attributes, the display shows them, and the save path works from stale data. The result looks like corruption in the project, but the project file is fine.

Check 2: Prove the attribute change survives save, close, and reopen

Do not test on the full tag list. Build a small file that exercises the exact attributes that failed.

1. Save a copy of the project under a new name. Work only in the copy.
2. Export the tag database to CSV.
3. In the spreadsheet, delete every row except five in-use tags. Include at least one structure member and one standalone tag.
4. Set retentive to TRUE and enter a non-zero initial value on each of the five rows. Change nothing else.
5. Import the file, then open the tag database and read the five tags.
6. Save, close Productivity Suite completely, reopen the project, and read the five tags again.

On a healthy 2.0.2.1 install, import changes any attribute of an in-use tag: remote access, retentive, initial value, and the rest. The in-use flag does not lock attributes against import. If they refuse to change, look at the installation first, not the file.

Check 3: Fill the SystemID column before importing new tags

A spreadsheet row with no SystemID fails with a missing System ID error. This is true even when the data type column (column Q) is filled. The software assigns SystemIDs automatically only when you create a tag inside the editor. The CSV path does not. Automatic assignment on import, keyed off the data type in column Q, was logged as a future improvement. Test the build you actually run before relying on it.

Build the import file this way:

1. Export the current tag database.
2. Delete every row you do not intend to change. Leaving unchanged rows for existing tags in the file did no harm in practice: the import added only the new rows and left existing tags intact. Still, a short file is easier to audit and cannot overwrite what it does not contain.
3. Duplicate a known-good row for each new tag so the data type and format columns carry over.
4. Use search and replace on tag names and comments. Use fill-down for sequential Modbus addresses.
5. Enter SystemIDs from a reserved block (next section). Leave no blanks.
6. Import, then run the count check in Check 4.

Numbering new tags from around 10000 upward got a blocked import through. It leaves a large gap in SystemID numbering. That gap has no functional cost, because logic references the tag name, not the number.

Reserve SystemID ranges for spreadsheet-built and HMI-built tags

Tags created in the editor start at C000001 and count upward. Tags built offline need their own block so the two sources never collide. This works when the project is small relative to the available SystemID space.

Where the editor resumes after an import is not documented. Test it before committing a numbering plan:

1. Import a small block, for example C010000 through C010050.
2. Create one new tag in the editor and read its SystemID.
3. If it lands in the low range, keep putting offline batches above C010000.
4. If it lands at C010051, the editor now owns everything above your block. Put the next offline batch in an unused block below it.

This departs from the fixed address-range habits of register-based programming. Tag names carry the organization instead. Prefix names by function, for example LIM for LIMIT instruction structures and ALM for alarm instructions. That way sorting, filtering, and find/replace group related tags no matter what SystemID they hold.

Check 4: Count structure members after importing into a fresh project

Importing a complete tag set from one project into a new one caused silent data loss on the affected builds. The test sequence was: configure hardware (only auto-generated module tags in the database), then import the donor project's filename_Extended.csv unedited. The result:

• SystemIDs were reassigned, including tags inside structures, even though the file carried the donor project's IDs.
• The import appeared to run in this order: SSTR string tags, then C type tags, then structure members. The CSV itself was sorted by tag name. Some tags kept their IDs and some got new ones.
• Structure members were placed by SystemID first, then tag names were fitted in. A standalone Boolean tag could claim a SystemID that the importer had reserved inside a structure. When that happened, the importer used the Boolean tag and omitted the correct member entirely, with no message.

Mechanism: the importer resolves two keys, SystemID and tag name, in more than one pass. When a pass allocates IDs before names are bound, an ID already claimed by a name-matched tag blocks the real owner. Nothing flags the loser. The symptom looks random because the outcome depends on pass order and on which IDs happen to be free, not on the CSV sort order.

To detect it, export the tag database right after the import and compare tag names against the source file. With the source on sheet Source and the post-import export on sheet Imported, and assuming tag name sits in column A of both (adjust to the actual column in your export), add this to the source sheet:

=IF(ISNA(MATCH(A2,Imported!A:A,0)),"MISSING","OK")

Fill it down, then filter for MISSING. Run a second pass comparing the SystemID column for tags inside structures. A structure member that exists but carries the wrong ID can still break instruction references.

• Zero missing, IDs as intended: the import is good. Go to the procedure at the end.
• Missing tags or shuffled structure IDs: discard the fresh project. Update the software and reboot (Check 5), then repeat the import into a new blank project.

Copying logic from one project to another has a separate trap. Where pasted instructions referenced structures, the editor created new tags automatically. Those tags appeared in the exported CSV but not in the tag database view. Audit pasted logic from the export file, not from the on-screen database.

Check 5: Confirm the installed build carries the structure-import fix

Tech support indicated that the early-February 2016 software updates resolved the silent-omission problem. Retesting afterward did not reproduce it. The fix was not listed in the release notes, so reading the notes will not tell you whether your install is safe. Prove it with a test:

1. Install the current Productivity Suite release and reboot the PC.
2. Create a new project and configure only the hardware.
3. Import a donor _Extended.csv that contains at least one structure plus standalone Boolean tags.
4. Export the tag database and run the diff from Check 4.

If this passes, the build is safe for whole-project tag transfers. If a current, freshly rebooted install still drops tags, stop. Do not keep importing into the production project.

Generate repetitive tags and rungs without a mnemonic export

Productivity Suite does not export or import ladder as mnemonic text. The register-era workflow therefore has no direct equivalent: export a template group of rungs, script the address increments, re-import hundreds of typo-free rungs. Mnemonic support was logged as a requested improvement. Split the job instead:

Name the template tags so that one substitution retargets the whole group. For example, if every tag in the group carries the same equipment token, find/replace on that token moves the group to the next unit.

Round-trip tags between C-more and Productivity Suite by name

When the PLC and a C-more HMI project are built in parallel, the tag name is the only key that must never change. SystemIDs and HMI address references can move. The working loop:

1. Create the new tags in the C-more project with placeholder address references from the reserved block (C010001 upward).
2. Export them and import them into Productivity Suite with the SystemIDs filled in (Check 3).
3. Export the Productivity tag database.
4. Import that export back into C-more so the HMI picks up the PLC-side definitions.
5. Confirm every HMI object still resolves by tag name.

If the software ever assigns SystemIDs on import from the data type column, step 1 no longer needs a reserved block. Until your installed build is verified to do that, keep the ranges.

Restore production tonight, then make the permanent repair

Temporary restore: if a machine is waiting and only a few tags need retentive or initial values, set them by hand in the tag database. Save, close, and reopen the project to confirm the values held, then download. Do not mass-import on a PC that was upgraded but not rebooted.

Permanent repair (resolving branch):

1. Update Productivity Suite to the current release and reboot the PC.
2. Run the 5-tag persistence test from Check 2 on a project copy.
3. Export the full tag database and set retentive and initial values in the spreadsheet. Delete every row you are not changing.
4. For new tags, assign SystemIDs from the reserved block and confirm column Q holds the data type.
5. Import into the project copy.
6. Save, close, reopen, and export again.
7. Diff the new export against your spreadsheet: tag count, SystemIDs of structure members, retentive flags, initial values.
8. Download to the CPU only after the diff is clean. Power-cycle or stop/run as your process allows, then confirm retentive tags held their values and non-retentive tags loaded their initial values.

Verification passes when the reopened project and the export both match the spreadsheet row for row, with no missing tags.

FAQ