Thanks! We’re not ready yet. We’ll let you know.
1 Like
The short answer is yes; however, it is dependent on the level of precision which necessitates a recalibration. The biggest change in the kinematics calculations are: the chain-sag calculation now uses the catenary equations; and the inclusion of chain-stretch compensation. They both affect the positioning by <=6 mm.
Having said that, I have spent some time with the Triangular Calibration, and I am pretty sure it was like a random number generator. It may make the calibration better. It may make it worse. I am pretty sure the inaccuracy was greater than 6 mm.
So, the differences from the new kinematics equations is likely less than the errors on the existing machines. The only machines which are accurate enough for these changes to be meaningful are the machines owned by the people who are active on this thread. I think it is OK.
Don’t take these points/questions the wrong way…
IIRC, when chain wrap around sprocket and chain sag was incorporated, we notified people that a recalibration would be needed (really no way around it since it changed the formulas). When we introduced chain tolerance, it was made such that default (zero) values resulted in no change to the kinematics so calibration wasn’t required. I’m not personally against the concept of forced recalibration, but it’s always nice to avoid it unless it was absolutely necessary.
I’m working on restoring my machine (will take time) so I haven’y tried it out. How many people have made the switch?
1 Like
I agree. Unfortunately, that isn’t the case here.
I am not sure. That is my biggest hesitation. I get the feeling like people only communicate problems, not successes. Nonetheless, I would like to see people, who are technically capable that issues outside of Holey Calibration aren’t confused with the calibration its self. That is not to understate the need for an intuitive, simple, robust installation and calibration process.
couldn’t you just set the new parameters to 0 and have it produce the same
results as the prior calculations?
1 Like
That is a possibility, for chain-stretch, but it implies the default chain-stretch factor is zero.
In order to benefit from the improved calculation, the value needs to be changed by every user forevermore.
For chain-sag, it might be possible to create a translation between the old chain-sag correction value and a “sled weight” value.
One option is to make it a setting to use new calculations.
1 Like
Do we really want to do that? That would imply we need both calculations in both GC, and the Firmware, forevermore. Also, we would need to implement an option to select which one. This would be an option that all users would have to select. As time moves forward, the difference between the two will become less and less clear. We’ll have to maintain an explanation of what each is, and what should be selected.
I agree that to take advantage of the new calibration, they need to get the
right value, but if they are happy with how their machine is working now, it
should be possible to effectively ignore the new values (or translate old value
to new value if old exists and new doesn’t) so that the results remain
identical.
David Lang
It’s not that hard to implement the selection. You just need to add an option to the settings (like z-axis enabled) and assign a firmware key and you’ve done what you need in GC. Add it to the setting structure in firmware and then test for it in the kinematics and you’re done there.
Does your fork remove the existing calibration process? I thought I saw an option to pick which one to use as I was reviewing the kivy file. BTW, we have quadrilateral still in GC/FW and I think only one or two people in the world use it 
if we have to (i.e. we can’t just leave parameters at 0 to get the old results)
We need to get holey triangulation out there for people to be able to try, but I
don’t think we are ready to eliminate the existing calibration and say that
holey is better in all conditions. So we don’t want to force people to switch,
especially if their machine is accurate enough for them now.
David Lang
One option is to default sled weight to a -1. If its negative, then the FW assumes no holey calibration and uses old style kinematics.
1 Like
My opinion is; if someone has a functioning machine and they are happy with it, they shouldn’t update. If they accept this update, they may re-calibrate if they choose. I just don’t like the idea of having to maintain the all the legacy in the current version. I feel like we could spend our time on better things.
if they don’t upgrade, they can’t get any benefit of any other fixes, or even of
improvements to Ground Control.
telling people to not upgrade is a bad idea IMHO
2 Likes
If we can come with a testing methodology for the difference in error and acceptance criteria. I can use my machine to test this weekend. @Joshua and @dlang are both right. Having to tear down and recalibrate a working machine is a pain that should be avoided, but at the same time advising users to stop updating once the machine works is not only bad practice but borders on an admission of flaws in the development process. Just my two cents.
I looked at the code and much of it I don’t follow (not because it’s done wrong, just I don’t know enough about python/kivy programming to follow it all) but does this statement modify the values used in the optimization:
cal.__dict__[shcnm]=v
So much I don’t know about python apparently…
1 Like
That is the initialization. It pulls the values from kivy, and populates the properties of the cal class (the properties are the initial conditions of the optimization).
_dict_ is a dictionary in python that points to the properties of the class. It is not a kivy thing.
The comment on line 163 describes the columns in KeyMap, which is where shcnm comes from. schnm is “Start Holey Cal Name”, which is the initial condition for the optimization.
So it overrides the initial values that are hard coded into HoleyCalibration class… That’s what I was trying to figure out since I didn’t see anywhere in the HoleyCalibration class where values other than defaults are used. I didn’t know about the dictionary thing until now… handy.
1 Like
It is work to maintain this legacy content, and that work is not just a one-time effort. This is a burden that we will have to carry, for as long as we intend to support the legacy kinematics translation. Even Google stops supporting software after 3 years, and we shouldn’t be expected to have anywhere near that level of customer support. Part of a good software maintenance strategy is a sun-setting approach. The sun-setting approach defines the decision process for when we sunset legacy content.
Whatever we decide, I will do my best to help, but my vote is to let it go. Owning a CNC is not zero work, and I think owners of the Maslow are well aware of that. Having to recalibrate when updating software is work that I think most Maslow owners are very familiar with.
Also, there are alternatives to just adding switches in code. For example, we could have a code branch in the repository which maintains the legacy kinematics. We could merge certain updates into that branch, as long as we wish to support it.
@Joshua I totally get where you are coming from. Would it be advantageous to provide a simplified configuration option that would automatically skip the steps that are accomplished by the prior version? To get from classic math to Holey math (from the end user’s perspective) we:
- Drop the recording of the sled balance angle.
- Record the weight of the sled.
- Cut and measure the 6 hole pattern.
As everything else stays(looks) the same, would it be worth while to detect that the machine has been configured and only prompt for the missing pieces? Then going forward there would be framework to do the same with each release. If moving from 1.25 to 1.28 ask for sled weight and run the 6 hole, 1.28 to 1.29 no cal needed, 1.28 to 1.31 record elevation above sea level, etc.
Streamlining the process would increase adoption of new versions and therefor reduce the need to maintain legacy compatibility.
1 Like