Z crash but not into nozzle
-
Hi,
I'm using a Duet2 WiFi and FW 3.1.1.
I went to find the maximum Z distance I can support, so I drive the build table all the way down to just before it touches the stepper to lead screw couplers. I set this as my max Z
When homing it drops the build table 5mm ( what I set ), which is generally good if the build platform happened to be up against the nozzle.
The issue is, when the build table is all the way down and I home, it seems to over ride the max Z and slams the platform into the couplers. It really ought not do that. The firmware should know that its at the limit and not try to drop below.
Am I missing a setting?
Joel
-
Post your homing gcode that you're using.
-
@Joel The problem is that prior to homing, the firmware has no idea where Z max is, nor where the bed is. Z max is the distance relative to the homing position, so until the Z axis has been homed, the firmware has no means of establishing that distance.
You could take out that initial 5mm move from your homing file but then you run the risk of scraping the nozzle across the bed or not being able to deploy a probe when the bed is already at Z min. Or you could fit a switch to Z max and use a macro to run emergency stop if the switch gets triggered. The easiest thing, is just use a bit of common sense and make sure the bed is in a position where it is a few mm away from it's maximum travel before attempting to home it -
Hi,
When the table crashes, it is already homed. The controller knows it is at Z Max.
Code attached.
Joel -
@Joel I think you'll find that when you first run the homing macro, the very first thing that happens is the axis (or axes) get flagged as not homed. It has to be that way because if the homing flag remained set (i.e the axis is homed) then if a homing move failed for any reason, that flag would remain set. So the axis would be flagged as homed even if it failed. It only gets flagged as homed once a successful homing move is completed.
So when the homing status changes to "un-homed" (as it has to do at the start of a homing move for the reason set out above) then the axis limits are also "lost" at that point.
What is the use case for homing Z when it is already homed and happens to be at Z max?
-
Hi,
Hmm, interesting. I don't know why it should unflag that it's homed vs just rehome. Though that would explain the issue.
A potential use case would be I made a print that used every mm of Z axis, removed the print and now just want to press a button to return everything.
I can't think of a reason why "homing" would need to unhome first, just go find the end stops again and be done.
But if this is truly the case, I can just make a "return" macro.
-
@Joel Suggest you read my post again for the reason. But I'm only guessing. I'm just an end user like you and trying to help.
-
This is a good use case for conditional gcode in RRF3 where it can check if it's homed already and if so, not try to home again.
Maybe take a look through this thread: https://forum.duet3d.com/topic/17083/conditional-homing-and-z-height-fine-adjustment
-
Yep, that didn't register. But, I still think a better way then would be, if a home command is executed, only clear the "homed" flags IF the homing failed.
For now, I did add a return macro which is working fine.
@deckingman said in Z crash but not into nozzle:
@Joel Suggest you read my post again for the reason. But I'm only guessing. I'm just an end user like you and trying to help.
