Delta: Incorrect position boundary checks

[pienjo]

The maximum build dimensions seem to be calculated incorrectly on my delta printer (Arm length ~270mm, delta radius 149mm, build radius 120mm).

It claims that the max. build height is 239.86 mm(which corresponds to the minimum endstop position) with the radius tapered above 195.23mm. This isn't correct; if I move the toolhead to X0 Y-120 Z195 (which is on the boundary of the printable area according to Klipper, there is still ~35mm between the A and B carriages and their endstops. In other words: The maximum build height should've been around 230mm instead.

Also, the tapering seems incorrect; I was expecting a build volume resembling a cylinder with a cone on top, with the base radius of the cone equal to the cylinder. This doesn't seem to be the case: At Z=195.5, the first Y coordinate which Klipper claims to be reachable is -44.4. At Z=200, the radius has reduced to -39.8 (at which point there is still a minimum of ~28 mm clearance between the endstop and the carriages). So instead of a cylinder with a connecting cone, it seems the build volume on my printer is a cylinder with a skinny, tall cone, whose base diameter is significantly smaller than the cylinder.

Any suggestions?

See logfile: klippy.log

[KevinOConnor]

The maximum build height should've been around 230mm instead.

True, Klipper could have done better here. Your delta arms are a little shorter than most delta printers, and the current code isn't taking into account build_radius being smaller than delta_radius.

So instead of a cylinder with a connecting cone, it seems the build volume on my printer is a cylinder with a skinny, tall cone, whose base diameter is significantly smaller than the cylinder.

This is correct - the boundary constraints are currently a cylinder with a "tiny" cone on top of it.

Can you give some high-level info on what printer you have and the sizing of prints you are unable to complete (if that is the case)?

It's possible to address both of the above, but the math can get complex quickly. It's known that the boundary constraints aren't perfect, but (to date) most people don't push the envelope at the very top of their delta printers.

-Kevin

[pienjo]

Your delta arms are a little shorter than most delta printers, and the current code isn't taking into account build_radius being smaller than delta_radius.

Well, I knew my delta was was a bit peculiar somehow ;) It's got a 240mm diameter bed, but the outer 10mm or so are almost unusable. In fact, going beyond a 100mm radius is pushing it, since at least one of the arms will be near horizontal, so the effector tends to start to wobble.

Can you give some high-level info on what printer you have and the sizing of prints you are unable to complete (if that is the case)?

My printer is a Chinese kit, and started its life as a "FLSun Large Delta" ( https://www.aliexpress.com/item/32495135437.html - discontinued since). In the two years since I've had it, it's been modified a lot, but most of these modifications will not have significantly impacted the geometry: I replaced the rods (but used a jig to make them the same length as the original ones) and the effector (but the delta offset was reasonably close), and replaced the corners (which are slightly different). I'm still using the stock carriages.

My oldest Klipper config dates back to August 2018, and at that point I was still running with the stock corners, stock arms and stock effector. It has a delta_radius of 138.05 (148.8 now), with 169mm arms. (They're still 169mm, but for some reason the advanced calibration bumps them to 170)

It's possible to address both of the above, but the math can get complex quickly. It's known that the boundary constraints aren't perfect, but (to date) most people don't push the envelope at the very top of their delta printers.

Well, neither do I, to be honest.. I was trying to reproduce a print of a lampshade I did about 2 years ago - since then I've lost a significant amount of build height when I replaced the effector, and when I installed piezo bed probes, so I decided that it would probably be wise if I checked before I hit print. It would've physically fit (it's 20 cm tall), but Klipper was throwing a spanner in the wheel.

This is not a very big problem for me - I rarely print things this tall, and if nothing else, I could override the value of "self.max_z" in kinematics/delta.py for the duration of a print.

I don't know the Klipper sourcecode very well, but I'm naively assuming a position could be validated by first determining the required carriage positions and check if this would require pushing them beyond the endstops. A binary search would then be able to determine the threshold. It's a bit kludgy, but at least it wouldn't introduce more math (since it'd be re-using the same calculations as needed using regular operation), and you only need to do this at startup, so it doesn't have to be real-time.

[KevinOConnor]

I could override the value of "self.max_z" in kinematics/delta.py for the duration of a print

FWIW, I think adding a new "print_radius_taper: True" option to the config may be the simplest solution to this. That is, allow users to disable the endstop collision checks.

a position could be validated by first determining the required carriage positions and check if this would require pushing them beyond the endstops.

It's not difficult to validate the position where a move starts and where it ends. However, it's possible for a linear move to travel from a valid area, to an invalid area, and then end in a valid area. (One can think of the range of valid areas at the top of the printer as the union of three spheres - which is a complex shape.) So, it's difficult to validate the entirety of a move in advance.

Klipper can detect an endstop collision when it generates the actual steps for each motor, but at that point it's too late to raise a useful error. (Due to the nature of the look-ahead queue, by the time steps are generated, multiple upcoming movement commands would have been accepted and planned.)

-Kevin

[pandel]

Hi!

I'd like to ask if there is any progress in that matter? I recognized the same problem on my printer (Anycubic Kossel Linear Plus).

The reason I am asking is because I try to develop a nozzle park macro for (M600) filament changing. At higher print heights I am not able to determine the maximum Z position I can set in a G1 (for clearance during change), as G1 is always reporting "Move out of range", even though there is plenty of room between the carriages and the endstops.

Additionally, does Klipper output its currently valid axis max values (calculated depending on current head position) into any "printer.toolhead" coord somewhere, so that one could take those values instead of printer.toolhead.axis_maximum? I did not find any values in this regard...

Regards, Holger

[janherich]

I have the same problem, it's unfortunate that I can't use the build volume to the max extent physically possible - "print_radius_taper: True" option in config would be fully sufficient solution for me. I may give a shot at the proper solution involving calculation with three spheres & line representing requested move, hopefully the math won't be too complicated/slow for real-time check - in a worst case, some lower-resolution "mesh screen" of the top quasi-cone can be precomputed and stored during calibrate time and collision check would determine whether there is an intersection of the line (start/end move coordinates) with that 3d mesh (only checked above certain height).

[janherich]

More efficient (volume-wise) position boundary checks for delta printer are implemented in pr #5917

[github-actions[bot]]

This ticket is being closed because the underlying issue is now thought to be resolved.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.