Fix a dynamic text object that shows one character

Why does a dynamic text object show only one character?

Because the object's range holds one printable byte and zeros behind it. A 32-character object at V1200 reads 16 words, V1200 through V1215, and the dump of those words tells you whether the transfer or the object settings put the zeros there.

The object reads its configured range no matter how long the string is. Raising the character count makes it read more words, and it recovers nothing while those words hold zeros. One character on screen is a data signature, and the 16-word dump is the fastest way to read it. Fix the memory side first and the display side second.

What does each symptom tell you before you open the program?

The split is simple: anything wrong at the terminal points at the module program's two documented line errors, and a clean echo with one character on screen points at the bytes in V-memory or at the object's own settings.

• No question mark after you type r or w: the leading comma after INPUT1 on line 14 suppressed the prompt, so the program may still be waiting or may have ended without writing anything.
• "Device Timed Out" and then the program sits dead: line 220 sends the empty-input case to line 130, which the listing never defines, so the branch points at nothing.
• Full string echoes, one character on screen: the module received the text, so the fault sits between the block move and the display, in the bytes or in the object settings.
• One character that never changes between writes: the same signature, one good byte in the first word; dump the range before you edit anything.
• A pair that reads backwards, IL where you wrote LI: each word holds the right bytes and the object is reading the low byte first.

The first two symptoms are the line errors in the next section. The last three are read from the dump.

How many V-memory words does a 32-character text object read?

Sixteen words, two characters per word. A 32-character object at V1200 spans V1200 through V1215; the listing packs each pair as high byte first, low byte second, and 32 divided by 2 gives the 16 words the object reads.

The example listing does the packing in its write loop. DPORT((X-1),H)=ASC(<string>,X) puts the character at string position X into the high byte, DPORT((X-1),L)=ASC(<string>,X+1) puts the next character into the low byte, and BMOVE W,VH(1200),K(<string length>) carries the pairs into V-memory starting at V1200. In these lines, <string> and <string length> stand for the module's string variable and the LEN of that variable, exactly as the listing prints them. Two characters per word: 32 ÷ 2 = 16 words, so the object reads V1200 through V1215 and nothing outside it. It is the same two-per-word scheme described in packing an ASCII string into V-memory words for an HMI tag. Keep all 16 words reserved for the panel, the way reserving PLC memory for an HMI text panel without collisions sets out, because a stray write into any word of the range shows up on screen.

Which two lines stop the example program before it writes anything?

Line 14 and line 210 carry a leading comma after INPUT1, which suppresses the prompt's question mark and can leave you typing into a program that never accepted the choice. Line 220 branches to a line number the listing never defines.

Both fixes come from the corrections that made the example, written for a DirectLogic DL05 or DL06, prompt and accept input at all.

The first is the comma. Line 14 reads INPUT1 , "(r/w) ",<string> and line 210 reads INPUT1 , "Write What? ", <string>; in each, the comma between the statement and the prompt suppresses the question mark the INPUT statement prints. Remove it:

14 INPUT1 "(r/w) ",<string>

210 INPUT1 "Write What? ", <string>

The second is the branch. Line 220 reads IF INPLEN=0 THEN PRINT1 "Device Timed Out " : GOTO 130, and line 130 is nowhere in the listing. The empty-input case belongs with the read-or-write prompt on line 13:

220 IF INPLEN=0 THEN PRINT1 "Device Timed Out " : GOTO 13

With both corrections in place the program prompts, accepts your choice, accepts a string and echoes it. The echo on line 222, PRINT1 "Received > ", <string>, tells you the write loop ran with the text you typed.

How do you test the write path with a known string?

Write one short string from the terminal, confirm the program echoes it back, then read V1200 through V1215 directly and compare the bytes. The echo proves the module received the text and the dump proves where the block move actually placed it.

1. Apply the two line corrections and rerun the program.
2. Choose w at the prompt and type one short string of even length, 12 characters or fewer.
3. Check the echo shows the same characters back.
4. Open the PLC programming software and read V1200 through V1215; write the 16 values down.
5. Compare them word by word with the table in the next section.

Two things to know before you start. The listing's own read-back path, BMOVE R,VH(1200),K(15) followed by a loop from 0 to 15 step 2, reconstructs 16 byte positions, which is 8 words, so a terminal read-back exercises the first 16 characters and leaves the last 8 words of the object's range unexamined. And the block move overwrites whatever sits in V1200 through V1215, so run the test while the process is idle or on words reserved for the panel.

Worked example: what should V1200 through V1215 hold after the write?

For the 12-character string LINE 1 READY, V1200 holds 0x4C49, the pair LI, and the pairs continue two characters per word through V1205 at 0x4459, DY, leaving V1206 through V1215 at 0x0000 so nothing stale follows the text.

Take the first pair. L is ASCII 76, which is 0x4C in hex, and I is ASCII 73, which is 0x49. High byte first, so the word value is (76 × 256) + 73 = 19529, written 0x4C49. The rest follow the same way:

A dump that reads 0x4C00 in V1200 and 0x0000 in the other 15 words matches the one-character screen exactly: one printable byte, zeros behind it. A dump that shows the full set of pairs tells you the memory side is finished. When V1206 through V1215 hold leftovers from an earlier, longer test, write spaces over the tail before you compare again.

When is the fault in the transfer and when in the object settings?

The dump decides it. Packed pairs for the whole string in V1200 through V1215 mean the PLC side is finished and the object's address, 32-character count or byte order is wrong. One byte and zeros mean the block move never carried the text.

Does the dump show correct pairs?

Then the PLC side is finished and the object's three settings are the whole remaining job: source address V1200, character count 32, and character order that takes the high byte of each word first.

Check each against your dump. The source address must read V1200, the first word of the range. The character count must read 32, the 16 words your dump covers; a count of 1 shows exactly one character even with perfect data behind it. A reversed pair, IL on screen where the dump holds LI, means the object reads the low byte first, the same class of fault as a byte swap that blanks an HMI string. When the object refuses to map the range at all, displaying ASCII from integer words when the HMI cannot map the PLC string file covers the mapping from the HMI side.

Does the dump show one byte and zeros?

Then the transfer stopped early, and the edit belongs in the listing: confirm the echo, confirm the program took the write branch, and confirm the block move's count carries every character you typed before you dump again.

A choice the program never matched at the read-or-write prompt sends it to PRINT1 "Program CANCELED! " and END with nothing written. Confirm the block move's count comes from the string length, taken with LEN of the string variable, so the move carries every character you typed, then dump again. A dump that stays at one byte after a clean echo points at the move and its count, and that is where the edit belongs.

Correct pairs: fix the object settings. One byte and zeros: fix the listing.

What order fixes it fastest?

Fix the two line errors, echo a known string, dump the 16 words, and only then touch the object's settings. That order keeps one half of the data path verified before you change the other.

Recommendation: correct lines 14, 210 and 220 first, echo one even-length test string from the terminal, and judge the repair from the dump of V1200 through V1215 before you touch the object at all. When the dump shows the full set of pairs, go straight to the object's source address, 32-character count and byte order, and leave the BASIC listing alone. Once the dump and the screen agree, run the real production strings, keep them even in length where you can, and clear the range whenever a shorter string follows a longer one.

Questions