HMI Command Reset Behavior After PLC Restart

Restart behavior is part of command design

Many HMI commands are built as momentary buttons: the operator presses Start, the HMI writes a bit, the PLC sees the bit, and the bit is cleared. That looks safe until a PLC, communication driver, or HMI client restarts in the middle of the transaction.

A stale command can be written again after reconnect. A command bit can remain true in a controller tag. An HMI can show a button as released while the PLC still has a latched request. A gateway can replay the last write after its session returns.

Command reset behavior should be designed and tested, not left to default driver behavior.

Separate request, acceptance, and result

A single command bit is hard to troubleshoot. For important actions, use a small handshake.

Signal	Direction	Purpose
Command request	HMI to PLC	Operator or SCADA asks for an action
Command ID or sequence	HMI to PLC	Distinguishes a new request from an old one
Accepted or rejected	PLC to HMI	Shows whether permissives and mode allowed the request
Active or executing	PLC to HMI	Shows that the action is in progress
Done, failed, or timeout	PLC to HMI	Final result for the operator and audit trail

The sequence value matters after a restart. If the PLC has already processed command 1482, it should not process 1482 again just because the HMI reconnects and rewrites the same value.

Avoid retained command state

Commands should normally be edge-triggered or transaction-based, not retained as durable desired state. Retained state makes sense for a recipe selection or an operating mode target when the PLC validates it. It is dangerous for one-shot actions such as Start pump, Open valve, Reset fault, or Acknowledge alarm.

Check these places for unintended retention:

• HMI tag database default values after client restart;
• SCADA driver write cache or store-and-forward feature;
• OPC UA or MQTT gateway retained command topics;
• PLC retentive memory area used for command bits;
• script variables that survive screen navigation;
• redundant server synchronization of pending writes.

If a command must survive a restart, make that an explicit requirement and give it a visible pending state. Do not let it survive by accident.

Clear requests in the controller, not only in the HMI

The controller should own the final clearing logic for command requests. The HMI may drop the button state visually, but the PLC should clear or consume the request after it records the command.

Common patterns:

1. HMI writes request bit and sequence number.
2. PLC detects a new sequence number.
3. PLC checks mode, permissives, interlocks, and user authority if available.
4. PLC latches an internal accepted/rejected result.
5. PLC clears or ignores the request until the HMI sends a different sequence.
6. HMI displays the result and logs the transaction.

This avoids a race where the HMI clears the bit before the PLC scan sees it, or the PLC sees the same true bit on every scan after a communication pause.

Define startup masking carefully

After a PLC restart, many states are temporarily unknown. Drives may not be communicating yet. Remote I/O may still be reconnecting. Interlocks may not have current values. HMI commands should not become available just because the HMI is online.

Useful startup gates include:

• controller first-scan complete;
• remote I/O healthy;
• safety and permissive data valid;
• device feedback current, not stale;
• mode source confirmed as local, remote, or auto;
• command queue empty or reconciled;
• time sync valid if command audit requires it.

Startup masking should be visible. If an operator cannot start a pump because the controller is still initializing I/O, the screen should say that. A disabled button with no reason invites bypasses and phone calls.

Test restart points in the transaction

Restart testing should hit the uncomfortable moments, not only the idle state.

Run at least these cases in a safe simulation or controlled commissioning window:

1. Press command, then restart the HMI client before the PLC accepts it.
2. Press command, then restart the PLC before it clears the request.
3. Press command, then break the network between HMI and controller.
4. Restart the SCADA server while a command confirmation popup is open.
5. Restart a gateway that buffers writes.
6. Fail over redundant SCADA servers during a pending command.
7. Power up the PLC with command tags already true in retentive memory.

For each case, record whether the action executed zero times, one time, or more than one time. The correct answer depends on the process, but it must be known.

Watch the difference between button state and command state

Operators see a button. The PLC sees tags and scan transitions. Those are not the same thing.

Bad symptoms include:

• button springs back but request bit remains true;
• confirmation popup closes while the PLC still reports command pending;
• command is rejected but the HMI only shows a generic timeout;
• HMI enables the same command again while the PLC is still executing the previous one;
• a screen change drops local script state and leaves the operator without a result message.

Make command status visible near the button: Pending, Accepted, Rejected - auto mode required, Executing, Done, Timed out waiting for open feedback. Specific messages reduce repeated button presses.

Audit what actually happened

A command audit should describe the transaction, not just the mouse click.

Useful fields:

• operator and station;
• command name and target equipment;
• requested value or action;
• command sequence number;
• request time, accepted time, and final result time;
• PLC result code or rejection reason;
• controller restart or communication loss during the transaction;
• final feedback state.

This is especially important when someone asks, "Did the operator press start twice, or did the system replay it?" Without sequence and result fields, the audit trail may not answer that question.

Common failure modes

Failure mode	Why it happens	Prevention
Command fires after reconnect	Driver or gateway replays a cached write	Disable retained writes for commands, use sequence checks
Command executes twice	PLC treats a held bit as a new edge after restart	Use command IDs and last-processed memory
Command is lost	HMI pulse is shorter than PLC scan or communication delay	Let PLC clear request after consumption
Button is enabled too early	Startup quality and permissives are not ready	Gate commands with controller-ready status
Operator repeats command	HMI gives no pending or rejection detail	Show explicit command result and timeout reason

Commissioning checklist

Before release, verify these items for every critical HMI command:

• The command has a defined owner for clearing or consuming the request.
• A stale request cannot execute after PLC, HMI, server, or gateway restart.
• The PLC rejects commands while startup data is invalid.
• The HMI shows a specific reason when a command is unavailable or rejected.
• Duplicate requests are detected by sequence number or equivalent logic.
• Audit records include request, acceptance, result, and any restart during the transaction.
• Restart and failover tests were run at more than one point in the command sequence.

The goal is not to make every button complicated. The goal is to make restart behavior predictable before the first real abnormal shutdown.