Device Connection Conflict Recovery: Proposed Engineering Contract

The failure we must contain

A CNC connection drop is not just a networking error. The controller may still be moving, holding, alarmed, or waiting for input while the browser has lost its view of the session. A second process may also be probing the same serial device. The recovery contract must therefore fail closed:

one active application owns a controller session;
an uncertain command is never marked complete from a reconnect alone;
a reconnect never authorizes motion by itself;
work coordinates and modal state are re-read before any operator-approved motion.

Operating systems differ in how they expose serial ownership. “Single owner” is an application invariant, not a claim that every driver rejects every second open in the same way.

Schematic of Grbl alarm, hold, and recovery states — Schematic: controller state must be observed and acknowledged before a recovery path continues.

Recovery state machine

The proposed state sequence is:

Connected
  -> Link stale
  -> Motion hold / operator stop
  -> Port ownership check
  -> Reconnect without motion
  -> Query controller state
  -> Compare session checkpoint
  -> Manual approval or blocked recovery

Each transition must produce an observable event in the driver log and a visible state in the UI. A timeout is a blocked state, not a reason to jump to the next step.

What must be queried

After the serial session is reacquired, the driver should query the controller using the protocol supported by the target firmware. For Grbl v1.1, the interface documentation describes:

? for a real-time status report;
$G for the current parser modal state;
$# for stored coordinate parameters, including work coordinate offsets;
! and ~ as real-time hold and resume controls.

The driver must validate the response shape and firmware identity before using any value. A response timeout, malformed report, changed firmware family, or mismatch with the saved session checkpoint keeps the job blocked.

Schematic of preserving work coordinate offsets through a reconnect — Schematic: work offsets must be re-read; a local copy is not proof of the controller's current state.

What must not happen automatically

The first implementation must not:

replay unknown in-flight commands;
assume the last acknowledged line equals the controller's physical position;
send a cycle start immediately after a port opens;
use $X to bypass an unresolved alarm or safety condition;
infer that work zero survived from browser state alone;
let a sample configuration file become the runtime source of truth.

If the machine moved while the link was unavailable, software cannot reconstruct physical position from a browser timestamp. The safe outcome is a visible checklist and operator inspection.

Operator approval checklist

Before an approved recovery motion, the UI should require confirmation of:

the process that owns the serial port;
controller firmware and current state;
work coordinate system and offsets;
tool, stock, clamp, and safe-height clearance;
whether the operator intends to re-home, re-zero, abandon, or restart the job.

Schematic of checking workholding and clearance before recovery motion — Schematic: physical clearance is an operator check; it cannot be inferred from a reconnect event.

Implementation boundary

The first milestone should ship the state model, logging, blocked recovery screen, and read-only controller queries. Command replay, resume checkpoints, and any automatic feed override require a separate protocol review and hardware test matrix. Until those exist, the correct engineering behavior is slower recovery with explicit human approval rather than a fast but untrusted resume.