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:
max_z_velocity: 100
max_z_accel: 1500
max_z_velocity: 100
max_z_accel: 1500
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
[gcode_macro RatOS]
variable_macro_z_speed: 50
[gcode_macro RatOS]
variable_macro_z_speed: 50
- 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
miklschmidt
miklschmidtβ€’2y ago
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.
fascinating-indigo
fascinating-indigoβ€’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.
miklschmidt
miklschmidtβ€’2y ago
So the actual probing is
[probe]
speed: whatever
[probe]
speed: whatever
variable_macro_z_speed is the z speed used in RatOS macro's
[printer]
max_z_velocity: whatever
max_z_accel: whatever
[printer]
max_z_velocity: whatever
max_z_accel: whatever
Are the printer limits (ie, executed gcode won't exceed these values). You only make changes to printer.cfg
miklschmidt
miklschmidtβ€’2y ago
variable_macro_z_speed goes here
No description
miklschmidt
miklschmidtβ€’2y ago
printer and probe overrides go here:
No description
miklschmidt
miklschmidtβ€’2y ago
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:
fascinating-indigo
fascinating-indigoβ€’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 kekw i was under the impression that the
speed: whatever
speed: whatever
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 😬
miklschmidt
miklschmidtβ€’2y ago
for the superpinda i found 20 mm/s to be about the maximum before it starts getting too inaccurate
fascinating-indigo
fascinating-indigoβ€’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...
miklschmidt
miklschmidtβ€’2y ago
No it's 10 mm/s by standard Actually no, it's 5 giphyscream slow!!
fascinating-indigo
fascinating-indigoβ€’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 ^^
miklschmidt
miklschmidtβ€’2y ago
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.
fascinating-indigo
fascinating-indigoβ€’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
fascinating-indigo
fascinating-indigoβ€’2y ago
fascinating-indigo
fascinating-indigoβ€’2y ago
miklschmidt
miklschmidtβ€’2y ago
yeah you want lift_speed: 80 or whatever under [probe] as well. See: https://www.klipper3d.org/Config_Reference.html#probe
fascinating-indigo
fascinating-indigoβ€’2y ago
#lift_speed: it seems to be
miklschmidt
miklschmidtβ€’2y ago
that's the one without # of course
fascinating-indigo
fascinating-indigoβ€’2y ago
of course πŸ˜‰ this did the trick, although it is still a far cry from the prusas speed πŸ˜… Thank you very much β™₯️
miklschmidt
miklschmidtβ€’2y ago
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] too
fascinating-indigo
fascinating-indigoβ€’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!
miklschmidt
miklschmidtβ€’2y ago
You do, on horizontal_move_z. On sample_retract_dist you don't. And yes, standard inductive probes are indeed binary
fascinating-indigo
fascinating-indigoβ€’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:
14:19
PROBE_ACCURACY at X:90.000 Y:90.000 Z:15.020 (samples=10 retract=0.700 speed=20.0 lift_speed=50.0)
14:19
probe at 90.000,90.000 is z=1.243750
14:19
probe at 90.000,90.000 is z=1.283750
14:19
probe at 90.000,90.000 is z=1.292500
14:19
probe at 90.000,90.000 is z=1.292500
14:19
probe at 90.000,90.000 is z=1.293750
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.296250
14:19
probe accuracy results: maximum 1.296250, minimum 1.243750, range 0.052500, average 1.288250, median 1.294375, standard deviation 0.015209
14:19
PROBE_ACCURACY at X:90.000 Y:90.000 Z:15.020 (samples=10 retract=0.700 speed=20.0 lift_speed=50.0)
14:19
probe at 90.000,90.000 is z=1.243750
14:19
probe at 90.000,90.000 is z=1.283750
14:19
probe at 90.000,90.000 is z=1.292500
14:19
probe at 90.000,90.000 is z=1.292500
14:19
probe at 90.000,90.000 is z=1.293750
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.295000
14:19
probe at 90.000,90.000 is z=1.296250
14:19
probe accuracy results: maximum 1.296250, minimum 1.243750, range 0.052500, average 1.288250, median 1.294375, standard deviation 0.015209
miklschmidt
miklschmidtβ€’2y ago
<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?
fascinating-indigo
fascinating-indigoβ€’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
fascinating-indigo
fascinating-indigoβ€’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...
fascinating-indigo
fascinating-indigoβ€’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:
fascinating-indigo
fascinating-indigoβ€’2y ago
miklschmidt
miklschmidtβ€’2y ago
You'd have to take that to the klipper team πŸ™‚
fascinating-indigo
fascinating-indigoβ€’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πŸ˜…
miklschmidt
miklschmidtβ€’2y ago
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.
fascinating-indigo
fascinating-indigoβ€’2y ago
good tip, i'll look into getting to the right place for this. Thanks =9
Want results from more Discord servers?
Add your server