Multi-State Text keeps each message inside the indicator object, tied to one 16-bit V-Memory value. Lookup Text pulls messages from a shared panel database, so one edit reaches every screen using the entry. On one screen take Multi-State Text; on 3 screens showing the same wording, Lookup Text holds 4 entries where the object route holds 12 fields.
Both objects turn a register value into text on the panel, and on a running screen they can look identical. The difference is where the wording lives. Multi-State Text stores each message inside the indicator's own fill-in fields, tied to one V-Memory location. Lookup Text stores its messages in the panel's message database, and every object on every screen pointed at an entry displays that entry's wording. That storage difference decides the choice: wording one indicator owns goes into Multi-State Text, and wording shared across screens goes into Lookup Text. This article compares the two objects side by side, works the maintenance arithmetic for a three-screen case, and ends with the decision for each situation.
The short answer
Multi-State Text keeps its messages private to the indicator. The texts sit in the object's fill-in fields, associated with one V-Memory location, and editing them touches nothing else in the project. Lookup Text keeps its messages in the message database: the object reads one number from V-Memory and displays the entry carrying that number, so any other screen pointed at the same entry shows the same words.
The software's help entry for the Multi-State Text Indicator Object describes it as displaying multiple messages based on the bit number or the numeric value of a tag name; open the object's help from your installed software for the exact wording. Lookup Text works off one number in V-Memory, which fits whole-value mappings such as 0 idle, 1 running, 2 changeover.
The question that settles the choice: does any other screen need this exact wording? If yes, use Lookup Text and maintain the entry once. If no, use Multi-State Text and keep the wording isolated.
Side by side
Multi-State Text sits in the indicator object list and Lookup Text sits with the text objects, and the table below is the whole comparison:
| Question | Multi-State Text | Lookup Text |
|---|---|---|
| Where the text lives | The object's own fill-in fields | The panel's message database |
| What selects the message | The bit number or numeric value of a tag | One number in V-Memory |
| Who sees an edit | That indicator only | Every object using the entry, on every screen |
| Copying to a second screen | Re-enter the messages in the new object | Reuse the same entries |
| Characteristic fault | A register value with no message mapped | One number carried by two entries |
Where each one wins
Multi-State Text wins when the wording belongs to the machine in front of the panel. A changeover message naming Line 1 means nothing on the Line 2 screen, so there is nothing to share and no reason to place the text in a shared database. It also wins on containment: rewording a Multi-State object leaves every other screen untouched, because its messages live in the object's own fields. For driving several states from one value with a single indicator, see showing three alarm states with one HMI indicator.
Lookup Text wins when two or more screens repeat identical wording: stop reasons, packing rules, shift instructions. One database entry serves all of them, so a wording fix is made once and reaches every screen. The shared database carries its own fault modes. When two entries carry the same number, the panel shows confusing text; fixing duplicate HMI lookup text when two registers match covers that symptom. A lookup-driven text panel can also pull the wrong characters; fixing wrong ASCII initials on a text panel with lookup text covers that one. Message length and bit width carry limits of their own; read multi-state indicator message limits and bit width before you build a long state list.
Worked example: one 16-bit register, four messages, three screens
The case is a packing line with a state register and three panels. Inputs: one 16-bit unsigned V-Memory register holds the machine state; 16-bit is the common PLC register width, and unsigned it spans 0 to 65,535, because 2 to the 16th power is 65,536 values counting zero. The PLC writes four values into it: 0 idle, 1 running, 2 changeover, 3 fault. Three screens show the same status wording. The register width is the typical case; the values and the screen count are this example's inputs.
The rule in words: with Multi-State Text, every screen carries its own copy of all 4 messages, so a 3-screen project holds 3 screens × 4 messages = 12 text fields. With Lookup Text, the database holds 1 entry per value, and the screen count stops mattering.
The arithmetic. Multi-State Text: 3 screens × 4 messages = 12 message fields, and rewording the changeover message means editing 12 fields across 3 screens. Lookup Text: 4 database entries, one per value, and the same rewording is 1 edit. That is 12 - 4 = 8 fewer places for the wording to drift out of step. The value range also checks: two bits cover four states because 2 squared is 4, so values 0 to 3 fit easily, while the 16-bit register itself can hold any of 0 to 65,535, so the mapping must give a message to every value the PLC actually writes, in the exact sequence the PLC uses.
Result: 12 message fields versus 4 database entries, and a wording change that touches 1 entry where the object route touches 12 fields on 3 screens.
Decision: on one screen, take Multi-State Text, four fill-in fields and nothing shared to audit. On two or more screens showing identical wording, take Lookup Text; at 3 screens the project carries 4 entries where the object route carries 12 fields. When any message differs per screen, the shared set breaks down: keep the line-specific text in each indicator's own fields and share only the common entries.
Check the register before you switch an existing screen
- Save a recoverable copy of the project, open the screen, and record the V-Memory location the object watches.
- Watch that register while the machine passes through a full cycle, and write down every value it takes.
- Compare each observed value with the messages configured in the object, or with the database entries.
- Give every observed value a message, or correct the PLC logic writing a value the screen never expected.
- Compile, download through your site's change process, and re-test every state on the panel itself.
Drive the states from a maintenance or idle test condition, and keep test writes out of live control memory. A clean compile alone does not show what the panel displays; the state-by-state pass in step 5 is the verification. When the message is wrong because the register holds the wrong value, the fix sits in the PLC logic or the data path, and switching text objects changes nothing.
The decision
Recommendation: Put message text in Multi-State Text when the wording belongs to one indicator and its own register value, which covers most machine-status messages. Move a message set into the Lookup Text database when two or more screens show identical wording and one edit should reach all of them. Before the move, list every object that references each entry, confirm no two entries share a number, and re-test every state on the target panel.
By case: wording unique to one indicator, Multi-State Text. Identical wording on two or more screens, Lookup Text. A mix of shared and line-specific words, shared entries in the database for the common text and Multi-State fields for the rest. A wrong message caused by a wrong register value, fix the PLC side first, then choose the object. Whichever object you pick, the test that settles it is the same: every value the register actually takes must produce the message you intended, checked on the panel.
Questions
Does Multi-State Text have to map whole values?
No. The object's help entry says it displays messages based on the bit number or the numeric value of a tag name. Bit-number mode gives two states per bit, so four bits cover 16 combinations, since 2 to the 4th power is 16. Numeric-value mode maps whole numbers such as 0, 1, 2, 3 to messages. Lookup Text works off one number in V-Memory, so it matches whole-value mappings.
How many messages can one object hold?
The help summary for the Multi-State Text Indicator Object prints no maximum message count, and the lookup documentation summarized here prints none either, so the number is unknown until you open the object's properties in your installed software. Practical limits arrive sooner from message length and bit width, and a long list multiplies the state-by-state test at the end of a change.
What happens when I edit a Lookup Text entry?
The new wording shows on every object that uses that entry, on every screen, because the database stores one copy per number. Before editing, search the database for a second entry with the same number; two entries on one number is the duplicate fault behind confusing lookup displays. If the rewording should apply to one indicator only, leave the entry alone and keep that text in the indicator's own fill-in fields.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.