Marlin can get "lost" if stepper motors time out.

[jhitesma]

I'm on a fairly recent bugfix-1.1.x (maybe two weeks old) and have noticed that G26 can get lost since it always assumes the coordinates are correct. But if the stepper disable things can move and that's not a safe assumption.

G26 should do a homing first - at least if the steppers are disabled. I've bumped my print head removing a previous test and not noticed then then had my next test fail because it tried to print off the bed due to this.

[Roxy-3D]

If your steppers can't hold position when the power is turned off to them... Shouldn't you keep power turned on? You can do this by setting DEFAULT_STEPPER_DEACTIVE_TIME to 0.

I'm not opposed to helping you... But if this is a problem for users, it is a more general problem than just G26. There are a lot ways the stepper motors can become disabled. And if that happens and the position of the nozzle is indeterminate, we need to fix a lot of things in the code and not just G26.

Let's change the title and see what people think....

[fiveangle]

@Roxy-3D - does G26 honor Z_SAFE_HOMING when managing probing ? I can't seem to find where it might. If not, perhaps it needs to so it will check and ensure steppers haven't timed out prior to start if Z_SAFE_HOMING enabled ? What was originally created as Z_SAFE_HOMING is really now Z_SAFE_PROBING with the advent of software-defined bed leveling.

The issue does seem isolated to G26, since Z_SAFE_HOMING covers this condition for most normal Marlin operations like G29.

[Roxy-3D]

G26 doesn't use the Z-Probe. G26's purpose in life is to do a one layer print and see how well the nozzle can track the bed. I haven't really expressed things in these terms... But the reason I changed the title of this issue was this: If turning the stepper motors off causes them to lose position, we need to make axis_unhomed_error() return an error after the motors get turned off. That is how both G26 and G29 determine if the machine needs to be homed.

I don't know what the right answer is. Personally... I don't think you should turn off your stepper motors if the machine can't hold position with them off. But that issue aside, it may make sense to at least have axis_unhomed_error() indicate the machine needs to be homed.

[jhitesma]

FWIW - my machine (a Folger 2020 i3 which I believe @Roxy-3D uses as well) holds position just fine with the steppers off. But that doesn't mean it can't move when the steppers are off - and when peeling up a previous G26 test it's pretty easy to bump something if the steppers time out.

Increasing the stepper timeout seems like treating the symptom rather than the disease. The root problem is that marlin gets into a state where it thinks it knows it's position but it really doesn't. In normal use this isn't a problem since I always home before any print. But G26 is different since it doesn't have any startup code and just assumes that the machine coordinates are accurate.

[fiveangle]

The root problem is that marlin gets into a state where it thinks it knows it's position but it really doesn't.

See, now you lost me. You state your steppers "do not lose position", then go onto explain exactly how they lose position (by you bumping it) but how his this not expected ? How this is handled by the masses currently is that when we are to begin a process and the printer is in an unknown state, we issue a G28 to reset the physical universe to a known state.

If a user removes a print from the bed, they generally know that they will have to G28 to reset. This is a fundemental limiation of stepper motors and nothing new as far as I know. Once feedback loop motion control is implemented (like with the cool new I2C encoders @bgort is working on fixing), this will not be an issue, but for now there is no method to overcome this limit other than human to address, or set steppers to never time out.

But G26 is different since it doesn't have any startup code and just assumes that the machine coordinates are accurate.

@Roxy-3D - Is this true ? A user cannot issue G28 prior to executing a G26 command ? (my printer is running bilinear at the moment or I would test). Regarding axis_unhomed_error(), does it not return an error if Z_SAFE_HOMING is enabled and steppers have timed out ?

[Roxy-3D]

I think it is the opposite. I think he is saying G26 assumes that because the machine has been homed previously, the position is known and correct. As it turns out... G29 makes this same assumption.

And that is to my point, if your steppers do not hold position when they are turned off... Perhaps we should set axis_unhomed_error() to return an error if the steppers are turned off. Then both G26 and G29 will re-home.

Is this true ? A user cannot issue G28 prior to executing a G26 command ?

No.... A user can issue a G28 any time they want to do it. I think the people in this thread want it to happen automatically if needed. But G28's take so much time... I suspect most people don't want G28 and G29 homing the machine unless it really does need it. So the question becomes: Under what conditions should we assume the machine needs to be homed? It maybe any time the steppers are turned off it makes sense to home the machine. I don't know the answer.

[jhitesma]

I took Roxy's "steppers loose position" to mean things shifting just because the steppers are disabled. I've heard of some machines where the weight of a axis can cause that axis to drop just from it's own weight. What I'm saying is that my machine holds permission as long as it's not disturbed - but when removing a print...even a G26 test pattern it can be easy to move things unintentionally (or even intentionally.)

Yes, it is possible to issue G28 manually before G26 and that's what I've now got into the habit of doing. However the UBL instructions make no warning or mention about this. They do mention needing to home at other points.

I also could have sworn I saw feedback in the terminal or on the LCD from some other UBL command when I issued it from an unhomed state telling me I had to home first. Though I may be misremembering some of the instructions instead of something that came back from the machine. Maybe one of the LCD commands has it's own check, I do seem to remember a discussion about it in one of the issues/PR's on here in the past month.

So yeah, it can be done manually if the user knows it needs to be done. But it does seem that a way for Marlin to know that re-homing would be a good idea makes sense. Knowing that the steppers have disabled seems likely to be a safe way to determine when a re-home should be forced...but I don't know the internals of the firmware anywhere near well enough to know if there are deeper issues it could raise.

[Roxy-3D]

Well.... Let's change the question to this:

How upset will people be if the machine automatically homes after the stepper motors turn off? I think there are going to be people on both sides. We probably should do what is best for most users.

[jhitesma]

Along those lines which is better for the users.

To have the machine occasionally re-home when necessary - something which should be safe and sane on a properly operating machine.

Or having the machine suddenly try to run past it's limits and possibly cause hardware damage?

Extra rehoming seems like it has very minor negatives which are nothing more than slightly annoying. Ignoring the issue on the other hand has the potential to do physical damage to the users machine - about the biggest negative there is.

[fiveangle]

I think it is the opposite. I think he is saying G26 assumes that because the machine has been homed previously, the position is known and correct. As it turns out... G29 makes this same assumption.

For some reason I thought G29 followed the Z_SAFE_HOMING check to see if steppers were off, but I looked and see that it's only if G28 has been issued and X or Y steppers are deactivated that it homes XY prior to homing Z. It otherwise doesn't affect commands like G29 and G26.

Yes, it is possible to issue G28 manually before G26 and that's what I've now got into the habit of doing. However the UBL instructions make no warning or mention about this.

Okay, other than the documentation, it sounds like it's working as desiged and is not a bug. That's good !

How upset will people be if the machine automatically homes after the stepper motors turn off? I think there are going to be people on both sides. We probably should do what is best for most users.

I agree. The reason G28 isn't just automatcially performed before as part of G29 or a G1 or anything for that matter is because the user should not be surprised by unexpected bot movement — one should not expect the bot to beging printing a grid, but instead it homes all axis (which could be quite a catastrophy in a max-z-homed delta). The current method of a user manually instantiating G28 followed by whatever operation afterward that requires known location still makes the most sense.

I could evnision it as @jhitesma desires as a user-config option, but I suspect the reason it hasn't been done like this is because where do you implement it and where do you not ? If such a AUTO_REHOME_ON_MOVEMENT_REQUEST_WHILE_STEPPERS_OFF feature were implemented, any command that results in movement, including G1, should honor it. I don't see how that's even technically possible from a performance standpoint (inside the ISR for example). As closed-loop control become the norm, we absolutely would not want any contextual homing to occur ever.

It seems the solution to this is fixing the documentation with a warning ? I agree people should understand that G26 expects the state of motion system to be known.

[Roxy-3D]

It seems the solution to this is fixing the documentation with a warning ? I agree people should understand that G26 expects the state of motion system to be known.

If the machine has never been homed... G26 and G29 assume the user would prefer they home the machine just to save the user some hassle. Those commands kind of assume "You told me to do something, but I need to take a 'Time Out' to home the machine first...."

And actually... G29 is 'Smart' and only homes the machine if the command it has been given requires the machine to be homed. If you do a G29 T to print a Mesh Map, that can be done without the machine being homed, so it goes ahead and does that without annoying the user with a home operation.

[fiveangle]

Hrmm. If that's true then it probably makes sense to check if stepper had deactivated and treat it as the same as unhomed ? I've never attempted to issue G29 without doing G28 first so I'm not sure what people are used to.

[Roxy-3D]

Hrmm. If that's true then it probably makes sense to check stepper state and treat it as the same ? I've never attempted to issue G29 without doing G28 first so I'm not sure what people are used to.

Yeah... But I think the way it has to be done is if the steppers have been turned off... It doesn't matter if they were turned back on. You would have to treat that condition as 'Not Homed'.

[fiveangle]

So we'd have to write a flag whenever a stepper turned off, and clear it only after homing, plus check the flag before executing any G29 or G26 ? Gah, this seems overly complex. Sounds like something to revisit with Marlin32 when there are a lot more cycles to burn ;)

[Roxy-3D]

Oh! Check this out. Everything they want is already there:

  bool axis_unhomed_error(const bool x/*=true*/, const bool y/*=true*/, const bool z/*=true*/) {
    #if ENABLED(HOME_AFTER_DEACTIVATE)
      const bool xx = x && !axis_known_position[X_AXIS],
                 yy = y && !axis_known_position[Y_AXIS],
                 zz = z && !axis_known_position[Z_AXIS];
    #else
      const bool xx = x && !axis_homed[X_AXIS],
                 yy = y && !axis_homed[Y_AXIS],
                 zz = z && !axis_homed[Z_AXIS];
    #endif

[fiveangle]

HOME_AFTER_DEACTIVATE

boom !

Feel free to close @jhitesma after you confirm it's working :)

[Roxy-3D]

The Marlin code base is huge. Nobody knows everything that is in it!!!

[jhitesma]

Good find, that does sound like it does what I'm talking about. I'm reading the code now to make sure it won't affect anything else that would cause problems but it's looking good. I won't have time to try it on my machine until tomorrow evening at the soonest - so it will be a day or two until I can report back.

[thinkyhead]

Nobody knows everything that is in it

Actually… I do! I do! 😛

[p3p]

Unless you don't use microstepping you always lose position when disabling steppers no matter how well the machine can hold position, at most half a full step though so that's probably acceptable to most users.

[fiveangle]

I think all the admins need to (at least temporarily) become autocratic and just start closing issues like a south amercian mercenary, because nobody ever seems to ever want to close their own issues, even if you remind them 🤣

[jhitesma]

I haven't forgotten to close it...just haven't had time to recompile and test. The problem with only having one printer and a lot of projects ;) I'm actually hoping to have time this weekend to give it a try and confirm it solves the issue.

[fiveangle]

I already tested in and it and it did what one would expect on my Printrboard so should do what you want. At first I didn't think it worked, but then realized I had long ago upped my stepper timeout to 600 from the default 120.