rotary delta + mesh compensation | Strange Z-Lift

dc42

@Egris , @Orang_ , I am trying to work out exactly what the problem is. Can you tell me whether mesh bed calibration is working on your rotary delta printers?

Egris

@dc42 at the moment i cant confirm weather the mesh compensation is working or not. For me it was not possible to finish the grid probing. At the outskirts of the bed the Z-Lift is doing really fast moves to the other side of the bed. What i can confirm is that printing without the compensation is working really well.

Probing a single point changes / effects the the machine coordinate sytem. After a G30 when i whant to move lets say only in Y-Direction, the move is in Y and Z direction like in that last video.

Looking forward to solve this Problem together. Thanks alot for looking into it.

dc42

@Egris said in rotary delta + mesh compensation | Strange Z-Lift:

At the outskirts of the bed the Z-Lift is doing really fast moves to the other side of the bed.

Are you saying that when the machine has been calibrated manually so that good prints are possible, the Z-lift moves during mesh bed probing are not vertical?
What happens if you home the printer, command the nozzle to e.g. 5mm above the centre of the bed, and do G30 S-1 ? Does the Z lift move afterwards go straight up? If so, is it any different if you run G30 S-1 when the nozzle is away from the centre?

Egris

i looked into the Statemachine for bed-probing in Gcodes 4 but couldn find any hint.
before the Z-Lift there is called the Function SetMoveBufferDefaults(). Could there be somthing reset?

dc42

PS - one more test:

Move the nozzle to a point off-centre e.g. X0 Y50 Z10. Then command the nozzle up (e.g. to Z50) and check that the movement is vertical. Next, command the nozzle to X0 Y50 Z10 again, but after that send G91 Y50 Z10 (i.e. tell the machine where it is at, giving it the same coordinates that it thinks it is at). Then command the nozzle up to Z50 again and see if the movement is still vertical.

Egris

@dc42 1. Are you saying that when the machine has been calibrated manually so that good prints are possible, the Z-lift moves during mesh bed probing are not vertical?

Yes thats true. In the Center of the Bed the Z-Lifts are "more" vertical than they are getting to the edges of the bed.

If i set my grid-probing to X-145:145 Y-145:145 the first Probe is at X-145 Y-145. Everything works fine until the Z-Lift. When Z is lifted the head moves to abaout X-145 Y145 in a not coordinated move. When it arrives there the head will move to the next grid point at X-125Y-145. On that 2 moves it crashed the nozzle into the bed

Egris

@dc42 said in rotary delta + mesh compensation | Strange Z-Lift:

Move the nozzle to a point off-centre e.g. X0 Y50 Z10. Then command the nozzle up (e.g. to Z50) and check that the movement is vertical. Next, command the nozzle to X0 Y50 Z10 again, but after that send G91 Y50 Z10 (i.e. tell the machine where it is at, giving it the same coordinates that it thinks it is at). Then command the nozzle up to Z50 again and see if the movement is still vertical.

tested it and it works like it should. Z-Movment is vertical

dc42

Thanks; and what about the G30 S-1 tests?

Egris

i can do that test probably tomorrow. I think i damaged my Z_Probe_In Pin by the 5V Signal of the BLtouch. My Duet2 probably was older than the revision that can handle 5V on that Pin. . Is there a possibly to use another analog pin for my Z-Probe? I orderd a spare one

dc42

@Egris said in rotary delta + mesh compensation | Strange Z-Lift:

i can do that test probably tomorrow. I think i damaged my Z_Probe_In Pin by the 5V Signal of the BLtouch. My Duet2 probably was older than the revision that can handle 5V on that Pin. . Is there a possibly to use another analog pin for my Z-Probe? I orderd a spare one

Are you sure the pin isn't working? The Z probe input pin is fairy tough even on older Duets.

You can connect the BLTouch to a spare endstop input.

dc42

I have reproduced this issue by configuring my linear delta as if it is a rotary delta. The forward transform for rotary delta kinematics was inverting the Cartesian Y coordinate. What surprises me is that this has ever worked, because that code has not changed.

I have put a new firmware build for Duet WiFi at https://www.dropbox.com/sh/q5uqqkjbmhgvlhq/AACYqG0ynLME9ogoLd1zLB2Xa?dl=0. If you are not already running release 3.3beta1, please read the 3.3beta1 release notes before installing this.

dc42

I've made an attempt at implementing auto calibration for rotary delta machines. The firmware for Duet 2 is at https://www.dropbox.com/sh/q5uqqkjbmhgvlhq/AACYqG0ynLME9ogoLd1zLB2Xa?dl=0.

Calibration factors implemented are:

3 = homing switch position corrections
4 = as 3 + bearing heights (all 3 heights adjusted by the same amount)
5 = as 4 + delta radius
7 = as 5 + tower position corrections

I have no machine to test this one, so it is highly likely that it won't work. It's also possible that it will work but only if you home again immediately after running auto calibration.

Please test it very carefully. Use M669 and M666 without parameters after running auto calibration to see what parameters changed.

Egris

@dc42 thanks alot for your support. Bed probing is working now . I will try the autocalibration function and write a feedback how it works.

Egris

@dc42 did a Autocalibration. Result is as follows:

M669
Kinematics is rotary delta, arms (190.000,190.00,190.000)mm, rods (393.500,393.500,393.500)mm, bearingHeights (422.008,422.01,422.008)mm, arm movement -90.0 to 46.5°, delta radius 45.480, bed radius 212.1, angle corrections (59.839,59.430,60.000)°

M666
Endstop adjustments X-0.82 Y-1.04 Z-1.47°

Start Values:
;M669 K10 U190.0 L393.5 R45 A-90.0:46.50 H418.8 X60, Y60, Z60 B212.132 (59.839,59.430,60.000)
;M666 X0.0 Y0.0 Z-0.28

dc42

So it's made some small adjustments. Does it print more accurately, or less accurately? If you run auto calibration again, do the M669 and M666 parameters remain stable?

Egris

@dc42 after several calibrations the values will stop at a certain level and are adjusted each cycle a little bit higer / lower. After the calibration i moved the head to a bit above Z0 and moved in X direction. I noticed a bowlshape movment. So i adjusted the rod lenght manually, did another calibration cycles and now i have quiet a steady linear movment above the bed

Then i did a G29 Mesh calibration..
225 points probed, min error -0.188, max error 0.428, mean 0.017, deviation 0.094

When i want to look at the graph it says Invalid Height Map. Im not sure why this will happen. The File is saved to the sd card

heightmap.csv

Egris

This post is deleted!

Egris

@dc42 hello dc42, currently i think the calibration code works! I played again with the radius in which it probes the points and now it looks quiet good . I have one question.
Im using the fw 3.3 and when i do a mesh calibration the header of the hightmapfile is as follows..

axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,-140.00,140.00,-140.00,140.00,-1.00,20.00,20.00,15,15
0.115, 0.139, 0.118, 0.101, 0.075, ....

When i want to check the graph on the webinterface it says invalid hightmap..

when i change the header to

xmin,xmax,ymin,ymax,radius,xspacing,yspacing,xnum,ynum
-140.00,140.00,-140.00,140.00,-1.00,20.00,20.00,15,15
0.115, 0.139, 0.118, 0.101, 0.075, ....

It shows me the graph output.

Which format will the firmware need to do the compensation correctly?

dc42

Either height map should work for bed compensation. We'll need to update DWC to display the new format.

dc42

There is now a DWC that can display the new format height map at https://www.dropbox.com/sh/q5uqqkjbmhgvlhq/AACYqG0ynLME9ogoLd1zLB2Xa?dl=0.