Multi-state indicator message limits and bit width

6 min read · Published November 9, 2026

A multi-state indicator's message cap is a limit on its state list, not on the PLC value that drives it. A 10-bit word can select codes 0 through 1023, and 768 of those codes have no state behind them. Count the codes your ladder writes: keep the indicator when every written code is 255 or below; remap onto codes 0 through 255 or switch to a database-driven text object above that.

A multi-state message indicator reads one word from the PLC and shows the text you attached to each value. The text list tops out at 256 entries, states numbered 0 through 255, and that ceiling sits on the list, not on the value that drives it. A selector built on 10 bits can raise codes from 0 through 1023, and the object holds no message for any code above 255. So the question narrows to one audit: does your ladder actually write codes above 255? This article runs the arithmetic, gives the check to make before you type message 1, and ends with the decision for each case.

What the 255 limit limits

The ceiling is the size of the state list, not the width of the register behind it. Help for one panel family's multi-state text indicator states that the number of messages may not exceed 255; help for another package describes the same ceiling as 256 trigger entries, states numbered 0 through 255. Two wordings, one ceiling: the list stops at state 255. The help page on configuring message numbers on a multi-state text indicator shows how the entry count is set up.

The state list is a table you fill in the editing software, one text entry per state number. The object shows the entry whose number matches the incoming value and changes nothing about the value itself. The register behind it is a separate matter: PLC data memory holds 16-bit unsigned words, 0 through 65535, and the program decides how many bits of a word carry meaning.

When the machine only ever shows a handful of conditions, the ceiling never comes into play. Three states on one object can be the whole design, as in showing three alarm states with one HMI indicator.

What the bit width sets

Each selector bit doubles the number of possible codes.

Selector width Possible codes Against a 256-entry state list
8 bits 2^8 = 256 (0 through 255) Exact fit
10 bits 2^10 = 1024 (0 through 1023) Codes 0 through 255 covered, 768 codes left outside
16 bits 2^16 = 65536 (0 through 65535) Codes 0 through 255 covered, 65280 codes left outside

An 8-bit selector is the exact size of the state list, which is why 255 can feel like a bit-width limit. A 10-bit selector covers that range and keeps going through 256, 257 and up to 1023. Codes with no state are not something you fix by typing more messages into the same object; they need a remap or a different object, and both are below.

What an unassigned code shows

A code with no state behind it has no text to fetch. What the screen shows then depends on the panel software. One package documents its result for an unassigned value as a message-not-programmed error on a multi-state indicator.

The practical point: an odd field has two candidate causes, an unassigned code or an empty state, and you tell them apart by forcing the value in an offline project and watching the field. Do that before you rewrite any messages.

Count what the ladder actually writes

The cap matters only for codes your program writes, so audit the writes offline:

  1. Open the offline project and find every instruction that writes the selector register: moves, comparisons, computed results and fault paths. The register is a V-memory word on some PLC families, a data register on others.
  2. List every value it can hold, including fault codes and step numbers.
  3. Log the register through one full machine cycle on the bench or in the simulator, plus every fault you can safely set.
  4. Take the highest written value.

That one number decides the design. Highest value 255 or below: the state list covers the machine and the ceiling never binds. Highest value 256 or above: the object cannot carry every condition as its own message, so remap the codes or change objects.

Never force values on a running line for this. Work in the offline project, on the bench, or in planned downtime.

Example scenario: a packaging machine with a 10-bit selector

A packaging line uses one 16-bit unsigned PLC data word, of which the program builds a 10-bit selector for its condition codes. The machine's ladder writes codes 0 through 200 for its normal steps, and fault codes up to 600 for jam, empty-carton and guard conditions. The screen uses a multi-state text indicator with a state list of 256 entries, states numbered 0 through 255, as printed in the panel software help files.

The arithmetic:

  • 2^10 = 1024, so the selector can span codes 0 through 1023.
  • The state list covers codes 0 through 255, so the machine's normal steps, 0 through 200, all show.
  • The fault codes at 600 have no state behind them: 256 of the 1024 possible codes are covered, and 1024 - 256 = 768 codes would sit outside the list if the program used the full range.

Result: the operator sees a blank or an error, one package documents a message-not-programmed error for an unassigned value, whenever the machine raises a fault above 255. The remap fixes it: one rung per fault writes display codes 256 through 600 become codes 201, 202 and 203 in a new display register, all inside the list, and the indicator points at that register.

Decision and threshold: audit the ladder and take the highest written code. At 255 or below, keep the object and type one message per written code. At 256 or above, compress the mapping onto codes 0 through 255 in the PLC, or move the text into the database-driven object described next.

Remap the codes in the PLC

When conditions genuinely outnumber the list, or the natural codes land above 255, add a display register. One rung per condition writes a display code from 0 through 255 into a register that exists for the screen, and the indicator points at that register instead of the raw selector. The raw code stays in the PLC where the logic already knows what it means.

Keep the mapping honest:

  • One condition, one code. Never reuse a display code for two different faults, because the operator loses the difference.
  • Every condition keeps a message. The remap trims the number range, not the information; a fault that loses its text is a hidden alarm.
  • Store the mapping table with the project files so the next technician can trace a displayed code back to the rung that wrote it.

When the message database object fits

If the text list is long or changes often, the panel software's LookupText object with its Message Database selects display text by value, and the database imports and exports through XLS files. Bulk edits happen in the spreadsheet, one row per code, and the panel software picks up the changed mapping on the next load.

Two checks before you build it. Read the entry limit your software prints for the database object before importing several hundred rows. After the import, force the highest and lowest codes in an offline project and confirm the text on each. Back the project up before restructuring the indicator.

When the value belongs inside the sentence itself, a count or a batch number inside the message, that is a different object: see how to embed a PLC variable in an HMI message string.

The decision for each case

Recommendation: Before you type message 1, audit the ladder offline and take the highest value written to the selector register. Keep the multi-state indicator when that highest value is 255 or below: type one message per written code and leave the rest of the state list empty. Move to a PLC-side remap onto codes 0 through 255, or to the LookupText object with its Message Database, when any written value lands at 256 or above.

For a single running number instead of a message list, the display question is different, and how to display a PLC counter value where operators can see it covers it.

What reaches the operator stays the same in every case: one line of text per condition, readable from where they stand. If that job belongs to a separate status board away from the HMI, choose the screen from the display range; the planning figure is 30 ft of viewing distance per inch of letter height, and 20 ft per inch when the text must be read fast. The terms that matter when comparing screens are in what the spec sheet tells you.

Questions

What happens when the PLC sends a code with no message state behind it?

The object has no text to fetch, so the screen shows whatever your panel software does for an unassigned value. One package documents a message-not-programmed error for it; other packages behave as their help files state, so force the code in an offline project and record the result. Then either give that code a state or point the selector at a register that never holds unused values.

Does a one-based message code change the 255 ceiling?

Yes, at the top end. The state numbers run 0 through 255, so a scheme that writes codes 1 through 256 lands its last code one past the list. Shift the mapping down by one, code 1 to state 0 and so on, or cap the scheme at code 255 and renumber what sits above it. Note the shift in the mapping table so the next technician reads the panel correctly.

Is there a documented entry limit for the message database object?

No figure for the LookupText and Message Database pair appears in the sources this article draws on. The 255 and 256 numbers are printed for the multi-state state list, and the two objects are different features. Check the entry limit printed in your software's own documentation before importing several hundred rows, then test the highest and lowest codes in an offline project.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote