Read the GRBL machine state before sending a reset, unlock, home, or resume command. The state word identifies the controller condition; position, alarm messages, available input reports and the recent action give it context. If there is immediate danger, follow the exact machine’s emergency procedure first. Do not delay stopping a hazard to collect evidence or treat a software feed hold as an emergency stop.
In standard GRBL v1.1, a status report starts with the state word. A ? request asks for current runtime information, although homing and critical-alarm conditions can restrict reporting. The useful question is not simply “How do I clear this?” It is “What does this current report let me establish, and what is still unknown?”
Keep the report and the event together
When it is safe to observe, preserve the current report alongside its time, the preceding alarm or message, and what happened immediately before the interruption. Record the available position, coordinate-offset context, overrides, line information and input reports without assuming that every field will appear. A screenshot or saved console excerpt can do this; no special worksheet is necessary.
Keep observation separate from reconstruction. “The operator pressed pause” is a recorded event if someone witnessed it. “The limit switch must have failed” is a hypothesis until the machine’s documented checks support it. Resetting first can remove the context that distinguishes these explanations. Standard GRBL warns that resetting during motion can leave position uncertain.
Read position alongside Idle and Run
Idle means no controller motion is executing. It does not independently establish correct workholding, a clear tool path or reliable position. Run indicates active motion, but the state alone cannot locate the tool relative to the part. Read the available position and coordinate context before deciding what either label means for the actual setup.
GRBL v1.1 normally reports one position vector, MPos or WPos, rather than both. A sender can derive the other using work-offset information. If two displays seem inconsistent, preserve their labels and timestamps instead of treating the numbers as interchangeable. A coordinate readout is controller information, not an independent measurement of the physical tool.
Imagine two otherwise identical interrupted jobs. One has a recorded position reference and unchanged workholding; the other has uncertain position after an abrupt stop. An Idle label cannot make those situations equivalent. Their different histories change what must be verified before any next move.
Distinguish a completed hold from a transition
In standard GRBL v1.1, Hold:1 means the hold is in progress; Hold:0 means it is complete. The word Hold by itself can therefore hide an important distinction. Ordinary feed hold controls motion and does not by itself establish spindle or coolant shutdown. Do not infer that a laser, spindle or other hazard is isolated from a motion-state label.
Consider a hypothetical sender showing Hold:1 while the position changes, followed by a fresh Hold:0 report with a stable position. That transition supports the conclusion that the hold has completed. It does not explain why the interruption occurred or authorize reaching into the machine. Those remain separate questions.
Door represents the configured safety-door sequence, not a generic pause. Its numbered substates distinguish conditions such as an open door, a transition or readiness to resume. Interpret the actual build’s response without bypassing guards or interlocks. A controller response to an input is not proof that every physical safety condition is resolved.
Recognize deliberate modes and alarm lockout
Home identifies a homing cycle; Check identifies G-code checking without normal axis motion. Confirm why the mode was entered. Check mode can assess parsing, but it does not establish physical clearance, sound workholding or hardware safety. Jog and Sleep are also documented v1.1 states; use the actual firmware documentation if either appears rather than applying another controller’s recovery recipe.
Alarm locks out normal G-code operation. Preserve the accompanying ALARM:x message and the event history when safe. The state word alone does not identify whether the interruption involved a limit, probe, homing or position-loss condition.
Do not turn an unidentified alarm into an unlock experiment. This task ends with correctly identifying the reported condition and the evidence needed for the machine’s documented recovery process—not with a universal reset, unlock or jogging sequence.
Choose the next observation from fresh evidence
A previously displayed report describes a previous instant. After an interruption or transition, compare a fresh report with the saved evidence when reporting is available. If no fresh report can be obtained, keep that limitation explicit. Do not make the screen look reassuring by issuing commands that change the situation before it is understood.
You have enough evidence for the next documented check when the current state, position context and event history can be reconciled with the physical machine. If they disagree, an input behaves unexpectedly or the alarm remains unexplained, stop and consult the exact controller and machine instructions. Preserve safe access boundaries throughout; a readable report is not permission to resume.
Questions about the status display
Is Disconnected a GRBL machine state?
No. It describes the sender’s connection, not one of the documented GRBL runtime states. A retained state label in a disconnected sender is not a fresh controller report. Investigate the connection separately rather than assuming that the last label still applies.
Does a missing Pn field prove that limit and probe wiring is safe?
No. In standard v1.1, the field can be absent because reporting is disabled in the build or because no input is detected as triggered. Neither observation independently validates the wiring, switch configuration or protective function.
Does the state word establish the units used by the job?
No. The runtime condition is separate from unit interpretation. GRBL’s report-unit setting affects reported values, while the program’s modal context must be checked separately. Preserve unit labels with the report instead of inferring units from Idle or Run.
