Ahh @JDogHerman is the man, here are some photos
@JDogHerman , was that a standard Maslow motor that you took apart? We’re wondering about the gear ratio and your tear down pictures are of interest.
@blurfl yes it was a standard Maslow motor.
1 Like
Thanks to @dlang and @JDogHerman who both took apart their motors (three times for David) so we could count the gear ratio and @blurfl for his expert assistance it looks like the gear ratio is actually 289.776234568:1 resulting in 8113.7345679 steps/revolution. (i was close empirically with 8114).
Changing the gear ratio in GC should to this value should solve the issue.
You can find the discussion and photos to perform you own teeth counting here:
2 Likes
and we found this tuesday night. Is tomorrow a release day or is it next week?
between this, the cleanup/refactoring and the fix to the triangular kinematics to account for chain around the sprockets, we have more than enough to justify a release
now if we could just get the one-pass triangular calibration in, that would cap things of to really justify a 1.00 release. 
2 Likes
oh yeah, chain sag. but we have a forumula to calculate the tension, so we should be able to ballpark this as well
Obviously having measurements dead-on is always best, but what accuracy in “distance between motors” is good enough? If I scale Maslow’s measurement of 2888.6 by 8148/8113.7345679 I get 2900.8 mm. I measured it as 2905 mm. Assuming the actual measurement really is 2905 mm, is being 5 mm off going to result in any significant accuracy issues? i.e., is it good enough for how Maslow works?
And kudos on the hard work to figure out the gear ratio!
1 Like
@dlang thinks that 8114 is close enough. At 3000mm translates into an error of 0.098mm. I am inclined to agree with him.
Understood, but my question is even after this change, when Maslow measures the chain length and it’s 5 mm off (for reasons other than _encoderSteps), is this going to cause meaningful accuracy issues. I made some pretty nice things with already with it out of whack, just wondering if I should stop worrying about it.
The motors are about 3000mm apart, roughly 50 rotations of the sprocket. Using 8148 for the encoder steps would cause the measurement of the motor distance to be off by 13.3mm.
You can play with this number in the simulation in GC, but yes this will cause some distortion. Not likely noticable to the eye, but parts may not fit together correctly. That said some of this error was compensated for by the test cuts.
3 Likes
That said some of this error was compensated for by the test cuts.
That’s what I was thinking… I’ll find out this weekend how well it works… I’ve been suckered into making something for somebody.
please test the automatic measurement and see what your result is with the new
number (I would do 8113.7, but 8114 is probably close enough)
I don’t remember the details of your measurement, but if we are still off by
5mm, that is nearly one full link, so counting links should tell us if we are
still off in how much chain we are feeding out, or if it’s another problem (too
much slop in the chain for example)
If it’s not too cold out in the shed tonight, I’ll give it a go. Us Florida boys have problems when temps drop in the low 50s. 
Good news/Not Great news
Good News
I ran two tests this morning. I ran the motor for 500 revolutions (it takes 30 minutes at full speed btw).
The results for 8114 steps:
Before:
After:
Step Count:
Again, it hit the step count dead on. It is hard to see but it is just slightly out of vertical in the clockwise direction. I estimated .7mm of error. Which matches close to the 1.0387 mm of expected error. My estimate could easily be off by .3mm.
This is pretty damn good. This is 10x more distance than would ever be used by our design. Which means about .1mm of error in measuring the motor distance which I think is very near the longest distance we ever use on the machine.
The not great news
I then tested 8113.7, I will save you the photos and just tell you that it was short of the total desired rotations. The total step count was 4,056,499 or 8,112.998 steps per rotation (1 step short of 8113).
So while the encodersteps are stored as a float in the firmware, there is probably some place where we converted it to an int causing it to round down. I think I still have all the rounding and 2*/ arithmetic removed from my code, but I can double check that tonight.
Next Steps
The question now is, do we care to fix this or are we happy with 8114? The implementation to fix it likely isn’t hard. My concern is do we want to go down the road of allowing a float? It seems to me in the long term, we would rather have all of these things be integers as they are faster to compute and don’t have the same obscure inaccuracies that accompany a float.
2 Likes
I’d agree that using integers is the best approach. Now is a good time to make the change, as well 
, before we run a bunch of accuracy tests. Is there a way I can help?
Following along with a lot of interest here.
First - thank you all for the effort.
As I see the results of 500 revolution test, the sprocket is about 1 mm off after asking the motor to move the equivalent of 31,750 mm of chain (that’s almost 32 meters). That’s not too shabby. We’re talking a whole lot of zeros before the first significant digit. Back of the envelope math suggests that we’re now under 0.1 mm (0.004") of positioning error across a 4X8 workpiece. This is no longer a weak link IMO.
Pity that the more accurate value doesn’t work. If 8114 works, I’d suggest we go with it for now. Shouldn’t be that difficult to change in the code though. My 3D Printers and CNCs all are happy with decimal steps per mm values, and I am able to hold the motion stages to 0.1 mm across the work surface after a detailed calibration.
So, I guess the icky question I have is: Are all the motors identical?
Wouldn’t be the first time a minor mid-production change in a part manufactured overseas resulted in a major headache.
Has anyone ever measured this before, or was all the code based on the specs of the motor?
1 Like
We aren’t making turbines here…
Thinking about other gearboxes that may be in use (lower gear ratios with more
powerful motors for example), I can easily see the fractional part of the ratio
being a problem.
yes 8113.7 slightly undershoots instead of slighty overshoots, but one step
short should not be a problem. one encoder step is ~0.008mm, the difference
between the real value and 8113.7 @500 revolutions should somewhere around
0.13mm IIRC 8113.74 would be closer and slightly overshoot if you care.
now, it’s possible that being off by one step will create cumulative errors, but
I don’t think so, as long as it knows where it is, the move to the next location
is going to be moving to a specific set of chain lengths.
should it be entered as a ratio (X/Y) instead of a float? that would let
everything stay as int until the very end if we wanted.
Oops, sorry my wall of words got misinterpreted there. When I changed the value to 8113.7, it actually moved 8113 steps per revolution. It dropped the decimal entirely. So the error was much larger than when using 8114.
The 1 step off comment was just that it was 1 step out of 4 million off from hitting 8113 per revolution exactly, this will happen and isn’t an issue at all. Sorry for the confusion.
You may be right. I suppose if we really get that good at optimizing things we could do any number of tricks, the ratio as you propose, or multiplying by 10 or 100.