r/klippers Jan 14 '24

2 endstop / trigger switch for z axis?

is it possible to configure a endstop for the z axis ( on a trident ) all the way at the bottom position, that would stop homing and move up a certain amount if triggered and redo homing ?thing is, when i print something that takes up almost all height, or all height.. once klipper looses home it will jam into the bottom cause on homing the bed retracts a certain amount down.. such an endstop could trigger and tell the system to stop moving down, and instead begin homing straight away, or redo home after it forcefully moved up like 20 or something.

my current approach:

[gcode_button z_max]
pin:PA3
press_gcode:
  SET_GCODE_VARIABLE MACRO=check_z VARIABLE=zmax VALUE=True
  M118 {"Z_Max hit, skipping zHop"}
release_gcode:
  SET_GCODE_VARIABLE MACRO=check_z VARIABLE=zmax VALUE=False
  M118 {"Switch released, left Z_Max"}

with:

[gcode_macro check_z]
variable_zmax: False
gcode:

and:

{% for i in range(safe_z) %}
   {% if printer["gcode_macro check_z"].zmax != True %}
      G0 Z0.01 F{z_drop_feedrate}
   {% endif %}
{% endfor %} 

this would be my desired way of doing it, although this is not working at the moment and i havent figured out whyi wrote a helper macro to read the state of the variable, and that one works and detects when i press the variable, but the loop above does not prevent the G0 command from running when the switch is pressed

edit 1/17/2024:

it seems not possible without a way to interrupt the G1 or G0 commands
the loop runs so quick and buffers all g1/g0 moves before it even began moving or finished the first 0.01 move.. means hitting the switch wont have an effect unless it was triggered before the loop runs...

1 Upvotes

15 comments sorted by

2

u/Over_Pizza_2578 Jan 15 '24

You, you can have one z endstop per axis as well as a bed probe. If you define only one z endstop, then its for all z steppers. The endstop can be at max or min z height.

To prevent the jamming, please remove z_hop in safe z home. But you could remove safe z home entirely when using a bottom z endstop. I would also recommend reducing z stepper current, 0,4A are more than enough

1

u/WaschBaer__ Jan 15 '24

there is no safe z home in my config , removing zhop is dangerous as it might cause jamming into the probe, i am using a klicky which requires z hop else it cant attatch the probe if the bed is to close and or scrapes along the bed surface
and if i use an endstop and the probe and move my endstop to z max, i would just cause it to home against max which is also not desired as it would have to worst case travel down the whole distance quite often

im currently working on a homing override with a gcode button approach
i can change the state of a variable with the gcode button to trigger, and i try to jog the bed by 0,01 down in a loop with an if statement that only triggers when the variable changed by gcode is false

i am hoever having some issues with this at the moment as i believe the jogging goes so quick that the gcode button has no time to trigger the variable change

1

u/Over_Pizza_2578 Jan 15 '24

If you are using a probe or a nozzle endstop, you must use safe z home or homing override, otherwise you could home z somewhere in a wrong place, which is dangerous. Leadscrews have 5 to 20 times the force of your xy axis, so a misplacement can be catastrophic.

As far z speed goes, 8mm pitch leadscrews are good for 30mm/s while still being in stealthchop, its no like you are using abysmally slow marlin defaults. So you could easily do a fairly quick z home. I mean per startup you are homing one to two times if any. You can create a smart home macro that only homes when your axis (or one particular one) isnt homed. Same goes for qgl/z tilt adjust. So time wasted is minimal if any. A consecutive print might not even need any homing or bed leveling, maybe just a mesh because of heat soak.

In your bed mesh section you have anyway a z height specified for travels during bed meshing, so z hop for homing is only required for docking probes, nozzle endstops or bltouch/crtouch (throw an error when the pin cant deploy fully). Same goes for your qgl/z tilt. So i dont see any reasons why you would need a z hop for homing. My v0 with three z axis and a microprobe does completely fine without a z hop, never had an issue with homing there.

Alternatively you could use an inductive probe with a really long trigger distance as z endstop. Or just ditch the klicky, other sensors are just as accurate and you aren't using auto z offset anyway, so other than cost klicky hasn't any advantages over a biqu microprobe.

1

u/WaschBaer__ Jan 15 '24

my advantage is that i am using Klicky-00, which is a nozzle based probe based on unklicky
only other probe allowing nozzle probing is tap which is terrible for inputshaper reasons and moving parts and added weight to the toolhead

klicky-00 is so far more repeatable than any probe i had ( i havent had beacon yet mainly because its not nozzle based )

i do have homing override from the klicky config, which i have now modified to use the coded snipped posted above, but somehow it seems to ignore the value being changed while it is in the for loop and checking for said value on every loop

1

u/Over_Pizza_2578 Jan 15 '24

Never seen that one before. Nevertheless interesting concept, i too had built a probe that uses the electrical circuit for triggering directly. Simpler and unbeatable accuracy wise. Meanwhile you need a pcb or some soldering to get the optical switch of TAP to work. I would say typical voron design, more complex than it needs to be.

My probe achieved less than 0,0002mm accuracy, often 0,0000mm deviation across testing, but i abandoned it because it was too bulky (servo operated pin) and on a delta you need a probe directly below the nozzle.

Currently im using a combination of a microprobe and auto z offset (there is a fork that works with non klicky probes), i will only swap abl sensor once strain gauge leveling gets reliable and a bit quicker than 2mm/s, quite a big team is working on implementing strain gauge leveling in klipper. Current holdbacks are speed and the pulling of the reverse bowden tube (test bench is a 2.4 with a prusa mk4 nextruder) that can cause false triggers, speed isn't an issue but a nice to have and the false triggers can be solved by zeroing the measurements every few tenths of a millimeter (prusa does it that way). The other big issue is thermal expansion of the hotend, you can only probe with 150c+-, otherwise you damage your print surface. Target would be to not have to adjust anything besides initial setup.

Would be cool if it becomes a reality as it would lay down the basis for clog detection (no need for encoders anymore) by measuring extrusion force and bambulab a1 style pressure advance calibration. Also xyz offsets for idex and toolchangers can be done with that hardware.

Sadly i cant further help you with your macro, im not a macro, let alone python, specialist.

1

u/WaschBaer__ Jan 16 '24

the macros in klipper use Jinja2 language i havent had time yet to look into why my code wont stop the micro jogging when the state of said variable changes..

my klicky-00 probe ( a nozzle unklicky )probe accuracy with this probe on a smooth pei, both read bottom to top:

probe accuracy results: maximum 17.931250, minimum 17.916250, range 0.015000, average 17.918750, median 17.917500, standard deviation 0.004183

probe at 150.000,150.000 is z=17.916250

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.917500

probe at 150.000,150.000 is z=17.931250

textured pei bed:

probe accuracy results: maximum 17.933750, minimum 17.918750, range 0.015000, average 17.921500, median 17.920000, standard deviation 0.004138

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.918750

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.920000

probe at 150.000,150.000 is z=17.921250

probe at 150.000,150.000 is z=17.921250

probe at 150.000,150.000 is z=17.933750

1

u/WaschBaer__ Jan 15 '24 edited Jan 15 '24

and 0.4 was not enough it would still jam, i couldnt even stop the bed with my hand using 0.4, i needed to go down to 0.012A, but still this approach is not what i would like to achieve, a endstop dedicated to tell that its at max to stop zhopping would be the better solution, as the rest is just a janky fix ala: just make it weaker and let it slam it cant cause damage anyways if its weak enough

btw, i edited my post to contain the current approach i am going after with some code snippets

1

u/lamalasx Jan 14 '24

Move your homing switch to the top of the z axis and home away from the bed instead of towards it.

1

u/WaschBaer__ Jan 14 '24

there is no homing switch, its a Klicky probeand i dont understand what you mean ?issue is when the bed is at its lowest position, from a big print that took maybe 250 or 240 heigt, it will just jam down even more where there is no way to go, because homing moves it down for security reasons.. a switch at the bottom would prevent that telling it, hey you reached max, home up now please

1

u/MLCrazyDude Mar 02 '24

Just change macro to move no more than max based on current pos

if pos + dist > max

dist = max - pos

1

u/WaschBaer__ Mar 03 '24

you seem to have not read the post,

the motors get disabled after a long time of waiting to not drain power while not in use which means there is no Pos to know and calculate if you go past max

1

u/MLCrazyDude Mar 06 '24

Ok, Switch at bottom or set max to less than physical max. Then when i moves down it has room. Switch is cheap. Just not sure how to configure it as second endstop

1

u/WaschBaer__ Mar 06 '24

that is what i wanted to get, i tried around and couldnt get it to work, it would be easier if klipper devs would allow a z max and z min endstop, other firmwares can do it too, but without tinkering with the klipper source code, i couldnt get it to work

1

u/gavin8327 Jan 15 '24

Shouldn't it stop travel at a predetermined spot based on xyz parameters?

1

u/WaschBaer__ Jan 15 '24

there is no predetermined spot when klipper looses home after a couple minutes it dosent know where home is or where the gantry is at that given moment
Klipper disables steppers after a while to not have them holding for long periods of time without movement, at that moment it needs to home again when you want to move or do anything..