Problem: Random homing fail from 3.7.7 onwards
TITAN3737 opened this issue · comments
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: trueStartup 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
Send $message/level=debug and give us the debug log from a homing failure
What type of switches are you using?
Use FluidTerm to do what Mitch suggested and send $H.
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/
$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
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.
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.
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?
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.
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.