Open TITAN3737 opened 7 months ago
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.
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
Startup Messages
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