OpenDACT(Delta Automatic Calibration Tool) - For Repetier

[DSteck]

The stock arms are drilled on a jig, so having the mounting holes NOT be 269mm center to center would be pretty difficult to do. That being said, XY scaling IS affected by delta arm length changes, so take care when fiddling with it. Length differences won't likely occur in the arms themselves, but could present as a length difference due to the mechanical fit of the u-joints and the u-joints on the axles.

g.

I have Trick Laser arms.

[RollieRowland]

The stock arms are drilled on a jig, so having the mounting holes NOT be 269mm center to center would be pretty difficult to do. That being said, XY scaling IS affected by delta arm length changes, so take care when fiddling with it. Length differences won't likely occur in the arms themselves, but could present as a length difference due to the mechanical fit of the u-joints and the u-joints on the axles.

g.

Yes, I never noticed any error in length in the standard diagonal rods. The only reason that I upgraded to the TrickLasers were to get the traxxas joints.

[626Pilot]

The stock arms are drilled on a jig, so having the mounting holes NOT be 269mm center to center would be pretty difficult to do. That being said, XY scaling IS affected by delta arm length changes, so take care when fiddling with it. Length differences won't likely occur in the arms themselves, but could present as a length difference due to the mechanical fit of the u-joints and the u-joints on the axles.

I was able to consistently get ~20 microns of improvement on my calibration by switching to the Trick Laser carriage yokes and metal platform. It's not a lot, but if you're printing stuff where the screw holes have to line up properly, everything helps.

I have Trick Laser arms.

Those are assembled on a fixture as well. They should all be the same length. The ball joints are the tricky part.

[RollieRowland]

Version 2.0.5A - Steps Per Millimeter Correction - Untested

I still cannot test this (mostly because my printer is in a thousand pieces throughout the house), however, I am fairly sure the connection issues have been corrected. The thread created for reading the log from the printer would not be created due to incorrect input. This then would trigger an exception to be called as the thread was trying to be joined when it was never created in the first place. I have corrected this specific issue, there may be others though. Also, since there is a new step involved in the calibration you should stay near your printer/kill-switch.

Changes:
-Connection fixes
-Steps per millimeter correction: scaling correction
-Correct horizontal radius values and diagonal rod values

You will now have to know the exact length or at least the theoretical length of your diagonal rods for correct results. Although, you may leave the field blank and it will use the EEPROM value for the length of your diagonal rod.

Download:
https://drive.google.com/file/d/0B06WCA ... sp=sharing" onclick="window.open(this.href);return false;

[DSteck]

I'll give this a shot later. I re-aligned my towers to as perfect as they can get and re-ran the calibration on 2.0.4, and it began to just swing wildly back and forth with massive corrections. It also kept pushing the rod length out to 272. After it would complete, I began having issues with infill meeting perimeters. I went back and did the old school way using 269 for rod length and then adjusting end stops, then adjusting horizontal radius, and now it's back to printing nicely (I haven't tried another large print that covers the whole glass though).

[RollieRowland]

Ok, I finally have my printer back together and finished the steps per millimeter correction for the auto-calibration. I had to rewrite a couple functions and add several checks to make sure this won't break printers.

With the basic calibration (after changing the percentage change for each tower - printer radius change, carriage offset change), I was able to get a tolerance of +/-0.005 for my bed and my horizontal radius was set to its theoretical (now 106.5) and my diagonal rods were set to 269. After the calibration, my steps per millimeter value was set to 81.1 steps.

V2.1.1 Download:
https://drive.google.com/file/d/0B06WCA ... sp=sharing" onclick="window.open(this.href);return false;

I'll give this a shot later. I re-aligned my towers to as perfect as they can get and re-ran the calibration on 2.0.4, and it began to just swing wildly back and forth with massive corrections. It also kept pushing the rod length out to 272. After it would complete, I began having issues with infill meeting perimeters. I went back and did the old school way using 269 for rod length and then adjusting end stops, then adjusting horizontal radius, and now it's back to printing nicely (I haven't tried another large print that covers the whole glass though).

Not sure why this was happening for you. Mine doesn't usually over-adjust more than once. Also, I have now tried with two different machines with the same results.

[DSteck]

I'm not sure either. Before, it would make corrections and slowly home in on final values, but for whatever reason, it decided to swing like crazy after I squared the towers.

I'll give this new version a shot tomorrow. I had half a mind to hook my calipers up to each individual carriage and request vertical movements of 100mm, then measure how close each individual carriage is to hitting that with the current steps. I figure if I request a Z movement only, then each tower should move that same amount, so I can get a very precise measurement of the step count.

[RollieRowland]

I'm not sure either. Before, it would make corrections and slowly home in on final values, but for whatever reason, it decided to swing like crazy after I squared the towers.

I'll give this new version a shot tomorrow. I had half a mind to hook my calipers up to each individual carriage and request vertical movements of 100mm, then measure how close each individual carriage is to hitting that with the current steps. I figure if I request a Z movement only, then each tower should move that same amount, so I can get a very precise measurement of the step count.

That is interesting... If you would want to send the log if it happens again, I will be able to find the source of the issue if it happens again. I also should mention that the z scaling may not be perfect, however the offset is able to be measured to correct error as opposed to having X and Y scaling error.

[DSteck]

I'll play with it more and share what I have. Thanks for the work you've put in! I am hoping to get this thing as precise as possible so I can get the most from my E3D V6 with a 0.25mm nozzle.

[D-G-C]

Hi Rollie,

First of all this is a great work and fantastic software. This is was I searched.

I red most of the thread and got the paper from Steve Graves. I had only a short view on his equation but I will spend more time to understand what he did. Does your equation base on the same idea or did you use your own way?

[RollieRowland]

I'll play with it more and share what I have. Thanks for the work you've put in! I am hoping to get this thing as precise as possible so I can get the most from my E3D V6 with a 0.25mm nozzle.

Let me know what you find out!

Hi Rollie,

First of all this is a great work and fantastic software. This is was I searched.

I red most of the thread and got the paper from Steve Graves. I had only a short view on his equation but I will spend more time to understand what he did. Does your equation base on the same idea or did you use your own way?

No, it is almost the opposite actually. He discussed using theoretical kinematics to find the cartesian coordinates - then later, using said information, shows the possible positional accuracy in all dimensions. My method uses the cartesian coordinates - really just the z height - to determine the kinematics values. This of course with taking into considering relationships between these parameters and their affect on scaling - to compensate for not being able to measure X and Y positional accuracy through a probe.

Also, while on this topic, I am still slowly putting my notes together. I most likely won't be done for another week or two.

[geneb]

BTW, you might want to think about a real name for the software. To be honest, "RollieBrator" sounds like the brand name of one hell of a "marital aid". (and yeah, I think that moniker was my fault... )

I think something like OpenDACT or MegaDACT would be much cooler, more descriptive, and much, MUCH, less likely to bring out the snickering 13 year old boy in us all.

g.

[RollieRowland]

BTW, you might want to think about a real name for the software. To be honest, "RollieBrator" sounds like the brand name of one hell of a "marital aid". (and yeah, I think that moniker was my fault... )

I think something like OpenDACT or MegaDACT would be much cooler, more descriptive, and much, MUCH, less likely to bring out the snickering 13 year old boy in us all.

g.

As funny as RollieBrator would be....

I am liking OpenDACT though! And I hadn't even thought of giving it a non generic name, it would also be easier to say. Also, yes, less likely to make everyone snicker like 13 year olds!

[forrie]

Naarrrr.....RollieBrator! Do it Do it Do it!

[D-G-C]

[/quote]
No, it is almost the opposite actually. He discussed using theoretical kinematics to find the cartesian coordinates - then later, using said information, shows the possible positional accuracy in all dimensions. My method uses the cartesian coordinates - really just the z height - to determine the kinematics values. This of course with taking into considering relationships between these parameters and their affect on scaling - to compensate for not being able to measure X and Y positional accuracy through a probe.[/quote]

If I would calculate the different parameter I would start with the theoretical kinematics and solve the equation for the Cartesian coordinates. In the equation would be integrated some uncertainties we don't know like the X, Y and Z-tower offset, etc. With N measurement it would be possible to solve the equation matrix to get N unknown. What I red sounds like you did an optimisation to minimise the error. Is this correct? Its only a short thought and I would like to understand how your software works. Is impressive!

Another thought is if you change the step with it could have an influence of the hight scale but you can measure it with the calibre. After the optimisation move to, lets say 100mm, and measure it. It should be as accurate as the zero position.

[RollieRowland]

If I would calculate the different parameter I would start with the theoretical kinematics and solve the equation for the Cartesian coordinates. In the equation would be integrated some uncertainties we don't know like the X, Y and Z-tower offset, etc. With N measurement it would be possible to solve the equation matrix to get N unknown. What I red sounds like you did an optimisation to minimise the error. Is this correct? Its only a short thought and I would like to understand how your software works. Is impressive!

Another thought is if you change the step with it could have an influence of the hight scale but you can measure it with the calibre. After the optimisation move to, lets say 100mm, and measure it. It should be as accurate as the zero position.

Essentially that is what the printer already does, uses the theoreticals to solve for the positioning. Also, the x, y, and z tower offsets can be found through only having the z heights. For instance if the alpha rotation is corrected - all points opposite of the towers are equal - and the tower offsets are corrected - all points at the towers are equal - then the difference between these 2 sets can be used to correct the overall steps per mm. I have not found a method that differentiates the scaling in the tower vs the offsets. They both can achieve the same task at leveling the bed, however, one also adjusts the scaling. The issue here is determining which value is truly off. As of now, I am assuming that the error is from the endstops. Although, it may not be. This can cause problems; if the tower scaling is the issue then it is not being corrected. It is just not possible to know where the error is without the user manually checking the error. If the linear actuator from top to bottom is equivalent on all sides then the error is not in the endstop/xyz offsets. If everyone were to set their towers perfectly, and the values are still off, then it is a scaling issue. Also, I should mention that an error in the delta radius length can cause an extreme error in the z height, especially at the tower. I correct the delta radii through comparing the height at the tower(after horizontal radius correction) - delta radius of 0(the joints at the effector are directly under the joints at the carriage), and the height at the opposite of the tower - delta radius of the length of the diagonal rod(or at least close to it). If the values are not the same, then the delta radius is adjusted accordingly - very similar to how the horizontal radius is corrected.

*Don't know if I mentioned it in the huge block of text/tangents above; the X, Y, and Z offsets should have little to no error - unless the switches are at a different height and with all endstop screws at the same height. This is another reason as to why I think the error may be the difference in steps per mm per tower, as opposed to an offset in steps.

In short, yes, this program tries to minimize error but without knowing where exactly the error may be coming from, the calibration may not always work. I am still working on finding relationships between the error and the corresponding parameter, but having only one dimension to measure makes the majority of this seem like a shot in the dark.

Yes, if you change the steps per mm then there will be a change in the scaling in the z dimension - which can be corrected, as you said, with measuring the offset in scaling to adjust for it. Speaking of which, this can be calculated as well. If you take the quotient of the adjusted steps per mm over the original steps per mm, then that will give you the scaling percentage(Z) that needs to be set in the host software to correct the error. This would not take much to add to the program and will then have near perfect scaling as well.

Naarrrr.....RollieBrator! Do it Do it Do it!

As much as I would like to...

[geneb]

Rollie, would you recommend that people reset their end-stop screws to be all the same height/position before running the calibration program?

g.

[RollieRowland]

Rollie, would you recommend that people reset their end-stop screws to be all the same height/position before running the calibration program?

g.

That may not be a bad idea - mine are all the same height. Although it really shouldn't cause a problem, any error caused by the screws being off should be able to be corrected.

[RollieRowland]

Figured I would post a progress update.

I am currently working on improving the speed of calibration, i.e. less iterations. I started at 8-12 iterations for calibration. I can now calibrate in around 2-4 iterations - my goal is 1 every time. I have paused for now on this though. I have decided to clean up the code, it is very lazy. So I am completely recreating the code in another project. Once I have a working version I will post it up.

Edit:
This will be the new repository for the better organized project. Also, thank Gene for the name!
https://github.com/RollieRowland/OpenDACT" onclick="window.open(this.href);return false;

This is nowhere near completion, so don't expect to build it and calibrate!

[geneb]

Why did you start another project? You could have easily refactored what you had within the same project.

g.

[RollieRowland]

Why did you start another project? You could have easily refactored what you had within the same project.

g.

Well, mostly because I didn't want to modify a working version until it was in a workable state. Once the version I'm currently working on was able to calibrate I was going to merge the projects together and delete the new one. May have been better to just branch it now that I think about it, I'll go ahead and do that for simplistic reasons!

Edit:
Ok, renamed the repo and created a branch for the version I am working on, once it is working then I will merge the main branch and the secondary branch.
https://github.com/RollieRowland/OpenDACT" onclick="window.open(this.href);return false;

[duvdev]

Hi all
I need some help - I finally got the time to play with new ver of the app - thank you guys' you are doing a great job.

So I downloaded the latest ver of the app.
I have a micro switch that I want to assemble as a Z-probe.
I will connect it to Z min in the Rambo board
What do I need to do next?

Change "has Z probe" in configuration file to TRUE?

What a the stages to run the app?
What is the correct state of the switch? touches the glass High or low?
My switch will be a bit lower the hot end itself - how do I overcome that difference?

thanks a lot.

[626Pilot]

Why did you start another project? You could have easily refactored what you had within the same project.

As I was told by my American Lit history professor: "Good writing is re-writing."

[geneb]

...which is why he's a Lit professor and not a programmer.

g.

[derzaubererer]

Hi all
I need some help - I finally got the time to play with new ver of the app - thank you guys' you are doing a great job.

So I downloaded the latest ver of the app.
I have a micro switch that I want to assemble as a Z-probe.
I will connect it to Z min in the Rambo board
What do I need to do next?

Change "has Z probe" in configuration file to TRUE?

What a the stages to run the app?
What is the correct state of the switch? touches the glass High or low?
My switch will be a bit lower the hot end itself - how do I overcome that difference?

thanks a lot.

i have exactly the same questions also my microswitch is a little bit to the left of the nozzle is there a way to change the offsets?