Power loss, retentive memory, and the first scan

The Core Idea

A controller's state after power returns depends on which values are retained and which are initialized again. The program's first scan is part of defining how the machine should resume operation.

What you will learn

• Predict which machines start again by themselves when power returns, by asking which bits the controller keeps.

• Compare what a power cycle does to inputs, to retentive tags, and to every other tag.

• Use the first-scan bit to put a machine into a known state each time the controller starts.

• Explain why restarting after a power loss is a safety decision, and why emergency stops belong to a separate safety system rather than ordinary programmable logic controller (PLC) logic.

Why it matters

The state that made sense before a power loss may not be the state you want afterward. Restart behavior needs an explicit requirement and a check.

The problem

Two conveyors in the same building each have a Start pushbutton and a Stop pushbutton. Each Stop button is wired normally closed, so its input is ON until the button is pressed, and the program uses a normally open contact on it to permit running. The conveyors were programmed by different people:

• Conveyor 1 uses a seal-in. Start turns CONV1_RUN on, and a contact on CONV1_RUN itself, in parallel with Start, holds the rung on after Start is released.

• Conveyor 2 uses a set coil to start and a reset coil to stop. Its run bit, CONV2_RUN, is marked retentive.

The embeds in this lesson have a Power cycle button. It models the controller losing power and starting again:

1. Inputs keep their values. They come from field devices, and restarting the controller does not press or release a button.

2. Retentive tags keep their values, whatever they held, ON or OFF.

3. Every other tag returns to its initial value, usually FALSE or zero.

4. The next scan is the first scan. FIRST_SCAN is TRUE during that one scan, and the scan count starts again.

The simulator restarts instantly. On a real machine the conveyors would coast to a stop while the power was off, then do whatever the program decides when it comes back.

Safety boundary. The Stop buttons here are ordinary operator stops, read by the program. An emergency stop is a separate safety function, built from safety-rated parts such as a hardwired safety circuit, a safety relay, or a safety-rated controller, that removes power from the motors no matter what the ordinary PLC program does. No lesson in this course builds one, and nothing a PLC program does in this lesson makes a machine safe.

Predict

Press START 1 and START 2, then press Power cycle. Watch the CONVEYOR 1 and CONVEYOR 2 lamps.

Try it

Keep using the demo above.

1. Start both conveyors and press Power cycle. Conveyor 1 stops and stays stopped. Conveyor 2 appears never to stop, because the simulator restarts instantly; a real Conveyor 2 would stop when the power went out and start again, with no warning, the moment it came back.

2. Press START 1. Conveyor 1 seals in again as usual.

3. Press STOP 2, then Power cycle. Conveyor 2 stays off. A retentive tag keeps whatever it held, and this time it held FALSE.

Look closer

Start both conveyors while the demo runs, then press Pause. Press Power cycle, and use Step one scan twice. The scan stepper lists every tag:

The rung display shows the same story. On the first scan, Conveyor 1's rung has no path: Start is open and the seal-in contact reads the restarted FALSE value. Conveyor 2's set coil does not need to act at all, because its bit already holds TRUE.

What restarts depends on two things: the values the controller keeps, and the inputs as they are when power returns. A seal-in also restarts if its start condition is still TRUE, for example a maintained Run selector switch left in the RUN position.

Change it

This conveyor is started by a set coil and stopped by a reset coil. On this controller its run command, CONV_RUN, sits in the same retentive memory as BOX_COUNT, an up counter of boxes delivered this shift, in boxes. The count should survive a power loss; the conveyor should not start by itself.

1. Press START, then press BOX a few times. Press Power cycle. The count is kept, which is good, and the conveyor runs again by itself, which is not.

2. Add a rung with a normally open FIRST_SCAN contact and a reset coil on CONV_RUN.

3. Start the conveyor, count a few boxes, and press Power cycle again. The count is kept and the conveyor stays off until START is pressed. Run the checks.

Show the guided change

Add one rung: normally open FIRST_SCAN contact → reset coil on CONV_RUN. It can go at the top or the bottom of the program. On the first scan after power returns, the reset coil turns the retained run command off, and after that scan FIRST_SCAN is FALSE, so the rung does nothing until the next start-up. The box count is untouched. Use a reset coil, not an ordinary output coil: an ordinary coil would write CONV_RUN FALSE on every scan after the first, and the conveyor could never stay running.

Check yourself

Build the restart logic from an empty program. The tags are START_PB, STOP_OK (Stop wired normally closed), CONV_RUN, POWER_LAMP (the POWER RESTORED lamp), and FIRST_SCAN. On this controller CONV_RUN is retentive, and you cannot change that here.

• Start runs the conveyor, and it keeps running after Start is released. Stop stops it, and Start does nothing while Stop is pressed.

• Each time the controller starts, at power-up or when power returns, the conveyor stays off until Start is pressed.

• Each time the controller starts, the POWER RESTORED lamp lights on the first scan and stays lit until Start is pressed, so the operator knows why the conveyor is waiting.

Use Power cycle and Step one scan to try your program, then run the checks as often as you need.

Hint 1

CONV_RUN keeps its value through a power cycle. What has to happen on the first scan so that the conveyor waits for Start?

Hint 2

Use FIRST_SCAN twice: once to turn CONV_RUN off and once to turn POWER_LAMP on. FIRST_SCAN is TRUE for only one scan, so which coils keep their result after it goes FALSE?

Hint 3

A normally open FIRST_SCAN contact drives a reset coil on CONV_RUN, and on another rung a set coil on POWER_LAMP. Start, through a normally open STOP_OK contact, drives a set coil on CONV_RUN. Start also drives a reset coil on POWER_LAMP. A normally closed STOP_OK contact drives a reset coil on CONV_RUN.

Show the worked solution

Five short rungs:

1. Normally open FIRST_SCAN → reset coil CONV_RUN.

2. Normally open FIRST_SCAN → set coil POWER_LAMP.

3. Normally open START_PB → normally open STOP_OK → set coil CONV_RUN.

4. Normally open START_PB → reset coil POWER_LAMP.

5. Normally closed STOP_OK → reset coil CONV_RUN.

Rungs 1 and 2 are the initialization: they act only in the first scan, and the set and reset coils keep their results afterwards. A seal-in also works if it cannot hold through the first scan, for example with a normally closed FIRST_SCAN contact in series with the seal-in, and the lamp can be a seal-in started by FIRST_SCAN and broken by Start. A plain seal-in on its own does not pass: CONV_RUN is retentive, so its seal-in contact is still closed when power returns.

Now predict a restart you have not run. Conveyor 1's momentary Start button is replaced by a maintained Run selector switch, so CONV1_START_PB is TRUE whenever the selector is turned to RUN. The operator leaves it in RUN and walks away. The power fails, then returns.

Last, choose a design.

What happened and why

Every bit of memory the program uses either survives a power loss or does not. A seal-in stores "running" in a bit that is not retentive, so the memory disappears with the power and the machine waits for Start. A set coil on a retentive tag stores "running" in memory that survives, so the machine starts again the moment power returns. The instruction is not what decides it: a seal-in on a retentive tag restarts too, and a set coil on a non-retentive tag does not. Inputs are a second source of restarts, because they keep their values: a seal-in restarts if its start input is still ON.

That is why restart behavior is a safety decision, not a programming detail. When power fails, people walk up to stopped machines to look, clear jams, or make repairs. A machine that starts again by itself when power returns can injure them. Machinery safety standards, for example IEC 60204-1, the international standard for the electrical equipment of machines, require that power returning must not restart a machine by itself where that could be dangerous. Decide on purpose which values to keep and which must come back OFF:

• Keep: production totals, recipe values, setpoints, maintenance hours: anything useful that does not move the machine.

• Bring back OFF: run commands, motion steps, and outputs that start motors or open valves, so the machine waits for a deliberate Start.

The first-scan bit is the tool for that second list. Rungs that read FIRST_SCAN run only in the first scan after start-up, so they put the machine into a known state no matter what memory held: clear run commands, send a sequence to its starting step, light a POWER RESTORED lamp, or load default values. In Structured Text, the same ideas appear as variables declared in a VAR RETAIN block, which survive a power cycle, and the built-in FIRST_SCAN.

None of this is emergency stopping. An emergency stop must still work if the ordinary controller or its program fails, so it is a separate safety function, built with hardwired safety circuits, safety relays, or a safety-rated controller, that removes power. A PLC program decides how a machine behaves in normal operation, including after power returns; it does not make the machine safe.

Common mistakes

• Assuming every machine comes back stopped. Cause: not checking which bits are retentive. Symptom: a machine starts by itself when power returns. Fix: find every bit that can start motion, and clear it on the first scan or keep it out of retentive memory.

• Clearing everything on the first scan. Cause: treating initialization as "reset all". Symptom: shift totals and setpoints are lost at every power cut. Fix: initialize only what must start in a known state.

• Using an ordinary output coil with the first-scan bit. Cause: forgetting that an ordinary coil writes on every scan. Symptom: the conveyor runs only while Start is held, or never. Fix: use a reset coil, or a normally closed FIRST_SCAN contact in the rung that holds the run bit.

• Forgetting the inputs. Cause: thinking only about memory. Symptom: a seal-in restarts because a maintained switch was left ON. Fix: use momentary Start buttons, or require a fresh Start press after power returns.

• Treating a PLC stop as an emergency stop. Cause: assuming the program can protect people. Symptom: a stop that depends on the controller working. Fix: build emergency stops and personnel guard interlocks in a separate safety system, such as safety relays or a safety-rated controller.

Platform notes

Tag values are retained through a power cycle. When the controller enters Run mode it performs a prescan, which sets the bits of ordinary Output Energize (OTE) instructions to FALSE, while bits written by Output Latch (OTL) and Output Unlatch (OTU) instructions keep their values. That is why a seal-in built with OTE stays off after power returns, and a run bit set with OTL can come back on. The first-scan status bit is S:FS.

Tags are non-retentive unless you mark them Retain in the tag table or data block. The FirstScan bit of the system memory byte is TRUE during the first cycle after start-up, and the startup organization block OB 100 runs once before the cyclic program begins, which is another place to put initialization.

Variables declared in a VAR RETAIN block survive a power cycle, and variables declared VAR PERSISTENT also survive downloading a changed program. Initialization on start-up is usually written with a variable that starts TRUE and is cleared at the end of the first cycle.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.