Homing and Z Speed adjustments
Heyho fellow Rats ^^
I am running Squirrelbrains belted z mod on my V-Minion - by now my Minion is running stable'ish , so i was looking into adjusting some settings regarding this.
The goal was to get the z-axis speed to 100mm/s at 1500mm/s² as a baseline with homing speed at 50mm/s while increasing the mesh z-axis movements aswell (using PAM).
what i found so far due to sifting through the homing, printer and some other cfg files is the following i put into my overrides section:
It does not seem to do anything though...
i also tried to adjust the variable the RatOS macro section uses to adjust the z_hop speeds by injecting corrected z_speed variables in printer.cfg
- which unfortunately also does not seem to work - it gets calculated at some point before MY override and thus is being ignored...
So i am reaching out to the Rat Hive-mind: Any ideas? 😅
32 Replies
Where did you add these, and are you running RatOS 2?
Because i use these myself. Running max_z_velocity 80, max_z_accel 1800, variable_macro_z_speed 80 on my v-core 400.
first two go into user overrides, the latter goes into the RatOS macro that's already there in printer.cfg.
firm-tanOP•2y ago
Yes, running RatOS 2, added all of them in the printer.cfg overrides!
Last time I changed something on a file that was not the printer. Cfg Klipper threw an error that some critical file was changed, so I thought that is not possible 😅
So... Do I add the variable_macro_xxx line at the end of the macro file itself which ends up in the printer cfg due to the include? Or does it go at a specific place in the printer cfg itself?
I have to say though that I only tested homing and meshing, where I could see no difference with the current changes. Only the macro part would apply to those I guess?
Thank you for taking the time 🙂
@miklschmidt
I left the [printer] part untouched in the overrides section, and added the
variable_macro_z_speed part directly at the end of the gcode_macros RatOS section.
it does seem to make absolutely zero difference in both the homing and meshing speeds.So the actual probing is
variable_macro_z_speed is the z speed used in RatOS macro's
Are the printer limits (ie, executed gcode won't exceed these values).
You only make changes to printer.cfgvariable_macro_z_speed goes here
printer and probe overrides go here:
For a complete overview of the macro variables you can change in v2, see: https://rat-os.vercel.app/docs/configuration/macros
Configuring RatOS Macros | RatOS
RatOS comes with a bunch of flexible predefined macro's that can be customized via variables. In your printer.cfg at the bottom of the Macro's section, you'll notice this:
firm-tanOP•2y ago
Nice, so after placing it in the macro section after your first suggestion i had everything right, except that i was changing settings which had nothing to do with what i actually wanted to achieve 
i was under the impression that the
was only for the non z moves while probing - which are fast enough for me ^^
i found that, i just did not realize this is something you are allowed to change in the actual section of the printer.cfg instead of the overrides 😅 Thanks for pointing it out anyway ofc!
i am just trying to find the probing speed of let's say a Prusa MK3 as a reference, because that's fast anough for me, and if a prusa can make it, my minion surely can do too 😬
i was under the impression that the
was only for the non z moves while probing - which are fast enough for me ^^
i found that, i just did not realize this is something you are allowed to change in the actual section of the printer.cfg instead of the overrides 😅 Thanks for pointing it out anyway ofc!
i am just trying to find the probing speed of let's say a Prusa MK3 as a reference, because that's fast anough for me, and if a prusa can make it, my minion surely can do too 😬for the superpinda i found 20 mm/s to be about the maximum before it starts getting too inaccurate
firm-tanOP•2y ago
that's interesting, the prusa i use which also has a super pinda, seems to be way faster than the minion - i think 20mm is what is set as the standard for the minion in RatOS? i read that number somewhere...
No it's 10 mm/s by standard
Actually no, it's 5 
slow!!
slow!!firm-tanOP•2y ago
then i'll just profit of your already invested time in this matter and set it to 20 mm/s 😉♥️
that is actually why i am looking into quickening this, it is WAY to slow as it is ^^
I know, first thing i change myself. The probe config needs to work with all generic probes and those cheap inductive ones don't like much more than 5-10.
With more z accel, higher bed mesh / z_tilt speeds and proper probing speed my 7x7 bed mesh on a v-core 3 400 takes just under 30 seconds to complete.
firm-tanOP•2y ago
i guess even on the leadscrewed minion on a super pinda you could get away with much higher speeds (than the 5 mm/s),
but for my belted-z mod this is just unbearable 😅
with these settings now, it seems to go down faster for the probing taps, the up movement of the taps is still slow though... wait,. i'll make a vid
firm-tanOP•2y ago
firm-tanOP•2y ago
what i am looking for is this:https://www.youtube.com/watch?v=grHYoGSeUYw
yeah you want lift_speed: 80 or whatever under
[probe] as well. See:
https://www.klipper3d.org/Config_Reference.html#probefirm-tanOP•2y ago
#lift_speed: it seems to be
that's the one
without # of course
firm-tanOP•2y ago
of course 😉
this did the trick, although it is still a far cry from the prusas speed 😅
Thank you very much ♥️
That prusa vid looks fast because there's barely any horizontal_move_z, you can lower that on
[bed_mesh] it just needs to be higher than your probe's, z_offset (plus, add atleast whatever your mesh variance is)
Then just bump your z_accel till you're happy 🙂
you prolly want to lower sample_retract_dist on [probe] toofirm-tanOP•2y ago
i was under the impression that you have to get higher than the actuation point of the probe - which is actually quite high. That is, because i think the probing is binary.
i'll play with it and give feedback here for future reference!
You do, on horizontal_move_z. On sample_retract_dist you don't.
And yes, standard inductive probes are indeed binary
firm-tanOP•2y ago
What standard_deviation value when doing an accuracy test did you regard as still acceptable?
Also interesting: when i do an accuracy test, the first two values are usually quite a bit off from the rest of the 8 probes, which are pretty close to each other.
Would be interesting if it was possible to do say 5 probes, discard the first 2 and average/median the last 3...
Example:
<0.005
try 15 mm/s speed
It looks like there's a bit of drift though.
You sure your pulleys etc are tightened properly in your belt drive? And that the belt is properly secured?
firm-tanOP•2y ago
usually i would say yes, but after the pulleys by now loosened themselves 3 times now even after using loctite and special grub screws, i wouldn't do that anymore 😂
although the values after the first three are well damn near enough to each other to be fine for the purpose
firm-tanOP•2y ago
I dug a bit deeper into the problem and found quite the interesting read. unfortunately it does not come to an conclusion, but there were/are several people observing the problem.
I am not asking for a solution at this point anymore, since it IS in a range that works well enough for the realtively forgiving process of 3D-printing, but i thought out of curiosity this would interest you anyway:
https://github.com/Klipper3d/klipper/issues/2509
GitHub
Probe accuracy: always higher z? · Issue #2509 · Klipper3d/klipper
Specs: Ender3 frame, SKR v1.3, genuine BLTouch v3.0, TMC2208 for xyz. When I run the PROBE_ACCURACY, it almost always returns a higher z height. Is that normal or expected? If not normal, what coul...
firm-tanOP•2y ago
What i WOULD like though, is some way to discard let's say the first two measurements out of 5 and only take the last 3 into account. this could actually make quite a difference, but seems only necessary for the first batch of probings...
For clarification: after i do the second and third PROBE_ACCURACY Test the numbers stabilise and actually have minimal deviation around the middlepoint, as can be seen here:
firm-tanOP•2y ago
You'd have to take that to the klipper team 🙂
firm-tanOP•2y ago
thanks for your attention here, i'll mark it as solved ♥️
Well, fuck the Klipper Discord i'd say.
Asked the same question over three days, even got moved into different channels, but it's being ignored completely. Kinda similiar problem like here with no support channels, but also a lot more people on top of that.
Something i have to get a software friend of mine set upon😅
You kinda have to get it merged into klipper mainline. The discourse is a better place for feature requests like that. Klipper Discord is mainly a help server, and they can't help you since the feature you want does not exist.
firm-tanOP•2y ago
good tip, i'll look into getting to the right place for this. Thanks =9