Marlin icon indicating copy to clipboard operation
Marlin copied to clipboard

E3V2-UBL-BLTouch-10x10-v4.2.2-v2.0.1 HS

Open natewils opened this issue 3 years ago • 14 comments

Description

Steps to Reproduce

  1. [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.

  2. 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 and Configuration_adv.h files.
  • Provide pictures or links to videos that clearly demonstrate the issue.
  • See How Can I Contribute for additional guidelines.

natewils avatar Nov 20 '21 07:11 natewils

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.

Silenstryke avatar Nov 21 '21 07:11 Silenstryke

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)

alexanderhenne avatar Nov 22 '21 20:11 alexanderhenne

I haven't had this issue using a newly purchased CRTouch on same firmware.

Naomarik avatar Nov 28 '21 08:11 Naomarik

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

Sirnut avatar Dec 06 '21 04:12 Sirnut

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.

YClayton avatar Dec 15 '21 04:12 YClayton

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?

GraphiteCA avatar Dec 16 '21 01:12 GraphiteCA

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.

YClayton avatar Dec 16 '21 02:12 YClayton

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.

GraphiteCA avatar Dec 16 '21 06:12 GraphiteCA

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.

YClayton avatar Dec 16 '21 17:12 YClayton

Came looking for this same very specific thing. The probe is retracted and the nozzle crashed, on point 41, 10x10 HS

ghost avatar Dec 21 '21 06:12 ghost

Additional info: When the probing stops after point 65, I get the error "Unknown command: "5"" in my pronterface log.

Patrixe avatar Jan 11 '22 22:01 Patrixe

can confirm crashing on point 42 with HS 10x10 UBL and stopping at 65 with you want to save eeprom, mesh looks ok

nmkr avatar Jan 15 '22 21:01 nmkr

Same here. Happens every time I create a new mesh. Thought it might be a sick joke referencing HHGTTG

siahfri avatar Feb 04 '22 19:02 siahfri

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)

brdenos avatar Apr 06 '22 15:04 brdenos