Many thanks for your responses.
My aim was to get a better knowledge of the gear ratio of the new type encoder that I own. Some time ago we already found out that it is not the documented 63 counts per revolution (CpR) but rather something near to 63.3 CpR. I wanted to know if it might be a 63+1/3 CpR, which would have been nice, because then one could expect an integer number of 190 counts after three full revolutions. OK, this is not exactly the case (~63.330) but at least a good approximation for a lot of applications.
Also my aim was to realize this with a minimal effort setup using ft parts only, so that everyone can repeat this measurement to identify the encoder gear type, that ft has changed w/o notice for both encoder motors, old (75 vs. ~76.172) and new (~63.330 vs. ~63.888). Maybe there are even more different types around?
Yes, this setup isn't perfect, but I think the results proof that it's absolutely sufficient for a quick measurement.
I've simplified the program! Now it works reliably even on the TXT with the "high speed" old encoder motor type.
Thanks to Frans for the "flying stop" hint! With creeping speed at start and stop the results look fine.
You have to make sure that the revolution counter switch is pressed sufficiently long, e.g. half of the revolution. Otherwise the TXT might miss some revolutions counts. As Carel correctly stated the high/low times have to be longer than 10ms, … better more.
The program is available here: https://1drv.ms/u/s!AjSvbnB4EKxJmTw-2IY ... F?e=SZxdNa
If anyone is interested in the program, please give a short notice. I will add some documentation, do some further testing and upload it to the ftc download area.
Have fun,
Helmut
I don't know if I understand you correctly here but I'm sure that the TX samples and updates the fast digital "C1"-"C4" inputs each time the TX OS runs the RoboPro code. The TX calls the RoboPro user code once per millisecond in offline mode. So it provides in fact a 1kHz sampling rate. On the TXT the Linux scheduler (round robin?) runs the RoboPro process with an average period of 10ms with large sporadic jitter, I've observed up to 50ms. And there is a data transfer penalty from the Cortex M3 to the Cortex A8 processor. Thus on the TXT RoboPro cannot keep up with the fast digital inputs.The fast counters are only working as fast counters in case of the enhanced used; the black box before the Transfer area. ...
The universal "I1" to "I2" inputs are read out by a multiplexed ADC and measurements are updated with a period of about 10ms.
Also here I'm a bit puzzled. Should I take a ruler to count the number of rotations? … Ah, I think Frans got it correctly, this setup realizes a reliability check.I was using 3 encoder motors both connected with long worms or long stud bolts (M4 1000mm).
The distance of movement from the screw on the worm will be a accurate measure for the number of rotations. ...