Why your image cycle stalls while logging data in a loop

What stops, and where

In zero-based numbering the first element of an array carries index 0, so a 10-element path array runs from element 0 to element 9. An index outside that range is legal wiring but dead logic: the lookup returns the default value of the data type instead of an element, and the index itself raises no error. For a path array that default is Not A Path. There is no wrap to the first image and no fall back to the last one.

So the failure sits one step upstream of where it looks broken. The image reader runs, the display control runs, and both receive nothing usable. Changing the reader or the control changes nothing, because the selection feeding them already failed. A signage player can freeze the same way, and when a signage image rotation stops the fault is in the player's own settings, so be sure which machine you are debugging.

The three values to keep apart

The bug is a wiring error between rows: the third row's output lands in the first row's slot. The moment the count passes 9, every selection after it fails, and the count in this run goes on to 300.

Time the interval with a clock, not a count

An iteration of the loop is not a unit of time. Each one carries signal generation, an image read, a file write and whatever the scheduler adds, and those costs move from run to run. A count of iterations measures completed work. Use a time function.

The transition condition in words: current time minus interval start is greater than or equal to the interval length. Watch the units, because time functions commonly report milliseconds. That threshold is 30000 ms, and a threshold left in the other unit makes the first transition either instant or never. When the condition fires, advance the image index by exactly 1 and reset the interval start in the same step.

The split between sample count and elapsed time is the same one behind showing a full test duration on a live trend chart, and it bites hardest when the loop is busy. A timer comparison executes only when the dataflow reaches it, so a long file write pushes the recognition of an expired interval late. Long blocking work inside a loop delays everything downstream, the same failure shape as long-running loops blocking an HMI script. If your intervals drift, measure the loop's iteration time before touching the timer.

Example: ten images on the clock with the counter at 300

Inputs:

• 10 image paths in the array, from the sequence spec.
• One display interval per image, from the same spec.
• An acquisition count of 300, read from the running program at the failed selection.
• A valid index range of 0 through 9, from zero-based numbering on a 10-element array.

Rule in words: the image shown at elapsed time t is element t divided by the interval length, whole part only, and it changes only when that quotient changes. The acquisition count never touches the array.

The arithmetic:

• Full run: ten display intervals back to back, 300 s in total.
• The failing selection asks for element 300. The largest valid element is 9, so the request lands 300 - 9 = 291 positions past the end. The lookup returns Not A Path and the display keeps its last good image.
• With the clock: at t = 60 s the quotient is 2, so element 2, the third image, is on screen. At t = 270 s the quotient is 9, the last image. When the tenth interval closes, the end policy fires.
• The run and the counter end on the same digits, 300: one is a duration, one is a count, and neither is an array position.

Decision: each time the elapsed time reaches one full interval, advance the index by 1. When the index would pass 9, either stop the sequence or wrap to element 0. The acquisition count goes to the logger alone.

Why the display freezes while logging runs

Two facts about loops explain a frozen front panel. A while loop runs its diagram at least once before it tests its stop condition. And values leaving through an output tunnel reach outside code only after the loop stops, with only the last iteration's value surviving; that is how auto-indexing tunnels behave in loops. A picture control fed from outside the loop therefore updates once, at the end. Keep the image read and the control update inside the loop, in the branch that owns them.

The logging branch fails on its own terms. Probe the writer's data input to confirm samples arrive, then its error output. The destination path, the file format setting and the input wiring are the usual suspects, in that order. Accept the two branches with separate tests: a picture that cycles shows the timer works, a growing output file shows the writer works, and each result says nothing about the other.

What to check before you change anything

• Probe the value wired to the array index. It must read 0 to 9. A reading of 300, 30 or 60 is the whole bug.
• Read the array size at the lookup. It should be 10, and the valid range is one smaller: 0 to 9.
• Probe the selected path. Not A Path points at the index. A real path that fails to open points at the file, which brings the usual image-path faults, the same class as image paths breaking after a project migration.
• Confirm one time unit end to end: a threshold of 30000 ms on a millisecond clock, seconds throughout, never a mix.
• Confirm the stop condition is not already true on entry. A loop configured to stop immediately runs once and exits, which looks like a freeze too.

Recommendation: Hold three values in the loop: an image index kept inside 0 through 9, a start time reset at every image change, and the acquisition count. Advance the index by 1 each time the elapsed time passes one full interval, then wrap to 0 after element 9 or stop the sequence there. Wire the acquisition count to the logger alone. If the number feeding your array index reads anything above 9, fix that wiring first, before the reader, the display control or the stop condition.

Questions