Skip to content
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

Draft
wants to merge 1 commit into
base: Maslow-Main
Choose a base branch
from

Conversation

davidelang
Copy link

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

@davidelang
Copy link
Author

This will conflict with #163

@BarbourSmith
Copy link
Owner

Nice!

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.

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).

@davidelang davidelang marked this pull request as draft November 8, 2024 23:41
@davidelang
Copy link
Author

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

  1. the existing way that just shuts it off but does not set flags saying that the axis have been homed
  2. a way to load the position from nvm and clear the flags

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

@BarbourSmith
Copy link
Owner

the process to load the config from nvram needs to also set the flags to say that the system has been homed.

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:

    bool extendedTL;
    bool extendedTR;
    bool extendedBL;
    bool extendedBR;

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.

@davidelang
Copy link
Author

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)

@BarbourSmith
Copy link
Owner

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

@davidelang
Copy link
Author

davidelang commented Nov 12, 2024 via email

@BarbourSmith
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Need to be able to save position over power down.
2 participants