A scan cycle is the unit of thought.

A useful starting model for a cyclic PLC program is three steps: read the inputs, evaluate the logic, and update the outputs. The controller repeats the sequence. Real controllers also have task scheduling, communication, interrupts, and device-specific I/O behavior, so this model is a starting point rather than a universal timing guarantee.

Think about an AND gate connected to two switches. At the moment the logic is evaluated, both inputs must be true for the output to be true. The gate does not remember that the first switch was true a second ago. It answers a question about the values it receives now.

A latch, timer, or counter has memory. Its next result depends on the current inputs and its previous state. A rising-edge detector is a simple example: it produces a pulse when an input changes from false to true. Holding that input true should not produce a new rising edge on every scan.

This distinction matters when testing. Two circuits can have the same current inputs and different outputs because their histories differ. Record the sequence of input changes, not just a screenshot of the final values.

Start with the two-input AND example in the lab. Pause the simulation, set the inputs, and advance a scan. Repeat for all four combinations. Then replace a direct signal path with a stateful block and describe what you expect to be remembered.

The Fieldnotes lab is an educational browser simulation. Its scan and timer behavior are defined by its own engine; they do not certify how a particular PLC or physical machine will behave. Browser scheduling is also different from deterministic controller timing.