[BUG] Accumulating microstep shift during probe moves related to endstop oversampling

General Discussion
3

I’ve spent many hours researching this issue and unfortunately I am not able to reproduce a problem. In conversations with @Arksine, he has also spent time on this and is also unable to reproduce a problem. So, at this point, we need more information to track down the cause. I am definitely interested in identifying and fixing any problems in this critical area of the code.

We can both readily reproduce the consistent microstep shift occurs between trigger and halt positions during probing however we can not reproduce a problem resulting from that. It is normal for these two internal positions to be different - it’s why the code tracks two positions.

It would help to have the full Klipper log from an event. With the full information in the log it can help me locally recreate a closer replica of the impacted printers. Unfortunately I have not yet had access to a complete log.

It would also help to run some simple tests to check for a “shift accumulation”. The process is pretty simple - add the following macro to the printer.cfg and run it:

[gcode_macro TEST_MICROSTEP_DRIFT]
gcode:
    G90
    G1 X50 Y50 Z25
    M400
    GET_POSITION
    DUMP_TMC STEPPER=stepper_z

    PROBE SAMPLES=70

    G1 X50 Y50 Z25
    M400
    GET_POSITION
    DUMP_TMC STEPPER=stepper_z

During the above test, record the text reported from GET_POSITION and the MSCNT report from DUMP_TMC (eg, MSCNT: 0000003b mscnt=59). The key to the test is that the reported positions from the pre-probe report and the post-probe report should be identical. These commands report Klipper’s position tracking and the stepper motor driver’s position tracking. A “shift accumulation” will show up as a deviation between the two sets of values. A deviation generally indicates that Klipper has an internal error.

If a deviation is reported then I definitely want to see the full Klipper log from the event.

It may also be the case that a simple PROBE doesn’t reveal the problem. (At this point, we can’t reproduce so it’s hard to say for sure what is causing the problem.) Feel free to run other probe commands to see if some other sequence generates the result. Just make sure that the intervening commands don’t purposely change the internal positions (eg, don’t run G28, don’t run QUAD_GANTRY_LEVEL, Z_TILT_ADJUST, FORCE_MOVE, SET_KINEMATIC_POSITION, use a SET_GCODE_OFFSET, activate a bed mesh, or similar) and make sure to always return to the same position after probing (eg, G1 X50 Y50 Z25) prior to running GET_POSITION.

If a problem is found, best to issue an M112 command and then attach the full log here. (Details for generating the log are at Contact - Klipper documentation ).

-Kevin

EDIT: New updates to test macro from garethky.