The First Scan Is the Most Dangerous: Allen-Bradley Retentive Memory and Remote I/O Startup Traps

A programming review of startup versus normal scan behavior, based on the instrumentationtools.com article “PLC Startup vs. Normal Scan Time – Real Plant Impact”.

Why the PLC Wakes Up Confused

The instrumentationtools.com article states the trap plainly. During a normal scan, the controller assumes the plant is running and signals are valid. During the startup scan, that assumption is false. Inputs are still settling. Contactors have not pulled in. Transmitters are warming up. Network I/O has not connected. However, the logic already executes. Therefore, the CPU combines old memory with incomplete reality.

First, this explains pump damage. The article describes a level transmitter still outputting 12 mA after power-up while the tank sits empty. The PLC grants a pump permissive, and the pump runs dry for half a minute. Second, this explains conveyor danger. Retentive run bits remembered an operator command that the machine no longer honored. The belt restarted beside cleaning staff. No wiring fault existed. Only a missing startup reset.

Retentive Memory Remembers What the Plant Forgot

PLC memory retentivity is a feature. After a momentary power blip, an automatic sequence should resume. However, after a true outage, retention lies. Motors have stopped. Valves have drifted to fail position. Pressures have decayed. Therefore, the controller must distinguish a brief dip from a real restart.

In Allen-Bradley practice, I use the first-scan bit. Every ControlLogix CPU provides this system flag on transition to RUN. It is TRUE for exactly one scan. I gate sequence resumption, mode restoration, and permissive latches behind it. On the first scan, I force steps to zero and clear run latches. Then the operator restarts deliberately. On a Bachmann rack, the same idea uses a dedicated startup function block evaluated once per RUN transition. The platform differs. The discipline is identical.

Sequences, Batches, and the Alarm Storm

Step numbers stored in retentive integers create the nastiest failures. The article describes a mixing skid that resumed at the discharge step after a power loss. The discharge valve opened before heating finished. A batch was scrapped. Therefore, resume only after verifying the process state against the step's preconditions.

Moreover, alarms demand startup treatment. At restart, pressure is zero, flow is zero, and temperature is ambient. If alarm logic runs immediately, hundreds of nuisance alarms fire. Operators acknowledge blindly, and the article's true gearbox failure hid inside that storm. Therefore, mask or delay alarms until the process stabilizes. First, block analog alarms during startup. Second, release them one group at a time. Third, log the release so nothing hides permanently.

The Network Race Nobody Budgeted For

Modern controllers depend on remote racks, drives, and safety PLCs over EtherNet/IP or PROFIBUS. The CPU reaches RUN in seconds. Network devices do not. Switches boot, adapters negotiate, drives establish sessions, and SCADA tags refresh last. In that window, the PLC may read last-good values, zeros, or communication fault codes.

The article's own example is a remote I/O rack. It took six seconds to reconnect after a power dip. The PLC saw zero flow feedback and tripped cooling water valves. Therefore, gate operation on communication health, not on time alone. Use module health bits and explicit connection status. Allow permissives only when the I/O class reports good data.

A Startup Logic Procedure

1. Detect the RUN transition. Use the first-scan bit, then set a startup-active flag held until conditions pass.
2. Clear dangerous retentive states. Reset run latches, mode requests, and step counters to their safe initial value.
3. Verify field signals. Reject analog values outside sensor limits and wait for transmitters to report good quality.
4. Confirm network health. Require connection-good bits from every remote rack, drive, and safety interface.
5. Release alarms in staged groups. Log each release so masked faults cannot hide indefinitely.
6. Exit startup deliberately. Clear the startup flag, hand control to the operator, and record the startup duration.

Proving It Before the Plant Needs It

Startup logic fails silently. Therefore, test it under real power loss. First, perform a blackout test during FAT with a representative network. Second, measure reconnect times per device, then set your startup window longer than the worst case. Third, watch the trend during restart. Stale values that hold for ten scans reveal themselves immediately.

Moreover, document the startup philosophy in the functional specification. Programmers change over years. The rationale must not. Finally, train operators on startup alarms. When they recognize the masked window, they check the process instead of clearing screens. A well-engineered first scan is invisible in daily life and priceless during a blackout.

Conclusion & Action Advice

The startup scan is a distinct operating state, not an accident. Clear retentive lies, validate field quality, and gate permissives on communication health. Stage your alarm release, then prove the whole sequence with a real blackout test. Apply the first-scan discipline in Allen-Bradley or Bachmann platforms alike. Your plant will then restart safely every time.

Author: Jiang Lihao is an industrial automation engineer with over 10 years of experience in PLC, DCS, and control systems.