Marlin
Marlin copied to clipboard
E3V2-UBL-BLTouch-10x10-v4.2.2-v2.0.1 HS
Description
Steps to Reproduce
-
[During the mesh creation at point 42 of 100 the BLtouch probe retracts fully and pushes nozzle into the bed and starts back correct at point 43 to the end.
-
Created many meshes with same results
Expected behavior: [What you expect to happen]
Actual behavior: [What actually happens]
Additional Information
- Include a ZIP file containing your
Configuration.h
andConfiguration_adv.h
files. - Provide pictures or links to videos that clearly demonstrate the issue.
- See How Can I Contribute for additional guidelines.
I also experienced this with the same E3V2-UBL-BLTouch-10x10-HS-v4.2.2-v2.0.1.bin firmware using a CRtouch. The probe retracted after (or during) point 42 and nozzle crashed into bed.
Taken from my octoprint.log: 2021-11-21 03:07:38,949 - octoprint.plugins.action_command_notification - INFO - Got a notification: Probing Failed 2021-11-21 03:07:38,955 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Probing Failed | Last lines in terminal: | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: Probing mesh point 39/100. | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: Probing mesh point 40/100. | Recv: echo:busy: processing | Recv: T:30.92 /0.00 B:60.00 /60.00 @:0 B@:22 | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: Probing mesh point 41/100. | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: echo:busy: processing | Recv: //action:notification Probing Failed | Recv: Error:Probing Failed
Probing did complete after point 42. I tried re-probing and it happened again at the same point so it is a repeatable failure. I switched to E3V2-UBL-BLTouch-10x10-v4.2.2-v2.0.1.bin and have not experienced it since. Seems to be BLTOUCH_HS_MODE causing the issue, but why specifically at point 42 every time I haven't figured out.
I had a similar issue with the CRTouch where it would randomly fail a probe, while using that exact firmware. What fixed it for me was moving the CRTouch cables for OUT and G (the two top ones) to the Z stop header instead and compiling the firmware myself. No issues since. https://github.com/alexanderhenne/Marlin/commit/02d7b81baff282ed938fe2d154ba85f5a0ffe3e1 (this is with 15x15 but 10x10 works too)
I haven't had this issue using a newly purchased CRTouch on same firmware.
I have this same issue with a CRTouch. I also believe it makes my meshes very inaccurate
EDIT: After reinstalling the firmware, I can now probe 65 points. I've never been able to reach 100 on the 10x10
I'm running E3V2-UBL-BLTouch-10x10-HS-v4.2.2-v2.0.1 with a CR touch and have not had any issues. I did find once that after many hours of printing, the bed seemed to lower some 10's of microns (or more likely the frame grew) and the first layer would no longer stick. I attributed it to heat propagation from the long runtime and built another mesh which I stored in address 1 instead of overwriting the current mesh in 0. Now I can switch between the two. I did change my bed to solid mounts (silicone standoffs) right after installing the CR Touch. I've been happy with the Jyers Firmware (and the CR-Touch). Thanks.
On my 4.2.2 E3V2, running E3V2-UBL-BLTouch-10x10-v4.2.2-v2.0.1 -- my machine will only ever test 65 points, aka it says 65/100 then goes to complete. Interestingly the Mesh shows a 10x10 grid when viewing, but it didn't probe 100 points. I wonder if it's locked doing an 8x8 grid?
On my 4.2.2 E3V2, running E3V2-UBL-BLTouch-10x10-v4.2.2-v2.0.1 -- my machine will only ever test 65 points, aka it says 65/100 then goes to complete. Interestingly the Mesh shows a 10x10 grid when viewing, but it didn't probe 100 points. I wonder if it's locked doing an 8x8 grid?
I never watched it run the whole 100 probes before. I just checked, and my E3v2 is also quitting after 65 probes. I wonder if it extrapolates the additional probe points. My probe also retracted two or three times, I didn't notice the probe count.
Here's some info I found over at the Marlin site (https://marlinfw.org/docs/features/unified_bed_leveling.html)... Filling in the Mesh UBL includes a third phase, G29 P3, which fills in points on the mesh that were not probed automatically or manually. Note that unlike in bilinear leveling, UBL does not automatically extrapolate correction beyond the bounds of the mesh. If a mesh point is not defined no correction will be applied, and a missing point can affect up to 4 mesh cells. The text continues if you'd like to go read it.
I suspect the firmware decides there are areas of the bed that are unreachable and fills in those points with extrapolated elevations; which would explain why it displays 100 points in the viewed mesh. In the end the created mesh does work well for me. I've had - no issues - with the Z crashing into the bed.
Perhaps - Maybe I'm expecting too much here from the firmware - my sense was, saying it's X/100 for probing positions is misleading if there's no expectation for the machine to be physically probing 100 points. But eh, fair enough, if it's averaging then all good.
Perhaps - Maybe I'm expecting too much here from the firmware - my sense was, saying it's X/100 for probing positions is misleading if there's no expectation for the machine to be physically probing 100 points. But eh, fair enough, if it's averaging then all good.
I did some more research, and it seems probing 65 points when set to 10x10 is in fact normal operation. Upon completion the display states that - all reachable points - have been probed. This has to do with the offset of the probe from the nozzle.
It seems this has caused confusion multiple times and indeed an firmware tweak would be good. In the short term it could be stated for example. "Up To 10x10". I suspect the number of points to be probed can be calculated ahead of the probing operation. In which case, displaying... X (1 to 65) of 65 points probed would be clearer instead of... X of 100. Or a statement 10X10 selected - 65 points reachable. It's probably on the developers list of to-do items, but there are more pressing issues since it's working properly and just mis-reporting.
Came looking for this same very specific thing. The probe is retracted and the nozzle crashed, on point 41, 10x10 HS
Additional info: When the probing stops after point 65, I get the error "Unknown command: "5"" in my pronterface log.
can confirm crashing on point 42 with HS 10x10 UBL and stopping at 65 with you want to save eeprom, mesh looks ok
Same here. Happens every time I create a new mesh. Thought it might be a sick joke referencing HHGTTG
I am experiencing the same issue. Points 42, 84, 126. For the 15x15 HS firmware (actually Alex's firmware for Aquila, but same base code)