The current motor/encoder test routines runs the motor at full speed for a given period of time, counts the number of encoder steps produced, and if the encoder steps count exceeds that of some value, then its a pass and if not, it’s a fail.
I’m thinking the test can be improved to provide better information. Instead of running the motor at full speed for a second or two, what if we direct the motor to perform a one or more revolutions using singleAxisMove. This would involve the PID controller and therefore, if the encoder was not functioning correctly it would eventually time out and the encoder steps would not equal what would be expected. The user could watch the sprocket (maybe mark a particular tooth) and see if it returns to where it started. If so, then the user can be pretty confident everything is correct. For people that maybe are trying to use non-stock motors/encoder combinations and finding the motor is turning more or less than expected, they could glean some information from it and maybe help them figure out what gear ratio and encoder ppr their motors are using. If it is not doing a full rotation, then their encoderSteps value is too low and if its doing more than a full rotation, their encoderSteps value is too high (correct?)
Question 1: If you are missing encoder steps, am I correct in thinking the sprocket would turn further than a single rotation?
Question 2: Is there a way to determine the PPR of an encoder by looking at it? If you can’t, then I believe the PPR would always be an integer so the user could try different integer values in their encoderSteps calculations to make it work. And if they get really close and it still doesn’t work, then maybe they need to count the teeth on the gears to verify the gear ratio is correct (as we had to do for the stock motors).
We can use 3 AUX pins with photo-interrupter. 1 --> 5V; 2 --> GND; 3–> Signal
Algorithm:
Run motor
If signal UP then Down start counting encoder ticks. (Debounce needed)
If signal UP then Down(made full rotation) --> stop counting encoder ticks.
Print counter.
That way we can get aprox no. ticks for 360 deg.
Eyeballing that made 360 deg is bad. Encoders imperfections come out when extending One side is longer/shorter.
That’s why I had suggested the idea of making multiple revolutions for the test so errors would be more likely to be noticed. Maybe have it so the number of revolutions to perform is sent in the B command and make it configurable in ground control and webcontrol.
I’d rather not include new hardware requirements in this particular test improvement.
you can’t use single axis move until the encoders are working
one thing that would be an improvement
currently the motor/encoder test ‘knows’ what direction the encoders should
count and fails if it moves the other direction, it should detect it and if it’s
the ‘wrong way’ ask the user which direction the motor actually turned (since we
don’t know if it’s the motor or encoder that’s wired backwards)
the PPR is not an integer (it’s multiplied by the gear ratio, which is not
always an integer)
trying to detect skipped steps is hard, and not something you can do accurately
in a single rotation. if a single rotation is 8048 steps and it only moves 8000
steps, you probably aren’t going to see that. That’s why when we were figuring
out the gear ration/PPR count, we had people spin it 50 times to let the error
accumulate to be sure. That takes a long time, not something we want to do for
the simple test
remember, this test is supposed to be a quick test to make sure that things are
plugged in and working, not something to calibrate the encoders or detect missed
steps.
I think you can for this test. If I understand things correctly, the singleAxisMove would still turn the motors but the encoder values wouldn’t change so the PID controller would increase the duty cycle to full speed and after the number of movement steps are completed, it would stop the motors. The encoder values still wouldn’t have changed and the result would be a fail just like the current test.
I am referring to the PPR spec of the encoder… Whatever you call that number of which the stock motor’s encoder equals 7. (fyi, I searched the forum that very question to find out what you called it before I posted the original message )
Correct… that’s why I threw out the “one or more revolutions” idea. If you are off on your encoder PPR, I think you could tell from one revolution. But if you suspect maybe the gear ratio is off or you are missing encoder steps, you can tell it to do 50 revolutions…
Yes, that’s what that very simple test currently does. I’m suggesting something that gives the user a bit more information and if they want to run a single revolution test, they can and get the same results back as the current test… You could include an ‘advanced motors/encoder test’ option instead, but I don’t see the advantage of separating them other than it might help getting people to agree to a PR.
the difference between 7 and 8 would be significant, but the difference between
50 and 51 would be less so. But in any case, we don’t ever actually enter the
literal encoder PPR, we enter the effective PPR (motor PPR * 4 * gear ratio)
I don’t at all object to having an advanced test that does the 50 rotation spin
and things like that, but I do object to changing the quick-n-dirty santity
check that can currently be done on a fully connected machine (chains attached,
Z axis attached) into something that will take a lot of time and require that
the motors be detached for the test.
Right, but most values I’ve seen are like 7 PPR, 11 PPR, 14 PPR etc. on these motors from China. I agree we enter an effective PPR that’s calculated from the gear ratio and the encoder’s PPR… both of which you need to know. Something I ran into just very recently when ordering motors was that the cheapest motors didn’t actually report the encoder PPR so I bought a couple that were a few dollars more because they did provide the PPR spec. If I had thought about this process more, I might have bought the cheaper motors and figured it out… but probably not since it was only a couple of bucks… Nevertheless, I will be testing the motors when they arrive to make sure the gear ratio and encoder PPR are actually correct and that’s what I’m suggesting to incorporate into the firmware.
It would increase the test time from 1 second per direction to 3 seconds per direction based upon a 20 rpm motor… but I don’t think that’s your objection. I don’t see why if the current test could be done on a fully connected machine, the proposed test could not. If all you care about is whether or not the encoder is reporting values, I think you can just leave the chains on the sprocket. And really I think you could do the same for the more detailed test because (as is my case) I can still see the mark I put on the sprocket to indicate which tooth I call the ‘top’ tooth with the chain installed.
In a nutshell, I don’t think I’m proposing something that would eliminate the ability to do a quick-n-dirty sanity check… if I’m missing something, which is possible, let me know. Nevertheless, I’m ok with implementing in firmware as a separate B-command if that eases concern.
I’m with @dlang on this. The test in its present form provides a very basic check that the power, cables, motor control board and driver chips are operational and connected in the correct way, independent of any settings. That’s an important reality check.
If you go into relative mode, the B09 command does this.
G91
G21
B09 L63.5
G90
will turn the left motor one rotation with the stock chain and sprocket. 10 rotations is better. I like 100, but I bought a cheap counter to keep track for me… 100 CW and 100 CCW to test that it ended up at exactly the same spot, using a pointer taped to the sprocket, was reassuring. Be careful about absolute mode, though… and in either mode it’s easy to tear the machine apart if the chains are on! I doubt that having the chains attached is a good idea if the motor/encoder characteristics are uncertain
Is the objection based on not wanting to touch the existing test or is it that you don’t think it’s a good idea to include an advanced test as a completely separate function? I’m having a problem understanding what is being objected to.
Leave the existing test as it stands, it has proved very valuable in troubleshooting board, cable and power supply issues.
A utility to determine a motor’s characteristics would make a good separate tool. It whould be run on motors “on the bench” rather than mounted in a frame. Much easier to set up a jig to measure results down at workbench height than up on the ladder. Once a motor has been characterized, it’s worth the time to mount it to a machine. Until then there are many settings in a Maslow/GroundControl setup which would affect the outcome, and may or may not have been set in the life of the machine.
I have no problem with an advanced test (I’d probably call it something like
encoder calibration test) that walks someone through testing that the encoder
settings are correct.
since this new test is pretty meaningless to people using the stock motors,
include specifying all the values needed for non-standard setups (sprocket
diameter, etc)
Ok… like I said, I’m ok leaving the existing test as is if it helps make the more advanced test acceptable for inclusion into the main branch. I prefer not to have different branches/forks to do different things. However, since I love beating a dead horse, am I incorrect in my position that performing a singleaxismove of one rotation would result in the stock motor turning for three seconds at max feedrate (whatever the setting is for it) with the encoder connected and at full speed (i.e., full pwm duty cycle) with the encoder disconnected?
I was thinking that if you suspected you were losing steps (for whatever reason) you might be able to run a motor for a large number of revolutions to see if there is any visible difference in position of the top tooth. But just like the PID tuning page I put in webcontrol, it’s of limited use to most people… but really helpful to a few.
Ok, one more question and this is a might be a third rail topic… If a PR is made for firmware and webcontrol uses it but there is no associated PR for it’s use in groundcontrol, would it be voted against for that specific reason?
it’s possible, but I really don’t think that you are going to end up loosing
many steps under test conditions, it’s under load, with the electrical noise
from the router that you may end up loosing steps. and you have to loose a lot
of them before it shows up (remember, ~400 encoder steps for the equivalent
movement of one step from a common stepper motor)
I think the singleaxismove would fail way before that with the encoder
disconnected, you need to use the B11 set power for one motor for that
one rev will be around 3 seconds, but that’s nowhere close to an accurate
measure (it’s going to depend on the friction in the motor and gearbox, how hot
the motor is, and all sorts of other trivial details)
the 20 rpm rating is FAR from some calibrated figure. If you had 10 motors, I
would not expect that you would have any 2 that turned the same amount under
full power for 3 seconds
IMHO it would depend on the function being added, but probably not, as long as
it doesn’t break GC (adding a new $value would be iffy, adding a new B code that
WC had something setup to use, but GC doesn’t know about would be no problem)
Not certain what you mean by ‘singleaxismove’, but I would say that a motor running with maximum voltage for three seconds will probably not turn one accurate revolution.
B09 L63.5 S800 would turn the left motor 1 rev at the top permitted speed as governed by the PID routines. Takes just over three seconds, but it’s not 100% duty cycle. That’s what I’ve used to characterize ‘mystery motors’. For more info, stick a B10 L ahead of and behind to check the encoder positions (multiplied by a scalar). This tells you nothing about speed, but you can easily tell whether the encoder count per revolution is correct.
B11 L S100 T3 would run the left motor at 100% duty cycle for 3 seconds. That would give you a feeling for axis speed as distance/time, but as @dlang pointed out, that’s dependent on load, the individual motor’s health, friction, driver chip temperature and power supply status. It doesn’t seem as interesting to me… I’ve got motors of varying ages and their speed at a given duty cycle varies as much as 15%. Old guys go slower , but they get there.
As to a PR for a firmware function that isn’t accessible from GC, it doesn’t seem like a problem as long as it doesn’t change the operation.
)
, but they get there.