Wrong initials on a door-log panel come from storing raw ASCII in V-memory. Keep the four-digit PIN check in the PLC, write a unique 2-digit index per user into the newest history word V3000 after a match, and let the panel's lookup text object call up that user's message. A 32-entry log then fits in V3000 to V3031, one word per entry.
Wrong initials and swapped words on a door-log panel have one root: the raw ASCII path between the PLC and the display. Patching one character value at a time leads nowhere, because the next name breaks in a new way. Change what the panel is asked to show. Keep the four-digit PIN comparison in the PLC, and after a match write a unique 2-digit index, 1 to 20 for twenty users, into the newest history word, V3000. A lookup text object in the panel project holds one message per index and calls up the right initials or full name for the number it reads. Below are the symptom table, the checks, the mapping, a worked example with the arithmetic, the bench test and the timestamp question the log raises.
Why do raw ASCII initials show the wrong letters on the panel?
The panel's dynamic text object is documented to display the ASCII equivalent of whatever bytes sit in the tag register, so a scheme that packs four letters into two V words breaks when the byte order or one character value does not line up with the display.
A V word is 16 bits and one ASCII character takes 8, so one word carries two characters and a four-character set of initials occupies two words: characters 1 and 2 in V3000, characters 3 and 4 in V3001. Every one of those bytes has to survive the trip from the PLC write to the panel render in the order the display expects. How the two characters land inside one word is walked through step by step in packing an ASCII string into V-memory words.
That packing is why the two faults travel together. V3000 and V3001 showing in reversed order means the halves of each entry are being read in a different order than they were written. A few letters wrong while most look right means the character values are not landing as written. Correcting one letter's value fixes nothing, because the next entry breaks differently. The durable fix is to stop asking the panel to render bytes at all and store a number that selects a stored message.
Which symptom points at which fault?
Three faults show up in a log like this and each lives in a different place: reversed words point at character packing, wrong letters point at the raw ASCII render path, and a right user with wrong initials points at the PLC write or the stack shift.
| Symptom | What it points to | Next check |
|---|---|---|
| V3000 and V3001 appear in reversed order | The two characters per word are read in a different order than they were written | Write one known four-character string, then read both words in the PLC |
| Some letters wrong, most letters right | The raw ASCII render path, not one bad character value | Render the same string once as raw ASCII and once as a lookup message |
| Right user matched, wrong initials logged | The value written after the match, or the stack shift carrying an old entry | Read the match result and the newest history word in the PLC |
Work the table one user at a time. Identity comes first: no display change repairs a comparison that picked the wrong person. A single-letter correction has no basis in the panel maker's documentation, so treat it as guesswork and go to the lookup fix.
What do you check in the PLC before changing the panel project?
Read two values in the PLC before you edit anything: the result of the PIN comparison and the word written into the newest history entry, V3000; if the match names the wrong user, the fault is in the comparison logic and no panel change can repair it.
Enter a known PIN, watch the match result and confirm the user it selects is the user who typed it. Then check the stack shift: it has to move the identity value together with each entry and leave nothing from the previous entry behind. With raw ASCII that means verifying two words per entry; after the fix it is one word per entry, so the check gets shorter and a stale half-entry becomes impossible. The memory plan can stay where it is: the history keeps its start at V3000 and its 32 entries, newest on top.
How does a lookup text object display the right name?
A lookup text object holds a numbered list of messages inside the panel project, and the number loaded into the V word it is tagged to calls up the message carrying that number, so index 14 shows the initials stored at number 14.
The panel stops rendering bytes as letters, so byte order and character values stop mattering. Tag the object to V3000, the newest entry, and its message changes the moment the PLC writes the new index. The four-digit PIN stays as the credential: the comparison logic in the PLC keeps running unchanged, and the index is a second value that exists only after a match. A two-digit index is enough for a twenty-user roster, and the same object takes a wider index the same way if the roster grows past it.
Worked example: what happens when user 14 badges in?
User 14 badges in with a four-digit PIN, the PLC confirms the match and writes the index 14 into V3000, the newest entry; the lookup text object tagged to V3000 reads 14 and shows the message stored at 14, that user's initials.
The setup: twenty users with indexes 1 to 20 and a 32-entry log starting at V3000. The old plan stored four ASCII characters per entry, and at 2 characters per 16-bit word each entry took 2 words, so the log took 32 × 2 = 64 words, V3000 through V3063. The V3000 to V3076 allocation is 3076 - 3000 + 1 = 77 words, so 13 words of it were never used. The index plan stores one number per entry, so the same 32-entry log takes 32 × 1 = 32 words, V3000 through V3031, and every stack shift moves half the data.
User 7 is the previous newest entry and user 3 the one before it. After user 14 badges in, the shift has moved every entry down one word:
| Word | Before | After user 14 badges in |
|---|---|---|
| V3000, newest | 7 | 14 |
| V3001 | 3 | 7 |
| V3002 | 12 | 3 |
The object tagged to V3000 reads 14 and shows the message stored at number 14, say R.P.; a moment earlier it showed user 7's message. Number 0 maps to a blank message, so an unwritten word shows nothing and never shows another user's name.
How do you map 20 users to index numbers?
Assign each authorized user one number from 1 to 20, build the panel's message list in the same order, and set number 0, plus any number above 20 that the list holds, to a blank message so a stray value can never show a real name.
| PLC result | Index written to V3000 | Message the panel shows |
|---|---|---|
| Match, user 1 | 1 | User 1's initials or name |
| Match, user 14 | 14 | User 14's initials or name |
| Match, user 20 | 20 | User 20's initials or name |
| No match or invalid value | 0 | Blank |
Fill all twenty rows in on paper before the project goes near the panel, and give each person exactly one number. Two people sharing an index is the duplicate-lookup fault, one name shown for two different badge-ins; the fix for duplicate HMI lookup text walks through finding and splitting the collision. The blank at number 0 matters as much as the twenty names: it is what an erased or never-written word displays, and it must not be a real person.
What do you test before the panel goes back on the door?
Test on the bench first: the panel's free programming software includes a simulator, so you can run the lookup against forced index values without wiring anything, then repeat the same checks one user at a time at the live door.
- In the simulator, force 0, 1, 14 and 20 into the tag word and confirm blank, then the right three names.
- Enter one real PIN at the door, read the index in V3000 in the PLC and confirm the message matches the person who typed it.
- Enter a second PIN and confirm the new index sits in V3000 while the first person's index moved to V3001 unchanged.
- Repeat for all twenty users, starting with the ones whose initials contain L, M and S, the letters that failed on the raw path.
Recommendation: When a text panel shows reversed or wrong initials from raw ASCII, stop storing letters. Keep the four-digit PIN comparison in the PLC, give every user one index from 1 to 20, write that index into V3000 after a match, tag the lookup text object to V3000, map number 0 to a blank message, and run the simulator test before the panel goes back on the door.
Each failure isolates to one place: a wrong match means the PIN comparison; a right match with a wrong index means the PLC write; a right index with the wrong text means the message list; a right newest entry with wrong older entries means the stack shift.
Can the log show the time and date too?
As configured, neither the PLC nor the panel has a real-time clock, so the log answers who opened the door and cannot attach a time; identity-only history is a complete record for a maintenance-shop door.
If the record must reach further back than 32 entries, the index scheme extends cleanly: at one word per entry the full V3000 to V3076 range, 77 words, holds 77 entries, and widening the stack only changes the PLC copy logic. When even that runs out, the panel's data logging is the tool for a longer record; logging ASCII text on an HMI panel covers the case where the stored values are strings.
For a clock, this class of small PLC takes a calendar card in its expansion slot; for this PLC family the part is the D0-01MC memory card. Check that it fits the exact unit and that it is currently available before ordering, and expect the history area to grow, because a date and time take extra words per entry.
Questions
Can I keep the four-digit PINs after switching to lookup text?
Yes. The PIN stays as the credential checked by the PLC comparison. The index is a second, internal value written only after a match, so the door-release logic and the text shown in the history stay separate. Nothing about the touch-pad entry or the comparison changes; only the value stored into the history stack and the object that displays it change.
How many users can a two-digit index name?
A two-digit index runs from 0 to 99, so after the blank at number 0 it can name up to 99 users. Twenty users leave 79 spare numbers, so the roster grows without widening anything. Past 99 users, the index needs a third digit.
Does the D0-01MC memory card add a clock to this PLC?
It adds date and time to PLCs that take a card in the expansion slot. Confirm it fits the exact PLC model and is currently available before ordering. When timestamps go in, each entry grows from one word to several, so a 32-entry log with dates no longer fits in the V3000 to V3076 range and the stack logic has to be widened with it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.