some have been tested… but not this last set. My last test gave good results in the bottom left and right corners, but really bad results in top left and top right. Really bad means vertical measurements of the benchmark squares off by a 2-3 millimeters
And a new weirdness. ChainSagCorrection seems to have very little impact using these new numbers. When I war running it, ChainSagCorrection was varying from 15 to 45 with practically no impact on the total error. I just reran and it varied again but settled on 22.664455 after a little and stuck there and the only real difference is that the bottom cuts are off to the left rather than off to the right or vice versus (notice the sign of the errors changed)
To compare with run from a minute ago in parenthesis:
- Motor Y Offset: 472.290 (472.291)
- Rotation Disk Radius: 139.552 (139.554)
- Chain Sag Correction: 22.664455 (42.069)
- MotorX: 1803.3 (1803.3)
- Left Chain Compensation: 0.572% (0.572%)
- Right Chain Compensation: 0.584% (0.584%)
Calibration settled on the following error values:
- Error Magnitude (RMS): 0.765 (0.765)
- Left Chain Error Cut 1: -0.6195 (-0.6198)
- Left Chain Error Cut 2: 0.8018 (0.8017)
- Left Chain Error Cut 3: 0.7145 (-0.7146)
- Left Chain Error Cut 4: -0.8969 (0.8967)
- Right Chain Error Cut 1: -0.6191 (-0.6194)
- Right Chain Error Cut 2: 0.817 (0.8017)
- Right Chain Error Cut 3: 0.7148 (-0.7149)
- Right Chain Error Cut 4: -0.873 (0.8970)
I put my chain sag correction up to 4500 just messing around and it only seems to make about 5mm difference per 1000 in real world testing.
Yeah, the effect seems negligible… interesting.
sorry for throwing this in, but in a condition that i need to have it here because i bookmarked this post.
i have been looking into isolating the calibration procedures to a simple code writing the findings to a text file. No fun for now, nothing but a dream. With a widened motor distance there are at least 3 estimated numbers put into a calculation of more numbers for calibration. What i would need to reclaim my status as a beta-tester is the chance to override any number before the final calculation.
2 Likes
Same results as before. 1/8 too high in top left corner. I recut the triangular test pattern using those settings and results got worse. I suspect my chains more and more. Taking a break (storming here)
1 Like
I think I might be there!! Within 1mm Y and 1.5mm X 
I reset everything, loaded GC and Arduino 1.20, changed to top feed, entered all measurements manually and didnt run calibration. I was about 6mm off in X but I changed "rotation radius for triangular to 144 and alls well now from what I measure. Did NOT run! triangular calibration
Unfortunatly I’m back to work tomorrow so no time to do actual cuts but im excited with the results.
What Im not sure of is the diffence between “rotation radius for triangular… (default 100)” and “vertical distance sled mounts to cutter (default 139)” arent these the same thing?
1 Like
I reset everything, loaded GC and Arduino 1.20, changed to top feed, entered all measurements manually and didnt run calibration. I was about 6mm off in X but I changed "rotation radius for triangular to 144 and alls well now from what I measure. Did NOT run! triangular calibration
Unfortunatly I’m back to work tomorrow so no time to do actual cuts but im excited with the results.
It’s fairly easy to tweak things until you get the right shape in the center,
the test is to see if you still get the right shape at the corners, and
top/bottom center.
What Im not sure of is the diffence between “rotation radius for triangular… (default 100)” and “vertical distance sled mounts to cutter (default 139)” arent these the same thing?
very different, rotation radius is the distance from the chain to the bit
(triangular only)
.
vertical distance sled mounts to center is the length of the vertical part of a
T where the bottom is the bit and the top corners are the fixed mounts for
non-triangular kinematics
As a hail mary since nothing so far has worked well, I’ve changed the firmware to reduce Chain1Straight and Chain2Straight calculation by the chain stretch tolerance and leave the distPerRot uncompensated as 63.5 mm (or whatever chainPitch*numberOfTeeth is set to). So a Chain1Straight length of 1000 mm would end up being 996.5331 mm when using a 0.3479 chain tolerance factor. Still assumes a linear chain wear… but if there somehow ends up to be a means to quantify a non-linear chain wear, this is where the compensation would need to be made, not in the distPerRot.
I think this will at least eliminate some possible issues elsewhere (setting sprockets to 12 o’clock, etc.) and who knows, maybe it will help with calibration… though I don’t know why… its worth taking shot because I think its a simpler way of dealing with chain tolerance.
I’ll try to try it out tonight.
2 Likes
Just watching your tremendous efforts to solve this situation another thought occurs to me that I don’t think that I’ve seen discussed.
From what I gather the forces on the chain, which I think are used to calculate chain stretch and catenary effects of the chain, are calculated based on loads generated by the weight of the sled assembly, and weight of the chain itself.
As we all have pushed a router around for years, the force necessary to “push the router into the cut” does not appear to be discussed. This could be a significant force based on type of wood, cut velocity, bit size, depth of cut, and so on. This force could be significantly changing the catenary calculation at a minimum.
So my question is to ask if anywhere in the code is this taken into consideration.
Thank you
Ed
2 Likes
No, it hasn’t and it’s a good point, but I really don’t know how we could ever hope to do it. When we do our test cuts, we do it fairly slowly and to a shallow depth so this should minimize the impact. If we had a solution for it, I don’t know if how much would it actually impact the calculations.
It would seem to me that the ‘router through material’ force would act on the chain sag value (by effectively increasing the weight of the sled). ie: not a terribly large degree, but some measurable amount…
I still believe that the calibration should be done with a finer point than a 1/4" bit, a pen would be ideal, and eliminate the discussion of ‘router through material’, until it’s measurable, at a point when its added back into the equation, after the machine is calibrated, by then cutting material.
1 Like
Thank you for the quick response. Have you tried putting a sharpie (somewhere I saw someone was putting one into replace the router to make drawings) into the bit position, adding proper amounts of weight to equal the router, and running a test series of cuts with that sharpie marking onto the cut piece. Then put the router in place and run the same program, and see how the two differ? This could potentially show the difference the effect could make for different types of cuts and speeds.
I haven’t built mine yet or I would try it.
Thanks
Ed
Thinking about that, using slow speeds and minimum depths for test cuts, does not represent what users are doing with their projects?? If they chuck up a 1/4" bit and run it ad a good speed, I would think it would produce pretty different results, especially in the lower corner areas.
No I haven’t. Would probably make my life easier (could tape some sheets of paper over the area to be marked). I have a turned wood block from @marm but need to sand it down some to fit into the router… it’s just a tad too tight.
Very possibly, but if I can’t get it accurate at slow speeds/low depth, I have little hope of getting it accurate at high speed/high depth.
What I’ve been working to accomplish is to update the calibration model to deal with chain stretch. It’s “accounted for” in the model, but doesn’t work. So I’m trying to figure out why the model and calibration routine aren’t producing better results. My current theory is:
- Chain stretch isn’t uniform
and/or
- The routine of measuring distance between motors using the chain has an error.
and/or
- The cuts we make to optimize the machine are not optimal (i.e., different cuts would be better)
and/or
- The assumptions we make about the cuts (e.g., they are perfectly centered left to right) is wrong…
Also, I have absolutely no idea how the formula for chain sag was arrived at, so there’s little hope I’ll be able to make any meaningful progress there. This is what’s used:
ChainStraightCut1Est * (1 + ((chainSagCorrectionEst / 1000000000000) * math.pow(math.cos(ChainAngleCut1Est),2) * math.pow(ChainStraightCut1Est,2) * math.pow((math.tan(ChainAngleCut2Est) * math.cos(ChainAngleCut1Est)) + math.sin(ChainAngleCut1Est),2)))
My head hurts just looking at it.
1 Like
Do we know who wrote the original code?
What i did was drill a hole in my sled that a pen fits in tightly. Turn Z axis off so the sled would stop at each point and ask for bit adjustment. When it stopped mark a point and move to next point and mark. This way the weigh… Remains the same.
1 Like
@rjon17469 I believe, but haven’t seen him on the forum since April. I don’t know that there is a problem with the formula… I just don’t understand how it was arrived at… this is the only thing I’ve yet to figure out is all.
How did you account for the rotation of the sled? It’ll spin around the axis of the router bit depending upon where it is. Did you turn it by hand each time to make sure it was vertical?