Marlin: BLTouch repeatability

[Grogyan]

I am using an old RCBugFix RC6 which I will change when Marlin goes 1.10
I recently did some experimentation on the BLTouch using M48 and found that the deviations are greater than 5 microns when either the heat bed and/or the hot end is on. Even got deviations as high as 80 - 90 microns.
The probe is marketed as having a deviation smaller than 0.005mm which is indeed true when the heat bed and hot end, and any other sources of EM radiation could interfere with probing. Including fans.

Not sure if the firmware could briefly turn off heaters, such to give a more precise probing measurement.

Anyway, leaving this here for anyone else who is having issues.

Easiest work around is to probe before turning on heaters in the startup gcode of your slicer of choice.

[Roxy-3D]

Yeah... But I actually do the exact opposite. I want everything up to temperature before I probe because the hot end dimensions and the shape of the bed do change a small amount with temperature.

It might not be too hard to turn off the heaters as we start the run_z_probe() routine, and then restore them after the point is sampled. That would not be too disruptive to the actual bed and nozzle temperatures. And given the BL-Touch is using a HAL effect sensor, it might help it give better results.

I think this is a good idea to explore.

[Tannoo]

I don't have a BLTouch, but heat does make a difference.

My cold (ambient: ~20) UBL probing results:

My PLA temp (H:195, B:50) UBL probing results:

I don't have any ABS to try. So, I haven't made a map for ABS temps.

Pre-heated the bed for 10 mins and probed again (H:195, B:50):

[bgort]

I've noticed this same problem, though I hadn't localized it to EMI. I think momentarily disabling the heaters and fans while probing is a good idea/solution. My "work-around" was to just verify the position of the nozzle wrt the bed manually (resetting with G92 if necessary), which doesn't have to happen all that often at this point (I was using mesh leveling, and now UBL, so there's really only the one G28 when I turn the printer on for the day).

I've also seen similar heat-expansion-related changes in bed topography; even sat and watched the bed change with a micron dial indicator. At several positions I saw >1um/s change in the first minutes of heating, with overall/ending deviations similar to what Tannoo posted. Pretty neat. For me, more-or-less complete stability comes after ~20 minutes of heating (bed temp sensor gets to 45C in minutes, most of the bed surface itself in 12-15, and minor expansion continues for a few minutes after that as the edges and other components finish heating), so I just wait roughly that long to do my G28 and nozzle position verification. (As a reference, I'm using a ~6mm thick piece of K100S cast/tooling aluminum with 0.010" PEI on top of that.)

What I'd really like, ultimately, is to fit my printer with a laser triangulation sensor. At that point, we wouldn't necessarily need to 'probe' anything -- just position appropriately, read the distance to the bed, compensate w/the z offset, and bam -- done. Most of the triangulation sensors have pretty high refresh/output rates, so with UBL you could very nearly just move around the bed continuously and generate a 30x30 mesh (we're going to need to use those 8-bit ints, Roxy!), or whatever, in almost no time.

I priced out this little guy and he's ~$1k, unfortunately:
http://www.micro-epsilon.com/displacement-position-sensors/laser-sensor/optoNCDT_1320/

And then you'd need an RS-422 converter and another 'duino (or something) to convert sensor output into something Marlin can use. Or could possibly use the RPi that some of us are using with another interface (there's a USB adapter). EDIT: Suppose we could use the analog out and simply read it with Marlin directly; probably easiest/cheapest.

I may end up trying this, but am not quite there yet.

[Roxy-3D]

@Tannoo for sure with ABS temperatures, you will see more dramatic results.

For me, more-or-less complete stability comes after ~20 minutes of heating (bed temp sensor gets to 45C in minutes, most of the bed surface itself in 12-15, and minor expansion continues for a few minutes after that as the edges and other components finish heating)

Yeah... That is why I'm a big fan of the Z-BabyStepping and being able to Double Click to get to it. I don't want to wait that long to start a print. But I want the first layer to get good adhesion!

What I'd really like, ultimately, is to fit my printer with a laser triangulation sensor. At that point, we wouldn't necessarily need to 'probe' anything -- just position appropriately, read the distance to the bed, compensate w/the z offset, and bam -- done. Most of the triangulation sensors have pretty high refresh/output rates, so with UBL you could very nearly just move around the bed continuously and generate a 30x30 mesh (we're going to need to use those 8-bit ints, Roxy!), or whatever, in almost no time.

Yeah! We need to find what is causing that damn memory corruption. Then we can go use every last bit of memory. And... We need the code changes to store (and use) the mesh as 8 bit ints! And we need a 32-Bit version of Marlin so all this non-sense just goes away.

[bgort]

Yeah... That is why I'm a big fan of the Z-BabyStepping and being able to Double Click to get to it. I don't want to wait that long to start a print. But I want the first layer to get good adhesion!

I've still never tried babystepping. I'll have to at some point.

Yeah! We need to find what is causing that damn memory corruption. Then we can go use every last bit of memory. And... We need the code changes to store (and use) the mesh as 8 bit ints! And we need a 32-Bit version of Marlin so all this non-sense just goes away.

Hah! 32-bit will be nice. What's the status of that, anyway? I've not checked it in quite some time.

[bgort]

I just spent some time looking through the probing, temperature control, fan control, etc. code, and think I can put together an experimental 'pause anything that may create EMI' and 'resume everything that was paused' feature for BLTouch users without too much trouble. Maybe I can squeeze this in tomorrow. We'll see.

[Grogyan]

@bgort At the moment, I would rather see attention focused on getting the UBL fixed, so that there aren't any more delays in Marlin going 1.10

Something like adding a pause can be looked at after the release. I am in no rush for this, as I am still using an old RCBugFix RC6 in the meantime.

[mperdue]

Not that it really matters but I agree that getting 1.1.0 released should be the priority. Those of us with BLTouch setups can certainly wait awhile to get this and menu issues addressed in the next RC cycle.

[Roxy-3D]

Not that it really matters but I agree that getting 1.1.0 released should be the priority. Those of us with BLTouch setups can certainly wait awhile to get this and menu issues addressed in the next RC cycle.

I certainly understand your feelings. But the problem isn't that simple. People work on things that interest them because this is all being driven by the hobbyists. And even though I'm philosophically opposed to new features appearing in a 'Release Candidate', this is very low risk and of substantial value. If a Pull Request shows up that implements this prior to RC-8's RCBugFix going Golden... I'll carefully review what it does. And if I'm very certain it doesn't break anything... I'll merge it.

With that said... I'm pretty sure RC-8's RCBugFix is going Golden within a couple weeks.... Please don't get too hung up over the question of whether or not 'Proper Protocol is being observed...' Very very soon... We will have a 'Stable Release' that just keeps getting more and more bug free. We are almost there. You can see the light at the end of the tunnel.

[mperdue]

I believe you may have taken my comment as sarcasm and it wasn't meant to be taken that way. I truly do agree with the approach you are taking and I truly do believe that we can wait for the BLTouch changes. The preface "Not that it really matters..." was only to indicate that I am not one of the programmers working on this so I don't have, and don't expect to have, any say in it.

Anyway, sorry if it came across wrong. I think you guys are doing a great job and are on the right track.

[Roxy-3D]

No! What you said is fine! And actually... I do agree. Getting a rock solid stable release really is the most important thing. The problem is the people contributing are not getting a pay check. So there is nobody to 'manage' them and tell them what they have to work on.

But like I say... We are very very close to being ready to promote RC-8's RCBugFix to Golden Status. And at that point, people that want something that is very solid with very few bugs will have that as a choice. And people that want the latest and greatest new feature and can tolerate a little bit of pain will have a different choice available.

Mostly... The whole purpose of all that text up above is I expect somebody is going to choose to implement this feature. And when I merge it.... I didn't want you to feel like your opinions were ignored.

[mperdue]

It would be very difficult for me to say I feel ignored - I've seen things that I've mentioned implemented or fixed in very short order. For a non-paid group you guys are doing well. I, for one, appreciate all the work you guys are doing for us.

[cbusillo]

Grogyan, what are you using to control your heat bed?

[Grogyan]

Just an ordinary RAMPS Hi current FET.
Also tried, same result, with an SSR

[cbusillo]

Are you using bang bang or PID? Is your PID tuned? Can you post a graph of your temps? Initially my bed temps fluctuated enough to cause measurement issues on the level you describe.

[Grogyan]

Just Bang bang.

Can't post a graph right now as I am still at work. However there is no
fluctuations that I could see.
I do have a power supply issue for the bed, which I am getting to root
cause of. However this is unrelated to the BLTouch, as the Bed is
utilizing a second power supply, 24V 15A, to deliver the the high current
needed for the bed.

The above experiment just goes to show ow much EMR the probe can sense
through glass.

[cbusillo]

I can only offer the advise that a rock solid (0.1C) bed temp greatly improved my repeatability. I have my bed heated before running G28/G29

[Grogyan]

You might need to check that, as only when the current is applied to the
bed, does the BLTouch pick up the EMF.
So if you are at temp, the switch for the bed turns off, thereby the
BLTouch does not pick up the EMF of the bed, because there is no current in
it.

To check this, do M48, while the bed is warming up

[Grogyan]

In addition, likewise, if just the hot end is turned on, and depending on
the proximity of the probe to the hot end heater, does the BLTouch pick up
similar EMF.

One caveat, I am still using an old version of the probe, Mk2, and have
already got in contact with Paris, about replacing the probe, as I was part
of the original Indiegogo campaign.
Once I receive the new probe, I can try out again, maybe the new version of
the probe is less susceptible to external EMF.

[Roxy-3D]

In addition, likewise, if just the hot end is turned on, and depending on
the proximity of the probe to the hot end heater, does the BLTouch pick up
similar EMF.

On my gMax, the BL-Touch is within an inch of the wires that feed current to the heater for the nozzle. I suspect if it is vulnerable to the bed current switching on and off, probably that is not good either.

[Roxy-3D]

I just spent some time looking through the probing, temperature control, fan control, etc. code, and think I can put together an experimental 'pause anything that may create EMI' and 'resume everything that was paused' feature for BLTouch users without too much trouble. Maybe I can squeeze this in tomorrow. We'll see.

@bgort
Did you decided to go ahead on this? If not... I may just mess around with this tomorrow. If I did this, it would be easiest to just do it for BL-Touch probes. The reason is if it was done for the general case we would need to add a new #define to make it an option and update 37 Example Configuration.h files and then try to document it so people can make inteligent choices about whether to enable or not.

If it is acceptable to just always turn off the heaters when the probe starts its decent and then turn the heaters back on immediately after the probed point for BL-Touch probes... That is fairly tame to do.

[Tannoo]

Would it help to just shield the BLTouch sensor?

[Grogyan]

@Tannoo Sadly, not that simple, as the probe is metallic and acts as an antenna directing the EMF up into the BLTouch, which the hall sensor picks up.
Shielding it also becomes difficult too as you need to have a ground loop attached to the shield for it to work.

A while ago, I shielded my thermocouple with a ground with copper tape, and that was quite fiddly. Fixed the stray EMI it was receiving though.

[Tannoo]

I don't have a BLTouch. I was just offering a possible solution to an electronic problem.

[Tannoo]

Although, the ground loop is not what you want. Groung that metal body to earth ground.

[Grogyan]

It is a valid solution. Though it won't help those with the probe and seeing weird topographical errors.
I love the probe, which certainly, IMO beats a number of other probing systems out there.

Another solution to the problem, probably even easier to implement than a 'pause' is to have inline gcode inside the G28 Z command, such that it does a rough Z home, lowers the probe to just above the bed, execute M280 P0 S120 for a few seconds, then do a fine Z home.

As I believe, I may be wrong on this, that the 'Self Test' (M280 P0 S120) is an auto calibration routine inside the probe to know the minimum and maximum trigger points.
With the probe pin at that close proximity to the bed when it does that, should, at least in my head, compensate for any deviation error from the induced EMF onto the pin.

Just for clarification, i'm talking about getting a better deviation than the thicknesses of a sheet of A4 paper, which is about 50 microns.

[bgort]

@Roxy-3D

Did you decided to go ahead on this? If not... I may just mess around with this tomorrow. If I did this, it would be easiest to just do it for BL-Touch probes. The reason is if it was done for the general case we would need to add a new #define to make it an option and update 37 Example Configuration.h files and then try to document it so people can make inteligent choices about whether to enable or not.

I did decide to do it, but after switching to Gentoo/arm64 on the RPi I use to compile, flash, drive my printer, etc., I'm having issues. avrdude is giving me random timeout errors when flashing, for some reason, though everything else seems to be fine. Once I get that sorted out I plan to work on this, or if you want to do it sooner that's fine too.

FWIW, my plan was to make it an advanced config. option and to flag it as experimental for now, but I hear you.

If it is acceptable to just always turn off the heaters when the probe starts its decent and then turn the heaters back on immediately after the probed point for BL-Touch probes... That is fairly tame to do.

Yeah, it didn't look bad at all, though I was going to 'pause' the fans too.

[Grogyan]

@Tannoo BLTouch doesn't have a metal body, injection molded plastic

[Tannoo]

Well, a faraday cage can be applied. Just sayin'.

[Roxy-3D]

That would probably work if the user grounded the shield properly. But how is that going to be done? Maybe the user could wrap tin foil around the probe. But then they would lose the ability to see the error light. My guess is most users would not want to wrap (and ground) tin foil on their BL-Touch probe.

[Tannoo]

Can use some shielding from a sheilded ethernet cable.

If foil is used, a small hole in it to reveal the internal led.

[mperdue]

A Faraday Cage doesn't require a solid cover, it can be done with a wire mesh. The problem is the metal probe will extend outside the cage and defeat it's purpose by conducting the interference inside the cage.

[Tannoo]

How about dipping that metal probe in some 'Chem-dip'?

[Roxy-3D]

Well... How about we just turn the heaters off for 1 or 2 seconds to sample the point? That might resolve everything!

[mperdue]

@Roxy-3D That sounds like the best solution to me.

[Roxy-3D]

If you go into Marlin_main.cpp and replace this function.... It should turn off the heaters during the actual sampling of the point. And then it will quickly turn the heaters back on. I believe you should see the LCD Panel say the heaters are turned off. Please use M48 to see if you get better results. If so... I'll merge the changes in and they should be available in the Golden Master release.

  static void do_probe_move(float z, float fr_mm_m) {
    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) DEBUG_POS(">>> do_probe_move", current_position);
    #endif

    // Deploy BLTouch at the start of any probe
    #if ENABLED(BLTOUCH)
      set_bltouch_deployed(true);

    // 
    // The BL-Touch probes have a HAL effect sensor.  The high currents switching
    // on and off cause big magnetic fields that can affect the reliability of the
    // sensor.  So, for BL-Touch probes, we turn off the heaters during the actual probe.
    // And then we quickly turn them back on after we have sampled the point
    //
      float temps_at_entry[HOTENDS];

      HOTEND_LOOP() temps_at_entry[e] = thermalManager.degTargetHotend(e);
      HOTEND_LOOP() thermalManager.setTargetHotend(0, e);

      #if HAS_TEMP_BED
        float bed_temp_at_entry;
        bed_temp_at_entry = thermalManager.degTargetBed();
        thermalManager.setTargetBed(0.0);
      #endif
    #endif

    // Move down until probe triggered
    do_blocking_move_to_z(LOGICAL_Z_POSITION(z), MMM_TO_MMS(fr_mm_m));

    // Retract BLTouch immediately after a probe
    #if ENABLED(BLTOUCH)
      set_bltouch_deployed(false);

    //
    // Turn back on the heaters for BL-Touch setups
    //
      HOTEND_LOOP() thermalManager.setTargetHotend(temps_at_entry[e], e);
      #if HAS_TEMP_BED
        thermalManager.setTargetBed(bed_temp_at_entry);
      #endif
    #endif

    // Clear endstop flags
    endstops.hit_on_purpose();

    // Get Z where the steppers were interrupted
    set_current_from_steppers_for_axis(Z_AXIS);

    // Tell the planner where we actually are
    SYNC_PLAN_POSITION_KINEMATIC();

    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) DEBUG_POS("<<< do_probe_move", current_position);
    #endif
  }

  // Do a single Z probe and return with current_position[Z_AXIS]
  // at the height where the probe triggered.
  static float run_z_probe() {

    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) DEBUG_POS(">>> run_z_probe", current_position);
    #endif

    // Prevent stepper_inactive_time from running out and EXTRUDER_RUNOUT_PREVENT from extruding
    refresh_cmd_timeout();

    #if ENABLED(PROBE_DOUBLE_TOUCH)

      // Do a first probe at the fast speed
      do_probe_move(-(Z_MAX_LENGTH) - 10, Z_PROBE_SPEED_FAST);

      #if ENABLED(DEBUG_LEVELING_FEATURE)
        float first_probe_z = current_position[Z_AXIS];
        if (DEBUGGING(LEVELING)) SERIAL_ECHOLNPAIR("1st Probe Z:", first_probe_z);
      #endif

      // move up by the bump distance
      do_blocking_move_to_z(current_position[Z_AXIS] + home_bump_mm(Z_AXIS), MMM_TO_MMS(Z_PROBE_SPEED_FAST));

    #else

      // If the nozzle is above the travel height then
      // move down quickly before doing the slow probe
      float z = LOGICAL_Z_POSITION(Z_CLEARANCE_BETWEEN_PROBES);
      if (zprobe_zoffset < 0) z -= zprobe_zoffset;
      if (z < current_position[Z_AXIS])
        do_blocking_move_to_z(z, MMM_TO_MMS(Z_PROBE_SPEED_FAST));

    #endif

    // move down slowly to find bed
    do_probe_move(-(Z_MAX_LENGTH) - 10, Z_PROBE_SPEED_SLOW);

    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) DEBUG_POS("<<< run_z_probe", current_position);
    #endif

    // Debug: compare probe heights
    #if ENABLED(PROBE_DOUBLE_TOUCH) && ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) {
        SERIAL_ECHOPAIR("2nd Probe Z:", current_position[Z_AXIS]);
        SERIAL_ECHOLNPAIR(" Discrepancy:", first_probe_z - current_position[Z_AXIS]);
      }
    #endif
    return current_position[Z_AXIS] + zprobe_zoffset;
  }

[Hubertusfan]

Yes, a fine and working solution

[Roxy-3D]

Did you test the code and is that what you are saying is a "Fine and working solution" ?

[Hubertusfan]

Excuse, i forgot to quote...

From my point of view as electronic engineer its the best solution to
switch of heating behavior probing (some second are long enough) and switch
on after. So there is no electrical noise which can disturb probe.

[Roxy-3D]

The code up above worked... But because we are turning the heaters on and off... I went more paranoid on the implementation. I just merged https://github.com/MarlinFirmware/Marlin/pull/6476

I get better M48 numbers... But to be honest, I never really had too much of a problem with my BL-Touch. It will be interesting to hear how much the changes help @Grogyan and @bgort !

[mperdue]

I may have to reinstall one of the older BLTouch probes that I replaced due to inaccurate measurements to see if they work properly with this change.

[bgort]

Will be a few days for me, at this point, but will definitely let you know. Thanks for doing it.

[Grogyan]

I have only downloaded the latest RCBugFix this morning, and updated the config files for my setup, should be able to test this some time later tonight

[Roxy-3D]

I have only downloaded the latest RCBugFix this morning, and updated the config files for my setup, should be able to test this some time later tonight

Before you update... Please do a M48 with the old one with heat bed and nozzles turned on. If it doesn't get better results for you... It probably makes sense to revert the changes....

[mperdue]

I should be able to test this tomorrow. I plan to first run M48 on the current setup while heating and not. Then I'll install the old one and repeat the tests. After that I'll update the firmware and test them both again. Don't be too quick to back this out. It could be that my old BLTouch is just bad.

[Roxy-3D]

No hurry to back it out... I did see an improvement in my BL-Touch numbers. But because of how my heat pad is made with the heating wires running back and forth, much of the magnetic fields being generated cancel out. And the wires feeding current to my nozzle are probably 2" away from the BL-Touch. So I'm not a worst case example.

I do believe this code does what it is intended to do. I'm just saying... If we don't see enough benefit, we don't want the extra complexity. Its up to the users with a problem to decide if it should stay in the code base.

[Grogyan]

Using the RCBugFix that I downloaded today, and comparing against the additional code in marlin_main.cpp
I saw a stable reading of ~4 microns with the bed and extruder off code
vs
Somewhat unstable of up to ~10 microns without the bed and extruder off code

This is by no means definitive

I still have more testing to do, without the SSR. Using just the FET to switch the bed.
Job for tomorrow.

But what I can say is, by golly M.O.M.! is RC8BugFix has improved from, what seems so archaic now, of RC6BugFix in July of 2016. You could almost put a 2.0 moniker on the released version, it's that improved.

[mperdue]

Using my current BLTouch with power off I get readings between 2.5 to 4 microns. Repeating with power to the bed on the reading vary between 6 and 15 microns.

After installing the new rcbugfix bed heating off was again between 2.5 and 4 microns. With bed heating on it was now also between 2.5 and 4 microns.

With my old BLTouch I discovered that is is, in fact, a very sick BLTouch... :-(

One other thing, I have a ViKi2 LCD with the LED that shows Red for a heated bed and Blue for a cool bed. That LED toggles between red and blue while M48 is running. It's not a big deal but it did catch my attention.

Anyway, this looks good. If we can get the BLTouch control sub-menu added it will address all my current needs.

[Roxy-3D]

The user can now control if the heaters are turned off during a BL-Touch probe event.

//#define BLTOUCH
//#define BLTOUCH_DELAY 375      // (ms) Enable and increase if needed
//#define BLTOUCH_HEATERS_OFF // if defined the printer's heaters are turned off during probe event

https://github.com/MarlinFirmware/Marlin/pull/6485

[oysteinkrog]

Would this help for inductive proximity sensors too?

[Roxy-3D]

One other thing, I have a ViKi2 LCD with the LED that shows Red for a heated bed and Blue for a cool bed. That LED toggles between red and blue while M48 is running. It's not a big deal but it did catch my attention.

This one you will have to live with. The BL-Touch probe very literally turns the power off to the nozzles and the bed during the actual probe event. So... The LED is actually telling you the truth about what is happening.

[Roxy-3D]

Would this help for inductive proximity sensors too?

Very possibly. A simple test would be see how good your M48 numbers are with and without the heaters turned on. If you get better numbers with the heaters turned off... We can figure out how to make this available for inductive probes also.

[cbusillo]

I'm glad I commented above. Thank you guys for the hard work. Its really cool to see this process take shape. How can I tell when this is merged into a release? I would love to try it out.

[mperdue]

@Roxy-3D I figured the light flashing would be a side effect of turning the heater on and off. It's no big deal. It only occurs while the heater is below some threshold that I haven't bothered to determine. Once it gets near operating temperature it stays red.

[Roxy-3D]

I'm glad I commented above. Thank you guys for the hard work. Its really cool to see this process take shape. How can I tell when this is merged into a release? I would love to try it out.

Yes! Open Source is cool! Hobbyists from all over the world can collaborate and produce world class technology, just because it is fun to do it!

It is already merged into RCBugFix. You can get it here: https://github.com/MarlinFirmware/Marlin/tree/RCBugFix

And... I think ThinkyHead is looking to promote RCBugFix into a 'Golden Master' (Stable Release) on Sunday. So this should be in that branch going forward.

[cbusillo]

Wow. Does that mean it will get merged into the final that is due soon?! I assumed at his point it would be on a feature freeze.

[Roxy-3D]

Yes. But a few new features have been sneaking into the release.

[mperdue]

Yes. But a few new features have been sneaking into the release.

Isn't that how all programming projects go?

[Grogyan]

Have rewired my printer to use the on-baord FET as opposed to an AC SSR, running on 24VDC.
UBL Enabled
Running the same tests with the Heaters Off vs On during the probe event.

With the Heaters off enabled, saw ~2.5 microns +/- 1.5 microns
With the Heaters off disabled, saw ~4 microns +/- 2 microns

While the biggest change was simply to upgrade to the latest RCBugFix, which is unsurprising as there was a lot of changes to using interrupts for probe events over checking every step.

While not conclusive, as I am only one person with one active printer, it certainly helps reduces the error, with an average variance of 1.5 microns between disabling and enabling the heaters. I also see far less erroneous readings going as high as 50 microns, this could be due to the fact that my M6 leadscrews are not perfectly straight and causes significant oscillation in the frame during fast Z move, which I can tweak the acceleration and feedrate of.
My printer is currently printing replacement parts to become an I3, over the I2 that it currently is.

[bgort]

Disabling the heaters while probing seems to work fine for me, though I may now have a mechanical or other issue because my standard deviation has gone from a consistent 3-5um previously to 4-5x that now, and sometimes more (regardless of whether the heaters are on or off).

I had a BLTouch-metal clip collision a while ago, so could have damaged it, though that doesn't seem likely as there's no visible/obvious issue - no damage to the pin or anything else, pin moves freely, etc. - and the internals are so simple ..

Not sure what's going on, but I may try another one if I can't find another cause in the near future.

[Roxy-3D]

I had a BLTouch-metal clip collision a while ago, so could have damaged it, though that doesn't seem likely as there's no visible/obvious issue - no damage to the pin or anything else, pin moves freely, etc. - and the internals are so simple ..

You may have no visible damage... But what about inside the probe? That probe pin with the sensor wrapped around it might be very sloppy now????

Not sure what's going on, but I may try another one if I can't find another cause in the near future.

Do you have another one? I can send you one if you get me your address.

[bgort]

It doesn't seem sloppy or anything other than normal, but I agree that there's no way to know what may have happened internally.

No, I don't have another and it looks like it'll take until the end of the week for one to get here ordering from Amazon, eBay, or others. Appreciate the offer. Happy to pay you for it and for shipping, of course. What's the best way to get you my info?

[Roxy-3D]

What's the best way to get you my info?

Go to http://3dprintboard.com and send a private message to Roxy. I'll drop it in the mail as soon as I get your address. (It wouldn't hurt for you to include your email address too) I have a few of them that should be in developer's hands that are helping with BL-Touch issues. I'm very glad for you to get one. The one I'll send has a 10ms pulse instead of the original 5ms when it gets triggered. (This is the latest model)

[bgort]

Will do that shortly. Thanks very much!

[mgrl]

I think I can confirm, that turning off heaters works for me, too.
I have 2 printers with bltouch and had always issues with it on both. About 2 of 5 prints started with a nozzle squishing the extruded plastics on some parts of the bed more than on others.
Now I took the idea of having all heaters disabled from here by putting according g-codes at startup instead of switching to the new rcbugfix. Unitl today every print was a success (made 8 prints so far).

Will observe that further. thank you for your effort in this!

[Roxy-3D]

Now I took the idea of having all heaters disabled from here by putting according g-codes at startup instead of switching to the new rcbugfix. Unitl today every print was a success (made 8 prints so far).
Will observe that further. thank you for your effort in this!

Good to hear! But I believe you will get better measurements if you dial in all the numbers (Both Configuration.h numbers and probing numbers) with the machine up to temperature.

But still... more data is good to have.

[mgrl]

Yes, indeed I heat up the bed fully and the nozzle to 140°C before probing. Then all of to take 16 probes and heat again. Seems to work well this way, but leads to delays on print start of course