Display PLC string data on an HMI with N registers

Why won't the HMI display a string file over DF1?

The panel's DF1 connection in this setup does not carry the ST string data type, so a display object addressed to the string file has nothing valid to show, and the fix is to carry the text two characters per N register.

Re-entering the tag, reformatting the object and re-selecting the address all leave the problem in place, because the panel can render only what the link delivers. The register route leaves the panel alone and moves the data: the characters sit in N registers, the panel reads them like any integer table, and the string file drops out of the display path completely.

Keep the serial link off the suspect list while you make this change. A link that passes integer data cleanly is not what makes a string display come up empty. If the text you need is barcode data, the same registers are what carry MicroLogix ST barcode text on an HMI panel.

How do you copy string characters into N registers?

Use the COP file-copy instruction, because COP transfers the source file's memory contents word for word, and each 16-bit N register holds two 8-bit ASCII characters, so the length you enter for the copy counts registers, not characters.

The controller family's instruction set reference manuals document COP as an element-by-element copy between files: give it the string element as the source, the first register of the buffer as the destination, and the register count as the length. What a copy length counts, words or bytes, differs between controller families and is a recurring trap; how a copy-file length parameter counts words, bytes, or bits works through that question for the register files this layout uses.

If the text still lives in a string file, run one copy per string as a migration step and work in registers from then on. Two details to settle on the first attempt: test with a short known value, and remember the register buffer carries no string length portion, which is why every downstream limit has to live in your logic and in the panel entry.

How many N registers does one string need?

Divide the longest text by two and round up, because each register holds two characters: a 40-character maximum needs 20 registers, a 60-character maximum needs 30, and the capacity you pick becomes the copy length, the table stride and the entry cap at once.

Choose the capacity once, write it into the project notes, and keep it for every string in the project. The fixed maximum is the point of the method: the integer buffer carries no length word, so the agreed capacity is the only definition of how long a string can be. Doubling the capacity doubles the registers every table entry takes, so size to the longest text you store and accept the padding on the short ones. Round odd lengths up: 45 characters need 45 ÷ 2 = 23 registers, with the odd trailing character riding alone in the last register.

How do you verify the register layout in ASCII view?

Switch the programming software's data view to ASCII and read the buffer as characters, because the integer view shows word values that read as unrelated numbers here, while ASCII shows each register as its two-character pair for a letter-by-letter comparison with the source.

Run the first test with a short known value, then read the buffer at three places.

First register. The display address should land on a register that reads as a character pair. If it shows a small number instead, the copy has swept in the string's length word, so move the display address to the register where the pairs begin and use that register as the buffer start from then on.

Last register of the text. The final pair must land inside the block. A last character that spills past the last register means the copy length or the capacity is wrong; recompute registers as characters ÷ 2 and compare.

The empty registers. Decide now what unused slots read, and have the logic fill them with spaces after every store, so a short value never shows leftovers from a longer one.

The order matters: source value first, buffer in ASCII view second, panel last. Fix the PLC side while the buffer is wrong, and only touch the display object once the buffer reads correctly.

What does a worked example look like with a 16-character batch code?

Take a packing line that keeps 12 batch names in a table and shows the selected one in a 20-register buffer: the code PART-A-0417-REV2 has 16 characters, 16 ÷ 2 = 8 registers carry it, so N10:0 through N10:7 hold the code and N10:8 through N10:19 hold the fill.

The entry sits at table index 3, so the offset is 3 × 20 = 60 registers, the block runs from N11:60 to N11:79, and the copy into the buffer runs with length 20 so every register refreshes, fill included. All 12 entries at 20 registers each occupy 12 × 20 = 240 registers, N11:0 through N11:239, with entry 0 starting at offset 0 and entry 11 starting at offset 220.

In ASCII view the buffer reads:

The entry cap for this buffer is 40 characters, and this code uses 16, so the operator could append 24 more before outgrowing the block. Store an edited value back with the same 20-register stride and the buffer and the table cannot drift apart.

How does the offset formula find one string in a 12-entry table?

Multiply the zero-based index by the stride of 20 registers and use the product as the offset: index 3 gives 3 × 20 = 60 and addresses N11:60 through N11:79, with the index held in N7:0 and the computed offset in N7:1.

Use the same stride in the store path and the get path, so a block one move writes is exactly the block the other move reads. Keep a limit check on the index in the logic, 0 through 11 for a 12-entry table, enforced before any indirect move runs: an out-of-range index lands somewhere in the 240-register file and reads or writes a neighbour's text.

If your selectors count 1 through 12, the offset is (index - 1) × 20, and entry 4 lands at offset (4 - 1) × 20 = 60, the same block index 3 selects in the zero-based version. Pick one convention, apply it in the store path, the get path and the panel's entry selector, and the two formulas never coexist in one project.

How do you cap the string length an operator can enter?

Set the panel entry object's maximum to 40 characters, because the 20-register buffer holds exactly 2 × 20 = 40 character slots and carries no length word, so the entry limit in the panel is the only thing stopping an oversize text from spilling into the next block.

Enforce the same cap in the PLC logic as well: a length check before every store, rejecting anything past 40 characters. One safety point belongs here: a store that ignores the block boundary can overwrite a neighbouring entry while the line runs, and the entry cap plus the index limit are what prevent it. If a later job needs more room, raise the capacity in all three places together, copy length, table stride and entry cap, because a layout split between two conventions is what produces half-displayed text.

Recommendation: Fix the buffer capacity for the whole project at 20 registers per string, 40 characters, whenever the longest text fits that space: the copy length, the 12-entry table stride and the panel entry cap then all follow from one number, and a second panel added later reads the same blocks with no new arithmetic. For longer text, move to 30 registers and 60 characters and let all three numbers move with it.

What do the symptoms on the panel point to?

Match the symptom to the layer before you change anything, because a blank display with no comm errors points at the data type, garbled or shifted characters point at the copy, and a truncated text points at a length set in characters where the layout counts registers.

• Blank display, no comm errors. The string data type is not carried over DF1; move the text into registers as in the copy section above.
• Comm errors, NAKs or timeouts. Link fault, not a data fault; run the DF1 NAK and comm timeout checks before touching the copy.
• Characters shifted, paired or garbled. Wrong characters-per-register assumption, or the display address sits on the length word; read the buffer in ASCII view and set the display address to the first character pair.
• Only part of a string shows. Copy length or entry cap set too small; recompute the register count as characters ÷ 2 and compare every length in the project against it.
• The wrong table entry shows. Index base or stride mismatch; check the index in N7:0, the offset in N7:1, and the formula, index × 20 zero-based or (index - 1) × 20 one-based.
• Leftover characters after a shorter text. The fill step is missing; have the logic fill unused registers with spaces after every store.

Work the faults in this order: source value, buffer in ASCII view, index and offset, then the panel address and display. Fix the PLC side while the buffer is wrong; if the buffer reads correctly and the panel still shows something else, the panel's address path is the remaining suspect. Confirm the panel also sits within DF1 RS-232 distance limits for the baud rate in use, because a marginal serial link mimics data faults.

With the layout settled on the PLC side, the panel is an ordinary reader of integer data, and a large line-status board for the floor is a separate choice; that is the shop-floor signage decision.

Questions