A lookup-text object shows the one entry its register selects, so automatic message scrolling is PLC work: time an interval, add 1 to a bounded index on the timer-done rising edge, and wrap from 10 to 1. Treat a 0 preset as off, and shift data with a FIFO only when messages actually arrive and leave.
A lookup-text object shows one message: the entry that matches the value in the register it reads. Nothing in the object advances that value. A 10-message list sits on message 1 until the PLC moves the selection register. The scroll you want is a small piece of PLC logic: an interval timer, a rising edge on its done bit, and a bounded index that adds 1 per pulse and wraps from 10 back to 1. Treat a timer preset of 0 as off. Gate the run to the message screen, and the cycle runs for as long as that screen is up. This article builds the logic step by step, defines the zero case with numbers, and separates a fixed repeating list from a true FIFO queue. Character-by-character marquee movement is a different job; scrolling text on an HMI screen with PLC logic covers that one.
Why the list sits still
A lookup-text or text-list object maps values to strings: value 3 shows the message assigned to 3. The mapping is fixed configuration data, and some editors also let a value range point at one entry. The entry on screen changes only when the register value changes, so automatic scrolling means automatic register writes from the PLC. Editing the object, reordering the table or lengthening the block changes which text belongs to which number; none of those edits creates a periodic update. Decide which behavior you want before writing logic, because two designs get called scroll:
- Cyclic display: a fixed list shown in order, advancing on an interval and wrapping to the first message. The list never changes; only the index moves.
- Queue: messages arrive, are shown, and are removed. Data moves only when a message enters or leaves the list.
A fixed repeating list needs the cyclic design, and the rest of this article builds it.
What you need
- The message count, 10 in this design, and the first register of the message block.
- The selection register the lookup object reads, with its address and data type confirmed in the editor. A 16-bit signed integer is the common type for a text-list index.
- The value mapping, set so message 1 sits on value 1; the index then runs 1 to 10 with no offset. If your first value is 0, run the index 0 to 9 and wrap to 0.
- An on-delay timer and a rising-edge (one-shot) instruction.
- A first-scan bit, or an enable edge, to write 1 to the index at start.
- The screen-number tag, if the messages belong to one screen.
Build the cycle in the PLC
- Initialize on the first scan. On the first-scan bit, or on the rising edge of the enable, write 1 to the index and move it to the selection register. This is also the legitimate way to put the first message up immediately, which is what people expect a 0 preset to do.
- Time the interval. Run the on-delay timer from the enable with the preset at 5 s, and reset it from the done pulse so the next interval starts at once.
- Add 1 per pulse. On the rising edge of the timer-done bit, compare the index with the last message, 10 in this design. Below 10, add 1. At 10, write 1. One edge, one increment, no skips.
- Publish the index. Write the index to the register the lookup object reads, in the increment rung or every scan. Keep the index in its own register, clear of the message text block, so a wrap or a hand test can never overwrite message words.
- Gate the run to the screen. AND the enable with a compare on the screen-number tag so the timer holds while the operator is elsewhere; run PLC logic only on the HMI current screen number tag shows how to read that tag. Decide the restart here as well: the initialize step returns the display to message 1 after a power cycle, and whatever you choose belongs in the rung comments.
What a zero preset means
Define 0 before a maintenance screen types it in. Build in this rule: a preset of 0 stops cycling and the display holds the current message. Put a preset > 0 compare in series with the timer so 0 can never start a timing run.
The other reading, shift now and keep shifting, is a fault to design out. A done bit that never clears fires once per scan, and a small controller completes a scan in a few milliseconds. At 5 ms per scan the index climbs 200 times a second, all 10 messages pass in 50 ms, a twentieth of a second, and the selection register takes 200 writes a second. The behavior people want from 0, the first message up at once, belongs to the initialize step on its own edge.
Watch the time base too. On a controller with no millisecond timer, an interval built from a 1 s clock bit can step no faster than once per second, so that same preset means five clock pulses; build a PLC seconds countdown with a one-second clock shows that construction. When a screen object writes the preset and leaves 0 behind, the cycle stops by this rule; fix an HMI timer preset that resets to zero in the PLC covers that repair.
Cyclic index or FIFO queue
Use the timed index for any fixed list that repeats: safety notices, changeover reminders, product messages. Use a FIFO when the content is a true queue: alarms logged as they occur, work orders consumed in sequence. A FIFO moves data only when its logic performs the shift, on arrival or on removal, and the screen still shows whichever entry the selection register names. Shifting the message block on the scroll timer couples presentation timing to data handling, moves every message word on every step, and puts queue data in the path of a presentation bug. Pick one design per screen: fixed list, timer and index; queue, events and shift.
Example: 10 messages at 5 s
Scenario: a packaging line notice board on the shop floor cycles 10 messages on one screen. Inputs: the text list maps values 1 to 10 to messages 1 to 10; the index is a 16-bit integer with an initial value of 1; the timer preset is 5 s; the enable comes from the screen-number compare.
- Cycle time: 10 messages × 5 s = 50 s per full pass.
- Interval check: the longest message runs 15 words. Silent reading for an adult sits near 200 to 250 words per minute, so 15 words takes 15 ÷ 250 × 60 ≈ 3.6 s at the quick end and 15 ÷ 200 × 60 = 4.5 s at the slow end. The interval covers the slowest reader with margin.
- Wrap check: at index 10 the compare
index < 10goes false, so the branch writes 1. Value 11 has no entry, because the list ends at 10, so the object has nothing defined to show there. - Zero case: the
preset > 0compare reads false, cycling stays off, and message 1 holds.
Result: message 1 is up within one scan of the screen opening, messages 2 through 10 follow at interval steps, and the pass repeats every 50 s. At a 3 s preset the same list would pass in 30 s, and 3 s is shorter than the 4.5 s a slow reader needs for the 15-word line, which is why this design commits to the interval it chose.
How to check it worked
With the line in a safe state:
- Write 1, then 5, then 10 to the index by hand and confirm the object shows messages 1, 5 and 10. One pass proves the address, the data type and the mapping together.
- Enable the cycle and time one pass with a stopwatch: 10 messages, a wrap from 10 to 1, close to 50 s.
- Open another screen and come back: the timer holds on the screen-number compare, and the pass resumes at the message it stopped on.
- Cut control power and re-enable: the first-scan initialize puts the index back to 1.
- Enter 0 as the preset from a maintenance screen: cycling stops and the current message holds.
Then read the failures. If the register steps 1 to 10 on schedule but the text stays put, the object's address or data type is wrong. If the text skips messages, the increment is firing on the done level instead of the done edge, so add the rising-edge instruction. A one-scan done pulse is real in the logic even when it never appears on screen; why an R_TRIG pulse never shows on the HMI screen explains that gap.
The decision, case by case
Recommendation: For a fixed repeating list, run the cycle in the PLC: initialize the index to 1 on the first scan, preset the timer between 3 and 5 s from your longest line, about 4 s per 15 words of silent reading, add 1 on the rising edge of the timer-done bit, wrap to 1 at the last message, and guard the rung so a 0 preset means off. Reserve the FIFO for queues that grow and shrink, shifted by arrival and removal events. Let one device own the index register; if a maintenance screen also writes it, name the owner for each machine mode in the rung comments, or the display will look random however correct the timer is.
Questions
Can one message stay on screen longer than the rest?
Yes. Add a compare on the index: while the index equals that message number, reset the timer without incrementing once, then let the next done pulse advance as normal. The message then holds for two intervals, 10 s in the 10-message design built here. If it needs 15 s or more, give it a second timer with its own preset and select between the two done bits.
Should the cycle keep running when the operator opens another screen?
Usually hold it. AND the enable with a compare on the screen-number tag so the timer resets while the message screen is closed, and the pass resumes where it stopped when the operator returns. On a shared panel where other screens run their own timing, give the message cycle its own timer instance so the two uses never reset each other.
How large can the message list be?
The logic is identical at 5 entries or 500; only the wrap compare changes. Time is the real limit: at the design interval, 100 messages take 500 s, more than 8 minutes per pass. That suits slow notices and frustrates alarms, so for long lists write the index directly from the alarm number and cycle the rest only when nothing is active.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.