Manual_stepper BUG

[retnel]

Hi I found and identified what I consider a bug with using manual_steppers. Pertinent config and macro info below, then the issue. It is really not something the klippy.log would have, so no real need to upload it.

As configured in my printer.cfg:

[include macros.cfg]

[manual_stepper stepper_u]
step_pin: EBB_000:PD0
dir_pin: EBB_000:PD1
enable_pin: !EBB_000:PD2
#endstop_pin: EBB_000:PB6
microsteps: 16
rotation_distance: 40
endstop_pin: !PB10

As configured in my macros.cfg:

[gcode_macro HOME_U]
gcode:
  # we tell klipper stepper_u is at position zero, then we move to an impossible negitive distance to home
  MANUAL_STEPPER STEPPER=stepper_u SET_POSITION=0   # We give it a starting point
  MANUAL_STEPPER STEPPER=stepper_u ENABLE=1 MOVE=3 SPEED=5 # If it is already touching the endstop, we move it up to make sure it is not.
  MANUAL_STEPPER STEPPER=stepper_u ENABLE=1 MOVE=-200 SPEED=50 STOP_ON_ENDSTOP=1 #Here we tell U to move to a negitive position well beyond the endstop to ensure we hit it, then we stop. Fast moving.
  MANUAL_STEPPER STEPPER=stepper_u SET_POSITION=0 # We are at the endstop, and that is positon zero, so we set it again.
  # below is an attempt to increase endstops accuracy. 
  MANUAL_STEPPER STEPPER=stepper_u MOVE=3 SPEED=5 # We move up off of the endstop slowly.
  MANUAL_STEPPER STEPPER=stepper_u SET_POSITION=0 # We are homing so we set the possion to zero again.
  MANUAL_STEPPER STEPPER=stepper_u ENABLE=1 MOVE=-200 SPEED=5 STOP_ON_ENDSTOP=1 # Here we tell U to move to a negitive position well beyond the endstop to ensure we hit it, then we stop. Fast slowly.
  MANUAL_STEPPER STEPPER=stepper_u SET_POSITION=0 # We are at the endstop, and that is positon zero, so we set it again.

This is were the bug is:

MANUAL_STEPPER STEPPER=stepper_u ENABLE=1 MOVE=-200 SPEED=50 STOP_ON_ENDSTOP=1

Even if the endstop was hit at lets say -10, you will still have to wait for the time it would take to go the entire -200. If we are telling it to stop at the endstop, then it will stop and move no father anyway, so it should just exit the move at that point and continue executing.

If I set the speed to SPEED=100, it is almost undetectable, but I really do not want that stage moving that fast, ever. 50 is really too fast as well. I tested it multiple times, and I am sure what that is the reason for the long pause. If you would like a video o f it, please just let me know and I will provide it. If you use my macro, you will see the delay I am describing easily.

System info:

[jakep_82]

I believe this is intended behavior, not a bug. Have you tried using SYNC=0 as noted in the documentation?

https://www.klipper3d.org/G-Codes.html#manual_stepper

[retnel]

I did not, but I did not think I had to. I will give it a try when I am back working on that printer. I will let you know when I try it if it worked or not.

Thank,
/retnel

[EddyMI3D]

Please be careful not to call everything that does not work as bug.

[retnel]

Please read what I wrote again, please. I said I “considered” it a bug becasue I fix stuff like that when I write code. I did not say it was a bug. Bugs are just a part of coding, just like editing and proof reading is part of writing the written language.

Bugs happen, even things we originally consider not to be bugs later are redesigned to remove the issue.

I appreciate the manual_stepper feature, but realistically “if” I say stop at endstop, and it does, then I have to wait out the moves it was instructed to not make, then if it has the unintended effect, and I can not code it out using the klipper language, then it is a bug. It is why break;, try;, and exit; were invented. If this happens, then break out becasue there is no reason to continue executing code that isn’t doing anything but eating up processing time. That is the definition of a bug. It is not a bad word or an insult to anyone.

Similar to something like this:

########<If Settings are found we can stop looking for them>           
        else:
           if (readfile_line.lower().startswith(lChange)):
              Layer_Change = True
              #print("lChange")

           elif (readfile_line.lower().startswith(tChange)):
              Tool_Change = True
              Tool_Reorder_XYZ = True
              print("Q-tChange")

If it was perfect the first time every time, then programmers would be out of work. I have fired programmers before becasue they would say stuff like Steve Jobs did when they made the iPhone with the bad antenna. He would say the customer was holding it wrong. His version of calling someone a fool.

I am being told how to think, that is not my style.

I wish people would “read” what I wrote and not put their intentions on it.

I program, and I am super critical of myself as well. I spend three times as long writing in error handling and log feedback so the person using my free code get the very best. When I do it for free, I still do it like I am being paid a premium to do it.

I am not trying to hurt anyone’s feeling, but constructive criticism is very important. None of us can think every situation out and have all of the answers in the first design.

You will see 10x paths to gcode files I intentionally broke to make sure all of my features worked, and if the “fool” forgot to give a setting, it would write the error to the gcdoe file and *.ERROR it so they would know, and could read it.

H-Series_gCode_PostProcessor_V1.8.zip (7.5 KB)

I am not god’s gift to coding, but I do understand it better than most. I have only been in klipper configuration for 3-weeks tops. I think the way I am explain things should help yo understand I have coded a thing of two in my 48-years of life.

It is always an uphill fight to get to #3…

Respectfully,
/retnel