M172 PLC Restart Bit: Use Boot Logic, Not a System Bit

The M172 PLC does not expose a dedicated system bit for detecting that power disappeared and later returned. Create a restart flag in the boot task, consume and clear it in normal logic, and use battery-retained MD102.0 only when the application also needs information preserved across the outage.

Stop chasing the missing system bit

The usual quick fix is to search the system-variable list for a first-scan or power-restored bit. The required bit is not available on the M172. Setting an ordinary bit in cyclic logic also fails: it becomes true every scan and no longer identifies a restart.

Another failed approach is trying to execute shutdown logic after supply power has already disappeared. The controller cannot record an event after it loses the energy needed to execute code. Detect the event when the controller boots again, or use retained data written before the outage.

A boot-task flag is the shortest production-restoration path:

(* Execute once in the boot task *)
RestartPending := TRUE;

The cyclic application reads RestartPending, performs the required recovery action, and clears the flag. Keep it true until every required consumer has acknowledged it; clearing it too early can make slower tasks miss the event.

Define the event before choosing the memory

A boot flag proves that the controller started again. By itself, it does not distinguish a supply interruption from another event that causes the boot task to run. If the machine response is identical for every restart, the flag is enough. If production records must specifically identify power loss, add a controller diagnostic record or external supply monitor appropriate to the installation.

Prove the boot task and flag handoff

Assign the flag-setting logic to the boot task, not the normal cyclic task. Confirm the task executes once during the startup sequence by watching the flag online or incrementing a temporary diagnostic value. Remove the temporary test after commissioning.

Place the recovery action in one cyclic location. Multiple writers make restart behavior difficult to trace. A basic handshake is:

Adapt the acknowledgment to the machine sequence. Do not clear the flag merely because the cyclic task has seen it; clear it after the required initialization or logging action succeeds. If more than one task needs the event, use separate acknowledgments or latch the restart in a state machine until all consumers finish.

Check the retained path at MD102.0

A DWORD mapped to MD102.0 is retained by the lithium battery and can be written continuously. Use it for a last-known value that must remain available when control power disappears. Read the value after the next boot before overwriting it.

For a last-known operating time, cyclic logic can write the controller date-and-time value into the retained DWORD. At boot, copy the retained value into EEPROM before resuming continuous updates. That record represents the last time written while the controller was still executing; it is not an exact measurement of the instant power disappeared. Its resolution depends on how often the application updates the retained value and on the validity of the controller clock.

Do not write EEPROM every scan as a substitute for retained memory. EEPROM is the archive step at boot; MD102.0 is the working retained location. If MD102.0 returns an unexpected default or stale value after a power test, check the address mapping and lithium-battery condition before changing the application.

Build the restart recovery procedure

1. Create a global Boolean such as RestartPending.
2. Set it to TRUE in the boot task.
3. Read it in the normal application task and run only restart-safe actions. Do not issue automatic motion merely because the controller rebooted.
4. Clear it manually from the recovery logic after the action completes. For a manual-reset design, expose the acknowledgment through the existing operator or maintenance interface.
5. If retained context is required, map one DWORD to MD102.0. Write the required date-and-time value there during operation.
6. At boot, read the retained MD102.0 value before normal logic updates it. Store the required historical value in EEPROM.
7. Resume the cyclic update only after the boot copy and restart handling are complete.

Keep restart detection separate from machine permissives. The flag says that initialization is required; it does not prove that actuators, communications, feedback signals, or process conditions are ready.

Verify every restart branch

1. Start from a normal running condition and record the current flag, retained value, and recovery state.
2. Perform a controlled power interruption, then restore power.
3. Confirm the boot task sets RestartPending before the cyclic recovery logic consumes it.
4. Confirm the recovery action runs once and the acknowledgment clears the flag only after completion.
5. When using MD102.0, compare the retained value after startup with the final value observed before power removal.
6. Confirm the EEPROM record receives the retained startup value rather than the newly updated running value.
7. Trigger any other permitted controller restart and observe whether the same flag appears. If it does, treat the flag as a general restart indication or add a separate method for identifying the cause.

Repeat the test with communications unavailable and with the operator interface disconnected if either participates in acknowledgment. A restart path that depends on a missing supervisory device can leave the flag latched and block recovery.

FAQ