What is correct chain pitch?

not that I can see, that would be a ratio of 289.7857:1 with 7 PPR (28 encoder
steps/rev)

has anyone taken a gearbox apart to count the teeth?

doing the test all in one direction would eliminate backlash after the it starts
moving.

The fact that he’s taken it to 50 revolutions indicates that it’s not backlashy

There is, but not enough to cause this much movement and that doesn’t explain why the error compounds the higher the number of revolutions. If I run it for 36 loops the error is 1.5 teeth.

First this is already a solved problem, counting the time between encoder steps works very well and has a nice smooth transition from counting steps to counting time. But for academic purposes, how would this work? What would determine the voltage necessary to achieve the desired velocity?

1 Like

no, we want to track the very slow rotation, otherwise we end up with the
machine doing steps instead of very gradual rotation

Yeah, I was stuck at the same point. What about 8113? That is 289.75:1. I could be just looking for reinforcement, but that seems like a decent coincidence. Someone around here had some pictures of the gearbox.

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. :smile:

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. :snowman:

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 :wink:, before we run a bunch of accuracy tests. Is there a way I can help?