Sensorless home sanity check

[arades79]

Description

Adds a timing mechanism and debugging output to the homing procedure (G28) to check if the procedure takes significantly longer or shorter than expected from the current reported axis positions. This is only intended to work when axis are already in a trusted state from a valid home. This can be used to tune TMC sensorless homing parameters by giving feedback for false positive/negative scenarios while homing.

Requirements

This feature assumes usage of sensorless homing and may not work properly with traditional homing. This is also only tested on STM32 targets.

Benefits

Allows automated/assisted tuning of TMC sensorless homing parameters

Configurations

The following config block should be added (or uncommented) inside of the #if EITHER(SENSORLESS_HOMING, SENSORLESS_PROBING) block of configuration_adv.h file:

    // On axis home for trusted axis, check that a stallguard false positive or negative didn't occur by timing the move
    #define SENSORLESS_HOME_SANITY_CHECKING
    #if ENABLED(SENSORLESS_HOME_SANITY_CHECKING)
      #define HOME_SANITY_CHECKING_STARTUP_COMPENSATION 200
      #define HOME_SANITY_CHECKING_ERROR_MARGIN 50
    #endif

Related Issues

N/A

[thinkyhead]

This PR seems to be marked as not editable by maintainers. Do you see a checkbox on the page to allow edits by maintainers? If so, please enable that option.

[arades79]

I don't have that option... It's possible it's an organization rule. I'll add write access for you for now and see what I can do about getting that checkbox back. Apologies!

[thinkyhead]

Finally getting to a review of this submission….

It's an interesting diagnostic addition. Of course it should be pretty obvious to the user that homing failed merely by looking at the printer. What extra benefit is provided by this feature? Could it provide a suggestion for a better Stallguard sensitivity value or automatically tune the Stallguard sensitivity?

Some other firmwares (e.g., Prusa) include an automatic procedure to read the Stallguard while moving the axes at different speeds to find the range of sensitivity values that occur during normal motion. Something like that would be a more thoroughgoing approach to Stallguard tuning and would fit with our long-term plan to provide a suite of first-time setup procedures.

[arades79]

Yeah, the use case for this was mostly automated testing. I used it in tandem with a script that would send the printer to random coordinates, home, and then check if any of these sanity check messages occured. It would run a hundred or so iterations and then I'd be left with a log that would tell me the number and type of failures so I could tune the parameters and try again.

I agree though, an automated proceedure would be a better solution and fulfill most of the same requirements (we'd probably still use something like this for stress testing though). When I wrote this I wasn't as comfortable in the codebase, but I could probably take up implementing an automated stallguard tuning proceedure now. I don't think it should live inside of G28 like this does, but maybe this could be a sub-feature of that autotuning.

Should I go ahead and try to implement that auto tuning in this PR, or should it be a separate one?

[thinkyhead]

Should I go ahead and try to implement that auto tuning in this PR, or should it be a separate one?

You can push it to this PR if you want.

I'm not sure how Prusa Firmware (and others?) implement this kind of test, or whether there is a G-code connected with it. Of course we can peek at Prusa Firmware to see what they're doing. Anyway, I have some basic suggestions and thoughts off the top of my head….

• Since this would be testing Stallguard in an unknown situation, perhaps even before any G28 (since a working Stallguard is required for G28 in the first place), the first thing to do might be to move the axis slowly in the direction away from the endstop and examine the stall feedback from the driver (if possible). I'm not aware (yet) whether we can get a number back from the driver indicating how close it is to stall, but that would make it easiest. We could tell from any large jump in the value that it hit something.
• If we can't monitor the torque/intertia directly, then we'll just have to set the sensitivity to various values and see when it produces a DIAG signal, starting somewhere in the "normal" range for a stall. So… starting with some sensitivity value that is known to trigger DIAG only when the motor is hitting a solid object, and then try to home the axis at a relatively slow speed. We might have to accept some amount of grinding.
• Marlin doesn't exactly have existing utility methods to do this sort of thing, so we'd have to invent them as we go. At the moment, for endstop detection Marlin turns on an endstop flag and enables endstop interrupts, then does a move in the homing direction. The move gets automatically canceled when it "hits an endstop" so we don't necessarily know where the axis was in the long move when it stopped. However, we can look at the raw stepper position and convert it to mm at that point. So it should be possible to make something "smarter" out of that, if at all needed.
• Anyway, once we are certain that the axis is truly homed, then the axis can move into the middle and do some speed/acceleration tests to see how much the driver can handle in terms of speed and acceleration before it throws a false-positive. That would give us a good idea where to set the feedrate and acceleration for the fastest homing, and then it can determine the best sensitivity for most accurate homing during the slower bump move. I don't think we currently vary the stall sensitivity for the fast move versus the bump move, but that might be a good addition to get better sensorless-homing accuracy.
• As for sensorless probing, there is much danger of damaging the machine during any automated testing. So if any testing of the Z stall sensitivity is going to be done, it should be towards the other end of the axis where it cannot damage the bed. We'd want to know how close we can get to a false positive without actually triggering it and then use the highest sensitivity that we can. The position should definitely be "known" as much as possible before doing any actual sensorless probing, so that the Z axis can stop before it goes even a full millimeter below the bed.

I leave the details up to you, but drop in on the Marlin Discord if you have questions or want to get feedback or show your progress.

[arades79]

Just bumping to say this isn't abandoned, I have an implementation for sensorless homing autotuning, but I need to do some cleanup before I can cherry pick it here