Easy Calibration method to remove concave Delta movements

[radzia2]

After moving my printer around, small deformations occur in my printer frame. This means you need to calibrating for DELTA_RADIUS over and over again. (the software doesn't take the small changes in DELTA_RADIUS into account.

The delta code from Johann features an auto leveling code "G29 Z-0.4". With the Z-0.4 part, you can compensate the automatic leveling option with .4 mm ( you put the nozzle .4 mm closer than you would have hard programmed in the arduino code)

It would be nice if there was a comparable feature you could "modify" the DELTA_RADIUS value with Gcode. After moving the printer around from point A to B, you could just add or retract .5mm out of your slicer program to adjust the DELTA_RADIUS without having to reprogram your Arduino board.

Is this possible guys? I'm a real noob in Arduino programming but thought it might be a useful feature to improve user experience.

Regards, R-

[boelle]

i guess those that are good at writing code could do this, but then again i would rather take a look at the frame and see if it could be made more rigid.... it would be a big thing to add if only a few have the problem and it could be avoided ..... the less features the less chances of the code going sour

[galexander1]

I

[boelle]

| means?

[galexander1]

Ack sorry for the last message, fat fingers..

I'm not against this idea, but I wonder if maybe making the auto-calibration capable of handling small amounts of curvature wouldn't be a better way?

As I understand it, the current auto-leveling in Marlin does smart planar correction. It would be neat to have a smart system that also handled spherical distortion. I'm not excited personally about doing the trigonometry&algebra to make that happen, though..

The jcrocholl branch has a different approach -- it has a dumb leveling system that probes a grid of points across the whole bed (say 9x9), and then applies a correction as a linear interpolation between these points. So it can handle any bed shape -- even waves -- so long as it isn't too dramatic.

If we took on this other leveling system, would that obviate the need to change DELTA_RADIUS/DELTA_DIAGONAL_ROD at runtime?

[boelle]

+1 for that.. not only could the bed be tilted but also bend... so yes....

[nophead]

If you print on a bent bed you get a bent object. There is nothing the firmware can do, you need a flat bed.

On 19 December 2014 at 18:09, Bo Herrmannsen notifications@github.com wrote:

+1 for that.. not only could the bed be tilted but also bend... so yes....

Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/719#issuecomment-67674401.

[boelle]

doh yes.... brain fart

2014-12-19 19:19 GMT+01:00 Chris notifications@github.com:

If you print on a bent bed you get a bent object. There is nothing the firmware can do, you need a flat bed.

On 19 December 2014 at 18:09, Bo Herrmannsen notifications@github.com wrote:

+1 for that.. not only could the bed be tilted but also bend... so yes....

Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/719#issuecomment-67674401.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/719#issuecomment-67675728.

[galexander1]

If the bed is truly bent, that is true. But the spherical distortion that DELTA_RADIUS/DELTA_DIAGONAL_ROD addresses is a bit of an illusion. The auto-probing will see the bed as a bowl (either concave or convex), even though the bed is flat. The "dumb" linear correction in Z will introduce a slight distortion in the X&Y axes, but it isn't very large if the DELTA_RADIUS/DELTA_DIAGONAL_ROD aren't grossly wrong. You kind of have to draw out all the triangles and do the basic trig to see it, but I was surprised when I was done that it really wasn't a big factor.

And personally, even if my bed is not perfectly flat (i.e., +/- 0.2mm), I would far prefer to have my objects turn out warped than to have a few spots on the bed where the first layer doesn't adhere, or the head scrapes the acrylic.

[boelle]

my thoughts.... and maybe not expressing myself correctly... but:

to me this seems like fixing a hardware problem with software.... i would rather fix the hardware

[galexander1]

Well the problem is that the delta parameters are never precisely accurate. In a cartesian printer, we accomodate this with planar correction. In a delta printer, the same calibration errors present as spherical distortion instead.

[thinkyhead]

Johann's delta code has been merged, for the most part, including the newest non-linear leveling. Hopefully it is working better now that the code is also using the leveling results during printing.

[boelle]

Just going through everything to see what is solved etc...

Could this one be closed on the grounds that Johann's code has been merged? Also i dont see any new comments from the initial poster..

And in the end how many would this request benefit? for me it still looks like solving a hardware issue with software in the sence that moving the printer will result in hardware not alligned right

[thinkyhead]

@boelle During leveling I heard there had still been some curved movements, but that may also be resolved. We'll try to catch that as part of the bed leveling and probing bug dragnet.

[boelle]

@radzia2 are you still arround?

[a4jp-com]

@radzia2 are you there?

[linchunguang]

The book research 3 d printers algorithm

[clefranc]

@radzia2 Try this http://clefranc.github.io/Marlin4Delta @linchunguang You're looking for documentation on Delta kinetics?

[a4jp-com]

Nice work @clefranc

[jbrazio]

Thank you for your interest making Marlin better. You should re-open this topic on MarlinFirmware/MarlinDev for proper followup from the development team. We suggest you to use the MarlinFirmware/Marlin#<topic id> markdown to link back to this original topic.

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