OpenDACT(Delta Automatic Calibration Tool) - For Repetier

[Paxy]

Have you first clear all EEPROM values to default ?
If you are not sure, re-flash Repetier firmware with different EEPROM slot value to clear EEPROM.

[lordgort]

i did

[duvdev]

me too

[Paxy]

Have you experimenting with different types of calibration ?
I have tried just "Calibrate" and "A.I. Calibrate" but without luck. Only "H.A.I. Calibrate" did give me positive results.
Event with HAI, 2/3 attempts finish by getting some crazy values and smashing sensor to bed, or even worse total freezing firmware so only re-flash helps.
But when I start with default firmware and HAI, I am getting usually success in 40-60 iteration. Like in above video.

[crocky]

I have a usable configuration with 205A, but only the basic config.... The others go for a fair while and end up doing weird things with the head so I am waiting for Rollie to get a new improved version for testing... Not in a hurry, I can wait...

[ewm]

I've been trying to get Casper level and having a lot of difficulties in particular with areas on the right side. There are also some localized spots that print low towards the inner area of the bed as well that remain persistent. We've tried the following:

Adjusted skate screws to as close as possible.
Made sure bed was completely level.
Used the Manual Calibration method with a dial gauge using both basic and advanced mode.
Set up a Z Probe to use 2.0.5 of OpenDACT going from Basic, AI, to HAI
Added the TrickLaser Heat spreader and then continued using 2.0.5 with normal amount of clips and then doubled the clips
Used 2.1.1 Basic

These are the last two settings we tried from using 2.1.1 Basic

HRad:128.453204470222
Delta Radii Offsets: 1.09333333333335, -0.446666666666601, -0.646666666666732
XYZ:311 248 239
ABC:209.884020274722 329.988838529444 90.0055807352782
Steps Per Millimeter Changed: 81.5819261586699 SPM
yintercept: 173.422287114609 SPM
slope: -0.341413981248843
zMaxLength changed by: 7.51323499924736
zMaxLength before: 387.467
zMaxLength after: 379.953765000753
Diagonal Rod:267.853698874916
HRad Recalibration:128.466725514277

yopp, z, and xopp = 0
X = .01
Zopp = -.01
Y = -.01 y


HRad:128.409786418725
Delta Radii Offsets: 1.0733333333333, -0.446666666666563, -0.626666666666712
XYZ:312 249 239
ABC:209.889112128674 329.978026766896 90.0109866165519
Steps Per Millimeter Changed: 81.5842444033091SPM
yintercept: 173.508845172814SPM
slope: -0.341727140407083
zMaxLength changed by: 7.52383733234703
zMaxLength before: 387.457
zMaxLength after: 379.933162667653
Diagonal Rod:267.81731358175
HRad Recalibration:128.407204938468

x, zopp, y, and z = 0
yopp = .01
xopp = -.01

They both give nearly the exact same result which looks like this.

[img]http://orig00.deviantart.net/a54c/f/201 ... 9gaixr.jpg[/img]

Here are the results from one of the 2.0.5 attempts, I believe this one was an Basic to AI test. It also produced the same results.

Diagonal Rod: 273.416
Horizontal Radius 131.209
Tower X end stop offset: 85
Tower Y end stop offset: 69
Tower Z end stop offset: 5
Alpha A 210.102
Alpha B 330.179
Alpha C 89.911
Delta Radius A: .639
Delta Radius B: .247
Delta Radius C: -.885

z= -.02
y opp, x, and y = .01
x opp and z opp = 0

[rlburgos55]

Complete noob here.
Just got my Rostock Max V2 a few weeks ago, have it up and running and using the HTML V1.0.4 tool to get printer up and running as best as possible.
Used harbor freight digital calipers at first with decent results; printing a mount now to try digital indicator to see if it will have better precision.
After having read through this forum, have plans to try FSR kit further down the road after I get some more experience and run time on this printer.

My question with the calibration macro G-code is why are the data points taken at Z2 instead of Z0?

Hello,

I've been trying to calibrate my bed with the manual HTML script over the last few days now and I can't seem to get good results from it. I'm using electronic calipers to measure and after 4-5 iterations I get the 6 points to +/- 0.01mm. The problem occurs when I switch out the calipers for the hotend and actually try printing. At about 5cm from the centre of the bed I get height deviations of up to 0.6mm. I don't understand what's causing this. Am I not supposed to change the zheight once I finish calibrating? Should I zero the calipers for every iteration?

Another thing I noticed was that when running your gcode, the probe ends up about 2mm lower when going to the bed centre as opposed to when I bring it down manually through MatterControl.

This is the mount I'm using for the calipers: http://repables.com/r/614 though I don't think it's the source of the problem.

Unless the answer to my problems is painfully obvious, it might be good to update the tutorial.

I believe that PikachuPorkChops was hitting on the same thing that I am seeing. After running the calibration iterations using Z2, the Z-height is considerably changed with respect to the initial Z-height set using the LCD control panel.
After calibration, If I go to Z0 through the Matter Control panel, the hot end hits the glass bed hard.
What am I missing or doing wrong?

[RollieRowland]

"@RolliRowland
maybe im thinking wrong, but in my university we "see" everythink from the base coordinate system (x:0,y:0,z:0) so im a little confused with these ^^
from the default values i believe you are using the "noozle coordinate system" is that right?

Not sure entirely what you mean, however, the program uses just the basic cartesian coordinate system - just as the printers do.

My question with the calibration macro G-code is why are the data points taken at Z2 instead of Z0?

The only reason the code was taken at Z2 was because the nozzle would hit the plate on occasion when set to Z0 - using Z0 would give better results.


Also, I should mention that I've still been quite busy but still managing to do a little testing here and there - predicting where the hot-end will be when a variable is changed. Fairly sure the only other modifications that I needed to make were on the delta radius and xyz offset. The xyz offset can be predicted perfectly but I still am stuck in finding a way to calibrate each tower at the same exact time. I currently fix one tower and move to the next - which slightly offsets the other two towers. Eventually a limit is hit and there is no longer improvement, which of course is entirely due to the software, not mechanical issues.

I will most likely be able to put a couple of hours into it tomorrow and maybe finish correcting these issues.


Edit: Figured out the issue as to why the xyz offsets would not calibrate. If the delta radii are not set correctly then the endstops cannot be calibrated. I'm fairly sure I can implement the solution in the next hour or so - so expect the next version (the basic calibration will be the only method that works for the time being).

Edit 2: Version 3.0.0PA - Download
https://drive.google.com/file/d/0B06WCA ... sp=sharing

[SirLinhart]

So it sounds like there are no more parameters that can be accounted for. What about situations where it calibrates consistently and repeatebly correct within .025mm, but when actual printing there is a huge variance on sections of the bed that were not tested, even if the bed is flat?

[mhackney]

SirLinhart, this is exactly why I was working on automatic compensation earlier this year. Even if the actual printing is not huge - just .05mm +/- from the X-Y plane can cause problems. I have a dip in an area between the X-Y towers and a hump between the Y-Z towers that calibration will not resolve. The idea with compensation is you create a height map for entire bed at a reasonable grid size. Then, you map the actual Z height during printing using the height map.

This can be done in one of 3 places:

1) in the actual gcode itself by post processing the slicer output
2) in the controller by intercepting the Z coordinate and correcting it
3) in the firmware by intercepting the Z coordinate and correcting it

My approach - to test the idea - was based on 1. The challenge is that each slicer generates different "markers" in the gcode and some are easier than others to determine where the Z coordinates are. At the time I did not have a way to auto probe my bed so I used a map of triangles and use Barycentric interpolation so not as many points were needed. This is sub-optimal as the height map resolution really isn't sufficient to get good results.

I believe MatterControl's plug in mechanism would allow 2) to be implemented. I may have to re-investigate this now that I have FSR Z probes on all my delta machines.

[Micael]

For those having that issue, I believe that 626pilot smoothieware firmware could solve it, although that ofc means buying a smoothieware board and switching to his firmware, so not the cheapest solution and most pratical solution.

[RollieRowland]

So it sounds like there are no more parameters that can be accounted for. What about situations where it calibrates consistently and repeatebly correct within .025mm, but when actual printing there is a huge variance on sections of the bed that were not tested, even if the bed is flat?

The reason that your values change after switching the calipers out for the hot end is because of the height difference. If the height differs by 1mm and the towers are tilted by 0.5 degrees then it WILL significantly offset the resulting print height(at all points of the plate). Unless you can correct the error in your towers then this will occur. If you can measure the distance from the effector plate to the tip of the hotend and have that equal to the distance from the effector plate to the end of the calipers when measuring(at center), then you can effectively use calipers. That is the only way - this is why FSRs are perfect for calibration.

SirLinhart, this is exactly why I was working on automatic compensation earlier this year. Even if the actual printing is not huge - just .05mm +/- from the X-Y plane can cause problems. I have a dip in an area between the X-Y towers and a hump between the Y-Z towers that calibration will not resolve. The idea with compensation is you create a height map for entire bed at a reasonable grid size. Then, you map the actual Z height during printing using the height map.

This can be done in one of 3 places:

1) in the actual gcode itself by post processing the slicer output
2) in the controller by intercepting the Z coordinate and correcting it
3) in the firmware by intercepting the Z coordinate and correcting it

My approach - to test the idea - was based on 1. The challenge is that each slicer generates different "markers" in the gcode and some are easier than others to determine where the Z coordinates are. At the time I did not have a way to auto probe my bed so I used a map of triangles and use Barycentric interpolation so not as many points were needed. This is sub-optimal as the height map resolution really isn't sufficient to get good results.

I believe MatterControl's plug in mechanism would allow 2) to be implemented. I may have to re-investigate this now that I have FSR Z probes on all my delta machines.

This "hump" can be corrected for. This "hump" is formed radially from the center, which linearly (in most cases, can be exponential in others) worsens as the distance from the center increases. The areas between towers, i.e. the base rotations 30, 150, 270, can easily be leveled by merely correcting the alpha rotation. If for some reason the error is occurring around 60 degrees for instance, then the error is not due to kinematics and should not be possible - unless your skates are loose, your steppers are bad, etc.

[mhackney]

Rollie, the hump is not a delta kinematics issue and calibration can not correct it. It is some sort of mechanical issue that I've been chasing for several years. I've introduced errors into my machine's geometry and mapped the movement to try to understand it - similar to the heat maps that Steve Graves discusses in his "Delta Robot Kinematics" paper. What's odd is that none of these has had a tangible impact on these 2 issues. They are small though - .05mm or so at the peak/valley, but for my work it is enough to be problematic, most people wouldn't even notice. But the open weave side plates on my fly reels (the white part on my avatar) are visually impacted by this variation since the first layer is the most visible in the product. Today I simply work around it and print on the other side of the plate when I need dead flat movement.

As you know, nothing that automatic calibration can do can't be done manually with enough time and perseverance as the end result is a set of parameters that feed into the delta kinematics. I've spent more time than most would have the patience for if for no other reason to understand the root cause of this issue. The defects are asymmetrical and not directly aligned between the towers - they are offset to the side a little and shaped like a rounded triangle. I've replaced carriages (now run TrickTrucks), arms (CF rods) and most everything else including adding FSRs for a Zprobe with a new bed mounting system. The ONLY thing I haven't replaced is the original effector so I suspect that. However, I have JB Welded the effector so there is no movement on anything that isn't supposed to move. I've used Pilot626's calibration on Smoothie on this machine and Duet Calibration. Neither has a significant impact. Duet is the most convenient since I can run it any time I want when testing. It isn't as sophisticated as Pilot626's but with his I have to disable the panel and ethernet to free up enough memory to run, so I was constantly flopping back and forth between two firmware installs. Every few months I get annoyed enough to take another shot at understanding this issue. After banging my head against the wall for awhile I regain senses and get back to the business of printing - until it eventually annoys me enough to try again. None of my other deltas have this issue, just my very first early V1 (probably one of the first few off the laser) has it. At some point I am going to pick up a V2 for comparison and to eventually mothball this early one.

In the meantime, I did pick up one of the Max Metal kits that Eagle sold. I am thinking about building it up, calibrating it so I know it is good and then moving the effectors, arms and carriages from my V1 to this setup to test and vice versa. It should be an interesting test to see where the problem migrates.

cheers,
Michael

[geneb]

Michael, I'd bug the guys for a set of the new carriages and arms to see if that had any effect on the issue. The arm pack comes with a new, single piece platform as well.

I'm going to be updating Orange Menace with the new arms and FSRs as soon as OpenDACT has the scaling issue resolved.

g.

[mhackney]

I've replaced the arms and carriages, just not the effector yet. I'm using TrickLaser stuff. I do have the new trick carriage I may try. I'm in a "it doesn't bother me" mode right now though

Right now I'm on a filament driver and multi color hot end bender.

[geneb]

Heheh. S'ok, I've been rabbit-holed in to R/C again.

g.

[mhackney]

I'm REALLY trying to avoid that! I was big into RC helicopters right before I got into 3D printing. Imagine the $$$ just being pounded into the dirt. Probably one of the most expensive hobbies around. I have all my radio gear so getting into a quad copter would be sooooo easy.

[RollieRowland]

Rollie, the hump is not a delta kinematics issue and calibration can not correct it. It is some sort of mechanical issue that I've been chasing for several years. I've introduced errors into my machine's geometry and mapped the movement to try to understand it - similar to the heat maps that Steve Graves discusses in his "Delta Robot Kinematics" paper. What's odd is that none of these has had a tangible impact on these 2 issues. They are small though - .05mm or so at the peak/valley, but for my work it is enough to be problematic, most people wouldn't even notice. But the open weave side plates on my fly reels (the white part on my avatar) are visually impacted by this variation since the first layer is the most visible in the product. Today I simply work around it and print on the other side of the plate when I need dead flat movement.

As you know, nothing that automatic calibration can do can't be done manually with enough time and perseverance as the end result is a set of parameters that feed into the delta kinematics. I've spent more time than most would have the patience for if for no other reason to understand the root cause of this issue. The defects are asymmetrical and not directly aligned between the towers - they are offset to the side a little and shaped like a rounded triangle. I've replaced carriages (now run TrickTrucks), arms (CF rods) and most everything else including adding FSRs for a Zprobe with a new bed mounting system. The ONLY thing I haven't replaced is the original effector so I suspect that. However, I have JB Welded the effector so there is no movement on anything that isn't supposed to move. I've used Pilot626's calibration on Smoothie on this machine and Duet Calibration. Neither has a significant impact. Duet is the most convenient since I can run it any time I want when testing. It isn't as sophisticated as Pilot626's but with his I have to disable the panel and ethernet to free up enough memory to run, so I was constantly flopping back and forth between two firmware installs. Every few months I get annoyed enough to take another shot at understanding this issue. After banging my head against the wall for awhile I regain senses and get back to the business of printing - until it eventually annoys me enough to try again. None of my other deltas have this issue, just my very first early V1 (probably one of the first few off the laser) has it. At some point I am going to pick up a V2 for comparison and to eventually mothball this early one.

In the meantime, I did pick up one of the Max Metal kits that Eagle sold. I am thinking about building it up, calibrating it so I know it is good and then moving the effectors, arms and carriages from my V1 to this setup to test and vice versa. It should be an interesting test to see where the problem migrates.

cheers,
Michael

Ok, I should ask, is there by any chance you have a visual heightmap or a height matrix for those results? If not a general shape of the error location and the base angle at which the error shows up. This error would have to be a mechanical issue, if not an error in parameters. If we look further into this we may be able to find what exactly is causing this, however, I have several ideas but no way to test. So if you want to let me know everything that you currently know about the issue, we could try to diagnose the issue!

[mhackney]

I do, let me pull the latest out and email you. I agree, it is some sort of mechanical error and not a calibration issue.

Happy to have another set of eyes on it. I've spent more time on this issue than I care to think about!

[geneb]

I bought a Taranis X9E radio. *sigh*



g.

[mhackney]

run, run away...

[RollieRowland]

I do, let me pull the latest out and email you. I agree, it is some sort of mechanical error and not a calibration issue.

Happy to have another set of eyes on it. I've spent more time on this issue than I care to think about!

Excellent! From what I can tell this error - being consistent in two areas - would probably roll out the possibility that the issue is in the carriages or the tower . I would assume it would have to be due to the effector plate. What specifically? That is difficult to tell.

However, another way to look at it is how the there is no error occurring near the Z tower - this does not necessarily mean that the error might not be the effector plate. But it may mean that the effector plate is warped as opposed to just partially rotated. This could push/pull a single diagonal rod towards the tower (x - right diag pulling and y - right diag pushing). Considering this, the lack of error to the left of both towers would be accounted for and also the lack of error at the z tower.

Have you precisely measured the diagonal rods? If so then I would check the accuracy of the effector plate.

[mhackney]

Yes. I have a large caliper and everything has been measured. The other bit of info as I mentioned above, I had this issue with the original arms AND with the newer carbon fiber trick laser arms.

The effector plate is the 2 part plate used on the original V1. I've done as much as I can to measure it but it is tricky. I've also concluded that it is something to do with the effector. I had intended to rotate it 120° and see if the problem follows the rotation. But I've not had the time. I think my next step will just be to swap it out with the new trick laser effector. It is CNC machined and matches the trick trucks.

[RollieRowland]

Yes. I have a large caliper and everything has been measured. The other bit of info as I mentioned above, I had this issue with the original arms AND with the newer carbon fiber trick laser arms.

The effector plate is the 2 part plate used on the original V1. I've done as much as I can to measure it but it is tricky. I've also concluded that it is something to do with the effector. I had intended to rotate it 120° and see if the problem follows the rotation. But I've not had the time. I think my next step will just be to swap it out with the new trick laser effector. It is CNC machined and matches the trick trucks.

Then the plate is more than likely the issue, and if you decided to rotate the plate and see if the error rotated as well then that would be the perfect test! Other than that, replacing it would be even better.

[SirLinhart]

Our issue sounds similar to mhackney's. Regardless of calibration method we end up with 2 dips in 2 spots in the bed. Belts are evenly tight, skates are well locked in, rubber bands on the arms. We have an adjustable limit switch Z-probe that we set to match the position of the hotend to about .3mm. Have repositioned the bed multiple times, verified level by using a Starrett level. Multiple iterations though opendact from 2.0 to current on all modes. This has consumed a nauseating number of hours. I did pick up a set of tricklaser arms/effector/skates for a mex metal build, I can try them to see if it makes a difference, that will be our next step. If that fails then I'm not sure what to do besides an entire rebuild, and I'm not sure if Caspers frame can handle it.

If I still see failure, would generating a height map be useful to you Rollie? I could generate it with the Z-probe, just need to figure out how to use the G38 command and then determine a point set to check from.