Unsolved Mystery. Weird Z0 behavior around build perimeter.

[redoverred]

I created an Excel spread sheet with both inverse and forward kinematics. Given the values in the firmware for arm length, horizontal radius, radial position of towers and the positions of my printed columns, I determined the skate positions for each tower. I then had additional variables for the actual length of each arm, the horizontal radius and tower angles which I used to see where the end effector would move given introduced deviations from the idea. I could then try different values for each variable to try to match my printed results. This told me to rotate my X tower .4 degrees and to increase my horizontal radius .1mm. Making the changes in firmware and printing again and I'm close. Still need just a bit more fine tuning, but the first layer now sticks on all six points.

Can you share this spreadsheet? It would be SUPER helpful to a lot of people, I am sure.

[bot]

626, I don't disagree with wanting to make a printer as good as it can be... but I'm not sure if when a lot of you say "I got the end stops and radius right" that you actually did get them right... because that seems to be the only thing needed to resolve the issue.

I've calibrated two rostocks now, not just one, each of different design and build. Neither times involved rotating towers, spreadsheets, or anything other than observation and iteration. I hope to continue increasing the sample size, because I am confident I could fix this issue on any delta printer constructed in a suitable fashion.

[jmpreuss]

I've calibrated two rostocks now, not just one, each of different design and build.

At last year's midwest reprap festival I had someone try to calibrate my max who had literally calibrated over a hundred delta machines and could not get a usable print area greater than a 6 inch diameter. (btw my definition of a usable print area is will PLA stick using a .3mm first layer). I'm glad you have had success but there were several people at the fest who had similar experiences to mine so yes this calibration issue is real.

[0110-m-p]

I've calibrated two rostocks now, not just one, each of different design and build. Neither times involved rotating towers, spreadsheets, or anything other than observation and iteration. I hope to continue increasing the sample size, because I am confident I could fix this issue on any delta printer constructed in a suitable fashion.

Granted my printer is a V1, but there is zero chance I would have been able to get my printer even remotely close to flat between the towers without rotating the towers a few tenths of a degree.

[Jimustanguitar]

^agreed^ I was also at MRRF, and stumped the chumps.

If you read the whole thread from the beginning, you'll see that this goes far beyond a 4 point calibration, leveling, and radius config.

[bot]

I have read the enitre thread. Perhaps there is a physical build issue that some of you aren't noticing? How could this issue magically pop up for certain people but not others?

Either there truly is a random physical effect appearing in some builds, or people are just not being patient enough. It does take a lot of trial and error to get it right. Even with my abundance of confidence.

[lbarger]

I created an Excel spread sheet with both inverse and forward kinematics. Given the values in the firmware for arm length, horizontal radius, radial position of towers and the positions of my printed columns, I determined the skate positions for each tower. I then had additional variables for the actual length of each arm, the horizontal radius and tower angles which I used to see where the end effector would move given introduced deviations from the idea. I could then try different values for each variable to try to match my printed results. This told me to rotate my X tower .4 degrees and to increase my horizontal radius .1mm. Making the changes in firmware and printing again and I'm close. Still need just a bit more fine tuning, but the first layer now sticks on all six points.

Can you share this spreadsheet? It would be SUPER helpful to a lot of people, I am sure.

I'm not sure the spread sheet is ready for prime time just yet. It needs more testing/validation as well as instructions on how to use it. Unfortunately, I'm really busy with work right now and probably will be through the end of the year. I do plan to put it out there for those needing assistance beyond the normal calibration procedure. But at the moment, I think it will only add to the frustration of calibration due to the lack of instructions. Currently it only allows someone to input their firmware values and then alter those values until they find a relatively close match to the part they printed. What would really make it useful is to do curve fitting based on measurements of printed points that would allow it to display recommended changes rather than relying on trial and error.

I also would like to understand the math behind having too much play in the end effector/arms. That was my main issue and one I have not been able to simulate. The spread sheet therefore is useless for this issue. I suspect that play is the number one issue most users fight when they go outside the towers. In going through the calibration procedure I found end stops and horizontal radius that worked well as long as I always went from the X tower to Y and then Z. When I still could not print between the towers, I decided to check from Z to Y to X and found my stops and radius were significantly off (~.5mm!). Putting rubber bands on the arms seemed to help, but did not eliminate the issue. I was worried about long term deformation of the arms so I was afraid to try too much pressure. I chose to purchase the Trick Laser arms with their metal joints and tension bands. However, Geneb informs me the arms are fiber filled and should be OK for long term pressure. Just keep the bands near the joints.

So until I have time to type up instructions on my manual spread sheet, I recommend looking to see if you have ANY free play on the end effector/arms. Ideally you will not see any motion when you apply side to side pressure. If there is play, it will introduce randomness to the system that will prevent a good calibration.

[lbarger]

I've read the whole thread pretty thoroughly now, but I'm not seeing a set of enhancements or calibration steps that will result in a decent setup. I can see that using something on the arms to tension them is very helpful as well as making sure that everything is tight as far as screws, belts, etc. go. I also see that running the endstops and horizontal radius cycle until the radius is perfect is a good thing. I've done those things.

One thing I'm confused by is how to adjust the tower rotations. I know the physical reason for adjusting them and the location at which I adjust them in the EEPROM, but I am not sure what direction I should adjust them to or which one I should adjust.

Right now I am getting halfway decent adhesion at 100C for ABS on Elmer's purple glue stick and sort-of-okay first layer thickness on the very outer perimeter of the ~280mm diameter test print pattern, but some areas are thin and some are thick and some don't adhere properly. Furthermore, I've artifically "fixed" those issues by setting the Z0.0 height to be way lower than it should be, so basically at Z0.0 the nozzle is RIGHT at the glass bed, which basically means I adjusted it until it was catching the paper and then lowered it another 0.15mm until the paper was not quite pinned but almost pinned.

Let's say I'm getting thin areas between the X and Y towers (front 2) but further towards the Y tower (right front) and then I also get thinner spots on either side of the Z tower closer to it than the other towers. Would that mean I need to adjust the X tower and Y tower or X and Z or what?

Not that I am complaining, you guys are doing good work figuring out this stuff, but I sure wish there was an extensive guide on what, when, and how much to adjust each of the calibration items (endstops, tower rotations, horizontal radius, etc.) and formulas for how to adjust them. I suppose that I should just get into the kinematics of the thing and try and do it myself if no one else is going to, but I have enough maths to deal with in school on a daily basis

Anyways, what I found is I am getting the best adhesion ever from simply adjusting the Z0.0 height down by .10mm or .15mm below the height from the "paper test" artificially and also adding some zip ties to the middle of the twin arms to hold both ends tighter (Basically just threaded them through the arms and tightened a bit).

Additionally, I'm wondering why we're offloading these calculations to the RAMBO? Why would we not have the PC that is creating the g-code create it directly in delta-compatible code? Then we wouldn't need to have all these calculations running on the RAMBO in firmware and could probably do some more advanced calculations and optimizations based on some input numbers from the physical machine. The slicer would still produce normal g-code, we'd just have a second run of the g-code through a delta-computer that could optimize the movements and then the RAMBO would just output the XYZ commands directly as linear actuation of the cheapskates in XYZ delta space rather than in physical XYZ cartesian space.

What you are describing sounds EXACTLY like what I was getting before I resolved free play in the End Effector/Arms. My recommendations are:
1) Make sure there is now wiggle/rotation of the end effector when you manually move it (with power off).
2) Try calibrating the end stops in the opposite direction. If you normally go from X to Y to Z, try Z to Y to X and see if you have the same results. If there is play in your system, my experience says you will find different offsets needed.
3) Try adding rubber bands to the stock arms. They will need to be pretty snug. My semi-tight rubber bands only helped some. I went with the Trick Laser arms with metal joints and tight tension bands. The bands MUST be elastic so they can move with the arms and not cause binding issues.
4) With play eliminated go through the calibration procedure again.

For tower rotation, you want to 'move' a tower away from any high spot, toward the low spot on the perimeter. If all the midpoints between all towers are high or low, rotation is likely not your issue (I think that's play). After removing play from my system, I found a definite low spot between the X and Y towers (~.2mm lower than tower bases). The highest spot was between the X and Z tower but it was also a little high between the Y and Z towers. In my case I rotated the X tower a few tenths of a degree tower the Y tower so 210 degrees became 210.4. I also rotated my Y tower a little toward X so 330 degrees became 329.9. Now all my mid points and tower bases are within an range of .1mm. Your values will be different. Each time you rotate a tower, you will need to check your end stops and horizontal radius again so it does take some patients.

[rpress]

If all the midpoints between all towers are high or low, rotation is likely not your issue (I think that's play).

In my experience this problem is the arm length, and play in the joints would certainly change the effective arm length. My stock arms had a lot of play, so much so that I asked SeeMeCNC if it was normal. They said it was, so I build up the carbon arms from tridprinting.

To adjust the arm length the parameter is DELTA_DIAGONAL_ROD in Configuration.h as I mentioned in my previous post.

[bot]

I'm definitely agreeing with what lbarger is saying. I removed the play from my u-joints before I ever did any serious prints. I only printed maybe two things ever with the play in effect. Maybe that is the only issue?

Part of what I think the problem might be, as well, was how I was saying that the radius setting combined with the end-stop adjustment sets the center. There are two separate coordinate systems happening here. If the radius and end stop adjustments are not in equilibrium, z0 x0 y0 may be the "center" in one coordinate system, but not in the other (aka reality, the cartesian coordinates). Since, even with a perfectly calibrated machine, the build plane is never perfectly flat, but an undulating plane - a wave travelling and oscillating around the circle and outwards, we may not be actually "measuring" the center when we think we are measuring the center. This allows us to have the point under each end stop "the same" (ish), the "center" the same ish, but the true center is somewhere 3 or 4 mm away, and is raised. If you watch the motion of a poorly calibrated delta printer, you will see this undulating motion as it traverses across the bed. This is because the interplay of the arms is wrong.

As each tower lowers itself, it must move increasingly farther to affect motion "away" from it. If the radius of your machine (would be nice to know the ACTUAL theoretical number. is 130mm exact?) is set to, say, 133, but the actual radius is 129, then the effect will be the exact effect everyone here is complaining about. Just think about the movement of the arms, and watch as they move. The move much farther and faster as they get to the "problem" areas. It's because it thinks the radius is larger than it actually is. Picture if your radius really WAS 133, the extra movement would be needed to keep the nozzle level.

If you have high spots in your "across tower" locations, all of them, you likely have a bad radius setting. If you have a low spot on ONE of the across tower positions (or even under tower positions for that matter) you may only need to adjust a single endstop.

Also, as a note, it gets really confusing thinking about which way "lowers and raises" the plane, so take my "directions" with a grain of salt. I could have it reversed.

[626Pilot]

Not that I am complaining, you guys are doing good work figuring out this stuff, but I sure wish there was an extensive guide on what, when, and how much to adjust each of the calibration items (endstops, tower rotations, horizontal radius, etc.) and formulas for how to adjust them. I suppose that I should just get into the kinematics of the thing and try and do it myself if no one else is going to, but I have enough maths to deal with in school on a daily basis

teoman may be working on that exact thing.

Additionally, I'm wondering why we're offloading these calculations to the RAMBO? Why would we not have the PC that is creating the g-code create it directly in delta-compatible code?

The RAMBo is fast enough to execute G-code, even with depth corrections. AFAIK there is no free slicer that can natively correct for delta calibration issues. Overall I think that between inputting numbers to a slicer, and outfitting a printer with a Z-probe to correct its calibration issues locally, the latter is the more well-integrated solution. It lets the slicer focus on producing toolpaths, and doesn't introduce portability issues.

626, I don't disagree with wanting to make a printer as good as it can be... but I'm not sure if when a lot of you say "I got the end stops and radius right" that you actually did get them right... because that seems to be the only thing needed to resolve the issue.
...
I have read the enitre thread. Perhaps there is a physical build issue that some of you aren't noticing? How could this issue magically pop up for certain people but not others?

There are thousands of these printers out there, cut from who knows how many different lots of feedstock from who knows how many vendors, on at least two different laser cutters. Each laser cutter has its own tube and calibration, and a repeatability that I wish I could tell you - but SeeMeCNC refused to answer when I asked them. The G-code they use to drive the laser cutters may have been changed over time to correct for various issues, and they may not have used the same G-code to cut MDF as they did to cut lexan (back when they were cutting lexan, which they stopped doing for reasons I don't know.)

Have you calibrated any lexan Rostock MAXes from November-December 2012? Do you know whether your Rostocks are micron-perfect replicas of mine? These are the kinds of questions you should ask yourself before declaring the case closed. I have made the same mistake myself more than once.

Now, here is some hard data:

Code: Select all

[PD]             [Z]
[PD]            0.000
[PD]     -1.125  -.---  -0.258
[PD]        -.---  -.---
[PD]            -.---
[PD]        -.---  -.---
[PD] [X] 0.019  -.---  0.009 [Y]
[PD]            -0.066

The criteria for endstops and delta radius (less than 30 microns of variance between X, Y, and Z) are all met. Yet, X's opposite is -0.258, Y's opposite is -1.125, and Z's opposite is -0.066. If I adjust the delta radius to try to correct the opposite points, what value do I put in that makes all three opposite values (all of which are quite far apart) converge, without screwing up the depths at X, Y and Z?

I don't think it can be done, but I'll tell you one thing. Reducing Y's individual tower radius improved both X's and Y's opposites. Z's opposite got a little worse.

[RegB]

My build is from a July 2014 kit.
At the time I understood the clips holding the U-joints together to be a recent "enhancement", but they seemed unreasonably tight and only held in the direction along the axles, relying on the spring of the arms' jaws to hold those.
It just didn't seem right, plus they were a pain to remove/replace every time I needed/wanted to futz with something.
I replaced all 6 with rubber bands, I don't have a spec for those, other than in the relaxed state they are slightly shorter than the distance between arms.
I have them positioned just about half way between the beginning of the jaw opening and the U-joints.
A carefully matched set, of course.
Actually they are hoarded leftovers from mail delivery, but they DO match.

It seems to work well enough on what I do, i.e. I don't get sudden unexpected shifts that slop in this area could be expected to produce.

[bot]

626, I have not calibrated any other Rostock MAX. The other machine was a home built rostock that suffered many more problems than I'm sure any laser cut rostock could suffer.

Even so, I don't see the point in trying to calibrate a machine if you are convinced it is flawed. Simply remedy whichever hardware issue you seem to be facing. Laser cut melamine runs less than $200, I believe.

Your hard data leads me to believe you have some ways to go. There will NEVER be one variable that adjusts the machine into calibration from a state such as that. It will be a combination of all variables repeatedly. It is a gradual process. I really wish I could try myself to calibrate your machine.

[lbarger]

Now, here is some hard data:

Code: Select all

[PD]             [Z]
[PD]            0.000
[PD]     -1.125  -.---  -0.258
[PD]        -.---  -.---
[PD]            -.---
[PD]        -.---  -.---
[PD] [X] 0.019  -.---  0.009 [Y]
[PD]            -0.066

The criteria for endstops and delta radius (less than 30 microns of variance between X, Y, and Z) are all met. Yet, X's opposite is -0.258, Y's opposite is -1.125, and Z's opposite is -0.066. If I adjust the delta radius to try to correct the opposite points, what value do I put in that makes all three opposite values (all of which are quite far apart) converge, without screwing up the depths at X, Y and Z?

I don't think it can be done, but I'll tell you one thing. Reducing Y's individual tower radius improved both X's and Y's opposites. Z's opposite got a little worse.

Based on my very limited experience I am inclined to ask if you have any free play in the end effector? Have you tried checking end stops by approaching the towers from different directions?

I set up the following scripts for my calibration procedure:
1) Home, goto X0 Y0 Z100
2) Goto Z10, Goto X-112.15 Y-64.75, goto z2
3) goto Z10, goto X112.15 Y-64.75 Z1, goto z2
4) got0 z10, goto X0 Y129, goto z2
5) Goto Z10, goto X0 Y0, goto Z2

My procedure was based on the 'quick' calibration method posted by someone else on the forum (sorry did not remember name).
Add 1mm to the Max Z travel. Run script 1 to home and stage the head. Run Script 2. Manually jog the head down till it grabs the paper. Note the offset. Repeat for scripts 3 and 4. Adjust the stops and repeat to consistent. (Probably did all that.) NOW run scripts 1, 2 and 4. Check the ends stop for Z tower. Run scripts 3 and and 2 and check stops at Y and X tower respectively. If the numbers are very close, you probably do not have much play so we can continue. If they are off by approximately .1mm or more you probably need to remove play in the arms. (Try rubber bands or something elastic or chose to 'upgrade' arms with magnetic ball joints, etc.)

Unfortunately most of the variables we can adjust will effect the readings at X, Y and Z at least a little. Seems to be the nature of the beast. Many variables will effect X, Y and Z potions equally so we can adjust the printer height instead of end stops.

To have a chance to accurately predict the changes you need to make we will need additional information. With just 6 points on the perimeter we and only test 6 variables, three of which are your end stops given the location of the points. We can then look at each tower rotation, each arm length or horizontal radius for each tower, but can not distinguish well between these effects very well. Can you provide the height at 0,0 along with your current settings for arm length, horizontal radius, tower angles etc.? PM me with the settings and 0,0 height, it will help me test my spreadsheet. I'll run the numbers through and see if I can discern any pattern. (It would also be helpful to have heights for points midway between 0,0 and each tower as well as midway between 0,0 and tower opposite. I used a 129mm radius for tower/opposites and 64.5mm radius for the midpoints, but can enter any points to test.)

If my math is correct, arms shorter than set in firmware looks should tend to lower points opposite each tower, but will also greatly lower the center point. So if you adjusted the horizontal radius to zero the center point with arms of incorrect length, the radius will also be off. Also for tower rotation you want to move the tower away from any high spots toward low. (Low spots means towers are actually closer than specified in firmware and conversely, high spots means the towers are further away. This does not work well if all points opposite towers are lower or high.)

General points:
1) Play/slop is a calibration killer - will not allow consistent results and could have travel direction dependency.
2) End stops set angle of plane for the bed. If a point beneath a tower is low, the opposite point should be high (with everything else being correct).
3) Horizontal radius effects concavity/convexity of head motion, should not effect -X, -Y and -Z positions (2, 10 and 6 O'clock positions)
4) Short arms will cause Z to raise moving toward the center, but fall when going outside the tower triangle. If calibrated at 4 points using wrong arm length, horizontal radius will also be off. Generally, if arm length needs reduction, so does the horizontal radius.
5) If there are low and high spots between towers at the perimeter, move tower away from high and toward low a few tenths of degrees.

[626Pilot]

There will NEVER be one variable that adjusts the machine into calibration from a state such as that. It will be a combination of all variables repeatedly. It is a gradual process. I really wish I could try myself to calibrate your machine.

Just for s---s and giggles, I implemented your calibration method in code. It wasn't a big deal to do so - I just had the code average in the tower-opposite points along with the tower points, and the DR was increased or decreased to make that average as close to bed center as possible. The endstop and delta radius values wound up chasing each other around in circles. If all three tower-opposite points had very similar deflections, I think it's plausible that adjusting the delta radius might fix it, but they are too divergent. The value that fixes one throws off the other two because of the differences between them. That's why being able to correct an individual tower's radius and angle offsets are useful in my case. Maybe arm length too, but I've found that changing the individual arm length offsets causes only a tiny change for any realistic offset.

I had thought about getting a version 2 kit, and got really excited about the idea that it might fix my problems. Unfortunately, when I asked an upgraded forum member whether they still had the Z=0 problem, they said yes. I was crestfallen.

Based on my very limited experience I am inclined to ask if you have any free play in the end effector? Have you tried checking end stops by approaching the towers from different directions?

I had some play in the effector when I was using SeeMe arms, but I switched to Trick Laser CF arms and there is none - at all. The arms are rubber-banded very close to the joints.

I've spoken some about the firmware upgrade I'm working on for Smoothie, and this has one probe calibration method (G29) and two printer calibration methods (G31 and G32). G31 is the heuristic simulated annealing method that isn't done yet. G32 is an iterative probe-adjust loop that measures the depths at the print surface, makes minor adjustments using a gradient descent method, probes again, etc. until the points converge. For a baseline endstops/delta radius calibration, I use the iterative G32 method because it's similar to what you'd get from geneb in the Rostock manual. Unlike that method, it converges the endstops and delta radius at the same time. It doesn't go clockwise or counterclockwise - it samples all the points, does the gradient descent, and then tests. After a few iterations (usually 3-4) it gets all three endstops within 30 microns of each other, and de-lenses the delta radius until the center depth is within 30 microns of the average of the tower depths. (And the tower-opposite depths, when I was testing them to try out bot's theory.)

Before, I was using separate methods to set the endstops and then the delta radius. This actually takes far more probing passes, and produces a less perfect calibration.

Can you provide the height at 0,0 along with your current settings for arm length, horizontal radius, tower angles etc.? PM me with the settings and 0,0 height, it will help me test my spreadsheet. I'll run the numbers through and see if I can discern any pattern. (It would also be helpful to have heights for points midway between 0,0 and each tower as well as midway between 0,0 and tower opposite. I used a 129mm radius for tower/opposites and 64.5mm radius for the midpoints, but can enter any points to test.)

OK. These numbers were collected with Z-probe, with stats as follows: Range=2 steps (0.0094mm), sigma=0.64 steps (0.003mm). I used a target tolerance of 30 microns (0.030mm).

Settings:

Code: Select all

[PG]           Arm length: 269.000
[PG]         Delta radius: 131.531
[PG]      Endstop offsets: {-1.756, -1.695, 0.000}
[PG] Radius offsets (ABC): {0.000, 0.000, 0.000}
[PG]  Angle offsets (DEF): {0.000, 0.000, 0.000}
[PG]    Arm offsets (TUV): {0.000, 0.000, 0.000}

Now for the data. Sorry it isn't formatted prettier. I'm going to ask SeeMe if they can change their stylesheet to use a fixed-width font in their code tag.

The actual numbers as of right this second, relative to the center (TP_CTR in the following table), with the outmost points sampled 115mm from center:

Code: Select all

[PD]             [Z]
[PD]            -0.038
[PD]     -1.172  -0.713  -0.314
[PD]        -0.492  -0.295
[PD]            0.000
[PD]        0.014  0.080
[PD] [X] -0.005  0.220  0.009 [Y]
[PD]            -0.089

Table format:

Code: Select all

enum _cds_test_point_t {
                                  TP_Z,

              TP_OPP_Y,        TP_OPP_MID_XY,        TP_OPP_X,

                     TP_MID_ZX,             TP_MID_YZ,

                                  TP_CTR, 

                   TP_OPP_MID_YZ,          TP_OPP_MID_ZX,

           TP_X,                TP_MID_XY,                   TP_Y,

                                 TP_OPP_Z
};

[bdjohns1]

Maybe arm length too, but I've found that changing the individual arm length offsets causes only a tiny change for any realistic offset.

My understanding is that all other things being equal, changing arm lengths tends to affect cartesian X/Y (part scaling) more than Z.

[lbarger]

626Pilot, I have not yet been able to replicate the measurements you provided. What's particularly difficult to emulate are both the extreme dip at the -Y position and the funky sine wave like oscillation along the line going from Z to -Z. I'll keep trying. I'm seeing if I can add other tests to the spread sheet.

In case I am able to make some progress I would like to verify the coordinate system. Does the minus Z value mean the end effector is too low or high?

Also, did you tighten the onyx plate down at room temperature are at typical operating temperature? I had received a recommendation to loosen the screws, run it to temperature for a few minutes, then tighten. Different thermal expansion rates may be inducing an actual bow or wave in your build plate. It seemed to help me some when I was also fighting the free play in my build.

[redoverred]

626Pilot, I have not yet been able to replicate the measurements you provided. What's particularly difficult to emulate are both the extreme dip at the -Y position and the funky sine wave like oscillation along the line going from Z to -Z. I'll keep trying. I'm seeing if I can add other tests to the spread sheet.

In case I am able to make some progress I would like to verify the coordinate system. Does the minus Z value mean the end effector is too low or high?

Also, did you tighten the onyx plate down at room temperature are at typical operating temperature? I had received a recommendation to loosen the screws, run it to temperature for a few minutes, then tighten. Different thermal expansion rates may be inducing an actual bow or wave in your build plate. It seemed to help me some when I was also fighting the free play in my build.

Would you like to share the spreadsheet? I think it would be extremely helpful to a lot of us!

[lbarger]

Would you like to share the spreadsheet? I think it would be extremely helpful to a lot of us!

I will be more than happy to share it once I'm sure it works. Releasing a tool that does not work correctly and does not have any meaningful instructions will only add to the frustrations of those struggling.

Right now I'm having doubts it is working correctly in testing 626Pilot's issues. If anyone wants to assist in testing/validating it I will share it one on one in its 'alpha' form. At the very least it needs more testing and instructions on how to use it. I've started to write up an explanation of the equations, but nothing that is very user friendly.

What I have is suppose to allow you to individually tweak various factors and see what effect they should have. It's still very much trial and error, but quicker than using a dial indicator or printing sample parts. It did help me correctly identify a tower rotation issue once I resolved the free play I had. But in its second test, with 626Pilot's numbers, it seems to be failing.

I'm starting to converge on something close for 626Pilot, but what it's suggesting goes against logic. Its saying the delta arms are <261mm in length. That's a full 8mm shorter than spec and I don't see how that's possible. I briefly wondered if he might had gotten Orion arms by mistake but they're only 178mm. That said, the numbers I'm currently on replicates his results to with 0.07mm except for 4 of the 13 point. It's still off by as much as 0.36 mm midway between Y&Z, midway between X&Z and at OppY. Its off by 0.68mm midway between OppX &OppY! That just does not make since. I'm guessing there is another variable that I am not accounting for yet that will effect the inner points (and probably tower opposites as well). Another possibility is that there is an error in part of the spreadsheet effecting certain cells.

262Pilot, if you want to test this, my values are currently
Arm Length 261mm (all axes)
Horizontal radius 129.4mm for X, 130.1 for Y and 129.4 for Z
Tower rotation angles are 209.5 for X, 330 for Y and 90 for Z
If all this is true, you will also need to modify your z height by approximately 8mm. I'm not trusting this even though it looks close! I would measure the arms at it should be easy to see if they are within 8mm of spec. Of course there is a small possibility that this bed in particular is actually warped and these numbers will somewhat force the end effector follow the warped surface. I should also note such a dramatic change does effect the X and Y positions as well. In this case, upwards of 5mm lateral displacement around the 115mm radius so if it is following a warped bed, there are still bad side effects. (More testing to come.)

[626Pilot]

In case I am able to make some progress I would like to verify the coordinate system. Does the minus Z value mean the end effector is too low or high?

-1 = 1mm below center depth
1 = 1mm above center depth

Also, did you tighten the onyx plate down at room temperature are at typical operating temperature?

I think it was tightened cold. The glass plate sitting on top of it doesn't bow like a PCB.

Arm Length 261mm (all axes)
Horizontal radius 129.4mm for X, 130.1 for Y and 129.4 for Z
Tower rotation angles are 209.5 for X, 330 for Y and 90 for Z

I have Trick Laser CF arms, which are supposedly "about" 269mm.

Of course there is a small possibility that this bed in particular is actually warped and these numbers will somewhat force the end effector follow the warped surface.

That is possible, although I laid an aluminum straight edge across it and there don't seem to be any deformities.

Here is my thinking:

• Calibrate geometry using heuristics (my Smoothie calibration, your spreadsheet, or whatever else)
• Compute the "average surface" from all the depth-mapped points, and use the surface normal to rotate the printer's coordinate system (this requires firmware support, which Smoothie has)
• Whatever isn't fixed by all that will have to be corrected by adjusting Cartesian Z according to an interpolation of the depth map (same)

I have made a few breakthroughs in the simulated annealing process. It can be a bear to figure everything out. Right now I've got it generating virtual printers with various configuration differences to see if it can converge on a solution. It seems to resolve endstops, delta radius and arm length pretty well. Tower radius and angle offsets slow things down a little, and I haven't figured out the right parameters to get it to converge to a good number. This is the "curse of dimensionality" - more things to converge makes it that much harder for the algorithm to figure out what changes are good, and what changes are bad. I may need to switch to a parallel annealing algorithm, where each variable set has its own temperature and breadth-of-search.

The algorithm is based on simulated annealing, but it's more like how a heliotrope finds the sun, or a fungal plasmodium finds its way in and out of a maze of arbitrary complexity. It uses a binary search to figure out the setting for each variable with the lowest energy (deviation) and this is used to "lure" the value, which advances towards the ideal a random amount each time. The randomness scales with the annealing temperature, so it moves slower and slower as time passes. This means the values are not constrained to the surface of the geometric function describing the printer geometry, and that in turn means that the values are free to tunnel "under" the function, thereby escaping local minima in order to seek the global minimum.

[lbarger]

626Pilot, Sounds like your math is much more sophisticated than my own. More like where I would like to get to. My question is what are the variables we would likely need to be able to adjust? As I said in my last post, I think there is something (or several things) going on with your system that my current configuration does not allow for. I currently adjust end stops, arm length, horizontal radius and tower angle (all for each tower). I don't think tilt in towers can be tested for well as that should look like changing horizontal radii or tower angles as the Z level changes and would not be noticeable for just the first layer. For the general case, it would be nice to be able to mathematically determine if play in the arms was effecting prints. (That would not seem to be the case for you or me now.)

I agree that the glass should not bend like a PCB, but there is some limited flex to it. It would have some tendency to conform to variations when it is clamped in place. I could therefore see the glass taking on a bit of a taco shape or possibly a pringle/saddle shape, but I'm guessing the flex would only be a few tenths of mm at most. I don't expect the glass could cup or dome. It seemed to help me a little, but I had other issues happening at the time so it might have been a coincident.

Your virtual print approach sounds similar to what I'm attempting to do in the spreadsheet (and manual value adjustment). I run the inverse kinematics using the printer's firmware settings to determine where it is sending the skates. I then run forward kinematics with different settings to find how various changes effects the position of the end effector on the hypothetical/virtual printer. I try changing one parameter at a time to see if the computed results gets closer or further than the printed (or probed results).

For anyone wanting to look at the kinematics, the forward kinematics do get involved. I found the simplest way to think about it (and solve) is to consider the problem as the intersection of three spheres. The spheres are centered on each skate and their radius is the length of the delta arm. You can PM me for more information (including current unvalidated spreadsheet) or you can find the method online.

[redoverred]

I will be more than happy to share it once I'm sure it works. Releasing a tool that does not work correctly and does not have any meaningful instructions will only add to the frustrations of those struggling.

Right now I'm having doubts it is working correctly in testing 626Pilot's issues. If anyone wants to assist in testing/validating it I will share it one on one in its 'alpha' form. At the very least it needs more testing and instructions on how to use it. I've started to write up an explanation of the equations, but nothing that is very user friendly.

If you would like to send it to me, I'm sure I can figure it out and help testing with my own machine. I'm a mathematician, so I should be able to grasp the equations and such, although I haven't yet familiarized myself with delta kinematics I am sure I can understand them once I actually take the time to study it.

[626Pilot]

626Pilot, Sounds like your math is much more sophisticated than my own. More like where I would like to get to. My question is what are the variables we would likely need to be able to adjust?

Endstops
Arm length (possibly per-arm, but I'm dubious)
Delta radius (per-arm)
Tower angle offset

I also think it may be useful to calculate the surface normal of the bed. There is some code in Smoothie that does this, and I'm looking at it to see how it's done.

I don't think tilt in towers can be tested for well as that should look like changing horizontal radii or tower angles as the Z level changes and would not be noticeable for just the first layer.

Tower tilt would most definitely show up in the first layer, especially out towards the edge. It would be necessary to alter the kinematics to treat each tower as a rotatable line, which should be mathematically possible. The rest of the math doesn't care as long as it knows the coordinates the carriages wind up at. This could be set up as a simulated annealing variable. I haven't really looked into it because I used an angle gauge (like you'd use to calibrate a table saw) to make sure all the towers were within about 1 degree of vertical, and I don't think it would explain the unusual elevation near my Z tower.

I agree that the glass should not bend like a PCB, but there is some limited flex to it. It would have some tendency to conform to variations when it is clamped in place.

I don't use clamps. I printed six retaining clips that hold the glass from the side, but not from the top.

current unvalidated spreadsheet

This contains the full forward and inverse kinematics used in Smoothie: https://github.com/626Pilot/Smoothiewar ... lution.cpp" onclick="window.open(this.href);return false;

If you simulate carriage positions with IK and then simulate the effector position with FK, and if you don't change the settings between running the two methods, you will get the same numbers out that you put in. If you change the settings after running IK, FK will return numbers that make sense for how it was changed. Indeed, I can use simulated annealing to find the correct endstop settings, accurate to within a few microns.

I've also been extending the code to do parallel simulated annealing, where each variable can have its own annealing temperature. I've found this can help the algorithm converge on better solutions than otherwise.

[lbarger]

I also think it may be useful to calculate the surface normal of the bed. There is some code in Smoothie that does this, and I'm looking at it to see how it's done.

I don't think tilt in towers can be tested for well as that should look like changing horizontal radii or tower angles as the Z level changes and would not be noticeable for just the first layer.

Tower tilt would most definitely show up in the first layer, especially out towards the edge.

This contains the full forward and inverse kinematics used in Smoothie: https://github.com/626Pilot/Smoothiewar ... lution.cpp" onclick="window.open(this.href);return false;

I look forward to hearing what you learn about surface normal of the bed from the Smoothie code as well as how that is used.

I agree that tower tilt will effect the first layer, what I was trying to say was it would be difficult to distinguish the tilt from horizontal radius effect (if leaning toward the plate center) or tower rotation (if it was toward toward another tower) with JUST a single layer check. If one could check for z errors at multiple heights, say 1mm and >=10mm then you may see differences based on the height and calculate the lean. That said, would there be any way to account for this in software/firmware? Identifying it could still be helpful for some user if they have such an issue with their build.

My spreadsheet currently does output the same positions that are entered when the same parameters are used for both inverse and forward kinematics. However, being new to Delta printers I made several assumptions that apply to both forward and inverse kinematics calculations. I will look at the Smoothie code you provided to see if my assumptions are valid or if I need to update the file.

[626Pilot]

Math time...

I have a question about finding a point on a 3D mesh made out of triangles, the vertices of which are the test points on the print surface. If I probe the surface and get a bunch of depths, I have a "mesh" approximating that surface. I need to use that mesh to correct for Z.

I assume that in order to get the right depth for a given (x, y), I have to find the nearest triangle of that mesh and then somehow turn the surface normal into a depth.

How do I do that really quick (since it will have to be done 100s of times a second) and with the smallest memory footprint possible? I don't know that much about computational geometry. Help me find the right answer, and I will help you print!