[BUG] Delta with MicroProbe V2 Fails Auto Calibration and Bed Level

ant0nyk1ng commented 1 month ago

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

Yes, and the problem still exists.

Bug Description

I have test the latest Bugfix and the Biqu MicroProbe Version and all have the same result as described.

This is a new build and I have printing with a Anycubic Magnetic Removable Probe (Like on the Anycubic Predator) This has been faultless and was able to Auto Calibrate and create Bed Mesh without any errors. I would prefer a fixed probe with retractable pin and the MicorProbe being so small I can fit it under the effector and thus the upgrade.

I have setup the MicroProbe as per the online Manual.

The probing is random on when it fails, it sometimes just probes the one point a few times and then moves a large amount in Z then fails or sometimes crashes into the bed.

On deploying and moving to the bed, it appears to ignore the NOZZLE_TO_PROBE_OFFSET for X and Y

On the one time it finish the first iteration but failed on returning to Home the saved the Height to about 650mm and should be aprox 700mm and the Radius to a very small negative number.

Bug Timeline

No response

Expected behavior

Run Auto Calibration and complete.

Actual behavior

Every time Auto Calibration runs it fails at a different time probing the bed. If it finishes probing the bed it fails as it homes for the second probe iteration.

Configuration.zip

Steps to Reproduce

No response

Version of Marlin Firmware

2.1.2.3

Printer model

Delta

Electronics

SKR 1.4 Turbo

LCD/Controller

TFT35 in Marlin mode

Other add-ons

No response

Bed Leveling

None

Your Slicer

None

Host Software

None

Don't forget to include

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

Additional information & file uploads

No response

thisiskeithb commented 1 month ago

Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

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 Pronterface, Repetier Host, or OctoPrint.
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.

ant0nyk1ng commented 1 month ago

Ok I revisited the latest Bugfix and the same issues prevails.

Here are the config files and also I have added the ouput from Pronterface with G28 and G29

Configuration.zip

Here is G33 from Pronsole output. On this occasion the fail was after probing the bed but before it got to the Home Position.

G33_Pronsole_output.zip

classicrocker883 commented 1 month ago

MicroProbe V2 has certain requirements, I'm not so sure about Delta, but here it is for a bed slinger:

#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_MIN_ENDSTOP_HIT_STATE LOW
#define Z_MIN_PROBE_ENDSTOP_HIT_STATE LOW
//#define BLTOUCH
#define BIQU_MICROPROBE_V2
#define PROBE_ENABLE_DISABLE

ellensp commented 1 month ago

MicroProbe requires a pin with a pull up on the trigger signal, its not as board agnostic as other probes.

This is why we have the warning

#warning "BIQU MicroProbe V2 detect signal requires a strong pull-up. Some processors have weak internal pull-up capabilities, so we recommended connecting MicroProbe SIGNAL / GND to Z-MIN / Z-STOP instead of the dedicated PROBE port. (Define NO_MICROPROBE_WARNING to suppress this warning.)"

Since the SKR V1.4 officially only has 3 endstop plugs and they are all used on a delta, you used the probe port but there is no pullup on P0_10 probe port pin

Try the E1 Det port (It looks unused from a quick scan of Config) Ie P1_25, it has a external pullup

ant0nyk1ng commented 1 month ago

MicroProbe requires a pin with a pull up on the trigger signal, its not as board agnostic as other probes.

This is why we have the warning

#warning "BIQU MicroProbe V2 detect signal requires a strong pull-up. Some processors have weak internal pull-up capabilities, so we recommended connecting MicroProbe SIGNAL / GND to Z-MIN / Z-STOP instead of the dedicated PROBE port. (Define NO_MICROPROBE_WARNING to suppress this warning.)"

Since the SKR V1.4 officially only has 3 endstop plugs and they are all used on a delta, you used the probe port but there is no pullup on P0_10 probe port pin

Try the E1 Det port (It looks unused from a quick scan of Config) Ie P1_25, it has a external pullup

Ok yes I saw the warning but because it was probing I assumed it to be fine.

I setup the pin P1_25 as suggested... funny how you try every combination of what is possible and the answer was in the Warning all the time... bugger.

So yes this seems to have resolved the issue... I will do a few print tests just to be sure but it works as expected. Thanks for that it was driving me crazy.

My thoughts: As for the MicroProbe and this issue... I think it needs to be better documented with maybe even just suggested things to try/trouble shoot. The difference looking at the probing from the outside, well it looks identical but a fail or a win depending on the pin... and for us less knowledgeable folks... I would have assumed this warning didn't apply to my setup if it was probing away without the obvious connection to the "detect signal requires a strong pull-up".

ant0nyk1ng commented 1 month ago

Lol it wont Bed level now?

Connecting... Printer is now online.

g28 SENDING:G28 echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing g29 SENDING:G29 echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing Error:Probing Failed [ERROR] Error:Probing Failed

Given this is new to what I have partly resolved... I will do a fresh firmware just to make sure I haven't inadvertently changed something simple in my effort to "try every possible thing" to resolve the first issue.

ellensp commented 1 month ago

Revisit the first reply, enable all the logging

classicrocker883 commented 1 month ago

before I was able to finally figure out using this probe, someone else was able to make it work like so: (because of the pull-up resistor situation - they ended up reverting the wiring configuration to the Z endstop only)

https://github.com/classicrocker883/MRiscoCProUI/issues/118#issuecomment-2041601506

what i did is i took wires that i had and soldered them to two outputs on the ground and trigger signal so they where now 4 wires instead of 2 then i wired it to both the bltouch area and z axis area

https://github.com/classicrocker883/MRiscoCProUI/issues/118#issuecomment-2041602524

ant0nyk1ng commented 1 month ago

Ok checked over the latest bugfix firmware and ran some reports with M111 S247

G28 G28_Pronterface_output.zip

G29 G29_Pronsole_output.zip

Config files Configuration.zip

So as per the conversations above running G33 runs successfully every time and G28 works every time as well.

G29 is random... starts fine but after sometimes 2 probes but sometimes 10... it fails.

OK even weirder... I just ran it again from the LCD and it completed (at least appeared to complete) but when I reset the printer and ran it again it stopped after about 6 probes... and with No error on the LCD.

ant0nyk1ng commented 1 month ago

I was using Bilinear Bed Leveling so I turned on UBL and Building a Cold Mesh resulted in a fail so I took a video and you can see it is not right... and towards the end it starts to probe in the air before it fails.

https://github.com/MarlinFirmware/Marlin/assets/19344094/8bf26027-b1e9-4b7b-87d9-a6040c41e71e

classicrocker883 commented 1 month ago

try adding one of those ferrite cores around the wires. maybe its EMI interference.

because this probe is really small, maybe whats happening is the probe isnt seated down far enough. or the Z_PROBE_LOW_POINT isnt low enough
// (mm) Farthest distance below the trigger-point to go before stopping

ant0nyk1ng commented 4 weeks ago

try adding one of those ferrite cores around the wires. maybe its EMI interference.

because this probe is really small, maybe whats happening is the probe isnt seated down far enough. or the Z_PROBE_LOW_POINT isnt low enough // (mm) Farthest distance below the trigger-point to go before stopping

Ok I set Z_PROBE_LOW_POINT -3 (it was -2) should I go more?

I added the only type of ferrite I had in my draw of electronic bits. No difference and if I took a video it would look exactly like the one from before.

Where is the best place for the ferrite? at the probe end or the MB end... or both I do have 2 more ferrites.

ant0nyk1ng commented 3 weeks ago

Ok after failing with AUTO_BED_LEVELING_LINEAR, AUTO_BED_LEVELING_BILINEAR, and AUTO_BED_LEVELING_UBL never finishing without starting to probe in the air and failing.

So I tried AUTO_BED_LEVELING_3POINT and it seems to run and finish with no errors at all?

I will do a couple of calibration prints to see if I get a good first layer covering the whole bed.

Update: well yes it does work fine and seems pretty even on a flat glass plate... does concern me that with a magnetic bed and removable plate it won't be quite as flat... so although it works fine the aim would be to have the other more comprehensive bed leveling work as expected.

classicrocker883 commented 3 weeks ago

should not matter where the ferrite core goes. it doesn't hurt having one even if there's no change.

Ok I set Z_PROBE_LOW_POINT -3 (it was -2) should I go more?

you can try setting this as low as you'd like. if it is even 10mm above , go for -10. the reason for it being near 0 to begin with is so it doesn't crash into the bed incase.

what do the coordinates measure at each time the probe doesn't contact vs when it actually does? and if your printer (a delta) isn't going down far enough, and it goes higher and higher at the end, perhaps it thinks the bed is at a skew? just imagine the X-Y plane where the printer thinks it is, vs where it actually is, and it is as if you're holding a flat surface but at an angle above the actual bed.

maybe there is an issue with the motors not being "in sync". you would know if this is the issue if prints aren't dimensionally accurate by disabling bed leveling altogether.

ant0nyk1ng commented 3 weeks ago

should not matter where the ferrite core goes. it doesn't hurt having one even if there's no change.

Ok I set Z_PROBE_LOW_POINT -3 (it was -2) should I go more?

you can try setting this as low as you'd like. if it is even 10mm above , go for -10. the reason for it being near 0 to begin with is so it doesn't crash into the bed incase.

what do the coordinates measure at each time the probe doesn't contact vs when it actually does? and if your printer (a delta) isn't going down far enough, and it goes higher and higher at the end, perhaps it thinks the bed is at a skew? just imagine the X-Y plane where the printer thinks it is, vs where it actually is, and it is as if you're holding a flat surface but at an angle above the actual bed.

maybe there is an issue with the motors not being "in sync". you would know if this is the issue if prints aren't dimensionally accurate by disabling bed leveling altogether.

I tried -10 and same result.

As per the description... this printer was working without fault with the Anycubic removable Magnetic Probe. It could probe the bed in Linear, Bilinear and UBL perfectly and never had an error. It printed a perfectly flat and even 0.2mm test files at 380mm diam across the bed... so we can rule out any mechanical issues.

This issue seems to be related to firmware and how this MP probe code is different to BLtouch and Anycubic removable Probe. I do vaguely remember the first time I put a BLtouch on a Delta years ago (when BLtouch was new system) had similar issues that where eventually resolved.

Only thing other than it failing that I find odd is:

With a Cartesian Printer the probe will probe the bed at what would be the nozzle center and so would observe the NOZZLE_TO_PROBE_OFFSET for X and Y while probing.

The Delta probes the bed with the nozzle on center and the probe off... so ignoring the NOZZLE_TO_PROBE_OFFSET for X and Y. It seems to observe the PROBING_MARGIN and not probe outside the bed but it did seem odd to me and maybe a clue?

classicrocker883 commented 3 weeks ago

so youre saying that a BLTOUCH works with your machine and the MicroProbe does not?

have you adjusted the NOZZLE_TO_PROBE_OFFSET to see if that makes a difference?

I would try disabling PROBING_MARGIN altogether, set it to 0.

ant0nyk1ng commented 3 weeks ago

so youre saying that a BLTOUCH works with your machine and the MicroProbe does not?

have you adjusted the NOZZLE_TO_PROBE_OFFSET to see if that makes a difference?

I would try disabling PROBING_MARGIN altogether, set it to 0.

On this Delta no... I don't have one spare atm... this was on another Delta back when BLtouches where the "new kid on the block" but thinking now I have setup a HE3D Delta with a Bltouch a few years ago and it worked fine.

I will try the other suggestions

ant0nyk1ng commented 1 week ago

so youre saying that a BLTOUCH works with your machine and the MicroProbe does not?

have you adjusted the NOZZLE_TO_PROBE_OFFSET to see if that makes a difference?

I would try disabling PROBING_MARGIN altogether, set it to 0.

Ok I have tried both suggestions and the results are the same as far as Auto Bed Leveling and again only 3Point Bed Leveling works without failing.

Changing the NOZZLE_TO_PROBE_OFFSET does seem to change the probing pattern... so I think it is working and not ignored but just different to Cartesian and maybe by design.

MarlinFirmware / Marlin