logoChat01.ai

F_MOVE (unhomed) CAR -10.000 mm Rejected: CAR forc...

Created on: September 28, 2026

Answered using GPT-5.6 Thinking by Chat01

Question

AIRO_LAB3_6.ino

F_MOVE (unhomed) CAR -10.000 mm
Rejected: CAR forced move would exceed 0.0..47.0 mm.

F_MOVE (unhomed) SLD -10.000 mm
Rejected: SLD forced move would exceed 0.0..83.0 mm.

please fix it f_move should move anyway no any blocks, its used for fixing axis and should not effect position changing, if car position 20 and used f_move it wont change 20 but moving stepper motor

Answer

I’ll patch F_MOVE so it becomes a raw recovery/jog command: it will drive the selected stepper by the requested distance even while unhomed, ignore normal software travel limits, and leave the stored logical axis position unchanged. I’ll also check for any secondary position updates in the motion code so the fix is consistent.

Thought

Inspected forced move implementations and Arduino logic

Answer

I found that this file already has a partial forcedMoveActive bypass, but its forced-move scheduler still computes and tracks F_MOVE through the normal logical coordinate system. I’m tracing that path now because that’s exactly what can make the motor’s “raw jog” semantics inconsistent with “position stays 20 mm.”

Thought

Designing raw motion

I’m separating forced movement from normal position tracking: the command will count pulses independently, avoid collision and travel-limit checks, and leave the reported position unchanged. I’m retaining only essential emergency-stop handling for safety.

Designed raw motion

Thought

Implementing raw motion

I’m updating the forced-move path so it uses an independent pulse counter, bypasses position, homing, limit, collision, and travel checks, and preserves the logical position. Emergency stopping remains effective.

Implemented raw motion

Thought

Inspected motion commands, step conversion, homing logic, and motor status code

Answer

The key change will be to give F_MOVE its own pulse counter instead of changing currentSteps. That means a logical position of 20.000 mm stays 20.000 mm before, during, and after F_MOVE, while the driver still receives the requested physical STEP pulses.

Thought

Patched forced-move tracking and updated Arduino exception logic comments

Answer

The raw path now bypasses both software travel and the physical limit switch, and it also bypasses the CAM/REL coordinate interlock. I’m making one recovery-specific adjustment as well: an axis in FAULT should still be allowed to use F_MOVE; only an actually running/homing axis and the latched emergency stop will prevent it.

Thought

Allowed F_MOVE recovery from fault state

Answer

The final behavior is now: F_MOVE CAR -10 at logical CAR=20 sends only raw negative STEP pulses; CAR remains logically 20.000 mm. The same applies to SLD at 0: F_MOVE SLD -10 is no longer rejected by the 0..83 mm range and does not make the stored position negative.

Thought

Validated fixed motor movement sketch

Worked for 4m 56s

Answer

Fixed. F_MOVE is now a true raw recovery jog:

  • Ignores 0..max software limits.
  • Ignores the physical limit switch.
  • Ignores CAM/REL positional interlocks.
  • Works while unhomed and can be used from FAULT.
  • Sends STEP pulses directly.
  • Does not modify currentSteps, CAR_Position_mm, SLD_Position_mm, etc.
  • Does not change the homed flag.
  • Emergency STOP still works, and it won’t override an axis that is already actively moving/homing.

So, for example, if CAR logically shows 20.000 mm:

text
F_MOVE CAR -10

physically moves the CAR motor by -10 mm worth of steps, but CAR will still report 20.000 mm.

Likewise:

text
F_MOVE SLD -10

at logical SLD position 0.000 mm will physically move -10 mm instead of giving the 0.0..83.0 mm rejection, while logical SLD remains 0.000 mm.

Download the fixed AIRO_LAB3_6 firmware

Share this Q&A