Call for beta testers: Chain stretch compensation improvement

I will join in on this one.
Do i need to beta test 2 forks tomorrow?
Was it pink sunglasses that made me believe there was a pulling on the same rope?


Hi everyone,
It is great to see beta testers looking for oppoprtunities to contribute :-:tada:

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!!!

1 Like

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.

David Lang

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.

David Lang

1 Like

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.

1 Like

Hi @dlang
Thanks for pointing this out :slight_smile:
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.

It follows this post.

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 :slight_smile:
The complete GC with easy holey triangular calibtation is not yet ready.
Actually @Joshua calls 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.

And that is where we are heading :tada:

1 Like

Any feedback?

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…

Should we go forward with a pull request?

@c0depr1sm, i still plan on testing your firmware. But, I think I am working backward. :dizzy_face: 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.

1 Like

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.

On linux $$ sadly only writes to the log.txt. Is that different on Win$?

@c0depr1sm, yes to all your questions. I already wiped the eeprom and reloaded the stock firmware and re-entered all my calibration settings and reset the chains.

So, I don’t have a console dump to show you. However i did have a backup of the groundcontrol.inigroundcontrol.bak2 (1.5 KB)

The Maslow seems back to its original state. I will five it a quick test cut and then re-try with your firmware.

Automatic has never worked for me… Always does what you have reported (Fw 1.25)

@c0depr1sm I ran a test cut with the stock firmware 1.25 with following results.

Circle 18" ht., 17 13/16 width
Square 12 1/16" ht., 11 15/16 width.

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.

I ran the $$ macro and have attached the log output. and my current ini.
log.txt (1.1 MB)groundcontrol.bak3 (1.5 KB)

Can you give it a sanity check, before I try to cut the test file with it?
currently chainsagcorrection = 0 Im guessing I need to enter the value in lbs?

I’m checking it…
But be carefull! In this firmware improvement step, the sag correction IS really the sag correction factor. Don’t enter a sled weight there :slight_smile: Use the same sag correction you used to have.

Just following your progress until I get the chance to test it myself. Not to digress too much from the topic but …

I’ve had issues like this as well and it may be related to the “not keeping up” error. You might want to check all your cables to make sure nothing wiggled loose, maybe even disconnect and reconnect. Check the female ends of the motor cable connections to make sure the pins are making good contact. Also, one of the shield designs out there (don’t remember the name) has a pin on the underside of the board that touches the usb housing when pressed all the way down on the arduino. If yours is like that you might want to put electrical tape on the usb housing.

1 Like

GroundControl.ini looks ok.

So, having the left chain rolling all out, it looks like possibly the chains position was not preserved during the firmware update. In that case the right thing to do was to recalibrate.

Also @WoodCutter4 's point might be something to check, but I did not have that issue, so I don’t know about that.

Recalibration, I can see in log.txt, here is what you did:

line 18076: you finish moving the right sprocket to have 12 OClock fine. (B09 R-0.12)
line 18733: you set these sprocket as 0 chain length.
line 18739: the chain over top is restated to the firmware
line 18753: A message that the firmware cannot figure a valid sled position… we could expect that since nor the left nor the right chain were extended.
line 18755: The position error alarm limit ($42) is set to 2000 mm in the firmware.
line 18810: the chain over top is restated to the firmware
line 18819: A message that the firmware cannot figure a valid sled position… we could expect that since nor the left nor the right chain were extended.
line 18821: the macro $$ is called to print parameter values. Everything seems fine. (sag correction value is 0 but that is not a problem)
line 18870: The position error alarm limit ($42) is set to 2 mm in the firmware (effectively restoring the position error check).
line 19727: command to extend left chain
line 21040: left chain extended to 1648.86mm
line 21288: command to extend right chain
line 22601: right chain extended to 1648.83mm
line 24043: command to move sled to center
line 24277: firmware reports a request to comppute the xy position of the sled from the chains current positions and reports x=0.75, y=0.87
line 24385: $16=1 (Z axis is motorized)
line 24572: $16=1 (Z axis is motorized)
line 24682: $16=1 (Z axis is motorized)
line 25174: some Z moves…
line 26353: a message stating that exiting clibration process early may cause problems
line26477: Ground Control reports reconnecting to firmware
line 26483: firmware reports a request to comppute the xy position of the sled from the chains current positions and reports x=0.73, y=0.79
line 26482 $$ macro followed by parameters lists
repeating a few time $$ then list… then end of file.

Now, You can put the normal chain sag correction for you machine. And give it a go.

1 Like

Test cut with chain stretch comp firmware loaded, was done a little bit left of center and about 22.5 in down from center. I set chainsagcorrection = 25

Circle 18" ht., 17 7/8" width
Square 12 1/32" ht., 11 15/16 width.

@WoodCutter4, my cables are all secure and have strain relieve where needed, but its always good to give it the look over my pcb is the older 2 chip version any does not have the issue shorting out.

Its getting late, going to shut down for the night.