[BUG] Inconsistent G34 Behavior (Quad Z)

[fiveorders]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Every G34 result is different. Sometimes it says accuracy achieved, sometimes it says accuracy deceiving and sometimes just numbers instead of those two.

Bug Timeline

Seems like an old issue

Expected behavior

Accuracy Achieved

Actual behavior

Accuracy Decreasing or numbers instead

Steps to Reproduce

G34 multiple times

Version of Marlin Firmware

2.0.x bug fix latest release

Printer model

Quad Gantry Core XY

Electronics

Octopus

Add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Prusa Slicer

Host Software

SD Card (headless)

Additional information & file uploads

No response

[peter-neu]

I think i have the same Problem, ordered a new probe because i thougth it is broken and delivers inconsistent values.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[fiveorders]

I think i have the same Problem, ordered a new probe because i thougth it is broken and delivers inconsistent values.

It is not about the sensor, I use a very high-quality heat resistant inductive sensor but it doesn't help.

[InsanityAutomation]

Quad z as a whole was written blind without hardware, as the company that offered some to work on it flaked out. Therefore I don't have hardware to work on efficiency or perform tuning of things like G34 under it.

This will take someone with hardware playing with methodologies to find a solution.

[fiveorders]

Thanks for the info, Is there a way that I can help you with this? Btw, Klipper does that very smooth as far as I see maybe its calculation method can be derived.

[InsanityAutomation]

I had considered it, but ive got alot of other projects i do have hardware for lined up, so ones I dont, especially where promised hardware evaporated, get pushed to the back burner. Its alot more time consuming to work blind on this type of thing.

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[fiveorders]

I had considered it, but ive got alot of other projects i do have hardware for lined up, so ones I dont, especially where promised hardware evaporated, get pushed to the back burner. Its alot more time consuming to work blind on this type of thing.

I understand, however, I successfully built a quad gantry levelling printer with touch screen. I made G34 reliable by adding a macro on the LCD controller. When you press ZAlign, first I made it move the whole gantry to the top and make corners even by forcing them with less motor current. Added G34 right after that which makes it reliable after making the corners even at the top.

So if you guys can make G34 as reliable as klipper, there is only one thing that makes Klipper superior which is input shaper(accelerator) against Marlin 2 at the moment. I don't know if it is possible to code the input shaper feature on Marlin but if it was possible, I would never look back to klipper.

[InsanityAutomation]

Just keep in mind input shaping by definition rounds corners and changes geometry. Theres been some discussion on it, so it may happen but not soon.

What youre describing is the mechanical gantry leveling function which is an alternative G34 method. It could be possible to have both live side by side, where as I wrote them they were either or.

[fiveorders]

Yes, it is either mechanical or probe on Marlin. I am using a BTT TFT LCD screen and I customised the interface and firmware of it. I wrote a short macro for the Z Align button to overcome this inconsistent G34 issue and now it does manual mechanical levelling at the top and then G34 with the probe. Basically, when I press the Z-Align button on the LCD, it homes first, then goes 250mm up at a faster feed rate and then slowdowns and goes 100mm more with a slower feed rate, the max Z is 300 on my machine so with the extra 50mm movement it aligns all corners at the top. Then G34 comes into play and it does its job.

I know time is money, same here. But I proved that Marlin could manage a Quad Gantry Gantry very well except for this glitch. Ignorant people tend to believe that Klipper is the only way to go... I hope you guys will find some spare time to fix it someday. All the best.

[InsanityAutomation]

Absolutely, and the workaround you have is something I could do quite easily to give both options together. Ill try to sneak that in after Rapid TCT.

[fiveorders]

That's great if you could add that, this can be done through native LCD controllers with a single command. 👌 if you can also add a feed rate definition, it will be nice.

if you would like to see it in action, here: Quad Gantry Levelling on Marlin

[InsanityAutomation]

Nice to actually a machine working with it! Ive heard of a few but dont often get to see it

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[Scope666]

I'm having this issue with the latest 2.1 stable build. I've never seen the "Accuracy Decreasing!" message before 2.1.

Send: G34 Recv: Recv: G34 Iteration: 1 Recv: //action:notification G34 Iteration: 1 Recv: Z2-Z1=0.0425 Recv: //action:notification 1:2=0.042 Recv: G34 Iteration: 2 Recv: //action:notification G34 Iteration: 2 Recv: Z2-Z1=0.0200 Recv: //action:notification 1:2=0.020 Recv: G34 Iteration: 3 Recv: //action:notification G34 Iteration: 3 Recv: Z2-Z1=0.0485 Recv: //action:notification 1:2=0.049 Recv: Decreasing Accuracy Detected. Recv: //action:notification Accuracy Decreasing! Recv: G34 Iteration: 4 Recv: //action:notification G34 Iteration: 4 Recv: Z2-Z1=0.0225 Recv: //action:notification 1:2=0.023 Recv: G34 Iteration: 5 Recv: //action:notification G34 Iteration: 5 Recv: BABYSTEP_ALWAYS_AVAILABLE Recv: Z2-Z1=0.0580 Recv: //action:notification 1:2=0.058 Recv: Decreasing Accuracy Detected. Recv: //action:notification Accuracy Decreasing! Recv: Did 5 of 5 Recv: Accuracy: 0.06

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.