Problem: Some alarm conditions can disable the steppers, even with idle_ms set to 255

Wiki Search Terms

axis, motor configuration, idle time, motor disable

Controller Board

ESP32 test rig

Machine Description

single stepper test rig, but issue will occur with any machine.

Input Circuits

No response

Configuration file

board: "ESP32 test rig"
name: "ESP32 test rig 20240520"

stepping:
  engine: RMT
  idle_ms: 255
  pulse_us: 4.0
  dir_delay_us: 6
  disable_delay_us: 10

axes:
  shared_stepper_disable_pin: gpio.13:high
  x:
    steps_per_mm: 200.000
    max_rate_mm_per_min: 3000.000
    acceleration_mm_per_sec2: 200.000
    max_travel_mm: 100
    soft_limits: false
    homing:
      cycle: 1
      allow_single_axis: true
      positive_direction: false
      mpos_mm: 0.000
      feed_mm_per_min: 50.000
      seek_mm_per_min: 300.000
      settle_ms: 250
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: gpio.26:low
      hard_limits: true
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.33
        direction_pin: gpio.32
        disable_pin: NO_PIN

  a:
    steps_per_mm: 106.667
    max_rate_mm_per_min: 720.000
    acceleration_mm_per_sec2: 20.000
    max_travel_mm: 360.000
    soft_limits: false
    homing:
      cycle: -1
      allow_single_axis: true
      positive_direction: true
      mpos_mm: 0.000
      feed_mm_per_min: 50.000
      seek_mm_per_min: 200.000
      settle_ms: 250
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.2
        direction_pin: gpio.15
        disable_pin: NO_PIN

start:
  must_home: true
  check_limits: true

Startup Messages

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13220
ho 0 tail 12 room 4
load:0x40080400,len:3028
entry 0x400805e4
[MSG:INFO: uart_channel0 created]
[MSG:RST]
[MSG:INFO: FluidNC v3.7.17 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:config.yaml]
[MSG:DBG: Running after-parse tasks]
[MSG:DBG: Checking configuration]
[MSG:INFO: Machine ESP32 test rig 20240520]
[MSG:INFO: Board ESP32 test rig]
[MSG:DBG: SPI not defined]
[MSG:DBG: See http://wiki.fluidnc.com/en/config/sd_card#sdfallbackcs-access-sd-without-a-config-file]
[MSG:INFO: Stepping:RMT Pulse:4us Dsbl Delay:10us Dir Delay:6us Idle Delay:255ms]
[MSG:INFO: Axis count 4]
[MSG:INFO: Shared stepper disable gpio.13]
[MSG:INFO: Axis X (0.000,100.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.33 Dir:gpio.32 Disable:NO_PIN]
[MSG:INFO:  X All Limit gpio.26:low]
[MSG:INFO: Axis Y (-1000.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO: Axis Z (-1000.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO: Axis A (-360.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.2 Dir:gpio.15 Disable:NO_PIN]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Using spindle NoSpindle]
[MSG:INFO: STA SSID is not set]
[MSG:INFO: AP SSID FluidNC IP 192.168.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]

Grbl 3.7 [FluidNC v3.7.17 (wifi) '$' for help]
[MSG:INFO: ALARM: Unhomed]
ALARM:14
[MSG:DBG:  X All Limit 0]
?
<Alarm|MPos:0.000,0.000,0.000,0.000|FS:0,0|WCO:10.000,0.000,0.000,0.000>
$h
[MSG:DBG: Homing Cycle X]
[MSG:DBG: Homing nextPhase FastApproach]
[MSG:DBG: Starting from 0.000,0.000,0.000]
[MSG:DBG: Planned move to -110.000,0.000,0.000 @ 300.000]
[MSG:DBG:  X All Limit 1]
[MSG:DBG: Homing limited X]
[MSG:DBG: Homing nextPhase Pulloff0]
[MSG:DBG: Starting from -11.705,0.000,0.000]
[MSG:DBG: Planned move to -10.705,0.000,0.000 @ 50.000]
[MSG:DBG:  X All Limit 0]
[MSG:DBG: CycleStop Pulloff0]
[MSG:DBG: Homing nextPhase SlowApproach]
[MSG:DBG: Starting from -10.705,0.000,0.000]
[MSG:DBG: Planned move to -11.805,0.000,0.000 @ 50.000]
[MSG:DBG:  X All Limit 1]
[MSG:DBG: Homing limited X]
[MSG:DBG: Homing nextPhase Pulloff1]
[MSG:DBG: Starting from -11.685,0.000,0.000]
[MSG:DBG: Planned move to -10.685,0.000,0.000 @ 50.000]
[MSG:DBG:  X All Limit 0]
[MSG:DBG: CycleStop Pulloff1]
[MSG:DBG: Homing nextPhase Pulloff2]
[MSG:DBG: mpos was -10.685,0.000,0.000]
[MSG:Homed:X]
[MSG:DBG: mpos becomes 0.000,0.000,0.000]
[MSG:DBG: mpos transformed 0.000,0.000,0.000]
[MSG:DBG: Homing done]
ok
?
<Alarm|MPos:0.000,0.000,0.000,0.000|FS:0,0|Ov:100,100,100>

User Interface Software

fluidterm, but will occur with all senders.

What happened?

I have a machine that has a heavy Z axis that can crash down if the steppers are disabled before a support can be inserted under the Z. In Protocol.cpp, the method protocol_disable_steppers() (starts on line 653) has the code sequence:

if (state_is(State::Sleep) || state_is(State::Alarm)) {
    // Disable steppers immediately in sleep or alarm state
    config->_axes->set_disable(true);
    return;
}
if (config->_stepping->_idleMsecs == 255) {
    // Leave steppers enabled if configured for "stay enabled"
    config->_axes->set_disable(false);
    return;
}

Therefore if the method is called while an alarm is triggered, the steppers are disabled and the function returns before the test is done for idle_ms being set to 255, and so the steppers can turn off not under full operator control.

The example test file and output shows a condition where an issue can occur with the current fluidnc homing code, where after homing, the motors disable and the just-found home position in Z on my machine is promptly lost when the heavy Z axis drops (as per issue #1228).

For my other CNC machines, the current behaviour is one I like as disabling the steppers under alarm conditions is a bit of an extra 'safety net', albeit not quite what is described in the on-line documentation, so the question as to whether the current '255' behaviour is a feature or a fault is moot. I thought I would flag the behaviour issue though just in case it had not been spotted so far.

For machines that need the Z-axis chocking before $MD is sent by the operator, it would be useful to have an option to have a 'true steppers always enabled' mode, but I am not sure what may be considered the neatest way to implement that.

At the moment I tweak and compile the code so that a 255 check in protocol_disable_steppers() comes before the alarm check and so is made 'true enable' to match the documentation. As idle_ms is no longer restricted to an 8-bit value, I modify the current 255 code in protocol_disable_steppers() to be '256' as a 'enable except when alarm active', and also an appropriate tweak to line 378 of Homing.cpp. Although using '256' as an additional code works, it is a bit of a hack! A better option may be to have a line in the config.yaml file that selects how the legacy '255' operates.

EDIT: I forgot to mention, I have not dug into how to add into the code for config.yaml yet, but if it looks like a practical option, I am happy to take that on.

GCode File

No response

Other Information

No response

bdring / FluidNC