The first instinct — wipe it and start clean — is the one that destroys the evidence. A Do-more MPU that lands in PROGRAM after a power cycle almost always wrote a timestamped entry explaining why. Clear memory and you clear that entry along with the fault, which is exactly why the same CPU does it again three weeks later on a different shift.
Skip These Fixes First
Four repairs get tried on this symptom. All four can make the CPU boot to RUN once, and none of them tells you anything.
- Restore factory defaults / clear PLC memory. It wipes the system log, the retentive image, and the device configuration in one operation. The CPU boots clean because the blocking condition was erased, not corrected. It also drops the Ethernet settings, so the next tech may not find the CPU on the expected subnet.
- Re-download the project. A download forces the CPU into PROGRAM. If the mode switch sits in TERM and nobody commands RUN before the disconnect is pulled, the stored mode is PROGRAM and the next boot honors it. The "fix" builds the next failure.
- Power cycle until it takes. If the 24 VDC rail sags on inrush or rises slowly, boot success is a coin flip. Repeated cycling samples a power quality problem instead of correcting it.
- Swap the MPU. Same project, same I/O configuration, same halting error on the replacement. Hardware swap is justified only after the log points at a watchdog or memory fault.
Pull the System Log Before the Next Power Cycle
Go online with Do-more Designer over USB or Ethernet and open PLC → System Info, then the log. The log is non-volatile and timestamped: it survives power cycles, but not a memory clear or factory-default restore. Save or screenshot it before you touch anything else. While you are online, read the warning and error state the software reports — an active error is the fastest route to the cause.
| What the log shows at power-up | Mechanism | Next check |
|---|---|---|
| Power-up followed by a PROGRAM-mode entry, no error | Mode switch in STOP, or in TERM with PROGRAM stored as the last mode | Read the physical switch position on the MPU face |
| I/O configuration mismatch | Enumerated I/O at boot does not match the stored configuration — module pulled, or expansion supply came up after the MPU | Compare configured vs. actual I/O; verify expansion power sequencing |
| Retentive memory or checksum fault | The retained data image failed validation at boot | Battery / backup status in System Info; check for a reset real-time clock |
| Watchdog, scan overrun, or fatal runtime error | The CPU dropped out of RUN on its own and the condition persists at reboot | Locate the logic or instruction that faulted; check scan time |
| Clustered power-fail or low-voltage entries | Brownout or undersized supply resetting the MPU mid-boot | Measure 24 VDC at the MPU terminals during startup inrush |
Why the CPU Lands in PROGRAM Instead of RUN
Three inputs decide the power-up mode: the physical mode switch, the mode stored at the last power-down, and whether the CPU can validate its program, configuration, and retained data. Validation wins every argument. A CPU with a blocking fault stays in PROGRAM no matter where the switch is.
Switch behavior on this class of CPU is straightforward — RUN forces RUN, STOP forces PROGRAM, and TERM restores the last commanded mode while allowing the programming software to change modes over the link. TERM is where machines get stranded: it is the convenient position during commissioning, and it faithfully remembers the PROGRAM state left behind by the last download or manual stop.
Faults behave differently. When a runtime error is severe enough, the CPU transitions out of RUN and logs it. If the underlying condition is still present at the next boot — a missing expansion module, a configuration that no longer matches the hardware, an unvalidated retentive image — the CPU refuses RUN again and looks like it "won't boot up in run." That is a fault report, not a dead processor.
Get It Running Tonight
- Go online. Open
PLC → System Infoand save the log and the firmware revision. Do not clear memory. - Read the mode switch on the MPU. If it is in STOP, that is the answer — move it to RUN and cycle power.
- If the log shows an I/O mismatch, confirm every expansion unit and option module is present and powered, then re-read the I/O configuration and compare it against the stored one.
- If the log shows a runtime or watchdog fault, correct the condition first. Do not command RUN into an unresolved fault; it will halt on the same scan.
- With the switch in TERM, command RUN from Do-more Designer. Confirm the CPU stays in RUN through several seconds of scanning, not just the transition.
- Move the switch to RUN, disconnect the laptop, and cycle power at the disconnect. The CPU must reach RUN unattended.
- If it still holds PROGRAM with the switch in RUN, the fault is blocking the transition. Go back to the log — the switch is no longer the variable.
Make Power-Up Deterministic
Get it running, then fix it properly. The recurrence in a BRX after a factory reset is the signature of an unaddressed trigger, so close the trigger out:
- Leave the mode switch in RUN on production machines. Use TERM only while a laptop is connected, and put it back before you leave the panel.
- Feed the MPU and every expansion or option power supply from the same disconnect so the rails rise together. Separate supplies invite boot-time I/O mismatches when one is switched independently.
- Size the 24 VDC supply for the MPU plus field-device inrush. A rail that dips below spec during startup restarts the processor mid-boot and produces intermittent, unrepeatable failures.
- Keep the backup battery current if the log ever reports retentive or clock faults. A real-time clock that comes back at a default date is the first symptom of a dead cell, and retentive validation failures follow.
- Use the first-scan system bit to reset latches, step pointers, and outputs so a return to RUN does not move the machine unexpectedly.
- Archive the working project and configuration. If a factory reset is ever genuinely required, you need a known-good image to restore, including the IP settings.
Verify, Then Stop and Escalate
Three consecutive power cycles at the disconnect, laptop disconnected, RUN indicator lit each time, scan running each time. Add one cold start — power off long enough for the supply capacitors to drain — because a warm restart can mask a slow-rising rail. After each cycle, go back into PLC → System Info and confirm the log contains only power-up and mode entries with no error or warning lines. Record the timestamps; a clean log across four boots is the proof, not a single successful start.
Stop when the MPU still holds PROGRAM with the mode switch in RUN, no expansion attached, and a minimal project loaded, or when the log repeats watchdog or memory faults across power cycles. At that point the fault is inside the processor and no configuration change will clear it. Capture the saved log, firmware revision, and MPU part number, and open a case with AutomationDirect technical support before you burn another shift on it.
FAQ
Does restoring factory defaults fix a Do-more CPU that will not power up in RUN?
No. It erases the blocking fault and the system log in the same operation, so the CPU boots once and the trigger returns later. Save the log from PLC → System Info before any memory clear.
Can I leave the BRX mode switch in TERM on a production machine?
You can, but TERM restores whatever mode was stored at power-down, so any download or manual stop leaves the CPU in PROGRAM at the next boot. Put the switch in RUN once commissioning is finished.
Does the Do-more system log survive a power cycle?
Yes — it is non-volatile and timestamped, so entries written before the outage are still there when you go online. It does not survive a memory clear or factory-default restore, which is why you read it first.
Can a missing or unpowered expansion module keep the CPU out of RUN?
Yes. The MPU enumerates I/O at boot, and a mismatch against the stored configuration is logged and can hold the CPU in PROGRAM. Power expansion supplies from the same source as the MPU so they come up together.