I’m looking forward to testing this over the weekend. But, I’m a little confused on the firmware forks, It appears that the two of you (@c0depr1sm, @Joshua) are aligned on improvements to firmware and GC which I applaud. But, I noticed that both of you have firmware in git.
So just for clarity, is the current path to Beta test using @c0depr1sm firmware with chain stretch comp in conjunction with @Joshua’s GC with Holey Calibration?
The only reason I ask is because the Holey Calibration instructions point to a different firmware.
If you test Holey Calibration, I recommend going with the Holey Calibration fork of both the Firmware, and Ground Control.
Besides the Holey Calibration process, the other difference is how chain-sag (not chain-stretch) compensation is calculated. @c0depr1sm’s fork utilizes a simplified quadratic form for chain-sag. The Holey Calibration fork uses the full catenary equation.
For Holey Calibration, because there are differences in chain-sag compensation, I recommend using the Holey Calibration fork of both firmware and Ground Control. Otherwise there is the potential that these differences mean the machine (Firmware) does something different than GC calibrates to.
It is great to see beta testers looking for oppoprtunities to contribute :-
There are actually two (2) opportunities!
This Topic is for a careful incremental improvement to the Official MaslowCNC Firmware.
It is important because each change has to be small and robust in order to protect the community against deceiving bugs and regressions. After all, we want everyone to enjoy a bettter masowCNC experience.
Above, I gave **instructions to try it out and I refer to use the standard GC for the basic test, then I propose an extended check by using the GC prepared for HoleyCalibration just to run an optimiser part of it and let people foresee the chain tolerance optimisation, which gave good result for me in that sequence.
And as @Joshua pointed out, there also is another topic for beta test of the advanced Holey Calibration prototype currently in test as well. This is the compass direction for more improvements. But it contains many changes and is more risky to have regressions just because it is more complex. That said, some people reported about it and it works! But we must not bring this straight to the official release: we have to protect the Maslownian community where users of a wide range of experience level are present.
Now you can help both. But please be careful to report the proper results to the proper Forum Topic!!!
Is it possible to make the firmware modifications be identical (or to make the
modifications for chain stretch compensation to be a strict subset of the
changes that include holey calibration?)
it doesn’t make sense to do minor changes that will have to be undone to get the
long-term fix in.
How much does chain stretch compensation fix things without also fixing the
calibration routine? We’ve changed calibration before when we found that it
wasn’t doing the job, we don’t need to keep backwards compatibility with a
broken calibration routine.
I don’t like that the holey calibration routine requires you to enter the weight
of the sled rather than figuring it out from the tests, but I haven’t had a
chance to check to see how well it handles extra heavy or extra light sleds, or
how sensitive it is to errors in the sled weight.
If this is a good subset of the changes in the holey calibration fork, then
merging these to narrow the difference to be just the calibration makes it
easier to test the calibration differences, but if this is so different that it
can’t work (or be made to work) with the other changes, then we are probably
better off testing the full set of changes and moving directly to them, rather
than sitting for months with known-broken stuff in our official codebase while
we ‘gradually’ fix it.
Hi @Gero ,
To answer you last question: I would use the values I know.
But I tested some bare setup: default 0 chain tolerance adjustment because that is the situation for new users.
New users would need the actual GC calibration to help them figure out some values like the sag correction factor. Then we would recommend use of the known rotation radius and only cheat (a little) the motor (sprocket centers) distance due to missing chain tolerance corrections. That is one reason why we’ll need the Holey Triangular calibration soon.
Overall we aim to check that this improvement (chain tension calculation and stretch compensation) works well, really helps, does not break when used with the current GC.
Thanks for pointing this out
I design the firmware improvement step exactly as a subset of the holey triangular calibration improvements. It is intended to be kept and built upon. And I can say it improves the results for me (and for others?). Not perfect yet, but better.
I would like to say that I do work it out with @Joshua to not take months to make it happen. And all contributors are welcome to make it better faster
The complete GC with easy holey triangular calibtation is not yet ready.
Actually @Joshuacalls for contribution to improve GC for an easy Holey Triangular calibration.
This could be included in Holey Calibration. However, I found that a mis-measurement of 0.5 mm can result in a sled-weight that is way off from what a scale can measure. I concluded it was best to just leave the scale-measured weight as-is. The difficult part is: chain-sag has a small effect. If the model is 5% off, it is not too bad, because it is 5% off on a phenomenon that has an absolute magnitude of 5 mm of displacement. It is is very small, 0.05*5=.25 mm. We can calibrate it; however, I think we’re going to get better results if we don’t.
Yeah. My development pace may be the bottleneck here. Don’t hold your breath.
I would like to point out the required accuracy for each parameter. I listed my findings here as a summary. And I conclude that mainly the chain tolerances are really worth an optimisation.
What is also pretty interesting in the optimisaton tool is when the optimisation result presents some sanity check by confirming some known values. Let’s say: motor (sprocket) distances or the motor (sprocket) height above the workspace.
@c0depr1sm, I ran into a problem, when trying to set auto chain calibration. both sprokets went out of alignment and when I try to set the 12 O’clock position on my left sprocket, it spins about a 180 degrees when I choose 1 or 5 degrees.
I am also getting the sled is not keeping up with expected position alarm pop up when doing this. Using 1.26 GroundConrol.
Please post the Groundcontrol.ini file.
Did you complete the steps from How to test the Firmware beta version down to And that is it. ?
Then you were at step 2 of From here you can try and report, that is “Does Ground Control calibration propose values that are close to you current settings” Right?
So when you say
when trying to set auto chain calibration, both sprokets went out of alignment
when I try to set the 12 O’clock position on my left sprocket, it spins about a 180 degrees
You said you tried The holey calibration fimware just before right?
Please also execute a macro with command $$ and get a copy of the Groundcontrol output on the console listing all firmware parameters.
I know have your firmware loaded and running stock GC 1.26. This time the sprockets set to 12 o’clock without issue. But when I hit center sled, it rolled out all the left chain and I had to hit stop. I was able to run through the calibration routine and reset the chains and center the sled.