New "Near" endstop, allowing homing at full speed

Features
21

This is very simple. If you want a new feature, you have three options: 1. Implement it yourself. 2. Convince someone else to implement it for you. 3. Live without it.

If #2 is your objective, sarcasm and a sense of entitlement are likely to be counterproductive. As has been explained, you’re more likely to convince a volunteer developer to take on this project if you can demonstrate that the proposed change will have a “‘high impact’ benefit to real-world users performing real-world tasks.” So far, based on the discussion in this thread, it does not appear that the feature you are proposing would provide a non-negligible benefit to a significant number of users. And again, being snarky probably isn’t going to change anyone’s mind.

2 Likes
22

Save the lecture. GO READ THE THREAD FROM THE TOP AND SEE WHO POSTED THE FIRST SMART ASS REPLY. LECTURE THEM.

23

I think you’re missing the point. I’m not policing forum etiquette, I’m simply pointing out that you’re the one asking for a favor so it’s in your best interest to come across as someone people might want to help.

1 Like
24

I still don’t understand the motivation. You can, as previously pointed out, do homing while the bed is heating up and it will almost certainly complete first, so the status quo is not slowing anyone down. Why complicate things for no gain?

1 Like
25

So if the suggestion is taken to leave the heaters on, where does the homing time get buried?

Plus did you miss the point where Klipper is used for other types of machines that don’t use any type of initial heating, i.e. mills, routers, pens, lasers, engravers, etc. Those don’t have heating times.

26

I think you are misunderstanding my post . I’m not asking for any “favor”. If I want the feature I’ll implement it myself. Decades of sw development , I don’t have to grovel.

27

Ok, my mistake. Carry on.

1 Like
28

This might be the first part I agree with, I 100% most likely posted the first smart ass reply with…

29

I use endstop at the far end of the Z axis and homing 40 cm takes quite some time.
I was also annoyed by it, but it seems to me that the proper way of doing it would be to set the end stop not at the very end, but at 1 cm before it (for example optical endstop which stays triggered until the end) and use a high initial homing speed, and a lower secondary speed “second_homing_speed”.

Is it needed to change the firmware?

The same approach applies when homing at z=0! Just place the endstop at Z=10mm.

30

That approach would not work if the endstop hw could bottom out, such as with a typical microswitch. Overshoot due to latency from endstop trigger to stepper stop at full speed would do that. Plus wouldn’t you lose usable axis length?

31

Yes if there is bottom out you are out of luck.
But if the microswitch (with a lever) detects not the front of the carriage (or whatever, I mean the face getting close to it) but the side, the carriage would not crash into the endstop.

But obviously it’s done best with an optical endstop placed sideways, so that the flag blocking the light can keep moving through the slit between the two pillars (which is the correct way to do it anyway for optical switches).

Changing endstop to optical or placing it on the side should not be an issue since you mention tinkering/customising.

No you can define the position of the endstop at 10 mm (or Zmax minus 10 mm) and set the maximum motion extent to 0mm - Zmax anyway.
It’s only important that the endstop stays active between the trigger coordinate and the nearest end of the motion range.

32

So you configured Klipper so that Axis0-10 are legal moves, but does your slicer understand that? Most slicers have a Z offset setting but don’t have X or Y offsets so they will complain if you position the part at X0-5 - “Part is outside printable area…”

33

I think you are mixing stuff here.

From the config reference:

#position_min: 0
#   Minimum valid distance (in mm) the user may command the stepper to
#   move to.  The default is 0mm.
position_endstop:
#   Location of the endstop (in mm). This parameter must be provided
#   for the X, Y, and Z steppers on cartesian style printers.
position_max:
#   Maximum valid distance (in mm) the user may command the stepper to
#   move to. This parameter must be provided for the X, Y, and Z
#   steppers on cartesian style printers.

position_endstop has absolutely no impact on the slicer: it’s where the FIRMWARE expects the sensor to be, and it’s the coordinate the firmware “assigns” to the carriage/bed at the end of homing.

position_min and position_max is where the firmware ALLOWS the carriage to be, either as result of manual motion from web interface or as GCODE from the slicer.

Obviously the endstop it must be between min and max: if min is 0 and endstop is -5, you get an error.

The slicer usually assumes 0-max. The Z offset is likely translated in final Z coordinates, so if you have Z offset -0.5mm, the printer should be able to move to -0.5 mm.
Which is not an issue: it is always recommended to set the origin a couple of mm above the Z=0 (position_min=-2, position_endstop=0), so that if bed mesh or Z offset goes below 0 you don’t get a panic in Klipper.

Final remark

You can study and experiment using the config reference and my explanation, which should make things easier, but it’s pretty clear that the modification to the firmware has no reason to be.
You didn’t know, I see why you tried to solve the issue.

I’m more surprised none of the previous users/replies (many way more experienced than me) thought about this, when the solution was pretty evident from the first question already.
Move the printhead, home while eating, … sure they work, but they don’t solve THE issue at the core.
Correctly placing the endstop, and correctly setting up klipper, does.

And the topic becoming heated, this solution would have made things nicer and more relaxed :slight_smile:

34

My bad on reading the other poster’s replay too quickly and too early in the morning before coffee. It’s obvious from my replay I thought they were talking about using negative min_positions.

The majority of 3d printers use microswitches as their endstops. And they are directly inline with the toolhead or bed, so they will bottom out if the travel speed into them is too fast when homing, due to overshoot.

So what is the “Correct placement” in your solution for those, if you want to home at full axis speed? What Klipper config in your solution solves that?

35

If you have microswitches, what you ask cannot be done.

Only way is to place a flag on the side carriage/bed and replace the switches at the end with with optical switches on the side.

After all, even your proposal involves modding to add additional sensors on the side, or something that does not bottom up, so just do the modification which doesn’t require firmware changes.

See what I mean, from HyperCube Evolution by SCOTT_3D - Thingiverse

1024×768 75.9 KB

See the gray flag on the X rod? it goes between the two poles of the optical endstop at the end. Assuming you use a wide enough flag and place the endstop a bit farther away from the end of the motion range, you get what I suggest: it stays triggered from Xmax - 10 mm until Xmax and allows super fast homing.

Apply the same for the bed, rotating as required.

36

Endstops have different resolutions/accuracies. I want my final endstop to be the most accurate, where as a near_endstop can be “sloppy”. The mod I suggested gives the best of both worlds. Plus since the second homing would not be using the offset endstop, it would not matter if it doesn’t stay continuously triggered (10mm offset to 0mm).

There is a reason the “endstop phase” feature was added to Klipper, to get
maximum end stop accuracy.

37

I think everyone’s initial confusion to the question was based on two things…

#1.) Homing speed… I use hall effect endstops on x/y but that’s not really relevant (see #2).

My homing speed for x/y is set at 250 mm/s, which is probably a little too fast. I have a ~350mm^2 gantry. X/Y homing takes 1.4 seconds. (Not true, I’m dumb, 2.8 seconds max. I didn’t take into account they home in sequence)

Z probing is a little slower, I use a Voron tap, My z probe speed is 20 mm/s but my nozzle starting point is rarely more than 30 mm off the bed (sufficient to clear most simple prints). So 1.5 seconds to home Z.

Lets say another 2 seconds on the super slow movement end to position the probe for safe Z homing.

2 + 1.5 + 1.4 + 1.4 (per x and y) = 6.3 seconds MAX to home all my axis. Granted some people home at the extreme other end of their z axis but that’s rare, most people probe the bed.

Another edit to be thorough (I had to find a tape measure too)… My max Z height is ~430 mm.

So at the extreme end of all my axis.
and I’m way over estimating the Safe z movement cause full axis movement is only 1.4 seconds.

X full movement = 350mm / 200 mm/s = 1.4 seconds
Y full movement = 350mm / 200 mm/s = 1.4 seconds
Movement to Safe Z homing pos = ~2 seconds
Z full movement = 430mm / 20mm/s = 21.5 seconds
Total MAX movement time = 26.3 seconds

and I have only been at my max Z height maybe twice and that was only when testing something. Again, 99.9999% of the time I’m within 5 to 40mm of the bed and thus only a second or two to Z probe.

#2.) The endstops are, in general, a relative measurement. It just gives the firmware a “Starting point” reference for every other move. Every endstop of every variety is going to have variance.

Really the one that matters most in that regard is the z endstop/probe because it sets your height off the bed and affects print quality. So you might want to go slower with that, but like mentioned in #1, even then… We’re talking a second or two?

X/Y accuracy only matters if you’re literally using every square mm of real estate on your printer bed while printing and I mean EVERY square mm, otherwise who cares if you’re off a mm or two?

Move the printhead, home while eating

If your homing isn’t done by the time you take the second bite either you have an enormous printer or your setup is doing something extremely funky. Or you’re shoving the food in you rmouth.

1 Like
38

If a custom M600 filament change or some other pause turned X/Y steppers off (user maybe moves axises), homes and returns to the saved position, it would matter on the resume.

Z 20mm/s… What happened to “>5mm/s” = slop, from your multi-mcu homing post?

39

Rehome? You HAVE to rehome if you disabled your steppers and I meant a mm or two from a “cold” start on a print, the variance isn’t on the order of mm’s.

Most people don’t pause for long enough for the steppers to disable. If you do, you already screwed up because of that very thing. The only way you’re getting around that is positional encoders.

Z 20mm/s… What happened to “>5mm/s” = slop, from your multi-mcu homing post?

I fixed it.

40

Delta printers do home at the top.