A tag name travels between operator panels; the address behind it does not. Address grammar belongs to the protocol driver, so every address is re-entered in that driver's documented format and checked with two writes: 40000 catches a 16-bit width fault (panel shows −25536), and 100000 catches a word-order fault (panel shows 2,258,632,705).
Swap an operator panel for a new one and the screens come with you: the tag names, the objects, the layout. The address string behind every tag does not come with you. Address grammar belongs to the protocol driver selected for the panel connection, and each driver writes memory in its own notation. A project moved to a new controller family is therefore a re-entry job with a verification step, never a translation job. This page explains what changes, shows the three address grammars you will meet, and gives two controller writes, 40000 and 100000, that show every numeric tag lands on the right register with the right width and the right word order.
Are HMI tags the same on every operator panel?
A tag is portable and its address is not: the tag name and the screen objects carry over to a new operator panel, but the address string behind every tag belongs to the protocol driver you select, and each driver writes its own grammar.
The concept is identical on every panel: a screen object references a data point, the panel polls the controller over Ethernet or serial, and the object displays or writes the returned value. That model survives any change of panel or controller.
What changes is the notation the panel must send. One controller family stores symbolic tag names and lets the panel address by name. Another speaks in numbered 16-bit registers. A third addresses by data block, width and byte offset. The driver selected for the panel connection decides which grammar applies, and the panel software rejects strings written in another grammar or reads them as a different address entirely. The Help entry for that driver is the documented format, so it settles every syntax question before you type a tag.
What does a tag address look like in each protocol?
Three grammars cover most panel jobs: a register-numbered protocol such as Modbus RTU counts 16-bit holding registers from 40001, a data-block protocol names block number, width letter and byte offset, and a name-based controller takes the controller's own tag name as the address.
Register-numbered protocols. Modbus RTU exposes memory as 16-bit registers, and the application protocol fixes that width while staying silent on how a 32-bit value splits across two registers, which is exactly why drivers carry a word-order choice. Holding registers use the common 40001-series numbering: 40001 is the first register, and a 32-bit value starting there occupies 40001 and 40002.
Data-block grammars. These name a block first. The documented shape in one widespread family is %DB'X'.DBW[...]: a percent sign, the letters DB, the block number, then the width letter and the byte offset. In that notation the byte at offset 0 of block 10 is %DB10.DBB0, the 16-bit word at offset 2 is %DB10.DBW2, and the 32-bit double word at offset 4 is %DB10.DBD4. Same memory, three widths, three strings.
Name-based controllers. These store symbolic names in the controller. The panel browses the controller's tag table and addresses by name, and the absolute address underneath rarely gets typed. Controllers without stored names leave the panel-side tag name as a label only; the typed address is what reaches the wire.
Which habits from the old panel cause the trouble?
Four habits carried over from an old panel cause most of the lost hours on a new one: typing the old address style, expecting to browse controller tag names, guessing addresses until a value moves, and touching communication settings when the numbers arrive but look wrong.
- Typing the old grammar into the new driver. The parser accepts only the selected driver's format. A string that looked right in the old project is rejected, or it lands on a different memory area and reads someone else's data.
- Expecting to browse controller tag names. Browsing works where the controller stores names. Everywhere else the panel-side name is a label, and the typed address is the only thing the controller receives.
- Guessing addresses until a value moves. A wrong address that lands on valid memory returns plausible numbers from the wrong register. Nothing faults, so the error rides into production and surfaces as a mystery value on the first shift.
- Changing communication settings when values arrive but look wrong. Baud rate, node number and IP address move data or stop it. Once values arrive, the link works, and the fault lives in address, width, word order or scaling.
How do you re-enter the addresses on the new panel?
Re-enter every address from the new driver's documented format: select the protocol for the panel connection first, open that driver's entry in the panel software's Help, and copy its address shapes and supported memory types exactly before you type a single tag.
- Export or list every controller address the panel needs, with data type, engineering range and read or write direction, from the controller program.
- Select the protocol driver for the panel connection first, because the grammar changes with this choice. The protocol check that comes before any address typing is the same one described in check the PLC serial protocol before replacing a legacy HMI.
- Open that driver's entry in the panel software's Help and copy its address formats and supported memory types exactly.
- Create the panel tags with names that mirror the controller documentation, and attach objects to the tag names so a later correction happens in one place.
- Match each tag's data width to the controller data type, and flag every 32-bit and floating-point value for the word-order test below. When a width change would touch many objects, changing a tag data type without rebuilding every object keeps the edit contained.
What does a worked example of the two test writes look like?
Two controller writes settle it: put 40000 in the controller and a panel still set to 16-bit signed shows 40000 − 65536 = −25536, which names a width fault; then put 100000 in and a word-swapped panel shows 2,258,632,705, which names an order fault.
Scenario: a filling line's panel project moves from a register-numbered serial protocol to a data-block Ethernet protocol. The tag Line speed holds a 32-bit signed integer in the controller, the addresses have been re-entered, and two writes verify the tag before the line runs product.
Width test. Write 40000 from the controller. The 16-bit signed range ends at 32767, so 40000 overflows it: a panel still set to 16-bit reads the low word 0x9C40 as 40000 − 65536 = −25536. That negative number names a width fault. Set the tag width to 32-bit signed and the panel shows 40000.
Word-order test. Write 100000, which is 0x000186A0 in hex: high word 0x0001 (= 1), low word 0x86A0 (= 34464). A panel assembling the pair in the wrong order computes 34464 × 65536 + 1 = 2,258,632,705, displayed as −2,036,334,591 on a signed 32-bit read. Controller says 100000; panel says about 22,586 times too much; the value's two 16-bit halves are exchanged. Flip the word-order choice in the driver's tag or connection settings and the panel shows 100000.
A field shortcut: when only the low word is nonzero, a swap shifts it 16 bits left and multiplies the displayed value by exactly 65536, so a controller value of 1234 shown as 80,871,424 is a word-order fault with no arithmetic needed. Floating-point tags get the same treatment, since a float also spans two word registers; displaying a PLC float stored in two word registers covers the byte-order variant.
How do you tell a link fault from a data fault?
A dead link and a wrong number fail at different points: a communication error on every object points at driver selection, path or identity, while live but wrong numbers point at the address, the data width, the word order or the scaling, checked in that order.
| What you see | What it names | What to change |
|---|---|---|
| Address entry rejected on every tag | Grammar, so the wrong driver is selected | Reselect the driver and re-enter from its Help entry |
| Communication error on all tags, no data anywhere | Path or identity | Station or node number, IP address, driver match |
| Controller answers a ping but every read fails | The protocol behind the path | Pick the driver whose protocol the controller speaks; the pings-but-failed-reads checklist walks it step by step |
| Live but wrong value, or zero forever from one tag | An address in the wrong or an unused register | Re-enter the address from the driver's Help entry |
| Values turn negative or roll over above 32767 | Tag width | Set the width to 32-bit where the controller holds 32 bits |
| Magnitude wrong by a factor of 65536 | Word order in a 32-bit pair | Swap the word order and repeat the 100000 write |
| Correct raw count, wrong engineering value | Scaling applied twice | Keep one conversion, in the controller or in the object |
Total failure lives in the first three rows; wrong numbers live in the last four. Separate the two cases before touching anything.
What changes on the floor once the addresses are re-entered?
On the floor this changes the commissioning sequence: the project keeps its tag names, the address list is re-typed once from the new driver's Help entry, and every numeric tag takes the 40000 write and the 100000 write before the line runs product.
Mark every write-capable tag in the project and keep read-only process values on display-only objects, so a maintenance tech cannot nudge a production count from a screen. Delete test addresses before handover; an address parked in an unused memory area reads zero forever and raises no error, which is how stale test tags survive into production.
Keep the exported address list with the panel project. The next protocol change then becomes mechanical: select the driver, open the Help entry, type the list, run the two writes. A project that skips the two writes finds its width and word-order faults during the first shift, with product on the line.
One boundary worth knowing: an operator panel is the device that speaks the controller's protocol and moves register values. A shop-floor notice or status board that shows published content is a different device doing a different job. It displays what you publish to it, and it has no tag address to re-enter.
Recommendation: when a panel project moves to a protocol it has never spoken, select the driver first, re-enter every address from that driver's Help entry, and accept the project only after a 40000 write has caught the width faults and a 100000 write has caught the word-order faults on every 32-bit tag. If the panel shows live but wrong numbers after that, work down the table above in address, width, word order, scaling order and leave the communication settings alone.
Questions
Do my tag names carry over to the new panel?
The names carry as labels, and it pays to keep them. Many controller platforms allow tag names of 40 or more characters using letters, numbers and underscores, so name the panel tags exactly as the controller documentation names the points. Re-entry then becomes mechanical: same list, same order, new grammar, and the two test writes confirm each tag.
Can the panel and the controller both write the same address?
They can, and the controller usually wins. Controller logic rewrites its own addresses every scan, so a panel write to an address the logic also drives appears to do nothing. Put manual entry points on addresses the logic leaves alone, or gate the logic write with a hand or auto mode bit, then verify the panel write during the two-write test.
The raw count is right but the number is wrong. Where does scaling belong?
Scale once, in the controller or in the object properties, never in both, because two conversions multiply twice: a raw count of 4095 scaled by 0.1 in the controller shows 409.5, and an object that also scales by 0.1 shows 40.95. Write the single scaling location on the exported address list so the next project keeps it.
How do I verify a bit tag?
Toggle it. Turn the bit on from a panel test object, watch the controller's online data view change that exact bit, confirm no neighbouring bit moved, then switch it back off. A bit written to the wrong address inside a used word area changes a neighbour instead, which is why bit tags get their own toggle check before the numeric writes.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.