Mesh probe movement optimization

j3d

Currently, when a point is probed, the head must move in X to the point, probe all the way down to the bed, then raise all the way back up, when it will move in X to the next point. This could be optimized by moving in X while simultaneously raising the head. I don't see an option to perform this using G29. I believe this modification could reduce probe times by quite a bit.

Phaedrux

How bout this?

j3d

Sorry, I should have mentioned that that diagram is viewed from the X-Z plane. Eg left/right is X and up/down is Z.

I don't quite understand your edit @Phaedrux. If you were using a probe such as a switch or piezo sensor, you would be dragging the sensor across the bed. The diagonals that I had included would allow the sensor to clear the triggered state by still utilizing the dive height. This is important when it comes to highly warped beds, or for any sensor that requires contact with the bed.

Edit: Oh, I think your suggestion may work for analog non-contact probes and beds with a low amount of warp, but it would fail for anything else.

Phaedrux

OHHHHH I see now what you mean. I thought you were talking about the XY movement between points.

DanS79

It would be really nice if something could be done to speed up probing.

for example,

If I generate this mesh

M557 X10:290 Y45:290 P21:21

with these settings

M201 X4500 Y4500 Z250 E1500                           ; Accelerations (mm/s^2)
M203 X24000 Y24000 Z1500 E3600                        ; Maximum speeds (mm/min)
M566 X1500 Y1500 Z120 E1500                           ; Maximum jerk speeds mm/minute
M558 P9 X0 Y0 Z1 H2.5 F180 T12000 A5 S0.02

It will take 16 minutes and 38 seconds to complete.

A substantial portion of that time is waiting on the Z moves. Upping the M558 Feed Rate above what it already is, doesn't accomplish much as it's already well into the realm of diminishing returns.

Phaedrux

@DanS79 well dive speed is a bit tricky because you're then affecting accuracy. Reducing dive height to the minimum and only probing at a density that actually matters would help more. The BLtouch is pretty sensitive to dive speed. Other probe types may be less. Even so, the faster you go, the harder it is to be accurate.

DanS79

@Phaedrux said in Mesh probe movement optimization:

@DanS79 well dive speed is a bit tricky because you're then affecting accuracy. Reducing dive height to the minimum and only probing at a density that actually matters would help more. The BLtouch is pretty sensitive to dive speed. Other probe types may be less. Even so, the faster you go, the harder it is to be accurate.

I've done several rounds of benchmark and found i could go as high as 300 without losing accuracy. Though at that speed it's frightening to watch. Dive height is about as low as i can go without risking the probe not deploying in time.

Something like Klipper touch mode would be a nice feature to add that would speed up probing regardless of how many points are being probed.

Phaedrux

@DanS79 said in Mesh probe movement optimization:

Something like Klipper touch mode would be a nice feature to add that would speed up probing regardless of how many points are being probed.

There actually was a post a while ago about getting that touch mode setup.

https://forum.duet3d.com/topic/14544/guide-to-marlin-s-fast-bltouch-probing-feature-on-duet?_=1615322157391

DanS79

@Phaedrux said in Mesh probe movement optimization:

@DanS79 said in Mesh probe movement optimization:

Something like Klipper touch mode would be a nice feature to add that would speed up probing regardless of how many points are being probed.

There actually was a post a while ago about getting that touch mode setup.

https://forum.duet3d.com/topic/14544/guide-to-marlin-s-fast-bltouch-probing-feature-on-duet?_=1615322157391

I'm aware of that thread. However @dc42's post made it sound like it wasn't advisable.

Phaedrux

@DanS79 said in Mesh probe movement optimization:

made it sound like it wasn't advisable.

For context, this is what he said:

Two words of caution:

RRF used to keep the BLTouch deployed throughout probing sequences. Unfortunately that doesn't always work. The reason is that when the probe triggers, it retracts the pin automatically. If it is then commanded to deploy again (by using probe type P5 instead of P9), then if the print head hasn't risen enough (or the bed dropped far enough) so that the pin touches the bed and triggers again, the BLTouch enters the error state. That's why we introduced probe type 9, which keeps the pin retracted until ready to probe the next point.

You should not call deployprobe.g or reractprobe.g using M98. Use M401 and M402 instead, so that RRF can track the deployment state.

For the first point, you would need to ensure a minimum dive height to allow the pin to actually drop completely.

dc42

@DanS79 said in Mesh probe movement optimization:

It would be really nice if something could be done to speed up probing.

for example,

If I generate this mesh
M557 X10:290 Y45:290 P21:21
with these settings
M201 X4500 Y4500 Z250 E1500                           ; Accelerations (mm/s^2)
M203 X24000 Y24000 Z1500 E3600                        ; Maximum speeds (mm/min)
M566 X1500 Y1500 Z120 E1500                           ; Maximum jerk speeds mm/minute
M558 P9 X0 Y0 Z1 H2.5 F180 T12000 A5 S0.02
It will take 16 minutes and 38 seconds to complete.

A substantial portion of that time is waiting on the Z moves. Upping the M558 Feed Rate above what it already is, doesn't accomplish much as it's already well into the realm of diminishing returns.

@DanS79, I think the real reason for Z probing being so slow for you is that your probing speed of 180mm/min is so low. Does it need to be that low? Have you calculated the contributions to the probing time of the probing movement, the Z raise movement, and the XY movement?

Another option I can see is to first raise the probe by e.g. 0.5mm, then do the XYZ move to be above the next point.

DanS79

@dc42 said in Mesh probe movement optimization:

@DanS79, I think the real reason for Z probing being so slow for you is that your probing speed of 180mm/min is so low. Does it need to be that low? Have you calculated the contributions to the probing time of the probing movement, the Z raise movement, and the XY movement?

This is the default railcore config, and it would take roughly an hour and 40 minutes to finish generating the mesh for the M557 i posted above.

M558 P9 X0 Y0 Z1 H5 F50 T6000 A5 S0.02

I didn't run every possible permutation, but I decreased the drop height and increased the travel speed between points and the probing speed till I started to see a degradation in repeatability. 180 seemed to be a good compromise between speed and me worrying about crashing the machine.

Phaedrux

180mm/min is about the limit for the BLtouch. It's pretty sensitive to speed.

DanS79

This post is deleted!

DanS79

@Phaedrux said in Mesh probe movement optimization:

180mm/min is about the limit for the BLtouch. It's pretty sensitive to speed.

I was able to get up to 300, but above ~220-240 repeatability started to suffer. If memory serves above 270 I had to start increasing the drop height or I'd get

Error: Z probe already triggered at start of probing move

errors.

DanS79

For reference here's Marlin's equivalent to Klipper's touch mode.

https://www.youtube.com/watch?v=95N2E6JVW2s

I've not looked into it, but i know one member of the RailCore Community has, and he felt to properly/safely handle touch mode, error/alarm handling as it relates to probing would need to be reworked.

Stonebaker

@DanS79

; deployprobe.g
; called to deploy a physical Z probe

M280 P0 S10
G4 P200

wait for it to be deployed
as Z Endswitch i use 2000 on mesh 1000