[BUG] BD Sensor stops during "no stop" probing

[aero4]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Hi all!

I recently installed my new BD Sensor probe. Everything works fine when probing, except when I enable "BD_SENSOR_PROBE_NO_STOP".

When enabling the the probing starts at the front right corner does two probing lines and suddenly stops (at end of line 2 of 6). After that I even have to reset the printer to be able to send commands again.

I am using a kind of clicky probe for z homing. But the bug also appears when using the BD sensor for probing. I also tried to decrease the probe to bed distance by relative positioning, but even when the nozzle is touching the bed while probing this issue happens. No "out of range" messages appear...

There is no command output when the probing stops too.

Bug Timeline

No response

Expected behavior

Bed is probed with a 9x6 grid using the BD sensor.

Actual behavior

Probing stops at the end of the second probing line (of 6).

Steps to Reproduce

1. Download latest bugfix marlin firmware
2. Adapt configuration.h and configuration_adv.h file
3. Install BD-Sensor
4. Run G29 after G28

Version of Marlin Firmware

Marlin 2.1.x_bugfix

Printer model

Custom

Electronics

BTT SKR V1.4

LCD/Controller

none

Other add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Simplify3D

Host Software

Same as my slicer

Don't forget to include

• [x] A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

My configuration.h and condiguration_adv.h files are attached. Config.zip

[ellensp]

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information so that we're not just taking stabs in the dark. Here is the boilerplate:

• Download Marlin bugfix-2.1.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Send M502 and M500 to ensure your Configurations are applied.
• Issue the command M111 S247 to enable maximum logging.
• Perform a G28 to do your standard homing procedure.
• Do a G29 to probe the bed. This will also enable bed leveling.
• Do some of the moves that revealed problems before. Take notes.
• Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

[aero4]

Hello, thanks for the instructions. I did what you suggested and even re-downloaded the latest bugfix code from today. Attached you can see the log file output while performing the following G-CODES: G28 ; home all axes G90 G0 Z5 F1200 G0 X-7 Y-5 F6000 G0 Z0 F1200 M211 S0 G91 G0 Z-1.4 F1200 G90 M428 M211 S1 G29 ; auto bed leveling

Bed leveling stopped as before at the end of the second line and I had to reset the printer to get control of it again.

output_log.txt

[aero4]

@markniu may you know what can cause that issue? I would be glad for any help.

[markniu]

@markniu may you know what can cause that issue? I would be glad for any help.

Hello, not sure what cause that, but we can open some debug message. actually, all the code about BD_SENSOR_PROBE_NO_STOP is here, you can remove theif (DEBUGGING(LEVELING)) at the begin of this lines as shown below, and then there should be some debug message from the serial port while do bed leveling

and you can try to replace the lineif (inInc > 0 ? ((pos+0.006f) >= cmp) : (pos <= (cmp+0.006f))) break; with if (inInc > 0 ? ((pos+0.006f) >= cmp) : (pos <= (cmp+0.006f))) break;

[aero4]

Hello @markniu, thanks for the instructions. I did what you suggested, re-compiled and re-flashed the firmware, ran M502 and M500 and re-run the commands from above. Same behavior and the log output can be seen here: output_new.txt

P.S.: the last line to replace you suggested was I think a copying mistake, because it's the same line. But I added the "+0.006f" on the corresponding two places.

[markniu]

oh sorry. it should replace the
if (inInc > 0 ? (pos >= cmp) : (pos <= cmp)) break; with if (inInc > 0 ? ((pos+0.006f) >= cmp) : (pos <= (cmp+0.006f))) break;

P.S.: the last line to replace you suggested was I think a copying mistake, because it's the same line. But I added the "+0.006f" on the corresponding two places.

[aero4]

Ok, I already did that with the output above!

[markniu]

Ok, I already did that with the output above!

could you add this SERIAL_ECHOLNPGM("pos ", pos, " cmp ", cmp);and try again and I suspect the printer stops at here.

[aero4]

Sure. Now it's outputting READ: pos 394.76 cmp 395.00 consecutively when the probing hangs. Seems to be the right position!

(my print bed is 395/260mm (x/y) with a homing offset of X_MIN_POS -7 and Y_MIN_POS -5 and a nozzle to probe offset of {-18.7, -8.8, 0} if that helps)

[markniu]

that's the reason, now you can replace the if (inInc > 0 ? (pos >= cmp) : (pos <= cmp)) break; with if (inInc > 0 ? ((pos+0.3f) >= cmp) : (pos <= (cmp+0.3f))) break;

Sure. Now it's outputting READ: pos 394.76 cmp 395.00 consecutively when the probing hangs. Seems to be the right position!

(my print bed is 395/260mm (x/y) with a homing offset of X_MIN_POS -7 and Y_MIN_POS -5 and a nozzle to probe offset of {-18.7, -8.8, 0} if that helps)

[aero4]

It works partially now! It passes the second line but hangs on the fourth with the output READ: pos 394.42 cmp 395.00...

[markniu]

What are the values of the x and y offsets?

It works partially now! It passes the second line but hangs on the fourth with the output READ: pos 394.42 cmp 395.00...

[markniu]

maybe you can increase the value to 1mm if (inInc > 0 ? ((pos+1) >= cmp) : (pos <= (cmp+1))) break;

[aero4]

maybe you can increase the value to 1mm if (inInc > 0 ? ((pos+1) >= cmp) : (pos <= (cmp+1))) break;

Now the entire bed can be probed! Does that have any influence to the probing? Is this a general bug?

[aero4]

What are the values of the x and y offsets?

It works partially now! It passes the second line but hangs on the fourth with the output READ: pos 394.42 cmp 395.00...

Do you mean PROBING_MARGIN? That is set to 10

[markniu]

that's very little, for example, it will measure the point at the position 394mm in y axis intead of 395mm

maybe you can increase the value to 1mm if (inInc > 0 ? ((pos+1) >= cmp) : (pos <= (cmp+1))) break;

Now the entire bed can be probed! Does that have any influence to the probing? Is this a general bug?

[aero4]

that's very little, for example, it will measure the point at the position 394mm in y axis intead of 395mm

Ok, but this is only for the points on the very edge, right?

Will there be a bugfix?

And thanks for the help and your time, now I can use your sensor flawlessly!

[markniu]

how about recovery the code and just modify this code const float cmp = abl.probePos[axis] - probe.offset_xy[axis]; to const float cmp = abl.probePos[axis] ;

that's very little, for example, it will measure the point at the position 394mm in y axis intead of 395mm

Ok, but this is only for the points on the very edge, right?

Will there be a bugfix?

And thanks for the help and your time, now I can use your sensor flawlessly!

[aero4]

how about recovery the code and just modify this code const float cmp = abl.probePos[axis] - probe.offset_xy[axis]; to const float cmp = abl.probePos[axis] ;

I don't want to move too near to the bed edges for probing, so I will use the if (inInc > 0 ? ((pos+1) >= cmp) : (pos <= (cmp+1))) break; solution for now I think.

[aero4]

Hello @markniu!

I found another issue. When doing G29 sometimes the bed leveling stops with the output Out of Range. (alway happens when the probe has reached the borders of the bed before moving to the next line). But when I run the command M102 S-2 the output is e.g. Bed Distance:1.84mm (manual measuring also gives about 2mm distance between BD sensor and bed). My nozzle to BD sensor offset is ~1mm -> should be within the BD sensor's range.

I saw, when programming a custom gcode, reading out the BD sensor without a delay after a movement also caused that the return value was 0. When adding a delay of some 100ms this issue didn't occur.

If it's actually out of range, how can I adapt the G29 source code to have a lower nozzle to bed distance while bed leveling?

Thanks for any help!

The console output while using G29 is the following (after uncommenting if (DEBUGGING(LEVELING))):

SENT: G29 
Total build time: 0.19 minutes
READ: Active Extruder: 0
READ: Active Extruder: 0
READ: X:-7.00 Y:54.00 Z:1.40 E:0.00 Count X:-1400 Y:10800 Z:1120
READ: ok
SENT: M105
READ: ok
SENT: M105
READ: ok
SENT: M105
READ: ok
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
READ: ok T:22.43 /0.00 B:23.23 /0.00 T0:22.43 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
READ: destX: 395.00 Y:18.80
READ: x_cur 28.64 z -0.17
READ: x_cur 45.17 z -0.16
READ: x_cur 61.82 z -0.15
READ: x_cur 78.47 z -0.14
READ: x_cur 95.13 z -0.14
READ: x_cur 111.77 z -0.15
READ: x_cur 128.42 z -0.16
SENT: M105
READ: x_cur 145.07 z -0.17
READ: x_cur 161.72 z -0.18
READ: x_cur 178.38 z -0.18
READ: Out of Range.
READ: x_cur 195.03 z 0.00
READ: X:395.00 Y:18.80 Z:1.96 E:0.00 Count X:78987 Y:3760 Z:1568
READ: ok
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
SENT: M105
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
SENT: M105
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0
SENT: M105
READ: ok T:22.57 /0.00 B:23.23 /0.00 T0:22.57 /0.00 T1:-50.00 /0.00 @:0 B@:0 @0:0 @1:0

[markniu]

What's the version returned after M102 S-1 ?

[aero4]

M102 S-1

The output is BD Sensor version:V1.1bpandapi3d.com. I even updated the firmware to your latest "V1_1BDsensor20240213.hex"... Sometimes G29 stops after the first line or before the last line and so on, always with the Out of Range. output. And sometimes G29 goes through and works. Is the z offset while probing too high? Could easily reduced by 1mm. How can I test this?

[markniu]

we can check the actually measure range by the calibration data. you can post the calibrate here after M102 S-5 one data represents 0.1mm.

The output is BD Sensor version:V1.1bpandapi3d.com. I even updated the firmware to your latest "V1_1BDsensor20240213.hex"... Sometimes G29 stops after the first line or before the last line and so on, always with the Out of Range. output. And sometimes G29 goes through and works. Is the z offset while probing too high? Could easily reduced by 1mm. How can I test this?

[aero4]

Sure, the output of M102 S-5 is:

data:0,198
data:1,221
data:2,254
data:3,287
data:4,320
data:5,354
data:6,389
data:7,422
data:8,457
data:9,492
data:10,528
data:11,563
data:12,599
data:13,634
data:14,670
data:15,706
data:16,744
data:17,783
data:18,820
data:19,861
data:20,902
data:21,945
data:22,1015
data:23,1015
data:24,1015
data:25,1015
data:26,1015
data:27,1015
data:28,1015
data:29,1015
data:30,1015
data:31,1015
data:32,1015
data:33,1015
data:34,1015
data:35,1015
data:36,1015
data:37,1015
data:38,1015
data:39,1015

[markniu]

the data 1015 means out of range. one data represents 0.1mm, so the actual measure range is 2.1mm. you can menu level the bed or decrease the mount distance between nozzle to BDsensor, or decrease the z axis height while G29 for example:

#define Z_CLEARANCE_BETWEEN_PROBES  1 // Z Clearance between probe points
#define Z_CLEARANCE_MULTI_PROBE     1 // Z Clearance between multiple probes

to

#define Z_CLEARANCE_BETWEEN_PROBES  0.6 // Z Clearance between probe points
#define Z_CLEARANCE_MULTI_PROBE     0.6 // Z Clearance between multiple probes

[aero4]

the data 1015 means out of range. one data represents 0.1mm, so the actual measure range is 2.1mm. you can menu level the bed or decrease the mount distance between nozzle to BDsensor, or decrease the z axis height while G29 for example:

Thanks for the info didn't realize it's always the same value after data point 22... The nozzle to probe offset is already very little so, it's not clear for me why the range is reduced that much... I will try with the reduced probing z values you mentioned above, thanks!

EDIT: Z_CLEARANCE_BETWEEN_PROBES seems not to allow float values...

buildroot/share/PlatformIO/scripts/../../../../Marlin/src/inc/../../Configuration.h:1655:37: error: floating constant in preprocessor expression
 1655 | #define Z_CLEARANCE_BETWEEN_PROBES  0.6 // (mm) Z Clearance between probe points

EDIT 2: I could overcome the compiling error by overwriting #if Z_CLEARANCE_BETWEEN_PROBES > Z_CLEARANCE_FOR_HOMING (line 3227 of src/inc/Conditionals_post.h) with #if 0 So, the comparison between float values were forbidden (in an if branch which isn't active anyway with my setup -> no impact). But the z height for G29 still seems to be the 1mm of before -> same issue! I guess the float value is converted to int and therefore no values below 1mm... Can i modify the G29 probing height in the "G29.cpp" code file directly?

[aero4]

Hello @markniu, I was able to lower the probing distance significantly, but the error still remains... Again my output of the command M102 S-5 is:

Calibrate data:0,208
Calibrate data:1,225
Calibrate data:2,259
Calibrate data:3,292
Calibrate data:4,327
Calibrate data:5,361
Calibrate data:6,396
Calibrate data:7,429
Calibrate data:8,463
Calibrate data:9,499
Calibrate data:10,535
Calibrate data:11,571
Calibrate data:12,607
Calibrate data:13,644
Calibrate data:14,681
Calibrate data:15,718
Calibrate data:16,756
Calibrate data:17,796
Calibrate data:18,835
Calibrate data:19,876
Calibrate data:20,919
Calibrate data:21,964
Calibrate data:22,1015
Calibrate data:23,1015
Calibrate data:24,1015
Calibrate data:25,1015
Calibrate data:26,1015
Calibrate data:27,1015
Calibrate data:28,1015
Calibrate data:29,1015
Calibrate data:30,1015
Calibrate data:31,1015
Calibrate data:32,1015
Calibrate data:33,1015
Calibrate data:34,1015
Calibrate data:35,1015
Calibrate data:36,1015
Calibrate data:37,1015
Calibrate data:38,1015
Calibrate data:39,1015

Therefore I should be able to read a relative distance up to 21*0.1mm = 2.1mm.

When doing G29 the probing mostly stops and it always stops at the edges of the probing area with the message Out of Range.. When I immediatelly run the command M102 S-2 the output is Bed Distance:0.81mm. So definitely within the range.

Whan can cause that kind of behaviour? How do I test or solve this? I think you are the only one who really can help me and the bug could be a common problem...

[markniu]

How about disable the BD_SENSOR_PROBE_NO_STOP? just for comparison.

Therefore I should be able to read a relative distance up to 21*0.1mm = 2.1mm.

When doing G29 the probing mostly stops and it always stops at the edges of the probing area with the message Out of Range.. When I immediatelly run the command M102 S-2 the output is Bed Distance:0.81mm. So definitely within the range.

Whan can cause that kind of behaviour? How do I test or solve this? I think you are the only one who really can help me and the bug could be a common problem...

[aero4]

I just disabled the NO_STOP feature and tested again. The problem also occurs (Out of Range. -> when using M102 S-2 its in the range of ~1.2mm). It happens on a random place (not only on the edges). It even happens earlyer and more often... It seems to correlate with stopping and probing...

@markniu, do you have any idea what to do about that?

[aero4]

@markniu, I implemented a retry routine if the reading of the BD sensor fails. Therefore I modified the file src\feature\bedlevel\bdl\bdl.cpp by adding the include #include "../../../core/utility.h" at the beginning of the file and I changed the line (line 102) const uint16_t data = BD_I2C_SENSOR.BD_i2c_read(); to

  uint16_t data = BD_I2C_SENSOR.BD_i2c_read();
  uint8_t  retry = 1;
  while(check(data) == true && retry <= 6)   // retry failed measurement multiple times
  {
    safe_delay(70);                         // mandatory delay, otherwise reading fails
    data = BD_I2C_SENSOR.BD_i2c_read();     // read sensor
    SERIAL_ECHOLNPGM("retry ", retry);  // send message
    retry++;                                // increase retry counter
  }

-> "if reading fails retry up to 6 times, otherwise fail"

This is a good workaround to avoid cancellation of the bed leveling after a reading error occurs, which happens multiple times every G29 and that up to 4 times... This for example is the output of just one G29 bed leveling:

G29
Out of Range.
retry 1
Out of Range.
retry 2
Out of Range.
retry 1
Out of Range.
retry 2
Out of Range.
retry 1
Out of Range.
retry 2

I also had to add that 70ms delay otherwise the reading failed. This indicates a problem with the I2C readout timing. I am very sure it's a BD Sensor or sensor readout problem, not a Marlin problem ...

Maybe you find some time to look into that issue?

[thisiskeithb]

Is it possible that your probe bad? Has anyone else experienced/reported this issue?

[aero4]

Is it possible that your probe bad? Has anyone else experienced/reported this issue?

I have no idea if that's a common problem or a faulty probe...

[markniu]

@aero4 for comparison, I would like to send you a new one which the mcu is stm32, please send me your shipping address to my email niujl123@sina.com

Is it possible that your probe bad? Has anyone else experienced/reported this issue?

I have no idea if that's a common problem or a faulty probe...

[aero4]

@aero4 for comparison, I would like to send you a new one which the mcu is stm32, please send me your shipping address to my email niujl123@sina.com

Hello @markniu, I appreciate the offer, thanks! I just wrote you an email with my shipping address.

[aero4]

Hi @markniu!

Today I received the new sensor you sent me, thanks again!

The output of M102 S-1 now returns BD Sensor version:V1.2c pandapi3d. I re-calibrated the sensor and the raw calibration data is now:

Calibrate data:0,124
Calibrate data:1,143
Calibrate data:2,170
Calibrate data:3,195
Calibrate data:4,224
Calibrate data:5,252
Calibrate data:6,282
Calibrate data:7,312
Calibrate data:8,342
Calibrate data:9,372
Calibrate data:10,402
Calibrate data:11,432
Calibrate data:12,461
Calibrate data:13,492
Calibrate data:14,518
Calibrate data:15,547
Calibrate data:16,572
Calibrate data:17,599
Calibrate data:18,623
Calibrate data:19,647
Calibrate data:20,672
Calibrate data:21,694
Calibrate data:22,715
Calibrate data:23,737
Calibrate data:24,756
Calibrate data:25,775
Calibrate data:26,794
Calibrate data:27,811
Calibrate data:28,825
Calibrate data:29,842
Calibrate data:30,856
Calibrate data:31,871
Calibrate data:32,883
Calibrate data:33,895
Calibrate data:34,908
Calibrate data:35,920
Calibrate data:36,931
Calibrate data:37,940
Calibrate data:38,949
Calibrate data:39,1015

So, except of the last value the range is way better now!

I also don't have retries anymore! So my first sensor was either a faulty one or the version 1 with the STC microcontroller has it's flaws.

I only saw one bug existing (I already had with the first sensor): My home position is negative (#define X_MIN_POS -7 and #define Y_MIN_POS -5). When I directly start G29 after homing, the sensor seems to start measuring too early because I have multiple retries (>6) at the first measuring point which causes G29 to stop. Therefore I added the following line just before G29: G0 X50 Y50 Z1 F9000 ; go to position 50/50 (avoids G29 bug) When starting with a positive value everything works fine.

Btw. this is how the G29result looks like. I definitely need many points for my print bed and without your BD-Sensor this grid would take ages and wouldn't be viable vefore every print! I also saw that with the first BD-Sensor I only had positive values and with the new sensor also negative values which is way more logical!

[thisiskeithb]

I only saw one bug existing (I already had with the first sensor): My home position is negative (#define X_MIN_POS -7 and #define Y_MIN_POS -5). When I directly start G29 after homing, the sensor seems to start measuring too early because I have multiple retries (>6) at the first measuring point which causes G29 to stop. Therefore I added the following line just before G29: G0 X50 Y50 Z1 F9000 ; go to position 50/50 (avoids G29 bug) When starting with a positive value everything works fine.

Ensure that X0, Y0 is the front-left corner of your bed and that you've properly setup PROBING_MARGIN.

[aero4]

Ensure that X0, Y0 is the front-left corner of your bed and that you've properly setup PROBING_MARGIN.

Yes, X0 and Y0 is in the front left corner. And PROBING_MARGIN is set to 10, which seems suitable for me...

[github-actions[bot]]

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.