3DTouch (Geetech) random fail - probe error?

[skyflyer]

Hello guys! This is more of a question than a bug report.

Description

Related to: #9702, #9389, #8153, #9320, #3902

I was using SN04 sensor before and it failed on me several times, driving the nozzle into the bed (sometimes breaking the Z axis mount). So I decided to test with the 3DTouch sensor. Testing Geetech BlTouch sensor and I found out, that when bed is heated, I get many probe deployment errors (and the nozzle hits the bed, while I panic in search for the emergency button :)).

The log file excerpt (below) seems fine to me. I'm just wandering if there is way to detect the anomaly when probe does not deploy?

I tried to test it with M43 S and variants, but nothing happens. M280 P0 S10 (and 90 and 120) work fine, though.

I witnessed more than 5 occurrences of nozzle hitting the bed when the Bltouch failed, so I don't feel confident. I can't even go through the G29 P1 (UBL), since the nozzle hits the bed during measurement.

What is interesting is that I'm able to reproduce those issue with the bed heated and not with the cold bed. I'm guessing this has to be a faulty BlTouch.

The question really is: is there a way to detect that the probe did not deploy (that it is still stowed)? I see that the code checks for TEST_BLTOUCH, but that just checks the current state of the endstop input. If I understood the comments correctly, the bltouch in the stowed position does not trigger the endstop?

I'm guessing that the temperature from the bed (60 C at the moment) might be just enough that it causes some "friction" in the BlTouch clone and that prevents it from deploying.

While stressing it out, I was able to put it into an error state by issuing M280 P0 S120 (test command, that should repeatedly deploy and stow the probe). The problem with my cases where the nozzle hits the bed is that the probe is obviously not in an error state and perhaps there's nothing Marlin can do to fix that?

< 10:15:00: 1st Probe Z:1.18
< 10:15:00: >>> do_blocking_move_to(48.00, 111.00, 6.18)
< 10:15:01: <<< do_blocking_move_to
< 10:15:01:   current_position=(48.00, 111.00, 6.18) : >>> do_probe_move
< 10:15:02: set_bltouch_deployed(1)
< 10:15:02: >>> do_blocking_move_to(48.00, 111.00, -10.00)
< 10:15:06: <<< do_blocking_move_to
< 10:15:07: set_bltouch_deployed(0)
< 10:15:07:   current_position=(48.00, 111.00, 1.17) : sync_plan_position
< 10:15:07:   current_position=(48.00, 111.00, 1.17) : <<< do_probe_move
< 10:15:07: 2nd Probe Z:1.17 Discrepancy:0.01
< 10:15:07: >>> do_blocking_move_to(48.00, 111.00, 6.17)
< 10:15:08: <<< do_blocking_move_to
< 10:15:08: <<< probe_pt
< 10:15:08: >>> probe_pt(133.00, 111.00, raise, 0, probe_relative)
< 10:15:08:   current_position=(48.00, 111.00, 6.17) : 
< 10:15:08: >>> do_blocking_move_to(92.00, 155.00, 6.17)
< 10:15:08: <<< do_blocking_move_to
< 10:15:08:   current_position=(92.00, 155.00, 6.17) : set_probe_deployed
< 10:15:08: deploy: 1
< 10:15:08:   current_position=(92.00, 155.00, 6.17) : >>> run_z_probe
< 10:15:08:   current_position=(92.00, 155.00, 6.17) : >>> do_probe_move
< 10:15:09: set_bltouch_deployed(1)
< 10:15:09: >>> do_blocking_move_to(92.00, 155.00, -10.00)
  10:15:11: Send emergency stop to printer. You may need to reset the printer for a restart!
< 10:15:12: start

[thinkyhead]

What happens if you enable these options?

//#define PROBING_HEATERS_OFF       // Turn heaters off when probing
//#define PROBING_FANS_OFF          // Turn fans off when probing
//#define DELAY_BEFORE_PROBING 200  // (ms) To prevent vibrations from triggering piezo sensors

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. If the problem has been resolved then we can close this issue. If you still see the bad behavior we should investigate further.

[skyflyer]

I'll test and report back, though I'm somewhat inclined that it might be a faulty sensor. You see, even M280 P0 S120 (self test) fails often when the bed is heated. I'm guessing that the materials expand slightly when the bed is heated and that might be causing errors in operation.

Nevertheless, I'll perform one set of tests (self test + G29 P1) on a cold device and then on a heated device, with the suggested tweaks.

Thanks!

[thinkyhead]

It's more likely electrical noise cause by heater PWM. You can also try adding ferrite beads to your probe wires to reduce interference.

[skyflyer]

@thinkyhead,

these are my observations and tests performed. I hope I've described them in enough (and hopefully not too much) detail:

3d touch is apx. 20mm above the bed.

16:56 Cold printer: issued M280 P0 S120 and it is working flawlessly.
Turned on heated bed and nozzle (60 and 200 degrees).
Issued M280 P0 S120 and it still works flawlessly.
16:58: the 3d touch test (S120) still working.

16:59: Issued G28 and got a BLTouch error (the sensor started blinking). Even though I got the error in the console:

< 16:59:34: Error:STOP called because of BLTouch error - restart with M999
< 16:59:34: Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
< 16:59:47: X:59.00 Y:144.00 Z:5.00 E:0.00 Count X:4720 Y:11520 Z:8000

the Z axis kept moving for cca 5mm downwards and only then stopped. I suppose it should be stopped automatically? The 3D touch was automatically reset by Marlin afterwards, but I still had to issue M999 to be able to move the head around (homing (G28) works even if I don't reset it with M999).

17:07: M280 P0 S120 still working. (but bed temps were reset before, so not as hot as I would want them)
17:08: M280 P0 S120 fails while I'm turning the fan on/off between the test, bed is now at 55 deg. I can repeat the failures quite reliably.
17:09: Turn off heated bed & nozzle & fan. M280 P0 S120 still fails. Now even faster, after "two deployments". Hmm.
17:11: Bed temp at 55 deg now. M280 P0 S120 fails after ~10 seconds.
17:12: Power off, on
17:13: I measure the temperature of the sensor to be 40 deg C (IR termometer); M280 P0 S120 now works (I stop it after 30 deployments)

I compile a new FW version (bugfix-1.1.x) with suggested settings:

#define PROBING_HEATERS_OFF       // Turn heaters off when probing
#define PROBING_FANS_OFF          // Turn fans off when probing
#define DELAY_BEFORE_PROBING 200  // (ms) To prevent vibrations from triggering piezo sensors

17:22: New firmware uploaded, I issue M280 P0 S120 and it fails after two deployments. A second attempt fails at 17 deployments.
17:26: Third attempt fails at 56 deployments. Fourth attempt works. (I stop it at 70 deployments). Puzzled, I am. :)
17:32: Heating the bed.... preparing for G29 P1
17:40: Started UBL leveling with G29 P1 and probe went into an error state:

< 17:39:44: Error:STOP called because of BLTouch error - restart with M999
< 17:39:44: Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
< 17:39:49: Error:Probing failed
< 17:39:52: Error:STOP called because of BLTouch error - restart with M999

What's strange though is that Marlin apparently reset the probe and just continued with measurements.

17:51: Probe failed to deploy and the nozzle hit the bed. Fortunately, I'm used to such mishaps and was standing by, just waiting for it.

I'm leaning towards a broken probe, what do you think? Based on my observations above, I assume there's nothing wrong with the software if the probe randomly stops working during its own test (S120) and during bed probing. One strange thing, however is that even though the probe failed (went into an error state), Marlin reset the probe and continued working.

[thinkyhead]

It does sound like a flaky probe or possibly induction caused by electromagnetism somewhere. But you can also try setting these options to the minimum required, just in case the probe is "timing out."

#define Z_CLEARANCE_DEPLOY_PROBE   10 // Z Clearance for Deploy/Stow
#define Z_CLEARANCE_BETWEEN_PROBES  5 // Z Clearance between probe points

Note that sometimes BLTouch probes can be damaged by getting pressed into the bed. To reduce chances of hurting the probe there's a new option in the bugfix branches:

#define Z_PROBE_LOW_POINT          -2 // Farthest distance below the trigger-point to go before stopping

[skyflyer]

@thinkyhead, thanks for the useful hints. I'll try the Z_PROBE_LOW_POINT one. WRT others, I've read that antclabs suggest that the min height is 15mm.

See their page (https://www.antclabs.com/bltouch) and the settings:

Anyway, closing this one -- I'm chalking this up up to the faulty touch sensor (and the seller will send a new probe to replace this one). I appreciate your support!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.