I am not sure how to interpret this. I am just going to type as I think.
The calibration is better than the first one I got with the TriangularCalibration.
Overall, if this accurately represents the quality of the calibration, it might not be all that bad.
All your measurements are short in comparison to “Ideal”
This could be due to the machine’s starting calibration/setup, or it could be due to your measurements.
What concerns me is:
The measurements are short, AND the calibration defined a positive left and right chain tolerance.
I would think the calibration should go the other way. If all the measurements are short, it should define a negative chain tolerance, so that the controller would feed out more chain.
I am having a difficult time with this one. I would like to see if I can reproduce the result. Then I will get back.
The intent is to measure the distances, center-to-center. The most practical way to do this is to measure to the edges of the holes (left-edge to left-edge) or (right-edge to right-edge) or (top to top) or (bottom to bottom)
Hi @Joshua
I was reviewing how I get accurate results and it seems the chain stretch factor is possibly one that could be used to tune up the calibration. My value is 8.1x10E-6 m/m/N. It is the only parameter acting on the top workspace edge dip while changing almost no curve on the bottom edge. It is difficult to estimate and I don’t know how variable it is across various chain supplies.
So I summarized my criticality / measurability analysis and decided to bump a (short) zombie thread just to avoid duplicating that topic or otherwise highjack your topic.
OK. I figured out what is going on. On the calibration/code side, everything worked correctly. I would recommend re-measuring the center-to-center distance between the holes, but other than that, everything is OK.
The chain tolerances are implemented in the kinematics.inverse function. They are implemented such that positive chain tolerance results in a shorter chain. This is a mistake, but it is fully functional and valid. The intent was for a positive chain tolerance to correspond to a stretched chain, however it is the other way around in this implementation.
Moving forward, you’ll just have to be careful. If this is switched in a future version, and you update your software, you’ll have to switch these numbers to negative values. If this happens, I will have to do this, and so will @c0derpr1sm.
To me the chain tolerance is a statement of how much the chain is longuer that expected.
So a positive value tells the firmware how much to shrink it so can be used accurately.
That was my interpretation, too. However, it is the opposite in this implementation. This factor is implemented in the kinetics.inverse function. When the firmware calculates the chain-length, a positive tolerance results in a longer requested chain length. This effectively is equivalent to the chain being shorter than it should be.
So the chain tolerance is a statement of how much longer the chain needs to be to really match the chain link nominal length. So a positive value tells the firmware how much to extend the chain length so the deployed length is accurate.
So, this is consistent with the main GC and Firmware branch. I wonder if this is the reason why they were having a difficult time implementing chain-tolerance measurement/calibration a while back, when they originally recognized chain tolerance as a potential source of error. The value they were measuring was effectively negative what was happening in the software.
Wow… I think that’s a great catch. When I worked on it, I was originally just multiplying the chain tolerance by the chain length and my value for chain tolerance was less than 1 (e.g. 0.998743). The original implementation by @bar used a postive small value (e.g. 0.003346) to increase the circumference of the sprocket using the formula you see in the kinematics (i.e., 1+chain tolerance/100)… applying chain tolerance factor to every calculation. When a PR was eventually made so that it was applied only to the straight chain length, I changed my implementation to use the same formula so people’s existing positive small values wouldn’t have to be changed to match my way of using values less than 1, but as you found, the sign of the chain tolerance should have changed from + to -. I think it should be (1-chainTolerance/100) so that it comes out with a number smaller than 1. Mea culpa.
My understanding is that because the chain is “stretched” you want to “let out” less chain and therefore you need to reduce the straight chain length. I think the virtually larger sprocket diameter does the same thing… reduces the amount of chain that’s feed out.
OUPS! I just realized that my firmware version indeed divides (1+tolerance factor).
Let me apologize and take back this idea of changing the definition.
About chain stretch… I see what you mean.
Now chain manufacturing is not perfectly producing a 6.35mm pitch. That is a manufacturing error expressed by the tolerance parameter.
On the other hand, steel is elastic and stretches under tension. That is a length change depending on chain tension expressed by the chain stretch parameter.
The later is missing in the current MasloCNC firmware.
I did consider this. However, the resulting correction is only a few mm in any direction. This magnitude of correction can be difficult to measure with a tape-measure. I put this into the same category as a chain-sag correction factor. In @madgrizzle’s original Holey Calibration, a chain-sag correction factor was included, that calibrated to a sled-weight that was half of what it should be. I struggled with this for a while, but eventually realized that if one of the ~6 ft measurements was just 1mm shorter, the result would have been very different. The elasticity of a part is a function of material properties and part shape. Since both material and shape are largely equivalent for all chains, I thought elasticity would be pretty consistent for all chains. I thought this was best left out of the optimization.
Both of these phenomenon are in my fork of GC and the firmware. I haven’t reviewed your implementation in detail, though.
Collectively, I think we’ve learned quite a bit this weekend.
I am not sure. Since everything is functional, it is not urgent.
I think we are ready to integrate one more Holey Calibration step improvement into the firmware: the chain tension calculation and chain stretch compensation.
I propopse to do it so that users get immediate vertical scale improvement of their center upper workspace. That would at least improve the standard calibration results.
The proposed implementaiton adds 4 slots into the EEPROM table: sled weight and chain stretch would have default values, plus two reserved slots. Bumping EEPROM table to version 6.
This way, a default value is applied, and macros of the type $4X=YY would allow advanced users to tune manually. Then it would be ready for a later update GC to offer GUI based adjustments.
I prepared a firmware version for review before triggering a pull request. I will test it in the coming days. (Arduino IDE compiles fine)
It is based on the current firmware and integrates these specific items from Joshua’s proposal.
Please review and comment.
OUPS! I just realized that my firmware version indeed divides (1+tolerance factor).