BLTouch probe deploys to soon when moving up between grid probes

dc42

The R parameter in the M558 command commands a delay between reaching the XY coordinates to probe and starting the probe move. You could also reduce the travel speed, which is the T parameter in the M558 command.

Scachi

I have tried the R parameter. The R does a pause before the Z move/probe moves down.
This is the wrong place for the pause I need.

My problem is the move up directly after the probe was triggered on its down move.
In this move upward, the probe is getting redployed to soon, hitting the bed again. sometimes.
I need a pause, not for the move, but for the deploy of the probe.
Or better, the probe deploy should wait until the z move upwards has finished, so it has enough space to deploy without hitting the bed.

dc42

I believe the redeployment is controlled entirely by the bltouch itself. What does the manual say about redeployment?

Scachi

Okay, I didn't think about that. You are right that the bltouch seems to do its own redeployment.
I'll try to play around with the probing speed and see if I can get it working more reliable this way.

Is it possible to probe the grid on my own and store the values as a grid in a (long) macro ?
This way I could do my own deploy/retract timings.

dc42

The movement back up to dive height after probing a point will be at the lower of the travel speed you specify in the M558 T parameter and the maximum Z speed that you specify in M203. Perhaps you need to increase one of those?

Scachi

Thank you very much, tuning those values seems to fixed my problem. The redeployement no longer touches the bed.

claus57

@Scachi Hi, I know it's a hold thread but I have the same problem. Can you tell me how you solved it?

Phaedrux

@claus57 how fast is your probe dive speed, your travel speed, and your max z speed? One or all of those may need to be increased to allow the BLTouch enough space after a probe move to deploy the pin.

dc42

Firmware 2.01 should have solved this.

claus57

Thanks Scachi and dc42 for your fast response.
Unfortunately I bought my A6 3 months ago without any previous experience on 3D, I'm a noob and I have some problem to understand your tips.
I installed with success Marlin 1.1.8 and BLTouch (clone) works but with alternate results and I suppose becouse of this bouncing.
On printer LCD I read: Vmax X & Y =400; Vmax Z=4; Vmax E=25 Are these the values I have to change? Or have I to use Pronterface to send some commands? And what could be correct values?

@dc42 I suppose you are speacking about original Anet firmware, I searched for it but unfortunately it seems scarce.

claus57

Searching in Marlin with Arduino IDE, in configuration.h I found this line that confirm LCD information:
#define DEFAULT_MAX_FEEDRATE {400, 400, 4, 25}
but I found nothing about M558.
Reading about parameter of m558 instruction I found this:
Rnnn - Z probe recovery time after triggering, default zero (seconds)
It seems could work to stop bouncig but in any case I have no idea about the value of parameter I could use and actual T value.

claus57

I tried to send m558 r1 and m501 and nothing changed.

adavidm

@claus57

This forum is dedicated to Duet3D based hardware (Duet WiFi, Duet Ethernet, Duet Maestro, etc) and software (RepRapFirmware, DWC). It looks like you are trying to to configure a Marlin-based printer instead. The methods for configuring Marlin and RepRapFirmware are completely different and it's unlikely that the advice given here is directly applicable to your use case.

The MAX_FEEDRATE parameter places physical constraints on how fast the various axes move under normal operating conditions. The Anet A6 is a cartesian printer which will have a relatively slow Z axis, so tweaking this value might not be a good idea.

Out of interest, are you using the Anet A6 example configuration file? It can be found in the repository in the examples folder, e.g.

Marlin/example_configurations/Anet/A6/Configuration.h

In there, you can see the following:

// Feedrate (mm/m) for the first approach when double-probing (MULTIPLE_PROBING == 2)
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z

// Feedrate (mm/m) for the "accurate" probe of each point
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 3)

So the fast probe feedrate is equal to the Z homing feedrate and the slow probe is 1/3 of that. Looking further up the file, the HOMING_FEEDRATE_Z is defined here:

// Homing speeds (mm/m)
#define HOMING_FEEDRATE_XY (50*60)
#define HOMING_FEEDRATE_Z  (4*60)

Assuming you have not altered the default 5mm/s MAX_FEEDRATE, you could increase HOMING_FEEDRATE_Z to 5*60 and see if that's enough to get the probe to clear.

Beyond that, I think you'll need to seek guidance from a Marlin / Anet expert as I simply don't know what the Z axis is capable of. Plenty of people seem to have added the BLTouch to the A6 / Marlin combination, so it must be possible.

Good luck.

adavidm

p.s. In that file there is a configurable delay for BLTouch probes:

//#define BLTOUCH
#if ENABLED(BLTOUCH)
  //#define BLTOUCH_DELAY 375   // (ms) Enable and increase if needed
#endif

and it looks like there is an option to tweak that value in realtime from the LCD/Encoder so no need to recompile to test.

claus57

Thanks a lot for your tips, I will try them asap and I will tell you if they work.
Excuse me for the wrong place I posted the issue. I found the post with Google and I didn't noted it's Duet dedicated focusing my attention on Bltouch.

Phaedrux

@claus57 Thanks for stopping by Don't feel like you need to leave just because you don't have a Duet. A more general place to seek help would be the RepRap Forums or the 3D Printing subreddit.

claus57

@adavidm
Thanks again for your interest, sadly nothing solved problem. I brought the value BLTOUCH_DELAY to 1000 without results. Then I tried with HOMING_FEEDRATE_Z before with 5x60 an then 6x60. Probing speed is visibly increased but issue persist. I think I will buy an original BlTouch.