Re-importing a corrected PLC tag updates the tag definition but rewrites no object properties, so every display and entry object bound to that tag keeps its old display format. Inventory the bound objects, set each format field to match the new type, and verify with known values.
Re-importing a corrected PLC tag fixes the tag definition and nothing else. The format a screen object uses to render a value is stored on the object, and a tag import does not touch object properties, so every display and entry object bound to that tag keeps rendering with the old data type until you open it and set its format field by hand. The fix is a short audit: list every object bound to the tag, set each object's numeric format to match the tag's new type, then verify against known controller values before the screen goes back to the operators. The worked example below shows the arithmetic that lets you recognise the mismatch on sight.
Does re-importing the tag update the display format on the objects?
No. The import rewrites the tag's definition in the project database, and the format used to render a value is a property stored on each screen object, so the import leaves every existing object exactly as it was.
An HMI project keeps two separate stores. The tag database holds the tag name, the controller address and the data type, and a tag import rewrites exactly that. Each screen object holds its own rendering choice, the numeric format field you selected when the object was placed. The object help for these panels describes the format list as part of the object, with the entries on offer changing to suit the bound tag's data type, which is precisely the setting an import leaves behind. Nothing in an import walks the screens and rewrites object properties, so the same stale format survives a second and a third import until each object is opened and corrected.
What does a stale object format look like on screen?
A format left on the old type shows a right-shaped number with the wrong value: counts near 65,535 where a small negative belongs, sudden negatives where the register counts past 32,767, or a decimal point one place out.
Match what the screen shows against the list:
- Counts near 65,535 where a small negative belongs: the tag is now signed and the object still renders unsigned. That is the classic case, and HMI shows large positive numbers: set the signed decimal data format works through it.
- Sudden negatives where the register counts past 32,767: the tag became unsigned and the object still renders signed.
- A value correct in magnitude with a decimal point one place out: the object shows whole counts where the scaling works in tenths; the decimal places are set on the same format field.
- Digits that never resemble the controller word: suspect BCD or byte order, a different fault family; HMI panel shows nonsense numbers from a PLC BCD analog register covers that one.
- An object showing nothing at all while its neighbours show values: that points at the tag address, not the format; check the address first, as in HMI numeric display shows nothing: check the tag address first.
Until the audit is verified, treat that screen value as unreadable: an operator looking at 65,524 in a cold room has no usable reading, so post the controller value at the station until the corrected project is running.
How do you find every object bound to the tag?
List every object bound to the tag across all screens before you edit anything, because numeric displays, numeric entry objects, trends and alarm banners can all bind the same tag name, and the screen where the fault first appeared is rarely the only one.
Use the project software's cross-reference or find-by-tag to build the list before you touch anything. Write the screen name and object name for every hit, and number the rows. Walk the screens in the development software rather than at the panel, because the running screen hides objects behind pop-ups and screen changes. The numbered list is what makes the job countable: you know the total, you strike a row as each object is corrected, and nothing hides in a screen nobody thought to open.
What format should each object show after the type change?
Match the format entry to the tag's new data type and use the PLC project as the reference: a signed 16-bit tag holds -32,768 to 32,767 and takes the signed decimal entry, an unsigned tag holds 0 to 65,535 and takes unsigned decimal.
The object's own help states the rule behind the table: the entries a numeric object offers change depending on the bound tag's data type, so a signed integer tag offers the signed decimal entry and hides the ones that would render it wrongly. Read the type from the PLC project, then select the matching entry. A plausible-looking positive value on the screen says little about what happens below zero, so set the entry from the type, not from how the current value happens to look.
| Tag data type in the PLC project | Format entry on the object | What a 16-bit tag renders |
|---|---|---|
| Signed integer | Signed decimal | -32,768 to 32,767 |
| Unsigned integer | Unsigned decimal | 0 to 65,535 |
| BCD | BCD | 0 to 9,999 in one 16-bit word |
| Timer or counter preset | The preset's own data format | Depends on the time base |
A timer or counter preset is its own case, since the preset value carries a time base with it; Set the correct HMI data format for a PLC timer preset gives that selection.
How do you change the format on each object?
Open the object's properties, select the numeric display format field, labelled Display Format on the object in one common panel line and Output format under the object's general properties in another, choose the entry matching the tag type, apply, and repeat for every row on your list.
- Open the first object on the list and open its properties.
- Find the numeric display format field: Display Format on the object in one common panel line, Output format under the object's general properties in another.
- Select the entry matching the table above, and set the decimal places to the tag's scaling resolution: one decimal place for a tag that resolves 0.1 units, none for whole counts.
- Apply the change, close the object, and strike the row off the list.
- Correct every row in the project before you transfer it once at the end; a single download at the end beats ten during the edit.
If the tag's data type field itself is greyed out and refuses the new type, the tag definition needs fixing first; Fix an HMI tag data type that is greyed out handles that side.
Worked example: what does a freezer tag show before and after the fix?
A temperature tag changed from unsigned to signed 16-bit integer holds -12 in its register at -12 °C; an object left on unsigned decimal renders it as 65,524, because the register stores -12 as 65,536 - 12 = 65,524.
Scenario. A machine room held between +2 and +8 °C gets a freezer wing, and the PLC program's temperature tag changes from unsigned integer to signed 16-bit integer so sub-zero readings can be shown. The corrected tag is re-imported into the HMI project. Four objects bind the tag: three numeric displays across two screens and one numeric entry object. All four keep the unsigned decimal entry.
At +8 °C the register holds 8, and both formats render 8. The screens look right, so nothing prompts an audit.
The room pulls down to -12 °C. The controller writes -12, and the 16-bit register stores it as 0xFFF4: 65,536 - 12 = 65,524. An object still on unsigned decimal shows 65,524. The same object on the signed decimal entry shows -12.
The numbers give the recognition rule: a signed 16-bit value is negative whenever the register reads above 32,767, and every register value from 0 to 32,767 renders identically in both formats, which is why the fault waits for the first sub-zero day.
After the audit, all four objects carry the signed decimal entry, the displays show -12, and the entry object accepts -15 from the keypad, putting 65,521 in the register, which the controller decodes as -15.
How do you check the fix before the line sees it?
Verify against the controller with known values: move -12 into the register and confirm the screen shows -12, then type -15 into the entry object and read the register back as 65,521, the 16-bit two's complement of -15.
Reopen two or three of the corrected objects and make sure the selection actually saved, then walk the whole list once more. Transfer the project once and spot-check the worst screen at the panel. If the tag itself never picked up the new type, no object audit will make the screens agree; the usual cause is the import landing in the wrong HMI project, so the old definition is still what every screen reads. Check the tag's type inside the project before auditing objects, and follow the import-and-verify steps in Import a PLC tag file into an HMI project and verify it.
What is the fastest way to clear the backlog?
Recommendation: Treat a data-type change on a heavily used tag as two scheduled jobs: import the corrected tag, then audit and set the format on every bound object before the screen goes back to the operators; book the audit as its own task rather than squeezing it into the import.
For the next project, check an imported tag's data type against the PLC before any object binds it; the audit costs minutes before objects exist and much more after. Keep the per-tag object list with the project files so the next type change starts from a list instead of a search. And if the tag type and the object format both match and the value is still wrong, stop re-importing; the next suspect is the tag address, whose shape changes between controller protocols, as Why HMI tag address formats change between PLC protocols explains.
Questions
Do numeric entry objects need the same correction as numeric displays?
Yes. An entry object renders what the operator typed and writes it to the controller with its own format selection, so an entry left on the old type can put a wrong word into the register even after every display is fixed. Correct each entry object on your list, then test by typing a negative value and reading the register back.
Can a project-wide setting fix the format on existing objects at once?
No. The format is stored on each object, and re-importing the tag does not walk the screens. A newly placed object does get a format list filtered to the bound tag's data type, so starting from a correctly typed tag avoids the trap for future objects; existing objects keep their stored format until each one is edited.
Why did the screens look right until the process went below zero?
In 16-bit two's complement, every register value from 0 to 32,767 renders identically as signed and as unsigned decimal. A format mismatch only becomes visible when the register holds a negative value, so a room or machine that never went below zero can hide the wrong format for months.
What if the value is correct but shows a wrong number of decimal places?
Decimal places are part of the same object format selection. Set them to the tag's scaling resolution: one decimal place for a tag that resolves 0.1 units, two for 0.01, and none for whole counts. The tag scaling in the PLC project, not the screen, decides how many places are honest.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.