Communication timeout during homing probe Z

[shlo-mix]

Hi

So this wired bug is only happens while doing a probing operations with BDsensor not mesh or calibrations.

HW: Voron trident 350mm BTT M8P Klipper Version: v0.12.0-61-gb50d6669 BTT EBB36 1.2, Klipper Version: v0.12.0-61-gb50d6669, CAN communication M102 s-1 V1.1 pandapi3d.com

Calibration data: 977 964 ... 290 266 245 also M102 S-2 Sensor measures distance look accurate

Homing: Homing of X, Y is successful, when its start doing Z homing I get "Communication timeout during homing Z" :

8:58 PM Z axis triggered at 0.000 mm 8:58 PM warning:triggered at 0mm, Please slow down the homing z speed and the position_endstop in BDsensor >=0.5 8:58 PM triggered at 10.150 mm ! 8:58 PM Communication timeout during homing z

After this failure:

• klipper on mcu EBBCan is busy MCU load going up from 2% to 20% then back to 2%
• "bytes retransmit state" going up from zero to about 150
• the communication with probe is very slow (M102 sS-5 take more then a minute).
• if I try do to second home it fails instantly on x axis: "Communication timeout during homing x"

So its look like a bug that overload MCU preventing communication. klippy (14).log

If under printer.cfg I disable the "probe:z_virtual_endstop" and use the mechanical z endstop pin the homing of x,y,z is successful. also I can use the BDsensor to do Mesh via Hightmap tab and it's really nice to see mapping results ,communication is still good and fast, (bytes_retransmit =0, bytes_invalid = 0.)

But as soon that I try to do Z_TILT probing, I get communication issues: "Communication timeout during homing probe" followed by: Z axis triggered at 0.900 mm

Then again the com is very slow, "bytes_retransmit" is about 150.

Its seems that only probing operations with BDsensor causing mcu load preventing communication, only reset can solve it sometimes I need power-cycle

[markniu]

try to decrease the value of position_endstop in BDsensor section to about 1mm, and delete the position_endstop in[stepper_z]

Back to the topic unfortunately it faild to do homing: Internal Error on WebRequest: gcode/script klippy (18).log

[shlo-mix]

I changed the position_endstop in BD sensor from 1.99 to 1mm, under stepper_z is was already commented out, I got same result

Important to say that when Z home start its going to the wrong direction, away from tool-head, (distance from plate to BD is increasing )

[markniu]

this new feature of home for the V1.1 seems need more test, I will test more.

I changed the position_endstop in BD sensor from 1.99 to 1mm, under stepper_z is was already commented out, I got same result

Important to say that when Z home start its going to the wrong direction, away from tool-head, (distance from plate to BD is increasing )

[shlo-mix]

Flashed FW V1_1BDsensor20240210.hex, with latest repo, my test results feedback:

1. The homing is working :)
2. The TILT is almost working: It's doing the calibration successfully (the TILT button is blue), but at the end it report error: "Home z failed! the triggered z position is 10.150 mm" "triggered at 10.150 mm !"

Also, if bed not completely leveled before, TILT will fail (triggered at 0mm or something like that).

[shlo-mix]

3. mesh most of the time fails: "Bed Distance Sensor, out of range.:10.15" klippy (19).log before update mesh never failed.

[markniu]

you can manual move the nozzle to the failed point and checked it by M102 S-2. BTW, please send me your email address via the email, and I would like to send you the V1.3 hardware to test.

3. mesh most of the time fails: "Bed Distance Sensor, out of range.:10.15" klippy (19).log before update mesh never failed.

[shlo-mix]

M102 S-2 = 0.99mm -It failed in 2 different places, after few retries I can have successful Mesh without any magor dips or peaks, so its mostly random reading error.

• If disable "no_stop_probe" it still fail

[shlo-mix]

updated to new e821238 commit and V1_1BDsensor20240212.hex With latest code klipper report syntax error on line 1212: I fixed this typo and now TILT ending successfully without errors. so both issue 1 and 2 are now working very good without any issues or timeout. Great job!

• Issue 3 still exists, Mesh still report "Bed Distance Sensor, out of range.:10.15", when actual value is valid (M102 S-2 =0.98mm)

[shlo-mix]

With latest ver, issue 3 was fixed. MESH is stable now.

Thank you!

[markniu]

if you have time you can test this new feature of collision sensing. here is the tutorial on how to use the Collision sensing: https://github.com/markniu/Bed_Distance_sensor/wiki/Collision-sensing

[shlo-mix]

First let me say that I run a macro with 20 cycle of full homing, TILT and Mesh without any issue it is very stable now. Will try to test accuracy, Z probe speed and temperature later.

I did tried collision_homing:1 with second_homing_speed: 1.5 The tool head crashed into bed , stopped it manually when the Z motor start loosing steps.

[markniu]

you mean it did not stop itself after it crashed into bed?

I did tried collision_homing:1 with second_homing_speed: 1.5 The tool head crashed into bed , stopped it manually when the Z motor start loosing steps.

[shlo-mix]

Yes, after that the nozzle touched It didn't stopped Using Trident - one Z motor on the rear and 2 in the front, the stepper motors continue rising the bed the rear Z stepper was starting to loose steps, so the bed wasn't horizonal anymore. I had to stop in manually.

[markniu]

how about decrease the current of the z motor or slow down the z axis homing speed(not the second homing speed)? if the nozzle touch on the bed the distance measured by the bdsensor will be no change or changed a little then give a switch signal to the klipper mcu. so if the current of motor too high and the bed continue rising too much then bdsensor can not recognize it stopped.

[shlo-mix]

It was already loosing steps while homing, also I will reduce current might loose steps while printing. I will try to reduce speed of primary homing.

[tjengbudi]

hello, i got bd sensor v1.1. and i got always out of range.:10.15 how to solve this?

[markniu]

hello, i got bd sensor v1.1. and i got always out of range.:10.15 how to solve this?

you can comment out this line no_stop_probe: and it will stop at the out of range point, then send M102 S-2 to see if it is out of range in actually.

[dralkaar]

I got a v1.1 sensor and yesterday I tried to install it on my 2.4. The installation was easy as always, did the configs and everything but... I'm using a canbus board (EBB SB2209) and after a few home/QGL I get a timeout error. I tried all the fixes I could find here and nothing works. The sensor works perfectly on my other printer (connected directly and not using CAN) so I suspect that CAN usage is a no go (al least at this moment).

[tjengbudi]

Mine, sometimes it cannot detect at all.

Suddenly it can detect. But after mesh bed it really has strange result.

On Fri, May 17, 2024, 7:18 PM dralkaar @.***> wrote:

I got a v1.1 sensor and yesterday I tried to install it on my 2.4. The installation was easy as always, did the configs and everything but... I'm using a canbus board (EBB SB2209) and after a few home/QGL I get a timeout error. I tried all the fixes I could find here and nothing works. The sensor works perfectly on my other printer (connected directly and not using CAN) so I suspect that CAN usage is going a no go (al least at this moment).

— Reply to this email directly, view it on GitHub https://github.com/markniu/Bed_Distance_sensor/issues/74#issuecomment-2117473309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXGEPZRAI3DSAOX73PSIKLZCXYQFAVCNFSM6AAAAABBXBD6ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJXGQ3TGMZQHE . You are receiving this because you commented.Message ID: @.***>