[bugfix-2.0.x] BLTouch sometimes drops pin while probing

[manutenfruits]

Description

When running command G29 to level the bed, some BLTouch devices drop the pin after some probing points. This doesn't seem to affect the actual probing measurements.

It is worth noting that this started happening after a recent firmware update, when I merged up to commit 5536228. Firmware config here

I reverted back to some old firmware that I had (this branch) and G29 ran with no issues.

I'm sorry I haven't updated in forever, so the change might be harder to spot. Happy to try any fixes you guys suggest.

Steps to Reproduce

1. Home all axes
2. Run G29 to level the bed

Expected behavior: For each probe point BLTouch drops, probes, stays stowed and moves to the next point.

Actual behavior: For some probe points, BLTouch drops, probes, which stows the probe, and while raising Z before moving to the next stop, the probe drops.

Additional Information

Demo here: https://photos.app.goo.gl/HzvxJPnnp3VuTfNu7

THE DEMO VIDEO DOESN'T CORRESPOND TO EITHER OF THE FOLLOWING GRID TABLES Like I said, the following two tables don't seem much different from each other.

Bed Grid on the reported firmware (with bug):

Bilinear Leveling Grid:
      0      1      2      3      4      5      6
 0 -1.389 -1.226 -1.127 -1.035 -0.942 -0.930 -0.977
 1 -0.777 -0.651 -0.519 -0.396 -0.329 -0.316 -0.414
 2 -0.470 -0.337 -0.175 -0.091 -0.044 -0.111 -0.229
 3 -0.330 -0.137 +0.015 +0.118 +0.180 +0.107 -0.051
 4 +0.067 +0.196 +0.304 +0.376 +0.374 +0.276 +0.109
 5 +0.339 +0.451 +0.538 +0.580 +0.562 +0.465 +0.308
 6 +0.346 +0.429 +0.496 +0.534 +0.498 +0.380 +0.258

Bed Grid on the old firmware (no bug):

Bilinear Leveling Grid:
      0      1      2      3      4      5      6
 0 -1.362 -1.172 -1.081 -0.966 -0.881 -0.841 -0.906
 1 -0.710 -0.590 -0.465 -0.325 -0.245 -0.240 -0.315
 2 -0.400 -0.255 -0.104 -0.019 +0.026 -0.029 -0.134
 3 -0.202 -0.017 +0.118 +0.238 +0.276 +0.226 +0.051
 4 +0.178 +0.317 +0.428 +0.498 +0.499 +0.404 +0.254
 5 +0.439 +0.559 +0.664 +0.714 +0.714 +0.629 +0.454
 6 +0.459 +0.495 +0.570 +0.590 +0.535 +0.440 +0.295

[thinkyhead]

Try increasing Z_CLEARANCE_BETWEEN_PROBES and see if it helps.

If that doesn't help, then take note: We're only updating bugfix-2.0.x from now on, so you'll have to test with that version to see if we've addressed the issue and to obtain a fix if there's a bug.

[Stephane-80]

Hello, I have the same problem for 1 or 2 months. I thought I had a problem with bltouch I tried a lot of settings on this one and powered directly with 5 v, I thought to buy a new but ultimately it may not be it which has problems I'm going to try increasing Z_CLEARANCE_BETWEEN_PROBES

[landodragon141]

Try tightening the screw on the top slightly, like a quarter turn.

[Stephane-80]

for the moment it still does it I tried several tightenings of the screw but at times the bltouch does not deploy and the leveling fails / stops :-/ @manutenfruits i have a mks sbase with bugfix-2.0.x do you have the same card ?

I specify that before this summer, with older versions I had never had this problem

[manutenfruits]

@Stephane-80 this is solely a firmware issue, as reverting the firmware fixes it. Also it's worth noting again that leveling works fine either way. The board is an MKS Sbase too, with bugfix-2.0.x, and the BLTouch is an original one.

@landodragon141 What screw? Everything is tight, and this seems like a firmware issue.

@thinkyhead I can try to tweak Z_CLEARANCE_BETWEEN_PROBES but that sounds like a workaround, not a fix, right? Also, I am running bugfix-2.0.x, as mentioned on my first comment. I will keep an eye on new updates either way.

[p3p]

It could be an issue with the new lpc176x frameworks servo implementation, I didn't test with BLTouch devices as I don't have one but others did and didn't report anything. Would have been introduced after https://github.com/MarlinFirmware/Marlin/commit/213e94bce2fd74b10014557bd6801b45193a08f8 in this commit if that is the case,

[dough29]

Hello !

I had this issue with clone xTouch and not with genuine BLTouch : are you all using genuine or clone ?

[Stephane-80]

@manutenfruits ok thanks , yes, before the updates of this summer I had no problems indeed, the problem appeared then.

@dough29 antclabs BLTouch here .

[Stephane-80]

I just saw something strange this time I had the problem after the last point of bed leveling (G29) only the pine was out I wanted to go back by pushing it with my finger but it came out every time and at that moment came to me the idea of making "M280 P0 S90" and he came back I thought at first that the pin could not go in properly but in fact it came out as if we doing a pin out: "M280 P0 S10" which really leaves me thinking about a software bug indeed.

[UtterlyD]

I also have issues with my genuine BLtouch dropping when probing randomly for a G29. My board is also an MKS SBASE. I have increased Z_CLEARANCE_BETWEEN_PROBES and still get drops just after probe stowing. In addition the probe often does not drop at all causing head crashing.

I can confirm that my previous build from 22 March 2018 does not exhibit this issue, however since updating to bugfix-2.0.x 2 November 2018 @ 1900Hrs I observe this issue.

I have also observed this issue during a G34 command, I have only successfully completed a G34 with 3 cycles once.

[Stephane-80]

@UtterlyD > In addition the probe often does not drop at all causing head crashing. I confirm that I also have this problem randomly

[p3p]

Can anyone confirm the issue is not in https://github.com/MarlinFirmware/Marlin/tree/213e94bce2fd74b10014557bd6801b45193a08f8 but does happen with https://github.com/MarlinFirmware/Marlin/tree/3d5be2ea4bac370e05b8acc61a9fba2684e5131e and tell me the pin used for the servo.

I've tested what I can without a BLTouch, the servo code is outputting the correct waveform for the requested angles on both the hardware and software pins.

[manutenfruits]

@UtterlyD > In addition the probe often does not drop at all causing head crashing.

Omg what a relief, I wasn't crazy, my wiring was fine! Lol

[UtterlyD]

@p3p I can confirm that the issue was not present in https://github.com/MarlinFirmware/Marlin/tree/213e94bce2fd74b10014557bd6801b45193a08f8 but does indeed occur in https://github.com/MarlinFirmware/Marlin/tree/3d5be2ea4bac370e05b8acc61a9fba2684e5131e.

I ran three 4x4 G29s with no premature drops or crashes with the first link, and premature dropped and head crashed on the first G29 row on the second link.

I believe I am using pin 1.23 for the trigger pin. Is there any testing you would like to perform with my logic analyser? Would be a good excuse to find where I put it!

[Stephane-80]

I am using pin 1.23 too I have to find the time to test the old version again

[p3p]

@UtterlyD If you could record the PWM signal for a failing probe that would be useful, I can't currently force an error in the signal generation but I'm obviously not trying hard enough, my test suite is external to Marlin testing the actual Servo library rather than the probe sequence.

[UtterlyD]

@p3p Please find attached a Pulseview Sigrok session file for a 5x5 G29 with multiple drops and finishing with a crash. The session is configured with channel D0 on the BLTouch servo output and channel D1 on the z-stop output from the BLTouch.

From my assessment it looks like the servo output is incorrect.
The G29 crashed on the 21st probe which is not seen on channel D1 due to the probe not being deployed. The D0 output following the 20th probe shows it was not commanded to deploy since the pulse width was approx the 1500us for a stow.

The first probe at approx 5.9s shows what I would expect as the correct command and response. However the second probe at approx 13.5s remains at the deployed pulse width at 650us following the probe touching the bed and causing the pin to redeploy hitting the bed.

G29 - Drops and crash.sr.zip

[p3p]

Thanks for that @UtterlyD will help a lot.

[p3p]

Have you all updated platformio platforms and libraries recently and have framework-arduino-lpc176x version 0.0.5?, I assume you have as it's was pushed a while ago but I thought I better check.

[UtterlyD]

@p3p I am all up to date including framework-arduino-lpc176x at 0.0.5. I actually setup from scratch on a new MacBook Pro a few days ago.

[p3p]

@UtterlyD Can you test on a software pin rather than a Hardware capable pin, anything other than P1_23 on J8.

[UtterlyD]

@p3p I can confirm that software pin operation does not have this issue. I managed to perform 3x 5x5 G29 without a drop or crash on pin 4.28.

It is probably worth noting that my E0 is on P2_03 which is shared by P1_23.

[thinkyhead]

@p3p — With the change in servo code did we sacrifice any of our tuning and control parameters, such as DEACTIVATE_SERVOS_AFTER_MOVE, SERVO_DELAY, (MIN|MAX)_PULSE_WIDTH, etc.?

[p3p]

@thinkyhead No Marlins extension to the Arduino Servo library are maintained here HAL_LPC1768/MarlinServo.h, the pulse width limits Marlin uses is the default for Arduino Servo library but can be overridden through the attach method as usual.

@UtterlyD okay now I just need to figure out what Marlin is doing that my tests aren't that seems to cause the new value not to latch into the match registers, interrupts are involved more than likely.

[Stephane-80]

hello , in pins_MKS_SBASE I have :

//
// Servo pin
//
#define SERVO0_PIN         P1_23   // J8-3 (low jitter)
#define SERVO1_PIN         P2_12   // J8-4
#define SERVO2_PIN         P2_11   // J8-5
#define SERVO3_PIN         P4_28   // J8-6

if I change Configuration.h with for using SERVO3_PIN for BLTouch

#define Z_PROBE_SERVO_NR 3

When I compile I have the error :

*** [.pioenvs\LPC1768\src\src\module\configuration_store.cpp.o] Error 1

[Stephane-80]

 Marlin\src\module\configuration_store.cpp: In static member function 'static bool MarlinSettings::save()':
Marlin\src\module\configuration_store.cpp:582:7: sorry, unimplemented: non-trivial designated initializers not supported
};

[p3p]

If you just want to test on a software PWM pin then change SERVO0_PIN to one of the other values. can't reproduce your error with the information you have supplied, I needed to add another 3 values to SERVO_DELAY to make it build but that's all.

[Stephane-80]

hello

, thanks yes even by configuring SERVO_DELAY I have the error at compilation

/**
 * Number of servos
 *
 * For some servo-related options NUM_SERVOS will be set automatically.
 * Set this manually if there are extra servos needing manual control.
 * Leave undefined or set to 0 to entirely disable the servo subsystem.
 */
#define NUM_SERVOS 4 // Servo index starts with 0 for M280 command

// Delay (in milliseconds) before the next move will start, to give the servo time to reach its target angle.
// 300ms is a good value but you can try less delay.
// If the servo can't reach the requested position, increase it.
#define SERVO_DELAY { 300, 300, 300, 300 }

tested with SERVO1 - 2 and 3 I have the compilation error.

maybe I have other problem here with editor or files I have warnings in platformIO each time I save Configuration.h even if the compilation works :-/ :

Error   GCC missing binary operator before token "("    157:12
Error   GCC missing binary operator before token "("    180:12
Error   GCC missing binary operator before token "("    190:12
Error   GCC missing binary operator before token "("    200:12
Error   GCC missing binary operator before token "("    210:12
Error   GCC missing binary operator before token "("    226:12
Error   GCC missing binary operator before token "("    244:12
Error   GCC missing binary operator before token "("    276:14
Error   GCC missing binary operator before token "("    400:12
Error   GCC missing binary operator before token "("    458:12
Error   GCC missing binary operator before token "("    554:13
Error   GCC missing binary operator before token "("    567:13
Error   GCC missing binary operator before token "("    779:12
Error   GCC missing binary operator before token "("    792:12
Error   GCC missing binary operator before token "("    880:12
Warning GCC #pragma once in main file   22:9

it does not matter. at first I wanted to change the servo number to make it clearer in the config file but I ended up with the option to change the pins in effect . So, finally coming back to the main problem I do not have the bltouch problems with the pin 4.28

[p3p]

Can you supply your complete config files and the pins file (in a zip) you have this compile error with.

[Stephane-80]

@p3p thank you ! And each time many warnings in compilation I do not know if it's normal :

Marlin\src\HAL\HAL_LPC1768\u8g\u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp: In function 'uint8_t u8g_com_HAL_LPC1768_ssd_hw_i2c_fn(u8g_t*, uint8_t, uint8_t, void*)':
Marlin\src\HAL\HAL_LPC1768\u8g\u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp:159:27: warning: ISO C++1z does not allow 'register' storage class specifier [-Wregister]
register uint8_t *ptr = (uint8_t *)arg_ptr;
^~~
Marlin\src\HAL\HAL_LPC1768\u8g\u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp:178:27: warning: ISO C++1z does not allow 'register' storage class specifier [-Wregister]
register uint8_t *ptr = (uint8_t *)arg_ptr;
^~~

In file included from Marlin\src\gcode\config\M43.cpp:29:0:
Marlin\src\gcode\config\../../pins/pinsDebug.h: In function 'void report_pin_state_extended(pin_t, bool, bool, const char*)':
Marlin\src\gcode\config\../../pins/pinsDebug.h:154:101: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int' [-Wformat=]
sprintf_P(buffer, PSTR("Analog in = %5ld"), analogRead(DIGITAL_PIN_TO_ANALOG_PIN(pin)));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
In file included from Marlin\src\gcode\config\M43.cpp:29:0:

Marlin\src\gcode\config\../../pins/pinsDebug.h:216:102: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'int' [-Wformat=]
sprintf_P(buffer, PSTR("   Analog in = %5ld"), analogRead(DIGITAL_PIN_TO_ANALOG_PIN(pin)));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^

Marlin\src\lcd\dogm\status_screen_DOGM.cpp: In function 'void lcd_impl_status_screen_0()':
Marlin\src\lcd\dogm\status_screen_DOGM.cpp:215:6: warning: '%02u' directive writing 2 bytes into a region of size between 0 and 4 [-Wformat-overflow=]
void lcd_impl_status_screen_0() {
^~~~~~~~~~~~~~~~~~~~~~~~

Marlin\src\lcd\dogm\status_screen_DOGM.cpp:215:6: note: directive argument in the range [0, 59]
In file included from Marlin\src\lcd\dogm\../../module/printcounter.h:25:0,
from Marlin\src\lcd\dogm\status_screen_DOGM.cpp:43:
Marlin\src\lcd\dogm\../../module/../libs/duration_t.h:153:16: note: 'sprintf' output between 9 and 13 bytes into a destination of size 10
sprintf_P(buffer, PSTR("%ud %02u:%02u"), d, h % 24, m);

Config files and pins file : pb_Compil_SERVO3.zip

[thinkyhead]

Those warnings are nothing to worry about. The last one warns that you could get a buffer overflow if you do a print of 1000 days or longer.

[p3p]

@Stephane-80 thanks, with the supplied configs I can reproduce the error,

@thinkyhead the generated C++ code does not seem to be valid? I'm not aware of a c++ compiler that supports out of order designated initialisation, array[num] = {[index] = value }; is C syntax, not standard C++, .. although I may be reading things wrong. I think gcc has extensions that are allowing this to mostly work but I would have to look into it more, and am working on the broken PWM atm.

[Stephane-80]

@p3p ok, thank you very much, at least it lets me know that it is not my software that bug.

[thinkyhead]

I just patched up all the compile issues that were possible to patch. Now we're just left with the LiquidTWI2 WProgram.h issue.

[p3p]

@thinkyhead I was referring to Marlin\src\module\configuration_store.cpp:582:7: sorry, unimplemented: non-trivial designated initializers not supported compile error the supplied config produces. The WProgram.h issue is just PlatformIO being a pain.

edit: ah I see you have patched that array initialisation.

[gloomyandy]

I had the WProgram.h issue earlier today. I deleted one of the PlatformIO cache directoies (.piolibdeps I think) and rebuilt everything and the problem seems to have gone away, don't you just love PlatformIO!

[thinkyhead]

@p3p — Yes, I know. I patched that first.

[Stephane-80]

Hello , thank you very much ! Complilation : OK "#define Z_PROBE_SERVO_NR 3" : OK BLTouch with the pin 4.28 : OK 👍

[thinkyhead]

So, would this addition to pins_MKS_SBASE.h help users find a decent probe pin?

#ifndef Z_MIN_PROBE_PIN
  #define Z_MIN_PROBE_PIN  P4_28   // Connector J8
#endif

Are there any printers out there already using this pin for their probe?

[p3p]

@thinkyhead No the hardware PWM pin is actually the best choice there is just something weird going on, I'm tracking down the problem, it's my fault I just don't know why yet.

[psavva]

I have replicated the same issue. Let me know if you need any details from me. For now, +1 on this bug report. I'm using Re-Arm and genuine BLTouch.

[p3p]

Thanks @psavva I can reproduce the issue now, I'm still trying to figure out why changing the pulse width of 2 channels in the same period causes it though, it's caused by the default FAN_PIN it is a Hardware PWM pin that gets updated in safe_delay() .. should be fine.. but depending on timing cancels the update for the other hardware channels.

If I can't fix it today I'l roll out a update disabling the hardware PWM until I can fix it.

[nemphys]

Nice, it also happens to my BLTouch clone. I am wondering if it also affects the actual probe values, since I am getting very inconsistent results between probes. Can somebody confirms that probe values are actually not affected (as stated above)? I recently installed the probe so I have no earlier reference. Either it is a bad unit or I should wait to see if the fix changes anything.

[gloomyandy]

@nemphys what control board are you using? The problem being discussed here only impacts boards using the LPC176X processor. If your board does not use this then you probably have a different issue. If it does use an LPC1768 then I would wait for some progress to be made on the issue before doing anything more.

[nemphys]

I have a Anycubic I3 Mega with the Anycubic Trigorilla 1.4 board (8bit RAMPS 1.4 with Arduino Mega 2560). I have no idea if it has a LPC176X processor, but the behaviour of the BLTouch is exactly as described above (and it only appeared recently).

[gloomyandy]

@nemphys your board is using an Arduino Mega 2560, so no it does not use an LPC176X. It is very unlikely that the solution being discussed here will help you. There is a small chance it is the same problem and that the issue has not been identified correctly, but that does not seem very likely. So you may want to investigate your issue more deeply and consider posting a new issue.

[nemphys]

I have no problem posting a new issue, but it would be identical to this one (since the title is not processor-specific). Are you sure you are looking at the right place? Maybe it is caused by something else.

[gloomyandy]

I'm not the one working on this problem, but the current focus is on an area that will not fix your issue.

Perhaps you should post the details of your system (including configuration files) and the details of what previous version of the firmware worked properly for you and exactly what version does not.

[nemphys]

OK, let's wait and see if any fixes produced here do anything good in my case and, if not, I will post a new issue.

[hidara2000]

I'm wondering if this is a problem with the MKS SBASE? I had the same issue with both genuine and non bltouch on smoothieware. Flashed Marlin in the hope that it would disappear. Whilst I still get the odd double drop with Marlin it has improved