-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
save arm position when idle, restore at startup #172
base: Maslow-Main
Are you sure you want to change the base?
save arm position when idle, restore at startup #172
Conversation
This will conflict with #163 |
Nice!
On an ESP32, a "float" is a 32-bit single-precision floating-point number, while a "double" is a 64-bit double-precision floating-point number. We're running out of memory so using floats wherever we can (32 bits is still a lot of bits) is a great idea, but I haven't been very careful about it. I think we need to do a "memory saving cleanup" at some point in the not too distant future. Overall a great idea. I'd like to put a little bit of thought into what this looks like from a user perspective...maybe we require an "apply tension" after loading this before allowing movement because that will work as a sanity check to make sure something weird hasn't happened (like the machine got taken apart and put back together). |
the process to load the config from nvram needs to also set the flags to say that the system has been homed. As far as the UI goes, what I think would be best is to still start the machine with the alarm on, but if there is a set of saved parameters, have two ways to shut it off
I need to dig more into the existing fluidNC code and find how it records that an axis has been homed, and set that up for the Z axis (for setZStop() as well as here) and also set the extendedXX flags My thinking here was just to follow the logic for the Z axis handling, but it looks like there is more to do, so changing this to draft |
I think that what we really want to do here is set the flag that the belts have been extended. That way we force the user to press "Apply Tension" before the machine can move around. That's important because it's a sanity check that the belt lengths are actually valid. If someone were to try to move the machine with the belt lengths not correct the machine would destroy itself. That would mean setting each of these to true:
when the position is loaded. The only issue that I see with this plan is that I'm not sure that Apply Tension works if the machine is not centered. That's something which might need some work. |
There is more work to do on this, which is why I changed it to draft. Besides setting the various extendedXX flags to true, it also needs to set the flag that I created for Z in #162 I think that I also need to calculate the x/y coordinates for the current belt lengths and set them before calling the functions to tell the gcode engine where we are. I don't think we need to do apply tension, we just need to do the tighten that is done after the machine starts to move after it goes idle at any point (I also think we need a way to adjust the timeout for the slack that the machine releases when it goes idle, including 'never' as an option for people doing manual cuts with jogs or manually entered gcode) I'm pausing work on this until some of the other changes get in place (including the #163 naming cleanup) |
The problem is that if anything has changed at all since the machine was last powered on, this will destroy the machine. Running the "Apply Tension" system will tighten up the belts, but also take a measurement to make sure that things are OK and if they aren't it will shut the machine down and prevent any damage from occurring |
BarbourSmith wrote:
> I don't think we need to do apply tension, we just need to do the tighten that is done after the machine starts to move after it goes idle at any point
The problem is that if anything has changed at all since the machine was last powered on, this will destroy the machine. Running the "Apply Tension" system will tighten up the belts, but also take a measurement to make sure that things are OK and if they aren't it will shut the machine down and prevent any damage from occurring
At startup, there should be a popup saying 'position was restored to <give
details> if this is not correct, retract and extend the belts and zero the Z
axis'
but even if it's wrong, this shouldn't destroy the machine.
The worst that should happen is
1. the router runs off the workpiece
or
2. you hit over current limits (4000)
David Lang
|
The over current limits are a nice idea, but they absolutely don't prevent the machine from destroying itself if the belt lengths are way off. The system has enough inertia that it can break itself before the limits kick in :/ Requiring the user to just press the "Apply Tension" button to me seems like even less steps than asking them to confirm with a popup tho. |
fixes #93 #171
disclaimer!!!
compile tested, but I don't have access to hardware from home to functional test this
I converted most of saveZPos to a helper function so that it's not opening and committing to the NVM for each variable, but I don't know enough about the nvm functions to be sure that this is safe
I created setPosition() in MotorUnit and gave it's parameters as a double because that's how values hare handled in that file, but in Maslow.cpp all the positions are handled as floats. I seem to remember that with the original maslow we needed to handle chain lengths as doubles or we ran into precision problems, but if that is the case, we have a lot to go through and change. I expect that FluidNC handles positions as mm floats, but it's not normally handling distances as large as the maslow