An HMI tag's data type control stays greyed out because objects on the screens still reference the tag. Create a new tag with the matching type at the same register, point every display, trend and lookup object at the replacement, then delete the old tag. When the register holds the correct value and the panel still shows 0, that sequence is the whole fix.
You finish the conversion, the PLC's own display shows the right temperature, and every panel object fed by the tag sits at 0. You go back to the tag database to fix the data type and the control is greyed out. The two facts are linked: the tag's type does not match the format the ladder wrote to the register, and the editor locks a tag's type while objects on the screens still reference it. The fix is to build a replacement tag with the correct type at the same address, point every object at the replacement, then delete the old tag. This article works the concrete case: register V4010, a 32-bit BCD value, and three objects, a numeric display, a trend and a lookup text.
Why the data type control is greyed out
An HMI editor locks a tag's data type once any object references the tag. The documented way back is to delete the object that uses the tag; with no references left, the type control becomes editable again. That path is quick when one object holds the only reference. The panel in this case feeds three object kinds from one tag, so the faster route is a replacement tag: create it with the correct type, rebind the three objects, delete the old tag. The panel keeps running its downloaded configuration while you edit, and you never have to fight the greyed control. The wider workflow for swapping a type with minimal rebuilding is in change an HMI tag data type without rebuilding every object; this article stays on the locked, shows-0 case.
Symptoms and what each one points to
Read the symptom before you edit anything. Each one has a different owner:
- 0 on every object, and the register reads correct. The tag's type does not match the format the ladder wrote. This is the locked-type case this article fixes.
- A wrong number that tracks the process, for example 9077 where the ladder wrote 2375. The tag is reading BCD digits as plain binary. That diagnosis and its fix are covered in the article on an HMI panel showing nonsense numbers from a PLC BCD register.
- Right digits, ten times off. A scaling factor between the register and the display, not a type fault. Fixing an HMI that shows the value ten times too small covers that case.
- 0 on one object only, the rest correct. That object still points at the old tag after the rebind.
- A value that never updates, plus a protocol error that reappears on a timer. The panel-to-PLC link is at fault, not the tag. See fixing an intermittent HMI protocol error.
Read the register, not the panel
Go online with the PLC software and read V4010 live. Read the register itself; the PLC's local screen can apply its own formatting, and the register holds whole counts. Two outcomes:
- V4010 holds the value. For a temperature stored in tenths of a degree, 237.5 °F reads as 2375. The PLC side is done and the fault is the panel's tag. Go straight to the fix below.
- V4010 holds 0 or garbage. The analog card setup is the fault, and no tag edit will help until the card produces a value.
A setup rung in this PLC family takes this shape: the rung hangs off the SP0 system contact, LD K400 loads the setup constant and OUT V7660 writes it to the module configuration register, then LDA O2000 loads the analog start address and OUT V7670 stores that pointer. The constant and the addresses belong to the card, its base and its slot, and the card's manual prints them. Newer programming software folds the whole setup into one instruction, ANLGIN for an input card, which asks for the base, the slot, the channel count, the data format (BCD or binary) and the destination V-memory, and works the configuration out from the CPU type; older CPUs may need a firmware upgrade first. One clarification that saves time: a plain analog input card with an external signal conditioner is set up as an analog card, and RTD module setup does not apply to it. Whatever format the setup and the conversion produce is the format the tag must read.
The fix: a new tag, every object, then the delete
- Create the replacement tag. Add a new tag in the tag database at address V4010. Set its type to BCD INTEGER 32 when the ladder writes a 32-bit BCD value; a 32-bit tag occupies V4010 and the next register, V4011. Name it so the format shows in every picker, for example TEMP_F_BCD32.
- Rebind all three objects. Open the numeric display, the trend and the lookup text, and select the new tag in each. Three objects, three selections. Miss one and that object keeps the old configuration after the download, which is how a panel ends up with 0 on the trend and a correct number on the display.
- Delete the old tag. Search the project for the old tag's name first. When nothing references it, delete it; an unreferenced tag left in the database invites someone to bind to it again.
- Download the project to the panel and run the verification below.
Example: 2375 at V4010 shows 237.5
Scenario: the transmitter spans 0 to 1200.0 °F and the conversion rung stores tenths of a degree as a 32-bit BCD value starting at V4010. At 237.5 °F the ladder has written 2375, so the register pair holds the pattern 0x00002375. BCD stores one decimal digit per 4 bits, so the digits read 2, 3, 7, 5 and the value is 2375. The numeric object has its decimal places set to 1, so the panel shows 237.5 °F. Capacity check: 4 bits per digit and 8 digits in 32 bits give a span of 0 to 99999999 counts, so with one decimal place the display tops out at 9999999.9 °F, well above the transmitter.
The trap in the same registers: read the pair as plain binary and the same pattern is 2 × 4096 + 3 × 256 + 7 × 16 + 5 = 9077, which is the nonsense-number case, not this one. After the replacement tag with BCD INTEGER 32 is bound to all three objects and the project is downloaded, the numeric display shows 237.5, the trend follows the process on its 0 to 1200.0 scale, and the lookup text picks its message from bands that contain 2375.
Verify every object after the download
- Numeric display: live value with one decimal place. A BCD integer carries no decimal point; the object's decimal-places setting adds it.
- Trend: set the scale from the transmitter's range, 0 to 1200.0 in the example, and watch it follow a real change.
- Lookup text: its bands must contain the counts the ladder actually writes; 2375 must land inside the band that means 237.5.
- Still 0 everywhere: re-read V4010 online, confirm the new tag's address and type, and confirm every object selects the new tag name.
- Correct number, but it never moves: the object is bound and the link is dropping; the protocol error check in the symptoms list is the next stop.
The decision
Recommendation: when the data type control is greyed out, stop editing the old tag. Create a replacement tag at the same address with the type that matches the ladder's format, BCD INTEGER 32 for a 32-bit BCD value at V4010, point every object that used the old tag at the replacement, delete the old tag once nothing references it, and download. Edit the type in place only when a single object holds the only reference, and only after the register itself reads the correct value live.
The decision by case: register correct and the panel at 0 with the type locked, run the tag rebuild above. Register correct but the number is wrong and live, treat it as a BCD-versus-binary mismatch. Register at 0 or garbage, set up the analog card first, then come back to the tag. One object on the tag, delete it, edit the type, recreate the object.
Questions
Why does the project fail to compile with an invalid data type after I edit tags?
In one documented case the compiler blamed the data type when the real fault was the connection assigned to the tag: the connection had been changed at some point and the tag table still carried the stale assignment. Check each tag's connection setting in the tag table and restore the one the controller actually uses. The message blamed the type even though the type itself was correct, so check the connection before you start changing types.
Can I edit the old tag's type instead of creating a new one?
Only when nothing references the tag. Delete the objects that use it and the type control becomes editable; change the type, then recreate the objects. With a numeric display, a trend and a lookup text on one tag, that is three deletions and three recreations against three tag selections on a replacement, which is why the replacement route wins on a multi-object tag.
Does the tag type have to be BCD if the card can deliver binary?
The tag must read the format the ladder stores, and the two settings are independent. The analog card's setup decides what the module delivers, the conversion rung decides what lands in V4010, and the tag must match that result. A card configured for binary feeding a BCD conversion, or the reverse, puts the wrong pattern in the register and no tag type displays it correctly.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.