Allow non zero z calibration #162
Conversation
|
When we run the calibration process we set the z-axis position to be zero (that's when the machine learns where it's zero z-axis position is) so at the time that the calibration process is run the z-axis position will always be zero regardless of where the z-axis is physically. Not saying that this is a bad change, but it won't mean that calibration can be run at any height. |
|
ahh, I missed that calibration set targetZ=0 and called setZStop (which also sets targetZ=0), those two lines need to be removed as well. PR updated |
|
changing this to draft until I can dig in and see how axis are marked as having been homed since startup. |
|
I think it's important to keep those in. We could ask the user to press the "Set Z-Stop" button before running calibration but some percentage of them will forget to do it and that's going to cause issues. I'd really like to work to keep reducing the number of steps in the calibration process and not add new ones to simplify things. The ultimate goal would be to as for no user input (like not even enter some rough dimensions) |
|
The right fix is to detect that the Z axis hasn't been homed and warn specifically about that. We even have a check in that claims to make sure the axis have been homed, but it doesn't check the Z axis. If I thought it was safe to do, I would have calibration run the Z axis all the way down to zero, but that's not safe to do (we can't know if there is a bit in the machine, or if the spindle goes below the sled). So the best we can do is to detect that the Z axis has not been homed, and if not tell the user they need to do so. |
As I see the fluidnc code, homing goes to the limit switches, which the maslow wants to use when setting where the bit will cut. But since the maslow belts need to be at different lengths based on the Z distance from the mechanical limits, knowing if that has been set requires an additional flag. it is set false by default but set true when you manually set the mechanical limit or when you restore the position.
davidelang
force-pushed
the
allow_non_zero_Z_calibration
branch
from
e4bacd5 to
891e4c2
Compare
|
I created a flag to know when we have set the Z position. I initially looked at trying to use the fluidnc flag that is used to indicate that an axis has been homed, but I think that means something slightly different, and gets set when you do a homing action (bit touchoff) |
|
I keep tripping over the 'change threshold to 12' changes, I think I've resolved the conflict, but every time I do a rebase or merge, it gets flagged again |
|
I'm still stuck on I'm not convinced that these changes are a good thing. I think that having the user lower the z-axis all the way down is a core part of the calibration process. If we remove it we're going to have to ask people to do an extra step of zeroing out the z-axis separately which is another change for something to go wrong. I'd like to as much as possible work towards simplifying the user experience and reducing the number of steps that the user needs to take. |
|
I don't think it's made obvious enough that the router needs to be all the way down. FAR too many people (including experienced ones) are reporting that they are forgetting to do so. So at the very least, I think we need a UI warning (and possibly a click-to-confirm) that the router has been lowered to the stops before calibration. past that, I think this is a cleanup, a nice-to-have in that it makes it possible for someone to re-run calibration (as we release updates/etc) without having to remove the bit. But calibration should be a small part of the maslow experience. Once you have it setup, it should not be something that you have to keep doing. In any case, this set of changes will have to be re-done after the big 'make array' patchset, and I need to dig into the codebase more to understand better the difference between Z stop and Z zero and how they are managed. I am missing the difference in the logic at the firmware level, but have not yet looked at the UI code to see what it's sending for the two cases. I am needing to understand this difference to see how this should interact with normal fluidNC homing code. In a Cartesian system, you don't have to worry about the difference between the physical location and the logical location (the user does, but other than soft limits, the machine doesn't). But with a moving Z, we do need to worry about that. |
|
Can we make it so that this still automatically homes the z-axis at the beginning of calibration? I think changing that is going to hurt the calibration work flow. |
|
This will need to be re-written after the big pile of patches is merged.
but automatically running the Z down to the bottom will cause problems if there
is a bit in the spindle, or if the spindle can poke below the bottom of the
sled.
David Lang
…On Mon, 2 Dec 2024, BarbourSmith wrote:
Date: Mon, 02 Dec 2024 15:23:33 -0800
From: BarbourSmith ***@***.***>
Reply-To: BarbourSmith/FluidNC
***@***.***>
To: BarbourSmith/FluidNC ***@***.***>
Cc: David Lang ***@***.***>, Author ***@***.***>
Subject: Re: [BarbourSmith/FluidNC] Allow non zero z calibration (PR #162)
Can we make it so that this still automatically homes the z-axis at the beginning of calibration? I think changing that is going to hurt the calibration work flow.
|
|
It does require removing the bit for calibration, but I still feel pretty strongly that is the right choice. Which one should I merge first? |
This builds on #161 to allow for calibration with targetZ != 0 (i.e. the router is not all the way down against the stops)
It may be worth adding some other safeguard to the system to ensure that a freshly flashed system has had the Z zeroed