The calibration process reiterates until it gets to within 0.5mm difference between a 600mm vertical and a 600mm horizontal. That’s pretty good.
My experience is that making certain that the motors are mounted securely, that the arms are very rigid and that the work area sheet hasn’t bowed very much are important mechanical considerations. I’m still learning about the software side, but not using too aggressive a feed rate, cut depth or overlap distance seem important as well.
The problem is that this is just that it’s accurate at that point on the work
area. The calibration routine only tweaks the distance between the chain mounts
to get the square accurate. If you have errors in the distance to the bit, or
distance to the CG of the sled, the calibration steps haven’t fixed that, just
introduced enough countererror to make the box square in the center of the
worksheet.
However, the different types of errors map out to different patterns of errors
across the work area, so as you move away from the calibration area, the
different errors don’t cancel themselves out and you start to see issues.
how bad this is depends on how far off the other measurements are.
I posted this earlier, but can’t find it now.
dimensions that matter are:
Traditional kinematics
 distance between the motors
 distance down to the (0,0) point from the motors
 length of chains
 distance between chain mounts on sled
 distance from chain mounts to router bit
 distance from router bit to CG of sled
Triangular kinematics
 distance between the motors
 distance down to the (0,0) point from the motors
 length of chains
 distance from bit to chain mounts on sled (as an ‘error’ to the chain length)
distance between the motors can be measured fairly accurately.
distance down to the (0,0) point [1] is hard to measure (but the triangular
calibration routine can calculate it), especially for a traditional frame, it’s
a little easier with a topbeam frame.
length of the chains we measure out by how far we have rotated the motors and
how many teeth on the sprocket. There is error here based on if we started with
a sprocket point straight up (how accurate is straight up), and error based on
the chain ‘stretching’ as the clearances between the parts of the chain are
taken up. This is down in the thousanths of an inch per link, but it starts to
matter as we have lots of links in play (in the area of 700 links)
beyond that, things get messy.
where the chains mount to the sled is hard with the traditional mounts because
what matters is where the chain bends, and you also need to shorten the
effective length of the chain as you have parts of the chain extending beyond
where it pivots.
on triangular kinematics, this is much easier and everything can be viewed as an
error in the length of the chain (although, centering the ring/pantograph with
the bit can introduce error) and discovered via calibration.
the other diemensions are impossible to automatically measure.
during the traditional calibration, the only thing that is being changed is #4,
so if #2, #5, #6 are off (or the amount of chain used at the mount is off), we
cannot fix them
David Lang
[1] the [0,0] point’s actual location is not critical, what is critical is that
we know how far below the motors it is and that the user of the machine knows
where it is, and has some control over it
That’s a very good summary, it would make a very good wiki page.
I expsnded this to make this wiki page
It could really use some pictures/diagrams to show the different options, but I
don’t have time to do that right now
Comments?
David Lang
Digging up this thread. For triangular kinematics, has an autocalibration scheme such as what @dlang described at the beginning of this thread been developed?
I’ve been playing with this idea. I started with the concept of trying to determine the motor spacing by having the user measure the vertical distance between two cuts. To do this, I took the triangular kinematics formulas used to calculate chain length and attempted to solve them in reverse, such that _xCordOfMotor and _yCordOfMotor could be determined. However, with the updated triangular kinematics equations accounting for sprocket geometry, this process led to some complex equations which I was not able to solve.
With that, and because this is not involved in the realtime operation of cutting, I decided to try an iterative approach instead. I designed an algorithm which would extend both chains a certain amount (this would likely have to be completed by the user pressing a button to extend the chains to the desired length), such that when connected to the sled the sled is at the top of the workspace. A cut would be made in place, then the user would move the sled vertically down to the bottom of the workspace and another cut made. The distance between centerpoints of these two cuts would be measured. This measurement, combined with the known chain lengths for each cut, would serve as the inputs to the algorithm to determine the motor spacing.
I formed a very simple algorithm to solve this. It started with assuming the top cut defined position (0,0) (this can be changed later, as desired), and then used a seed position for the right motor of (1,1). As the cuts were performed in the horizontal middle of the workspace, due to both chains being extended the same amount, only one motor position needed to be solved for. I then had the algorithm compute the expected chain lengths for this motor position. The calculated chain lengths were compared with the actual chain lengths for each cut location, and based on the results the motor position was updated. If both estimates were too low, the motor X and Y coordinates were each increased by 50% of the average chain length error. If the top chain estimate was too short and the bottom chain estimate was too long, I assumed the estimated motor position was too high and decreased the motor Y coordinate by 50% of the average chain length error while keeping the X coordinate static. Similarly, if the top chain estimate was too long and the bottom chain estimate was too short, I assumed the estimated motor position was too far to the side and decreased the motor X coordinate by 50% of the average chain length error while maintaining the Y coordinate. If both chain length estimates were too long then both coordinates were reduced.
I ran a test case of this using actual motor coordinates (3413, 1857). 561 iterations later beginning at (1,1) and the estimated motor position was (3412.995, 1857.007).
Next, I turned my attention to the rotationDiskRadius variable. Like David mentioned, if you performed three cuts (one at the top, one in the center, and one at the bottom), you would have two data points of the distances between them. I tried this, using the chain lengths of the top and bottom cuts to calculate the motor position, and then referencing the chain length of the center cut to calculate the rotationDiskRadius. The theory is, if the rotationDiskRadius variable was lower than the actual radius of the linkage assembly, the calculated chain length to this middle cut would be lower than the actual chain length. I used a feedback loop on this chain length to calculate the rotationDiskRadius while the motor position was being calculated as well.
This proved to be a bit more challenging. I had to scale down the feedback loop for this variable, otherwise it tended to become unstable and run off to very high values. With enough tweaking, I got it to run reliably. The downside of this is that it takes a lot more iterations.
My test case was a motor position of (1524, 724) with a rotationDiskRadius of 103.4. I began the motor at (1, 1) with a rotationDiskRadius of 1. After 3,842 iterations the estimated motor position was (1523.951, 723.967) with a rotationDiskRadius of 103.324.
Overall then, the theory checks out. However theory and practice can be quite different. My primary concern comes from chain sag. The accuracy level of the chain lengths required to produce these results was 0.001mm. Using the last simulation with an accuracy of 0.1mm the estimated motor position was (1519.147, 720.700) with a rotationDiskRadius of 97.635. This gives a motor position error of (4.853, 3.300) and a rotationDiskRadius error of 5.765. While it’s still in the right neighborhood, you can see that even small errors in chain length compound to substantial errors in the predicted dimensions.
All my simulations were done in Excel as I don’t have my Maslow yet, so I cannot comment on how much of a factor chain sag or other aspects would be. What I can say though is that from my simulations, if the rotationDiskRadius value was entered manually then the accuracy of the motor position becomes better than 0.4mm based on a 0.1mm chain accuracy. Given what I have seen doing this, and based on the relatively limited number of linkage kits compared to the drastic difference in motor position across different Maslows, I would prefer to use a static rotationDiskRadius and focus all the accuracy we have on motor position.
What do you guys think?
nobody has followed up on this, thanks for checking.
what about instead of increasing/decreasing the chain length by 50% you try setting it to what the chain length should be for the position actually cut (or 90% of the difference between what it thought it was and what it ould have been for that cut)
One interesting thing about the calculations being done in radians, it actually forms triangles and you can calculate where the top of the triangle would be if the chain wrapped around the sprocket were to be straight (if you dig into the math enough to make your head spin, you will see that it’s doing exactly that in the normal kinematics)
by the way, your testing is complicated by the fact that the chain lengths are incorrect, see What is correct chain pitch? and Whats inside the gearbox/motor? so that you can change the encodersteps variable and eliminate a 0.4% error that you didn’t know you had.
Using this approach you can’t set the chain lengths directly as they are calculated from the estimated motor positions, but you absolutely could use a larger step percentage to speed up the convergence. During my initial trials I used a very large step size and had issues with stability, so I was intentionally using a small step size to avoid those issues. There is definitely room for further tuning however.
On the topic of the triangles, I’ll have to investigate this further. If you try to accurately calculate the chain length with the sprocket portion of the chain straight then you still have the issue of unknown chain angle. You can remove this by assuming tan(x) = x, where x is the angle of the chain below horizontal. This is approximately true up to about pi/4, at which point the approximation breaks down. However, the chain angle from horizontal can easily exceed pi/4. Granted, the errors are not massive, but a couple mm error is possible, particularly in the bottom corners.
I’ve been catching up on the encoder steps per revolution topic. That’s a great find! Good job. I’m suspecting that will make a substantial difference in accuracy.
this is why you don’t try to calibrate in the bottom corners
do the calibration in the top half of the center of the workpiece (i.e. 0,0 and
0,+20" or so) that way the chain angles stay in the good range, and you can also
calculate the height of the motors above the work area.
The concern I have is that as the kinematics formulas get more accurate, say accounting for chain sag or other effects, the math for the calculation of the motor position becomes increasingly more complex. An iterative approach would allow simpler incorporation of future improvements to chain length calculations.
As an example, I put together an Excel calculator. Basically it has someone make two cuts/marks in the workspace, measure their distance, and then enter the programmed chain lengths required to get the sled to each position. This algorithm statically runs 1000 times, although if implemented criteria could be used to determine when to stop. Additionally, it could easily incorporate chain sag calculations or other aspects as well.
The calculator is here: MaslowTriangularCalibration v1.0.xlsx (158.3 KB)
Note that I haven’t tested this at all, so I would not say this is ready for inclusion in the GC code. However, if it works then it would be a possible method of providing an automated calibration routine for triangular kinematics.
If anyone has time and would be able to test the calculator to see if it gives approximately correct values, I would appreciate it!
The maslow is slow, doing 1000 cuts is not going to work.
The concern I have is that as the kinematics formulas get more accurate, say
accounting for chain sag or other effects, the math for the calculation of the
motor position becomes increasingly more complex. An iterative approach would
allow simpler incorporation of future improvements to chain length
calculations.
Anything with the triangular kinematics is SO
much less complex than the traditional kinematics (which could take hundreds or
thousands of iterations to try and figure out the chain length) that there is
pleanty of time for added calculations like chain sag.
As an example, I put together an Excel calculator. Basically it has someone
make two cuts/marks in the workspace, measure their distance, and then enter
the programmed chain lengths required to get the sled to each position. This
algorithm statically runs 1000 times, although if implemented criteria could
be used to determine when to stop. Additionally, it could easily incorporate
chain sag calculations or other aspects as well.
chain sag will have to be calculated on the fly because it will vary based on
the length of the chain and the tension on the chain
I don’t like the idea of making a separate thing in excel, the calculations
should be done in ground control.
If you look at my formulas at the top of this section, they are doing roughly
what you are talking about, making to cuts that should be at known positions and
then measuring the distance between them and solving the math.
I’ll take a look at your spreadsheet later, but how close are your forumlas to
mine? can you document how you came up with your forumulas?
Sorry for the confusion. Two point cuts/marks are made, the distance between them entered, then the algorithm iterates 1000 times to determine the motor coordinates. It’s more clear in the Excel file.
The formulas used here are literally exact copies of the triangular kinematics formulas. That was part of the goal, in that as the triangular kinematics equations are updated with things such as chain sag this would be updated with it. No reverse calculations required.
Also, the intention would be to build this functionality into GC. But for proof of concept (and because I don’t have a Maslow yet), I made it in Excel.
Ok, I understand better what you are trying to do here. I think we are pretty
close
I think we have a more accurate measurement of the distance between the motors
than the sled rotation radius, so I would want to measure motor distance and
calculate rotation radius rather than the other way around.
In an earlier discussion the possibility that the motors are not centered on the
work area was raised. I’d also like to avoid having people enter in machine
dimensions at all if we can.
I believe that we can do this by:

say that one of the locations is 0,0 (or possibly as close to this as a full
tooth movement allows so that the chains can be marked for this location) 
have the user manually move up/down/left/right to mark out the
limit of the allowable space
We then don’t need to have them measure/input anything other than the distance
between the two cuts.
I think it would be interesting to test this in two ways

Low Precision, Long Baseline
use as large a distance as possible with a tape measure (I’m good with
requiring this measurement be done in mm, even in the US most new tape measures
cover metric as well as imperial). 
High Precision, Short Baseline
use a small distance (about 6") so that a high precision measurement can be
made with a cheap electronic caliper
It would be interesting to see which approach is more accurate and easier to do
(and it may be worth offering both options and letting the user specify)
So where you list the steps as:
 Enter sled rotation disk radius and validate Machine Parameters are
correct  Calibrate chain lengths, then connect chains to sled
 Move sled vertically only to top of work space and make first cut/mark
 Record programmed chain length for first cut/mark below
 Move sled vertically only to bottom of work space and make second
cut/mark  Record programmed chain length for second cut/mark below
 Measure the distance from the top of the workspace to the centerpoint of
the first cut/mark and record below  Measure the distance between centerpoints of the first cut/mark and the
second cut/mark and record below
I think it should be.
 if using nonstandard motors/gears enter:
 stepsPerRotation
 link size
 sprocket tooth count
 measure the distance between the motors using the chain
 adjust the chain lengths to attach to the sled in the center of the work area. Mark the chains for this location.[1]
 do one small cut/mark
 move vertically as much as possible and still be in the work area
 do a second small cut/mark
 move the sled out of the way
 measure the distance between the cuts and enter it into the software
 move to the top/left corner and tell the machine we are at the limit there
 move to the bottom/right corner and tell the machine we are at the limit there.
 trace the full boundry of the work area to confirm everything is clear (possibly in both directions). This is sort of a ‘victory lap’, but it’s also a valid confirmation that the sled doesn’t hit anything or fall off anywhere along the way.
This only requires one measurement to be entered, the distnce between the cuts.
It also only requires three positions to be tagged (home and two corners), no
matter what the machine size is.
Since there are two unknowns here, I as thinking that we can’t just guess an
iterate to find the right answer (that’s why I took the more mathamatical
approach). But if we can, that is great (given that this only needs to happen
once, it doesn’t matter if it takes 1000 interations of 10,000 iterations, we
are talking seconds at most. Have it output what it thinks it’s accuracy is
every few hundred iterations so we can show a progress bar
If we can do this, I would not implement this calibration in GC, but rather in
the firmware. That way we can use literally the same code to do the calibration
calculations that is used to do the calculations during movement. (and the fact
that this is done in C will probably mean it’s faster than Python in GC, even on
a faster desktop)
If we need to, we can add a third mark (down from center) as a sanity check,
with three points and only two unknowns, I know we can calculate the unknowns.
David Lang
[1] this is a couple of steps as far as the user is concerned, but only one as
far as the machine is concerned because they all move both motors the same
amount ane they can be done on one screen without any prompts other than chain
movement.
First feed out a guess of the right length, then allow the user to adjust the
lengh by a multiple of one tooth movement until it’s convienient to attach the
sled, then move (again by multiples of one tooth) until the sled is in the
center of the work area
We don’t care when during this process the sled gets attached.
Will one need skirts around the workarea to support the sled? Perhaps this step could be optional; it takes quite a while to go ‘round the world’.
This is after the user has specified what the limits are by driving the sled to those limits. So it’s up to the user to decide if they are going to include skirts to support going to the very edge of the wood or not.
Yes, this can be optional (and the step before could allow for manual entry of the 4 limits), but I think it’s valuable to do this once (with any power tool, and especially with a CNC machine, it’s important to move it to it’s limits before trying to run it for real, you don’t want it hitting something while cutting)
by the way, this is why I suggested going round the world once in each direction, just to check that there’s not any instability that happens going one direction vs the other.
Better make it clear that the ‘workarea’ is not the same as the sled support surface, then. All the instructions are written around a 4x8 sheet, so the ‘workarea’ of that 4x8 layout would need to be three or four inches less on each edge. It’s one thing to plan a temporary support skirt for a cut that gets near the edge of a sheet, but different if its presence is required for calibration.
well, IMHO part of calibration (or at least machine setup, which is effectively
what this calibrtion process is) is defining what the cutting limits are. It may
be that we allow there to be multiple sets of limits (or easy ways to override
the limits), but the idea is to define what the machine’s effective size is, and
if you don’t want to cut too near the edge, you set the limits accordingly, if
you are willing to go all the way to the edge, you should plan to do so and test
it during the machine setup stge.
You shouldn’t have to drive to the limits to define them.
no, but it’s the easiest way to be sure that the limits are sane and what you think you are measuring.
So I would make the ‘drive to the corners’ be the default and allow for manual entry of the limits if people want to do that.
If you don’t actually move the sled to the corner, how do you really know that there is enough support there to keep it from tipping?
That makes sense to me, and is entirely possible. I’ll create another Excel document which functions similarly but solves for the rotation disk radius instead.
This is an interesting topic, and I feel itself could easily be an entire thread. The Excel calculator I created makes two assumptions:
 The line connecting the motor axes is parallel to the workspace X axis
 The X=0 line is equidistant from both motors
#1 is a function of build accuracy (due to the fact that currently the motors do not have individual Y coordinates but instead a single Y offset from the workspace). Individual Y coordinates for each motor, along with a corresponding change to the calibration routine, would allow this issue to be mitigated. Having said that, this particular issue does not affect precision or relative positional accuracy, but instead only influences absolute positional accuracy on the workspace. If you were trying to push to the very boundaries of the workspace or had a significant difference in height between motors then this could be more significant. I could see this being adjusted in the future, but for the time being I feel it is an acceptable assumption to make.
#2 is similar in that it only affects absolute positional accuracy. Having said that, while the code as it stands today cannot account for this, it would be a simple change to incorporate it. Individual motor X coordinates would be required, or an X offset of the workspace, but during calibration it could be assumed there was no X offset of the workspace center compared to the motor spacing midpoint. Then the X offset could be corrected after using a routine such as the one you mentioned of having the machine positioned to two opposite corners of the workspace.
I completely agree. My initial thought was to prefer the long baseline approach. Given the contents of my toolset, I can accurately measure down to roughly 0.5mm over a long distance. If I made such a measurement over say 900mm (assuming a 4x8 foot Maslow and performing calibration in the vertical direction), this would give an error of roughly 0.056%. The same error over 150mm would require an accuracy of 0.083mm. My current toolset is not accurate to anywhere near this level, and I suspect many Maslow users would be similar. Additionally, such accuracy is roughly within an order of magnitude of our current motor encoder resolution (assuming # 25 chain, a 10 tooth sprocket, and 8113.7 encoder steps per revolution). Because of that, we could see substantial resolutionbased error as well.
However, this level of accuracy during calibration may not even be required to achieve the project target accuracy levels, so I think it would still be interesting to test out.
Based on the steps you mentioned, it is possible to determine the rotation disc radius, the center of the workspace, and the workspace boundaries. Once the rotation disc radius is determined based on the two cuts/marks and the motor spacing is entered in, then the workspace limits need to be defined. This could be done either as you stated, by having the user move the sled manually to opposing corners and have the limits automatically calculated, or have the user enter the workspace dimensions manually as well as the offset from the top cut/mark to the top of the workspace. I think including both options would be beneficial.
Also, I completely agree on the iterative process. Even if it takes 10,000 iterations, we’re likely only talking a couple seconds at most, and then the process doesn’t need to be repeated until a change is made or a recalibration is desired. Having intermediate outputs is a good idea too.
I’ll work next on that updated Excel calculator.