Anycubic delta bed mesh problem

Hi

I'm trying to diagnose what part of my Anycubic Kossel Linear Plus might be the most likely cause of bed mesh problem. I've done the delta calibration a fair times now followed by bed levelling but too no avail. I've placed a small piece of Kapton tape in the centre which clearly shows up in the mesh data.

Here's the mesh data from two consecutive bed levelling sessions, the 2nd one is after rotating the bed by 90 degrees (the tape bump shows this rotation quite well), yet the dominant wave is unchanged, which means it's not the bed plate itself (that appears to be nice and level). The wave is about 0.3mm peak to peak, centered above and below zero.

Firmware is Marlin 1.1.19

The mesh data is the same whether the bed is cold (ambient 18C) or hot (60C), it doesn't change.

Any ideas what might be the most likely cause of the static wave (remains static no matter how much I rotate the bed plate) ?





Edited 2 time(s). Last edit at 12/09/2021 01:05PM by Pippy.

It looks like your bottom left tower is nearer (or further depending on sign of the error in your charts) to the centre in reality when compared to the geometry data in the firmware.
Plus some slight rise of all edges up - that indicates small error in delta radius or diagonal rod.

If you can handle some math then this may help you: [github.com]

Quote
hercek
It looks like your bottom left tower is nearer (or further depending on sign of the error in your charts) to the centre in reality when compared to the geometry data in the firmware.
Plus some slight rise of all edges up - that indicates small error in delta radius or diagonal rod.

If you can handle some math then this may help you: [github.com]

Thank you hercek for your reply. All replies/help are very welcomed !

Yes I'm fine with the math, it looks quite simple, I'll report back, Going to take a close look at the math in the your link.

Here's the current mesh after much fiddling with equalizing tower to tower distance, ensuring all 3 towers are vertical (90 deg to bed) and doing all I can to equalize the 6 rods lengths.
I think the rods are within a quarter mm of each other, can't do any better because of the way their lengths are fine tuned (twist a rod end in 1/2 turn increments to adjust length - quarter turn etc not possible).



Edited 1 time(s). Last edit at 12/13/2021 09:12AM by Pippy.

Well you can use also these:

• If you are lazy then try this: [www.escher3d.com]
• If you upgrade to RepRap firmware then a least square calibration of tower positions is built in the firmware
• If you are a math nerd then play with this: [github.com]
• If you have towers tilted in a different directions and can measure, guess or derive with calibration.wxm how they are tilted and when you can upgrade to Repetier then you can try my old branch of Repetier. No built in calibration but it can define also tower tilts: [github.com]
• If your towers are rotated along their long axe then you are screwed No firmware I'm aware of can calibrate out this kind of error. This error manifests itself more as XY dimensional inaccuracy than Z axe inaccuracy. To check for this use a bulls eye level on your platform. Check horizontal position at all places of your bed.

Good luck.

Thank you again hercek.

We would love to dump marlin, it's really not very good these days, what with compile problems and such like.
I just need to find a board that would run the reprap firmware, we can't justify buying one of their boards for this cheap printer at the moment, the printer was faulty when we got it, needed repairing etc, no telling what it had gone through before arriving here.
.

It depends whether you have money or time

The most easy and most costly solution is to update electronics and use RepRap firmware.

The most time consuming way is to use my stalled(*) Repetier branch and callibration.wxm. It is very likely you do not need any HW update but you need some math & firmware loading knowledge and free time to spend. I use it with an AVR board. All the added calibration stuff is not ported to DUE boards.

(*) I did not update it for ages. The reason is works fine for my needs. I have left software polishing to people who can earn some money with it (like e.g. dc42 with RepRap firmware and Duet boards).

Quote
hercek
The most easy and most costly solution is to update electronics and use RepRap firmware.

The most time consuming way is to use my stalled(*) Repetier branch and callibration.wxm. It is very likely you do not need any HW update but you need some math & firmware loading knowledge and free time to spend. I use it with an AVR board. All the added calibration stuff is not ported to DUE boards.

I didn't realise you'd done an AVR version. I've just done a compile of your firmware without any problems at all. Well done!

Just going through the Configuration.h file to see what need changing to the RAMPS 1.4 compatible board used in my delta, pin config, display etc.

Unfortunately @hercek, although I got the stepper motors setup and working and the end stops setup and all working in your AVR firmware, the firmware kept crashing, probably due to lack of RAM by the looks of it (stack overflow ?).
When I compile, the Arduino IDE does mention that the remaining memory is a bit low.

When the firmware crashes the hot end goes bang into the bed, and doesn't stop trying to carry on .. mainly when trying to do a bed level.

Anyway, I'm currently back with Marlin (for now), manged to improve things a little, think it's about as good as I'm going to get, around 0.35mm peak to peak variation ..

Most likely bad configuration. Or bad luck. Maybe something changed in Arduino IDE which needs a code change. The firmware I use was compiled about 3 years ago. I use the printer all the time since without problems. Compiled for Arduino Mega 2560 and RAMPS 1.3 shield. Controlled with Pronterface.

Verification does not complain much here:

Sketch uses 133930 bytes (52%) of program storage space. Maximum is 253952 bytes.
Global variables use 5955 bytes (72%) of dynamic memory, leaving 2237 bytes for local variables. Maximum is 8192 bytes.

2 kB for stack should be enough.

0.35 mm peak to pean means you are nearing. It will be well usable when you get it below 0.1 mm.

Quote
Pippy
Thank you again hercek.

We would love to dump marlin, it's really not very good these days, what with compile problems and such like.
I just need to find a board that would run the reprap firmware, we can't justify buying one of their boards for this cheap printer at the moment, the printer was faulty when we got it, needed repairing etc, no telling what it had gone through before arriving here.
.

It's taken me about 5 weeks to install and fully calibrate Klipper on an Anycubic Kossel.

Now X and Y dimension identical, scaled parts retain right angles, and bed mesh is within 0.1 no matter having an old plate with lots of plastic buildup.

All 3 rods are slightly different lengths (+- ten micros or so).

I took all the useful data (endstop positions) and incorporated them into initial Klipper config.

However, the Z offset needed a lot of adjustment through the calibration process. I ended up with the exact same value I started with, 16.5mm for a mark 2 Anycubic probe. But I had to change temporarily to get calibration models for delta and press advance printed out.

Definitely recommended for Delta's. Raspberry Pi math calculations blow Marlin out of the water.

Technically I can go a lot faster too, although with a Pulley Kossel, additional vibration is a problem.

I'm just happy with the accuracy improvement TBH.

One thing that would have made it all much easier would have been installing KIAUH onto a fresh Pi install. Mainsail to give you all the Moonraker and Fluidd graphic pretty prettyness.

You don't have to use a Pi (model Zero 2 is good enough), any Linux capable system with a usb port will do.

People have used old phones for the purpose, although it's a bit tricky to recharge them mid print.

Edited 4 time(s). Last edit at 02/13/2022 03:49AM by DragonFire.