Fix for [BUG] Head crashes after Home and Z-Align #21520 #21558
Conversation
|
What happens to you is really weird. I never noticed it and rehoming X and Y shouldn't be necessary once done the first time. |
|
We obviously cannot accept this PR as it is. See if it helps to enable |
|
@GMagician Yes, G34 is Z-align. I could remove G28 from my slicer start up script but I still have to be very mindful of not sending G28 more than once. That is stressful. Esp. since commands like G29 will issue G28 first. There are others that do that. |
|
@thinkyhead I did try that switch but it does not pass sanity check. #error "DISABLE_[XYZ] is not compatible with HOME_AFTER_DEACTIVATE or Z_SAFE_HOMING." Also, i hear what you are saying about not being able to pass this. The logic ahead of this change is the likely better place to update for only this style of configuration. I more wanted to share that hay, this change is fixing the problem and it isn't tmc drivers set too sensitive etc. |
|
If you very much need |
|
@thinkyhead In the attached ticket, I've added a link to a video that demonstrates the head crashing. This is easily done by calling G28 twice. In second G28, the head crashes. I think it is because in incorrectly sets X=0.0 in this case. For this configuration, the centre is home at X=116. In the output log, you'll see that Y is correctly homed at 117 but X is zero. I thing that is the bug. My hack in the related pull request is to explicitly call the homing function again on X and Y. I bet I don't need the Y though. The bug is with the X setting of home value. |
|
The problem is for sure X=0 after home. It shouldn't have such value. Are you sure you don't have a bad configuration? I still use G28 and G34 with safe home, but at end of home X is not 0 |
always home X, conditionally home Y
kpishere
force-pushed
the
fix-Head-21520
branch
from
78bf740
to
affa0dc
Compare
|
@GMagician My configuration is in the linked ticket. Guys, notice I've made an update to the PR. After some thought, review, I think this is a more serious PR request. Notice the scope of this change is only for ENABLED(Z_SAFE_HOMING). I've also tested on my machine, of course. It works well now. That is, only does what is needed, there is no double homing (a double bump at endstop) of Y axis now. |
|
Of course, The problem I see in your log is that X and Y are indeed being homed by See if it helps to enable |
|
@thinkyhead Yep, I'd agree with that and that was the first thing I'd checked, but the pins aren't getting triggered -- I'd used software monitoring pin debug tool to verify that early on. If that were the case though, even with the explicit add to home(X) again, you'd expect it to do the same thing right? IE, not move. I'm thinking the flag that sets if home is required is wrong. So, my code fix is basically to not check that and home always. I do have disable steppers off. I think by default that is on. I'm betting that is what is hiding this bug for most. Because if you have disable steppers enabled, then the flag that says home is required will be set when the steppers disable. When the steppers don't disable, this X coordinate is improperly being set to zero when the head is in middle at home position. I'm thinking that is the true bug, what I have here is a work-around for that. Notice the Y isn't getting reset to zero. that should be another clue? |
|
When you home first time, at end, what do you read on X position? is it 0 or is 0 after 2nd G28? |
|
@GMagician After home first time, on the display, it is X:114, Y:116 or so, basically the middle of the plate. After the second G28, on the display it will show same but the head is crashing to the right and is really byond 235. |
|
@kpishere a test can be a G28 as first and then just a G28X to see what happens |
It seems clear that X/Y homing is being attempted and aborted because endstops are seen as triggered. (There is no other reason that Marlin will abandon a move.) Try sending these commands from your host and see if anything interesting happens: G28
M120
G1 X0 F9999…or… G28
M120
G1 X0 Y0 F9999 |
thinkyhead
force-pushed
the
bugfix-2.0.x
branch
2 times, most recently
from
83cc0bc
to
73f6426
Compare
|
I found this thread (and a few others) because I've recently flashed to the latest bugfix (at the time, around the 1st April) and noticed that when cancelling a print and G28 XY is sent, the printer would attempt to "home" but X would move a few mm from it's current position and stop (usually somewhere near the middle of the bed), and Y would home correctly. I can immediately do another G28 (or just G28 X) and it homes as expected. I've only just gotten chance to look into why - the thing that "fixed" it for me is "ENDSTOP_NOISE_THRESHOLD" and setting that to 2. Enabling and setting that to 2, and the printer now homes correctly when doing G28 when cancelling a print. As far as I'm aware, the endstop sensors used for X and Y are the same, but the X endstop connects to a PCB/breakout board which also has the hotend, fans, thermistor and extruder motor connected. That PCB then then connects via ribbon cable to another board inside the case, which then connects to the mainboard, and I think the Y endstop is just connected via a simple extension cable to the mainboard. So it makes some sense to me that the X endstop would be "noisy". |
|
@ryamoo Thanks for this info. However, this issue specifically relates to G28 home first time, good, then second time always wrong. Probably only applies for where z-safe-homing is used aka: z is homed by probe at centre of bed. |
|
@kpishere technically, that's what happens to me, just not with a G34. I do have safe homing enabled. My first home (before a print) is fine and "homes" on the far left, the second home (when I cancel the print) will "home" in the centre. Everything I do after that is then using that near-centre position as X0, and the head crashes to the right. Have you tried changing your safe homing positions (Z_SAFE_HOMING_X_POINT and Z_SAFE_HOMING_Y_POINT) to somewhere near the front left, and see if that second home moves to that position, or if it stills homes X0 as the centre? |
|
@ryamoo So, I did as you suggested. Only, I put Z_SAFE_HOMING_X_POINT to 0.0 and Z_SAFE_HOMING_Y_POINT to YMAX as I'm expecting that Y-Axis is working fine. What I found was surprising. I'd expected that it would home OK, that is, always to zero and to y-max and it did, the first time. The second time however, the Y-Axis, still correct at YMAX but the X axis was offset by 44 mm. This is my X-Axis probe offset value. With each successive G28, the X origin moves in intervals of 44mm. So, 0, 44, 88, etc. To me, this proves there are definitely some issues with X-Axis reset values in G28 operation. Note: before doing the above change, I did revert my changes to fix this issue to what you see below which is the current branch version for bugfix-2.0.x last time I looked. |
|
@kpishere — After each homing of X, we would expect the axis position to be set to its home position. So it would be good to see some logs during the period when you are seeing the constant 44mm offsets.
Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine. |
|
@thinkyhead Ok, I've set Z_SAFE_HOMING_X_POINT to zero, left Y at the centre. Firstly, here is setup, and then log of issuing G28 3 times. What is physically happening:
SETUP Log OutputG28 Log Output |
|
It looks like you're using some version of Marlin from before April 3 because of this: After April 3 it will read: It's important to reply to requests for tests using the most recent version available. I will continue to review the log to see if it explains the problem…. |
|
Looking at the logs confirms my earlier conclusions. Your endstop is being triggered early. Then your It looks like you may have sensorless homing enabled for your Z axis, even though it is homing with a probe. Some boards have jumpers to tie the DIAG pins to the endstop pins. Maybe your Z is tied when it shouldn't be, or perhaps Marlin is not ignoring / disabling the sensorless homing trigger for Z when a probe is being used. After a quick glance at the code, it looks like the |
|
This might be the answer: #define TMC_HOME_PHASE { 896, 896, -1 } |
|
@thinkyhead Yes, z-sensorless endstop is still defined even though using z-probe. But, this is desirable still for when doing z-alignment. As for those alignment messages, I don't understand them so I have left them as is. Is it something to do with TMC having 1024 steps step table but you want to use a number that aligns with 1/2,1/4,1/8, or 1/16 step? In any case, thank you for your time! I'll rebase again, just to keep up to date for testing. |
|
Yes, I think it's ultimately a bug that sensorless homing is getting activated for Z probing, so that will still have to be patched. Then, presumably it will still be usable for features like axis alignment. |
|
As the error message also implies, "selected home phase 896 too close to endstop trigger phase 712. Pick a different phase for Z" — So you might be able to use a larger or smaller number. The formula to check for a too-close value is: |
Description
On any call to G28 a second time, the head crashes. home(x) home(y) needs to be unconditional.
Requirements
Tested on SMART RAMPS MEGA2560. By way of summary, this configuration has safe homing enabled with Z-induction probe and Z-min end stop with induction probe. So, after homing, the head is in the middle of the build plate, it isn't at position 0,0.
Benefits
No head crash
Configurations
In the referenced ticket #21520
Related Issues
#21520