bdring / FluidNC

The next generation of motion control firmware
Other
1.62k stars 386 forks source link

Problem: Random homing fail from 3.7.7 onwards #1182

Open TITAN3737 opened 7 months ago

TITAN3737 commented 7 months ago

Wiki Search Terms

Homing Fail

Controller Board

Root Controller ISO Rev 3

Machine Description

Gantry diode laser with external DM556 stepper drivers, dual Y motors, endstops switches on all axes, 80W laser module.

Input Circuits

No response

Configuration file

board: Root Controler v3.0
name: CNC-1250x1250
stepping:
  engine: I2S_STREAM
  idle_ms: 255
  pulse_us: 4
  dir_delay_us: 1
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: NO_PIN

  x:
   steps_per_mm: 800.000
   max_rate_mm_per_min: 4000.000
   acceleration_mm_per_sec2: 100.000
   max_travel_mm: 1280.000
   soft_limits: true
   homing:
    cycle: 2
    positive_direction: false
    mpos_mm: 0.000
    feed_mm_per_min: 300.000
    seek_mm_per_min: 3000.000
    settle_ms: 100
    seek_scaler: 1.100
    feed_scaler: 1.100

   motor0:
    limit_neg_pin: gpio.34
    limit_pos_pin: NO_PIN
    limit_all_pin: NO_PIN
    pulloff_mm: 3.000
    standard_stepper:
      step_pin: I2SO.7:low
      direction_pin: I2SO.5:low
      disable_pin: I2SO.3:high

  y:
   steps_per_mm: 800.000
   max_rate_mm_per_min: 4000.000
   acceleration_mm_per_sec2: 100.000
   max_travel_mm: 1280.000
   soft_limits: true
   homing:
    cycle: 2
    positive_direction: false
    mpos_mm: 0.000
    feed_mm_per_min: 300.000
    seek_mm_per_min: 3000.000
    settle_ms: 100
    seek_scaler: 1.100
    feed_scaler: 1.100

   motor0:
    limit_neg_pin: gpio.32
    limit_pos_pin: NO_PIN
    limit_all_pin: NO_PIN
    pulloff_mm: 3.000
    standard_stepper:
      step_pin: I2SO.12:low
      direction_pin: I2SO.10:high
      disable_pin: I2SO.8:high

   motor1:
    limit_neg_pin: gpio.26:low
    limit_pos_pin: NO_PIN
    limit_all_pin: NO_PIN
    pulloff_mm: 3.000
    standard_stepper:
      step_pin: I2SO.6:low
      direction_pin: I2SO.4:high
      disable_pin: I2SO.2:high

  z:
   steps_per_mm: 2000.000
   max_rate_mm_per_min: 1000.000
   acceleration_mm_per_sec2: 100.000
   max_travel_mm: 180.000
   soft_limits: true
   homing:
    cycle: 1
    positive_direction: true
    mpos_mm: 0.000
    feed_mm_per_min: 300.000
    seek_mm_per_min: 2000.000
    settle_ms: 100
    seek_scaler: 1.100
    feed_scaler: 1.100

   motor0:
    limit_neg_pin: NO_PIN
    limit_pos_pin: gpio.27:low
    limit_all_pin: NO_PIN
    pulloff_mm: 3.000
    standard_stepper:
      step_pin: I2SO.18:low
      direction_pin: I2SO.16:high
      disable_pin: I2SO.14:high

i2so:
  bck_pin: gpio.22
  data_pin: gpio.12
  ws_pin: gpio.21

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  card_detect_pin: NO_PIN
  cs_pin: gpio.5
# frequency_hz: 1000000

control:
  safety_door_pin: gpio.15:low
  reset_pin: NO_PIN
# feed_hold_pin: gpio.15:low
  cycle_start_pin: NO_PIN

probe:
  pin: gpio.2
  check_mode_start: false

Laser:
  pwm_hz: 5000
  output_pin: gpio.33
  enable_pin: NO_PIN
  disable_with_s0: false
  s0_with_disable: true
  tool_num: 0
  speed_map: 0=0% 1000=100%
  off_on_alarm: true

macros:
  startup_line0:
  startup_line1:
 #macro0: $SD/Run=lasertest.gcode
  macro1:
  macro2:
  macro3:

user_outputs:
  analog0_pin: NO_PIN
  analog1_pin: NO_PIN
  analog2_pin: NO_PIN
  analog3_pin: NO_PIN
  analog0_hz: 5000
  analog1_hz: 5000
  analog2_hz: 5000
  analog3_hz: 5000
  digital0_pin: NO_PIN
  digital1_pin: NO_PIN
  digital2_pin: NO_PIN
  digital3_pin: NO_PIN

start:
  must_home: true

Startup Messages

FluidTerm v1.2.1 using COM6
Exit: Ctrl-C, Ctrl-Q or Ctrl-], Clear screen: CTRL-W
Upload: Ctrl-U, Reset ESP32: Ctrl-R, Send Override: Ctrl-O
$bye
[MSG:INFO: Restarting]
ok
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x17 (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.16 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:con14.yaml]
[MSG:INFO: Machine CNC-1250x1250]
[MSG:INFO: Board Root Controler v3.0]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.21 DATA:gpio.12]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN freq:8000000]
[MSG:INFO: Stepping:I2S_stream Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (0.000,1280.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.7:low Dir:I2SO.5:low Disable:I2SO.3]
[MSG:INFO:  X Neg Limit gpio.34]
[MSG:INFO: Axis Y (0.000,1280.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.12:low Dir:I2SO.10 Disable:I2SO.8]
[MSG:INFO:  Y Neg Limit gpio.32]
[MSG:INFO:   Motor1]
[MSG:INFO:     standard_stepper Step:I2SO.6:low Dir:I2SO.4 Disable:I2SO.2]
[MSG:INFO:  Y2 Neg Limit gpio.26:low]
[MSG:INFO: Axis Z (-180.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:I2SO.18:low Dir:I2SO.16 Disable:I2SO.14]
[MSG:INFO:  Z Pos Limit gpio.27:low]
[MSG:INFO: safety_door_pin gpio.15:low]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Laser Ena:NO_PIN Out:gpio.33 Freq:5000Hz Period:8191]
[MSG:INFO: Using spindle Laser]
[MSG:INFO: Probe Pin: gpio.2]
[MSG:INFO: BT Started with FluidNC]

Grbl 3.7 [FluidNC v3.7.16 (bt) '$' for help]
[MSG:INFO: ALARM: Unhomed]
ALARM:14

User Interface Software

gSender over Bluetooth

What happened?

I was using FluidNC 3.7.0 for long time with almost no issues. Now I wanted to update to 3.7.16, but when I try to home the machine, I get some random homing error. About one in five homing fails without any clue why. I have tried almost all versions between 3.7.0 and 3.7.16 and the last version that work flawlessly is 3.7.6. From 3.7.7 onwards homing randomly fails. When homing the machine sometime randomly over travels one or more of the limit switches and crashes into the frame. In the 3.7.7 description in nothing about homing or limit switches changes. Can somebody please give me any hint what happened in version 3.7.7 that can cause this?

GCode File

No response

Other Information

No response

MitchBradley commented 7 months ago

Send $message/level=debug and give us the debug log from a homing failure

bdring commented 7 months ago

What type of switches are you using?

Use FluidTerm to do what Mitch suggested and send $H.

TITAN3737 commented 7 months ago

Send $message/level=debug and give us the debug log from a homing failure

I'm out of the workshop for today, will send the terminal log first thing in the morning

What type of switches are you using?

I use the most common ones used with Arduino, similar to these: https://www.amazon.de/dp/B08734MSDD/

TITAN3737 commented 7 months ago

$h [MSG:DBG: Homing Cycle Z] [MSG:DBG: Homing nextPhase FastApproach] [MSG:DBG: Starting from 300.000,200.000,0.000] [MSG:DBG: Planned move to 300.000,200.000,198.000 @ 2000.000] [MSG:DBG: Z Pos Limit 1] [MSG:DBG: Homing limited Z] [MSG:DBG: Homing nextPhase Pulloff0] [MSG:DBG: Starting from 300.000,200.000,3.916] [MSG:DBG: Planned move to 300.000,200.000,0.916 @ 300.000] [MSG:DBG: Z Pos Limit 0] [MSG:DBG: CycleStop Pulloff0] [MSG:DBG: Homing nextPhase SlowApproach] [MSG:DBG: Starting from 300.000,200.000,0.916] [MSG:DBG: Planned move to 300.000,200.000,4.216 @ 300.000] [MSG:DBG: Z Pos Limit 1] [MSG:DBG: Homing limited Z] [MSG:DBG: Homing nextPhase Pulloff1] [MSG:DBG: Starting from 300.000,200.000,3.797] [MSG:DBG: Planned move to 300.000,200.000,0.797 @ 300.000] [MSG:DBG: Z Pos Limit 0] [MSG:DBG: CycleStop Pulloff1] [MSG:DBG: Homing nextPhase Pulloff2] [MSG:DBG: mpos was 300.000,200.000,0.797] [MSG:DBG: mpos becomes 300.000,200.000,0.000] [MSG:DBG: mpos transformed 300.000,200.000,0.000] [MSG:DBG: Homing Cycle XY] [MSG:DBG: Homing nextPhase FastApproach] [MSG:DBG: Starting from 300.000,200.000,0.000] [MSG:DBG: Planned move to -1108.000,-1208.000,0.000 @ 4242.641] [MSG:DBG: Y2 Neg Limit 1] [MSG:DBG: Y Neg Limit 1] [MSG:DBG: Homing limited Y2] [MSG:DBG: Homing limited Y Y2] [MSG:DBG: Homing replan with X] [MSG:DBG: Starting from 94.505,-5.486,0.000] [MSG:DBG: Planned move to -1313.495,-5.486,0.000 @ 3000.000] [MSG:DBG: X Neg Limit 1] [MSG:DBG: Homing limited X Y Y2] [MSG:DBG: Homing nextPhase Pulloff0] [MSG:DBG: Starting from -5.733,-5.486,0.000] [MSG:DBG: Planned move to -2.733,-2.486,0.000 @ 424.264] [MSG:DBG: X Neg Limit 0] [MSG:DBG: Y2 Neg Limit 0] [MSG:DBG: Y Neg Limit 0] [MSG:DBG: CycleStop Pulloff0] [MSG:INFO: ALARM: Homing Fail Pulloff] ALARM:8 [MSG:ERR: Macro can only be used in idle state] ok

TITAN3737 commented 7 months ago

I just found out that this homing failures and random limit switches over travel only occur when connecting via Bluetooth. When connected by USB cable homing works fine. But cable connection is clumsy and unreliable for me, so I would prefer to use Bluetooth.

MitchBradley commented 7 months ago

It is possible that the Bluetooth system code is blocking a thread causing realtime response problems with homing. That is just a guess. I am away from the office with no way to test this hypothesis.

TITAN3737 commented 7 months ago

Thank you for reply. I am trying to figure this out all day long, about 500 homing cycles later I found out that this really does have something to do only with Bluetooth connection, but it is partially an issue in version 3.7.1 too. It looks like the Bluetooth connection can randomly overload the CPU during homing, so it becomes unresponsive, sometime even for 30 seconds with many $h commands in rapid succession. This does not happen in 3.7.0, at least not so much it becomes unresponsive. One of the enhancements in 3.7.1 is "5ms switch "debouncing" added.", can this be what puts so much load on the CPU? Is there anything else I can do to help figure this out?

MitchBradley commented 7 months ago

I'm sorry, I am not in a position to look into this right now. Realtime response in the face of a multicore,multithreaded system built on top of much third-party code is a very difficult problem.

TITAN3737 commented 7 months ago

I just donated 50$ to Honu Putters LLC/FluidNC. Maybe that can help with the development just a little. I understand that creating open source must be difficult challenge. Hope sometime in the future the Bluetooth can be used again on the newer versions. Thank anyway.