Discussion Regarding Triangular Calibration

It seems that when chain compensation is used during calibration, the rotational radius that gets calculated is really far off from what it should be. My theory is that if you don’t end up with a rotational radius close to what it actually is (for a ring kit, something close to 140mm… but I don’t know if this has been precisely measured/calculated) then something is wrong. When I do calibration with chain compensation values entered, I’ll get a rotational radius around 132 mm. This means it’s trying to compensate for something else.

I don’t know how to fix this, but I have an idea as to how to maybe make an improvement. The software currently adjusts motorYcoord and rotationalRadius at the same time and when the errors associated with those values come close to solving the equation, the software starts adjusting the chainSagCorrection as well to arrive at a final result. It makes the adjusts in motorYcoord and rotationalRadius in lock-step, they aren’t independently adjusted so if you need to make a change in motorYcoord, you’re getting a change in rotationalRadius whether you need it or not.

Without making enormous changes to the routine and considering we have a good feel for what the rotationalRadius should be, what if we adjust for motorYCoord only at first, then when that reaches some minimum error, start adjusting rotationalRadius and then when that reaches some minimum error, start adjusting chainSagCorrection.

I think doing this would minimize changes to the rotationalRadius… which, according to my theory, should be really close to 140 mm (for ring kit).


I’ve been diving into the calibration code to see if I can understand it and make some sort of progress using chain compensation factors. One thing I noticed was that there’s a “sled drift compensation” factor which, from what I can tell, is a fudge. It’s not used in the model so it’s an indication that it can’t arrive at a solution without fudging. If I’m correct, if this value is not zero it suggests there’s something else wrong that’s not getting calibrated. The way the calibration works, if you don’t change this sled drift compensation value, you can’t correct the error to cut 3.

So, I’ve spent some time modifying the calibration routine to incorporate the calculation of chain compensation into it AND also allow for calibration of the distance between motors based upon the error in cut 3. After a bazillion test runs trying to figure out the right way of doing it, I’ve been able to arrive at a set of parameters that actually meets the calculation goal (error <0.0001) …

My initial conditions when I ran the calibration test last night were:

motor spacing: 3600.862
y offset: 469.12
rotational radius: 132.992
chain sag: 27.48982
left chain tolerance: 0.3479
right chain tolerance: 0.3605

With these values, I ran a test cut and got the following measurements (this was done using some other tweaks I did to the firmware to possibly correct for issues with chain compensation)
My cut values were:
cut12: 1928.8
cut34: 1927.2
cut5: 236.536
bit: 6.35

I ran my modified calibration routine and after 9141 iterations, I ended up with the following values:

motor spacing: 3602.6
y offset: 468.9
rotational radius: 133.572
chain sag: 39.98098
left chain tolerance: 0.376
right chain tolerance: 0.388

One key to arriving at a solution was to increase the maximum number of iterations, but more importantly, change the motor spacing by very small increments (initial used 0.5 and it was unstable and blew up… changed it to 0.1 and it settled down and reached a solution)

I wish the rotational radius was higher (it’s effective radius is 134.07 when you consider chain compensation) and closer to 138 or so which I believe is where it should be, but I’m going to try these values tonight or tomorrow to see where I end up accuracy-wise.


Sounds like good progress! :slight_smile:

One suggestion I have if its possible? Is to add in settings a manual X and Y scale factor, the reason I suggest this is because for myself and from what I’ve read from others as well it seems like people are getting consistent reproducible measurements off in one axis. Seems like an easy fix. If for example you cut a 1000 x 1000mm square and it always off by 5mm in the Y you could set the Y scaling to either +or- .005 and the results should be corrected. Would they not?
Simplification at its finest! Lol

Another quick thought/question. Why are we even taking rotation radius into account at all if the system has been engineered to place the bit directly in the center between the chains? That should remain a constant point. Seems to be adding a variable that isn’t a variable.

1 Like

One of the things I worked on for a bit was to come up with a compensation matrix to accommodate different x,y errors across the work area. I used a camera and a pattern of squares to figure out the error, but life got in the way. One issue is that in order for this to work, you have to in effect change the target x,y. This could be done in the firmware for simple linear moves(i.e., go to x-compensationX, y-compensationy), but when you are doing arcs, I’m not sure if you have to change the i and j values or not. I think you’d end at the correct spot, but I’m not sure you’d get there by the path you want.

Worth a try?

Not sure if you saw this, sorry for reposting.

Just to clarify I was referring to the X or Y compensation as a ratio not an absolute.

PS I’d be satisfied with having arcs off a little if the X and Y dimensions were correct.

Exactly correct. The rotational radius is what it is and should be constant. I think it’s close to 138 but no one has precisely measured it as far as I know… that’s why when I get 134, I worry. The thing is, however, the current calibration routine makes changes as follows:

  • To minimize error to cut 1, motor height (Yoffset) is adjusted
  • To minimize error to cut 2, rotational radius is adjusted
  • To minimize error to cut 3, (in my method) distance between motors is adjusted
  • To minimize error to cut 4, chain sag compensation is adjusted.

If you just fix rotational radius, I don’t think you’ll ever minimize cut 2 error… I’d like to come up with a way to do arrive at a solution without changing rotational radius… that’s the holy grail to me.

It seems the calibration process ignores the Y measurements altogether (except for distance to top of sheet) and that Y is where most people’s calibration is off. I don’t pretend to know the math but common sense tells me if you don’t measure it you can’t adjust for it.

Let me know when I’m becoming aannoying. Lol

There was a discussion regarding that and @jwolter who, iirc, came up with the routine said that things got worse when a vertical measurement was incorporated. Sort of, you can optimize vertical or you can optimize horizontal, but can’t optimize both. That was one of the things I was going to look at.

edit: it was @rjon17469, I think, who came up with chain wrap… got them confused… I think

This may seem like an uniformed observation but it doesn’t seem possible to say either cut1 or cut2 is responsible for error in the X without a third reference point say 0,0.

What about centering sled, plunging bit to make a center point and then referencing that for diagnal measurements? It gives you much more valuable information.

It’s complicated and I’m still trying to wrap my head around. It’s not intuitive to me yet, but it does seem to make accuracy better so it’s got that going for it.

I’m just spit balling sorry. Hahaha

It also occurs to me that if the calibration test pattern cuts 1-4 were at angles facing each other we could stretch a tape across from 1 to 4 and 3 to 2 instead which would combine X and Y allowing them to be calibrated together.

I really wish the devs @bar would chime in on this too.


I’ve been following along, but I haven’t had any ideas that seemed particularly good :stuck_out_tongue_winking_eye:

I like the idea of a diagonal measurement, but @jwolter is probably the right person to really give a definitive response to that. The idea of having a test pattern which measures in both X and Y seems like a smart move.

I really think that the crux of what we need to solve is to figure out why when we measure the distance between the motors we’re consistently off from what we find with a careful tape measurement. It seems to me that if we’re off there we can’t ask for perfect results from any calibration pattern…however every time I start digging into it I can’t find anything wrong. I think maybe I’ve looked at it too much to see what is going on.

If it’s not chain wear, and its not a problem with the gear ratio being off (as it was a long time ago), then its something deep in encoders

It is possible to eliminate any variables such as rotation radius to simplify the math? As I see it with the ring we should be able to assume the bit is at the convergence of the chains. That leaves only distance between motors and length of each chain (with sag comp). The distance from center to top of sheet or “home position” could be measured manually (accuracy left up to individual user) and wouldn’t affect accuracy of movement just part placement on sheet accuracy.

Maybe someone (i wish i could program) could write a new expiremental branch of the software with simplification being the objective. I would be more than willing to opt into testing.


@bar, do we have a really good measurement for rotational radius of the ring kit? I know we use 140 mm as an estimate, but do you know if someone has accurately determined this value?

I found my machine was just as accurate/inaccurate when I first set it up without auto measuring the chains; just using my measurements; possibly this step is unnecessary too? 1 or 2 mm motor distance must only equate to fractions of a mm on the sled?

I decided to try a different approach in optimizing the values. I went with something akin to simulated annealing (google it) where small random adjustments are made to a variable and if it reduces the error, keep it… if not, revert back and then try again. IIRC my neural network class from 30 years ago, there’s formulas used to determine the amount of adjustment, but I just winged it and used fixed scale factors multiplied by the total root-mean-square of the error of all the cuts. I never achieve perfection, but I did achieve interesting results:

motor spacing: 3606.906
y offset: 471.768
rotational radius: 138.562
chain sag: 28.39741308
left chain tolerance: 0.465689
right chain tolerance: 0.478165

The end errors were:
Cut 1: -0.3888
Cut 2: 0.0688
Cut 3: 0.2883
Cut 4: -0.00

My assumption is the errors are in millimeters and if so, I’ll give these values a try and see what happens.

What I really like is that the rotational radius is close to what it should be… no more 132 mm values. Even when I start with a 132 mm guess, it shoots up to 138.562 and settles in.


@bar, I think my method works well. I put the settings in and ran some tests. 14 inches up and down from center I was dead on. I repeated this test multiple times moving the sled toward the left side. When I was about 6 inches from the side of the board, I noticed some error (but not when I was 12-inches from side). I measured 1/16th off when the sled was 14 inches above the centerline and 1/32 off when 14 inches below centerline.

I think some of the error might be due to the router not being perfectly centered. I did the best I could do by hand and thought it was really good, but when I rotate the sled it isn’t perfect yet. I think I’ll recut my sled this weekend using the new calibration values (since it’s bang on in the middle) and see what comes from it.

I’m thinking that to get more feedback that maybe I should turn it into a stand alone console based calibration program that allows you to enter the cut values and have it report its best solution. The changes I made so far are pretty substantial. I think it’s easier to do this way … yes?

I’d run the benchmark test but my spoilboard is butchered up and it’s impossible to figure out what mark is what mark.


I like this idea a lot, I think it would help me and others to better understand how the technique works