Change an HMI tag data type without rebuilding every object

Why the Tag Data Type field is locked

The lock tracks references. The C-More HMI documentation states the rule directly: if a tag is not referenced anywhere in the project, its Tag Data Type field should be editable. Every numeric display, numeric entry, alarm limit, trend pen and recipe entry that names the tag carries the tag's type into its own configuration, so a type change under a loaded tag would leave each of them built for the old type. Empty the reference list and the field becomes editable again. That is the whole mechanism, and it is why the reference count, not the screen count, decides the repair.

One refinement is worth a test on a saved copy: some releases also allow the change with a single reference left in place. Plan for the documented case, an empty list, and treat the single-reference edit as a bonus if your build allows it.

Symptoms that point at a mistyped tag

• A limit entry refuses the decimal. The alarm plan calls for a 72.5 °C high limit, the tag is a 16-bit signed INT holding whole numbers from -32,768 to 32,767, and the limit field drops the .5 or rejects the entry. Limit fields take the tag's type, and an integer has no digit after the decimal point.
• A numeric entry drops the operator's decimal point. Same cause on the input side: the panel formats the entry to the tag's type before it writes the value.
• The value reads, but the format is garbage. Bit-shifted or nonsense numbers usually come from a BCD register read as binary, a mapping fault with its own fix; check nonsense numbers from a PLC BCD analog register before you touch the tag database.
• The display steps by 1 while the process moves in 0.1 °C steps. An INT cannot carry the decimal digit, so the panel shows whole counts.

A test separates a type fault from a mapping or scaling fault: create a throwaway tag with the intended type, point one display object at it, and watch it against the controller value for a minute. A correct reading on the throwaway confirms the type is the fault; a wrong reading points at the mapping or the scaling, and the tag database is innocent.

Save a copy, then run the tag cross-reference

Work in a saved copy of the project from here on. Open the editor's tag cross-reference, the view that lists every screen and object using a selected tag, and record four things before any edit: the tag name, the current type, the intended type, and the full list of screens and objects. The list is the undo record for whichever repair you run. If your editor has no cross-reference view, build the list by hand: walk each screen, open the properties of every numeric display, numeric entry, alarm and trend object, and write down the tag each one uses.

Repair 1: redirect the references, change the type, put them back

For one or two references. The temporary tag keeps every object alive while the original tag is freed for its edit.

1. Create or pick a temporary tag of the same type the objects already use. A numeric entry must keep a type it can display and write, so the temporary tag matches the old type, not the new one.
2. Point every object on the cross-reference list at the temporary tag, ticking off each line as you go.
3. Open the tag database, set the Tag Data Type field on the original tag to the intended type, and save.
4. Point each object back to the corrected tag, working from the same list.
5. Save, run the project validation or compile, and clear every mismatch it reports before any download.

If your build allows the edit with one reference left in place, leave one object untouched in step 2 and skip its two redirects.

Repair 2: rename the tag and build a replacement

For two or more references. Renaming frees the intended name without touching a single object.

1. Rename the mistyped tag to a name you will recognize as disposable, for example ZOLD_TankTemp. The intended tag name is free again.
2. Create a new tag under the original name, with the intended type and attributes.
3. Walk the cross-reference list and point every listed object at the new tag.
4. Run the cross-reference again on the disposable name, and delete the old tag only when the list comes back empty. An object you missed still points at a tag you are about to remove.
5. Save, validate or compile, and clear the reports.

The same replace-versus-edit call shows up in controller code: when editing in place takes more work than rebuilding, it pays to replace a Studio 5000 AOI with a CODESYS function block and repoint the calls. Tags behave the same way. Past a handful of references, replacement is the shorter road.

Set the default type and check for conversion

Two settings prevent the next occurrence. Where the editor offers a default data type for new tags, set it to the type most of the project uses; the Tag Editor and Data Monitor preferences in Studio 5000 Logix Designer are one documented place to set it, and new tags then start with the right type. Second, check whether your editor converts types for you: WinCC's documentation for a converted HMI tag type describes an HMI tag that uses a different data type than the PLC tag and converts the value between them, which can make the whole repair unnecessary in projects where the panel needs the friendlier type.

Example: one mistyped tag on a 10-screen project

A pasteurizer skid panel carries 30 tags across 10 screens. TankTemp was created as INT before anyone checked the alarm plan, and the plan needs a 72.5 °C high limit with 0.1 °C display steps. An INT holds neither, and the cross-reference shows 12 objects on the tag: 7 on screen 3, 3 on screen 5, 1 alarm banner object and 1 trend pen. The check 7 + 3 + 1 + 1 = 12 confirms the list is complete.

Redirect effort: 12 objects out to a temporary tag, 12 back after the type change, plus the edit itself, so 2 × 12 + 1 = 25 operations. Replacement effort: rename, create the REAL tag, 12 repoints, delete, so 12 + 3 = 15 operations.

The break-even sits at two references. Redirect takes 2n + 1 operations for n references and replacement takes n + 3, so one reference favors redirect at 3 against 4, two references tie at 5, and every count above two favors replacement. Decision: rename TankTemp to ZOLD_TankTemp, create TankTemp as REAL, repoint the 12 objects, delete the old tag on an empty second cross-reference, validate, and bench-test before the download. 15 operations beats 25, and no object ever sits on a temporary tag.

Check the project before it goes back on the wall

• Tag database. The name, the intended type, and limit entries that accept the decimals, 72.5 °C in the example.
• Cross-reference. The disposable name returns an empty list before the delete, and no required object points at it afterwards.
• Validation. The compile or validation run reports no unresolved references and no type mismatches.
• Scaling. Moving a tag from INT to REAL changes what a per-count scaling factor means, and a leftover factor makes the value read ten times off; the fix for a value that reads ten times too small lives in the scaling table, not in the tag.
• Bench run. Point the project at the controller or a simulation, watch one repaired object per screen against the live value for a minute, and confirm a numeric entry writes the value the controller receives.

The numeric entry on a repaired tag usually writes a process setpoint. Bench-test the repaired copy, and download to the running skid only after the entry, the limits and the display agree with the controller value.

Recommendation: Run the tag cross-reference first and let the reference count pick the repair. One object on the tag: redirect it to a temporary tag of the old type, change the Tag Data Type field, point the object back, and validate. Two or more: rename the tag to a disposable name, create the replacement under the original name with the intended type, repoint the objects from the list, delete the old tag on an empty second pass, and validate again. Work in a saved copy throughout, and bench-test any project whose numeric entries write setpoints before the download reaches a running machine.

Questions