We need your help to bring the firmware one step closer to higher accuracy and uniform vertical scale accross the workspace. To do so a proposed test firmware is ready for a pull request:
It implements chain tension and stretch calculations to improve chain length calculation.
It uses a default sled weight of 25 lbs (11.6 kilo) that you can set with macro $46=value where value =kilo * 9.8 or lbs * 2.2*9.8. That settings would be eventually added to GroundControl.
If enough volunteers report everything is fine, then a pull request will be performed and the community will also enjoy improved standard Maslow Calibration results because:
the chain stretch compensation reduces the motor distance estimation error
the sag correction factor is well adjusted with that calibration.
Rotation radius looks good too.
Although the Standard calibration will be improved, you might want to keep your known values if you trust them to be better.
Why that step?
What are the benefits of making this firmware improvement in such a step?
More constant vertical scale accross the workspace.
Users of the triangular link should get better results out of the current GroundControl Calibration scheme.
When Ground Control will be improved with sled weight setting parameter, it will be easy to set it specifically for their sled.
With that update, one can also start experimenting with chain tolerance optimisation using the Holey triangular Calibration (instructions here). That without installing another firmware: Just download in a separate folder the HoleyCalibration GroundControl, then youâll find there the gcode and python scripts.
(EDIT) It gets users ready for getting a better GroundControl with sled weight setting and the later coming Holey Triangular Calibration.
So I invite you to test that firmware. I did test it and it worked well for me. But we need more feedback to make sure this is ready for a release to be shared with the whole community.
How to test the Firmware beta version
Note 1: If you are a new user, or if you are not familiar with the handlings listed hereafter, then beta testing is not recommended for you. (We would rather avoid supporting users that get in troubles and spend that time fixing / preparing next improvements )
Note 2: This Firmware works with the current Ground Control release.
Make sure you have a copy of your current firmware and GroundControl if you whish to revert after test.
Take screen captures of all GroundControlâs Maslow and advanced settings stored in your arduino.
Stop GroundControl
In a separate folder, get the current GroundControl, then the Beta Test Firmware git repository from here
Use the Arduino IDE to download beta test firmware to your controller.
Quit the IDE
Restart GroundControl and review settings panels and adjust as necessary to restore the same values as you noted with screen captures. Note: this firmware implements a new EEPROM version table so you may have to re-enter some of your captured maslow settings, but it should not lose the chains length measurements. If it does then youâll have to reset chains 12 OClock step then extend them again.
Now enter the real motor distance value. No need to cheat anymore to avoid the top middle vertical squash. At least youâll need to check if there still is some squash (see below)
Quit ground control and restart it to reconnect to the arduino controller and refresh settings and X,Y position identification.
And that is it.
From here you can try and report:
Did you have to recalibrate chain 12OClock and extend chains?
Does Ground Control calibration propose values that are close to you current settings?
Do you get a flat top sled displacement? If not:
Misadjusted chain tolerances are likely a cause for this,
That is unless your rotation radius value is wrong (typical tradeoff of the existing calibration). Use the triangulation kit official value
you may also want to enter a specific sled weight using a macro â$46=valueâ where value =kilo9.8 or lbs2.2*9.8.
On one hand you could cheat motor distance a little butâŚ
You can finally try out chain tolerances optimisation without installing another firmware. Especially if starting from 0 tolerance, this will likely improve you workspace edges location match and remaining top vertical squash issue if any.
Chain tolerance optimisation (advanced users)
I tried that as well. Again, it worked for me and a few others. So read the Holey triangular Calibration calibration instructions. Just download in a separate folder the HoleyCalibration GroundControl, then youâll find there the gcode and python scripts.
So if you are comfortable with those handlings, please try and report under this topic to support the firmware improvement
In order for the general community to spend time to absorb these changes, several things need to happen.
There needs to be a general consensus that there is a deficiency in the current Firmware/GC implementation that needs to be addressed. To me, this is the presence of a ~4 mm vertical offset on parts of the machine surface that is not captured in the kinematics calculations. This (Holey Triangular Calibration) plots this vertical offset. This (List of sources of error) is an analysis which attempts quantify many sources of error.
There needs to be a general agreement that the Standard Triangular Calibration is substantially limiting the accuracy of the machine, which limits applications to those which do not require accuracy. I tried the Standard Triangular Calibration, and I ended up with benchmark errors up to 6 mm. The Standard Triangular Calibration produces machine parameters which are not consistent, or aligned with physical measurements, e.g. Rotational Radius varies between 120 and 145 mm. There are several threads which are a result of people having issues with the calibration (What must be adjusted to correct out of round circles, Fully Calibrated but Oblong Circles, Oval Shaped circles Please help, Cut Sinking in the Middle). I have looked at the Standard Triangular Calibration code, and I believe it is the source of many of these problems.
These are problems that need to be addressed. This is one step in the direction of solving them.
Starting with GC/FW 0.67 in April 2017 and times with 10 or more calibrations and testing per weekly release, my personal best result was quadrilateral with the brackets and max error of ~3,8mm of the whole sheet. Since my late start with triangular due to remote location, and going from 10ft to 11.5ft, itâs gone only down for me. However this was with a 15kg sled tested at different frame angles.
The times have changed from having the first batch out to âcalled Beta Testersâ with a large amount of testing and feedback, to releases that where merged with 2 or less testers.
Itâs not a critic in any way, just a feeling that i share, that there are bugs we have dragged for more than 1 release jump. Changing the feedrate in GC settings and ending with an arduino in a state that does not allow any prediction what is going to happen next, or simply doing nothing any more until physically unplugged from the USB port to get it back to life, is such an example.
The speed and dynamic of the development was just to tempting to âimproveâ before testing every new release as a âfake new userâ ,preferably on 3 OS, with a deleted GC.ini and wiped eeprom. (2nd bug, i had 1 case where the built in wipe did not work and one from the arduino forum did).
On a 10tf beam the motor distance measure with pulling a chain was ~5mm of from what i can measure by hand to 0.5 mm by trained eye excluding parallax errors. With the 11.5 ft the chain measure GC is off by 12mm. Letâs not talk about the calculated rotation-radius.
Does it need to be addressed that the 30kg pull for 3 seconds can not give the results expected and might be harmful to the original motor-shield, or is it enough to present an alternative with hope to kick this well meant but failed dinosaur out?
The 3 thumbs up method on git to automaticity merge has the weakness that someone that has not tested can give a thumbs up just because he likes the idea.
I have no idea why iâve written this, guess it had to come out somewhere, so you are the random victims Just forgive me and pretend it never happened.
Actually i just came on this thread to ask @c0depr1sm about the preparation to try this out for someone with a brand new sled that has never been run. Would like to start clean with the measurements i know, or do the manual calibration first?
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.
Hi everyone,
It is great to see beta testers looking for oppoprtunities to contribute :-
There are actually two (2) opportunities!
1
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.
2
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!!!
Who disagrees with these two items? There may be disagreement in how to solve
them, but I donât think there are many people who disagree that there are
problems as things sit now.
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.
Hi @dlang
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.
There a several pulls in the to do list to implement stepwisein the official MalsowCNC repository all those features that will be used for the Holley Triangular calibrationâŚ
@c0depr1sm, i still plan on testing your firmware. But, I think I am working backward. I loaded .with Holey Calibration first and ran a test cut with improved dimensions.
I have your firmware loaded now and see how far I can get tonight and tomorrow. with a sacrificial sheet of OSB on deck and will report back.
@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
and
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.
At least youâll need to check if there still is some squash (see below)
Just forgive me and pretend it never happened.
I loaded .with Holey Calibration first and ran a test cut with improved dimensions.