Error Probing Failed

Hi folks,
Made some improvements/activation of features:

  • BLtouch is probing a little faster and doing 3 probes in each probing point and take the average of them (I think with my tests this approach is more reliable);
  • Activated EXTRAPOLATE_BEYOND_GRID function (to extrapolate probing grid where BLtouch can't go)
  • Activated M600 - Filament Change feature (see in Marlin manual);
  • Removed Smith3D url in titles (just aesthetics, the features in menu are 100% developed by them so all credits for them!)

firmware-20210222-172838.zip (119.1 KB)

It would be nice if you also include the sources
So other users can check which things you changed and build the firmware on their own :slight_smile:

I was just about to mention this. I like your (@phenriques3000) firmware very much, but I do intent to add a Bullseye mod (Petsfang v2) which requires custom values for my BLTouch offset in the firmware.
Unless there's another way off course?

Hi folks,
The only changes I made was in the configuration, the firmware core are based on the bugfix-2.x of Marlin.
Anyways please use my git repository, I made it public some minutes ago:

3 Likes

You're the greatest. I'm also running your latest firmware firmware-20210222-172838.zip and works great. :+1:t3:

Hi folks,

I have encountered the exact same issue. Same log, same fix with phenriques3000 firmware. Interesting thing : I had the issue with Jyer firmware, which replaced the smith3D one (see latest news here).

I could have stop here, but as grateful I am with phenriques work, I use a filament sensor which is not supported by this firmware. Building my own firmware is not a option at the moment, I would love to learn how to but I lack of time.

I read around here that it might have something to do with a "#define Z_PROBE_LOW_POINT" value. That's when it hit me : I have a -3.05 z-offset. I realized that Smith3D suggest to print a BL Touch mount. I didn't do that because I bought the creality BLTouch kit espacialy made for ender 3 v2, so a metal mount was already provided. So I printed the v2 version, which give me a -0.12 offset. I tried the Jyers firmware again and find out that with a lower z-offset, it works without any issue.

Did you guys used the original mount, and do you have a "big" z-offset value, around -3 ?

If that's the case, maybe we can make a suggestion for a pull request on the Jyers firmware to fix this value !

Z_PROBE_LOW_POINT defines the lowest probing point.
That means if a probing point is lower than that value (compared to the initial Z homing point) the probing will be stopped.
I guess your bed was very uneven if the probing failed because of that.

Thank for your answer PrintedWeezl and thank you for your work : without this forum, I would never have found a solution to this issue.

But no really, it isn't a matter of uneven bed: it was perfectly leveled, as that was the case for @Fil , @phenriques3000. I didn't save the bed levelling value at that time, but the fact was that I was able to print without any issue from SD card, and that the probing failure happens only with the Jyer firmware when trying to print from octoprint. Without modifiying leveling at all and only updating the firmware with @phenriques3000 one's, it solved the issue : I was able to print sucessfully from octoprint and the SD card with the same bed leveling.

What I'm trying to say here is that this is due to the firmware (old Smith3D or Jyers) which doesn't accept the z-offset that the official creality BLTouch mount need, which is around -3mm.

I don't have the skill to provide a fix for the Jyers firmware, but if someone met the same issue, we now have a explanation about why one firmware work and the other doesn't.

1 Like

Hey all... I’m new to all this and usually make myself sound really, really stupid lol but I too was having these probing issues. Seemed I could print off the SD card fine but the moment octoprint came into the equation my probing success rate dropped to like ~30% success. I’m using the jyers firmware with some custom tweaks specific to my needs(mainly size, speeds and probing grid) I have tested from stock creality firmware(ew) to preconfigured firmwares(not just jyers) looking for a fix. Given how all of them gave me similar results I’ve settled on the jyers cuz damn is it awesome.

Per this thread I saw that enabling the 5v in configuration.adv fixed many’s issues here. I made that change myself in the firmware and was able to achieve a 100% success rate when it came to probing with prints using octoprint. Before @phenriques3000 found the 5v thing the workaround to this (per jyers GitHub)was to set octoprint to ignore errors however under these settings the probing would still fail at about the same failure/success rate as before I just wouldn’t have to power cycle the printer to get it out of its m112 state.I also wasn’t comfortable with it “skipping” however many points were left and just moving to the print. when I posted this potential fix on the jyers GitHub (here: BLTouch 3.0 and 3.1 Info/ Possible fix for M112 failed probing · Discussion #603 · Jyers/Marlin · GitHub )many on the GitHub are saying this is damaging to our printers. That the processor is a 3.3v system.

I’d love to help get a proper fix to this. I’m new to the whole 3D printing world but I am sorta tech savvy. Curious what others think about the whole 5v situation or not. Have you guys been running it with no errors this whole time?

I’d like to get 100% success rate in probing as well as use octoprint but I’m not sure if it’s the bltouch(which seems to work) octoprint(which also seems to work) or the printer(again all in good working order) or the firmware settings. I don’t want to fry my main board by over volting but I really want the same success in probing as my cr10 v3 with the exact same bltouch kit

Hi @DeathDonky,
If your BLTouch is the version 3.0 or 3.1 you can and must use the 5v.
This will not fry your mainboard, if something is possible to fry is the BLtouch if you are not using the correct one (after all we are controlling the output voltage from the mainboard to the BLtouch not the opposite...).
I'm still using the firmware I posted here and I can say that I print almost every days things in the printer and with 100% success rate since day 1 of the firmware!
Just for info the BLtouch have itself a couple of resistors to regulate the voltage inside from 3.3-5v input to 3.3v so this is why I think the BLtouch works better if we apply the maximum input voltage (5v, you can check this in documentation from Antlabs) and in this case if we have some input fluctuations it doesn't matter because the input voltage to the BLTouch will always be more than 3.3v.
Hope this explanation helps.

Couple things to rebuddle... I took a multi meter to my bltouch. The voltages going TO the bltouch did not change weather I have the enable 5v commented or not it ALWAYS received 5v across the black and white wire. According to others on the GitHub enabling that 5v sends a 5v signal to the processor through the signal wire(it’s too fast for me to get a solid reading from with my equipment) and on the specific pin the bltouch sends that signal to it is not a 5v compatible pin according to the data sheet for the processor. Also according to the data sheet for the bltouch(I do have a 3.1 genuine bltouch so that is the one in question here) you should NOT enable the 5v on a 3.3 volt system like what on the 4.2.2 board. It’s actually in red print on the data sheet.

What you’re saying and what GitHub is saying are opposite. I’d like to know which one is right AND safest.

ok so i had the same error as described here. I used the one from the creality website, and nothing, still my probe would randomly just drive down and then start falshing and i need to cut power to booth Rpi and printer
I tried the newest creality firmware, no success
Tried the older one, no success
i tried the smith3d one, also no success (and weirdly no fancy display or an advanced settings menu...)
i was really close to just scrap it and send it back and try my luck again with manual leveling (i didnt even think about putting it onto the sd card because i hate running down stairs x'D)

well now i have found this here through the magic of google, and someone tells me heres a firmware that works, and im currently printing once thing to see if it does.

one question, is it normal that the probe lowers down, but then isnt retracting again until finished with all points? if so, good

and it just finished probing the 5x5 grid and it works, no failure so far where i had today nothing but failures (just not when i started the leveling via display)

soo since this works so far i hope it will be for a while. i really do hope
so thanks already for your work @phenriques3000 for that firmware that -works-
you dont know how many hours i used up on google and youtube and other portions of the internet trying to find a fix or atleast see what is wrong with my printer.
and it is printing now. My dear god finally

Thanks for that. I appreciate it. Everything is running smoothly right now.

Hi, I downloaded your software which solved the problem with BL Touch. I just can't seem to set the Z-Offset. When I set it, the Extruder won't start. Thanks a lot for the information or the video with settings :slight_smile: Greetings

Apologies for digging up an old thread, but this is where I got my fix about a year back when I was getting probe errors/failures from octoprint with the BL touch enabled firmware I was running back then. The firmware mentioned here resolved that issue and have been using it since without issue. Big thank you to @phenriques3000.

The reason I'm back is that I'm looking at adding a filament runout sensor to the printer and couldn't see any 'advanced' menu option from this firmware. The guides I'm finding out on the interwebs all seem to mention JyersUI firmware (and the advanced menu); which is what I was running before this fix and was showing the probe problems.

Is anyone using a runout sensor with @phenriques3000 firmware?

Have never compiled my own firmware for this printer,.. Is it a matter of just uncommenting 'FILAMENT_RUNOUT_SENSOR' in 'Configuration.h' ? Or is there more involved?

Will this expose the 'advanced menu' as I was expecting to enable it and set some values for 'load length' and 'unload length' there from a youtube I was looking at).

Or are these equivalents to:

  • FILAMENT_CHANGE_UNLOAD_LENGTH
  • FILAMENT_CHANGE_SLOW_LOAD_LENGTH and
  • FILAMENT_CHANGE_FAST_LOAD_LENGTH' ?

Apologies for dragging up the topic, any help would be appreciated.

Thanks,

Jim.....