HMI cannot map the PLC string file: display ASCII from integer words

Why can't the panel map the PLC string file type?

Most panel drivers list the PLC data types they can map, and a string file type is often missing from that list, so the panel object has no legal source for your text and the tag refuses to bind.

The driver's type list is fixed: it carries the numeric types, sometimes a string type, and when the PLC's string file type (the ST file on compact PLCs is the common case) is absent, no object reconfiguration creates the mapping. The panel cannot read data its driver never fetches, so the tag fails to bind or the object stays empty. Stop working on the object and move the data. The PLC's integer files are a type the same driver maps without complaint, two bytes per word is enough to carry text, and the remaining panel work is a data-type change on one object.

How do I carry ASCII text in integer words?

Pack the characters two bytes per word: an ASCII character is one byte, a 16-bit integer word holds two of them, so a 20-character message occupies 10 words and a 40-character one occupies 20.

ASCII fixes the byte values: capital A is 65, the space character is 32, and the digits 0 through 9 are 48 through 57. An odd character count rounds up to the next whole word, and the unused last byte is padded with the space character, decimal 32, so nothing printable is lost and the display holds a fixed width.

One decision waits before any logic is written: which byte of the word carries the first character of each pair. That order is fixed inside the driver, and the two-character probe in the testing section below settles it with one entry and one data-table read. Record the result, because every word the PLC assembles afterwards uses that order.

Packing two ASCII bytes per word is the standard transport for text across a word-register interface; a FINS write that carries two ASCII bytes per word documents the same layout on another protocol. The move is also the same one that puts a float stored in two word registers on the panel: when the driver cannot map a type, hand it a layout it can.

Worked example: what do the words hold for a 20-character message?

A line-side message reading ORDER 1042 PALLET 07 is 20 characters, so it fills 10 integer words exactly, and each word carries one character pair as a decimal value you can check in the PLC data table.

Take the probe result as 16706, the first character high, so each word value is first character × 256 + second character. The pair OR works out as 79×256+82 = 20306, and the whole message runs:

With the other probe result, 16961, every row swaps its two bytes: the first word becomes 82×256+79 = 21071 and the rest follow the same swap. Either way the block is 10 words at one start address, the object's element count is 10, and the panel shows ORDER 1042 PALLET 07.

Which words should the panel write, and which should the PLC write?

Give each direction its own block of integer words and record the two start addresses: one block for operator entry that the panel writes, one block for the message that the PLC writes, with no overlap.

The example blocks are 10 words each; size every block for its longest message and add a spare word if the text may grow. Two blocks cost two start addresses and buy clean tests: the entry path can be exercised while the message block sits untouched, and a PLC-side write cannot clobber an operator mid-entry. Keep the addresses the panel uses direct: the standing check for mapped integer data is to confirm the words are not indirectly addressed, the N100[N7:0] form, since the driver reads one fixed address and your layout hands it that address. If logic acts on the entered text, a batch ID that releases a transfer for example, validate its length and characters in the PLC rungs before acting: an entry object writes raw bytes, and a half-finished entry is a valid-looking wrong value.

How do I point the panel object at the integer words?

Set the object's data type to ASCII String, then give it the block's start address and the number of words it spans: an ASCII String object reads a vector of word values and shows each byte as a character.

An ASCII String display configuration asks for three things: the data type set to ASCII String, the start address of the block, and the number of elements, and it renders each byte in that span as one character. For the worked block that is the start address and 10 elements. The display object points at the PLC-written block and the entry object points at the panel-written block, so the two objects never touch the same words. If the object was first built as a numeric tag, changing the tag's data type without rebuilding every object keeps the rest of the screen untouched.

How do I test each direction with a short string?

Test the panel-to-PLC path first with a four-character entry such as ABCD, read the two written words in the PLC data table, then run the PLC-to-panel path with the same string assembled in logic.

1. Type ABCD into the panel entry object and send it.
2. Read the entry block in the PLC data table. Word 1 reads 16706 with the first character high or 16961 with it low, since A is 65, B is 66, and 65×256+66 = 16706. Word 2 reads 17220 or 17475 to match, since C is 67, D is 68, and 67×256+68 = 17220.
3. Assemble ABCD in the display block from PLC logic with the recorded order, and confirm the display object shows ABCD.
4. Load the real message, the 10-word block from the worked example, and confirm the panel shows it character for character.
5. When one direction works and the other does not, change only the failing direction's start address, element count and byte assembly. The passing direction is the reference for how the driver behaves.

What do the symptoms point to?

Each failure has one first cause to check before you touch anything else, and the table below pairs the four symptoms this arrangement produces with the setting or address that usually causes them.

A scrambled display with confirmed addresses and element count is byte order first: flip the assembly, rebuild the block, and compare against the example table. Numeric gibberish from a misread type is the same diagnosis with values, and nonsense numbers from a BCD analog register walks that case.

What does a working numeric tag prove?

A numeric tag that reads and writes correctly proves the cable, the driver and the address path work, so if strings still fail the fault is in the string object's data type or word layout, not the link.

That is why none of the checks above touch cabling, protocol settings or the network: the numeric tag already exercises them. It does not prove the string layout, because the string object adds a data type and a byte order a numeric tag never uses, and that is exactly what the ABCD probe isolates. Work one direction at a time, keep the two start addresses and the byte order in the project notes, and the next string on this machine is a five-minute change.

Recommendation: When the panel driver cannot map the PLC's string file type, stop reconfiguring the object and move the text: characters into integer words two bytes per word, the object's data type set to ASCII String with the block's start address and word count, one word block per direction, and the ABCD probe run in both directions before any real message reaches the screen.

This stays an HMI tag fix. A standalone board beside the line for shift notes, counts and targets is a different screen with a different job, and the shop-floor displays page covers that one.

Questions