I am confident that all of the maslow ones are the same. Although we may want to look at the zAxis motor, but this level of precision there wouldn’t cause much effect.
But, I think this demonstrates that the gearbox ratio reported may be the result of some rounding or weak math that only really matters when you are talking about the precision we are talking about.
When buying motors from alibaba, I would certainly take the gearbox apart and do the math myself to be sure the reported values are correct.
Fantastic sleuthing everyone! I feel like in the last few weeks we’ve crossed a threshold where my job has switched from leading the charge to doing what I can to help the people who are leading the charge. It’s so cool to wake up every morning and be impressed with all of the progress that was made during the night.
I’ve contacted Etonm and let them know about the slight discrepancy with the data sheet. I’m confident that all the motors are the same so far, but now they know to let us know if anything at all changes.
I think this quote deserves a second pass:
It IS pretty darn cool to hit the encoder steps dead on like that, and it only happens thanks to the work you’ve been putting into the feedback control system. That unexpected verification that your new feedback system is working so well is amazing! Great work.
Does someone want to make a PR and take credit for this fantastic effort or should I just make the change?
I should have said encoder steps not gear ratio there. We need to agree on whether it should be a fraction or not. It sounds like it should be. However, someone should figure out how we “push” this on users. I think this value is written into the ini file, so changing the default setting in GC won’t do anything.
I likely caused the fraction issue in the firmware, so I will track that side down.
Well, that’s good news. I seem to recall someone mentioning one motor was “off” and the other wasn’t.
I suppose that it really isn’t that hard to check. Looks like it just took a couple lines of GCode, then note the position of the sprocket before and after the half-hour of watching the motor spin.
It could still happen, but the error we found here is mechanical. In order for it to be different a different gear would have to be used and that would almost certainly cause a larger larger error.
If one motor is moving slightly more/less than the other. It is likely an electronics/software issue.
Was just concerned that there might have been a 1-tooth change in one of the internal gears during production, resulting in a 279.3:1 ratio in some of the gear boxes, which would necessitate knowing which gearbox(es) are on a particular machine when it’s time to calibrate it.
If it’s a fraction that’s stored, you would do it with two new variables, correct? Therefore, the .ini file with the old variable name wouldn’t matter. Only people doing custom stuff would ever change the default values anyway, so basically just including a warning in the firmware release notes that say they need to recalibrate after update for improved accuracy should be good enough. Include it in the newsletter as well.
Great work with that test @krkeegan…
I hadn’t checked the forum in a while, but to answer your question, an alternative control strategy would have been when the velocity gets too low, hold it constant and let the control loop aim for position… If using encoder step timing works too, then I’d leave well enough alone.
Thanks!
I have created a pull request in #496 which I hope applies these changes in a responsible way.
The way it works is that when Ground Control launches it will detect if someone has the old value stored in their settings file, and if they do it will update the value to the new value, then display a pop-up to let the user know that their settings have been changed.
I think this is an important change so I wanted to make sure it got into the code. Does everyone feel good about the implementation?
Yes, this is needed (although as noted, we should track down why 8113.7 doesn’t
work and use that when we can)
One thing I would suggest is that there be some way for someone to say “I really
mean 8148” in the config file, so that if someone actually has a gearbox of that
ratio, they can use it.
Well, all I did was to try to figure out why my two measurements were off… with lots of prodding by @blurfl. I just figured out a way to illustrate the problem. You’re the one that figure out what caused it…
… I was fixated on rounding issues. Cheers to everyone!
given the number of stages in this gearbox, a 1 tooth change in any of them would make a FAR bigger change in the ratio.
somebody was just sloppy in their calculations (something like calculating each stage to 1 decimal point and rounding at each stage, then combining the per-stage numbers)
@madgrizzle
by the way, we just found that the sprocket radius is hard-coded to an incorrect value in the kinematics code, look for 10.2 and change it to 10.1 and see if that accounts for the last of your error.
R (sprocket radius) shouldn’t be a factor in measuring the distance between motors, correct? The chains should come off the sprocket tangentially so there’s no wrapping to take into account.
Probably true, I never actually ran the numbers. I’ve just seen things go sideways in the past as a result of a manufacturer making a small change that was seen as insignificant.
All the more reason to measure what we have, then work with what we’ve measured.