Encoder problem

[hamlet]

Hello Frans and Carel,

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.

20200628_170858 (Groß).jpg (144.86 KiB) 4860 mal betrachtet

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

The fast counters are only working as fast counters in case of the enhanced used; the black box before the Transfer area. ...

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 universal "I1" to "I2" inputs are read out by a multiplexed ADC and measurements are updated with a period of about 10ms.

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

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.

[Dirk Fox]

Hello Helmut,

thanks for your clarification and your tests!

One reason for your "variance" could be the mechanism to count the revolutions (the push button).
I did a similar test (some time ago) with a contactless counter (using a laser), obtaining repeatable results:
viewtopic.php?f=21&t=4338&p=31403#p31403
viewtopic.php?f=15&t=5775&p=42320#p42320

Regards,
Dirk

[hamlet]

Hi Dirk,

The laser counter is great!
However even with the push button the results were absolutely stable and repeatable. Even with the old fast encoder at full speed the results were on point, 75 Counts per revolution (CpR), all times.

Even though it works with push buttons and I love the hypnotic Tic-Tac, I tried to setup the laser counter, because I felt bad about abusing the push button in long runs. But unfortunately my laser doesn't fit into the "Schnecken-mutter" and also needs a pre-resistor. And I would have need to add some of the flimsy "Rast" axles and couplings.

Being frustrated, I had an idea. ft has provided a very reliable and easy to use reference counter, the old exact 75 CpR encoder motor.
Here is the result:

20200629_195119 (Groß).jpg (152.46 KiB) 4733 mal betrachtet

Simple and stiff HW. And simple and robust SW, as the counter values are reliably determined in real time on the TXT's Cortex M3
core. So there's no need to care about the lags and jitters of the RoboPro Linux process on the cortex A8.

I hope that I did the error propagation correctly. I was rather pessimistic and assumed 2 tics of error, one for the start and one for the actual measurement, for each of the encoder. I added the errors of both encoders linearly, i.e. worst case.

The program is available here: https://1drv.ms/u/s!AjSvbnB4EKxJmT-GaEB ... s?e=CcystI

And also with this setup the new type encoder motor's CpR is 63.330x not the nice 63+1/3 we hoped for.

This result is absolutely compatible with your results: With those ugly odd gear ratios you have either 63 or 64 counts in each revolution and your calculated mean CpR is either a bit too small or a bit too large depending of the last revolution's count, and almost never on point, even if you count correctly. Thanks to H.A.R.R.Y. for this hint! In the test you presented in the ftpedia you did 300 revolutions and thus the error is about 1/300=0.0033. So your and my results are absolutely compatible.

I also believe that Frans has owned one of those "bad" encoders that were equipped with a different gearbox. He measured the 63.888 CpR.

Have fun,
Helmut

[H.A.R.R.Y.]

Hello hamlet,

with two identical motors (no matter if being old, new, weird, ...) you could check immediately your test setup. Both impulse counters should give the same readings for the same amount of rotation.

Regards
H.A.R.R.Y.

[hamlet]

Hey H.A.R.R.Y.
Good point!
Two old type encoders:

20200629_212757 (Klein).jpg (64.04 KiB) 4713 mal betrachtet

At some of the periodic updates cnt1 and cnt2 differ by one or two tics, but usually in the following update the two counters match again, sporadic small glichtes, nothing that piles up.
I would say, "Test Passed!"
... and now back to "DCI Barnaby" (-;
Best Regards,
Helmut

[H.A.R.R.Y.]

Hello hamlet,

thank you for this last doublecheck. I fully agree. 1 tic of uncertainty per counter and by chance one is 1 tic ahead while the other just is 1 tic behind. A mismatch of just 1 is more common and a mismatch of 0 is perfect. As expected.

:thup:

Regards
H.A.R.R.Y.

[fotoopa]

I think all the readings are almost correct now. Except for the old type FT engine which really does have a reduction of 25, the other types are not integer values. I repeated the measurements with a higher resolution with the hardware counters now having 24 bit. This way they can handle a very large range. Disadvantage is that the measurements take a very long time! I've made an overview table with the latest results. These are in line with what I had measured before but now even more accurate.


HD on Flickr + details setup: https://www.flickr.com/photos/fotoopa_hs/50062110402

I added to the overview the suspected gears that Helmut had already indicated and they turn out to be correct.

I will now continue my work on a new project with the DE0-Nano soc board from terasic using a combination of FPGA and a 925MHz Dual-core ARM Cortex-A9 processor that runs on an included Linux version. The ARM can work directly with the FPGA and part of its 1 Gb memory can be used for this purpose. I have already started the FPGA with my own program which allows me to work with the TXT via I2C. Also the linx kernel is already running but I have very little experience with this software. The combination of both is the best of both worlds, the hardware and the software.
info CD data of this Terasic board: https://www.terasic.com.tw/cgi-bin/page ... 1&PartNo=4

Frans

[hamlet]

Hey forum,
Also in the official ft documentation the new type 153422 encoder motor is specified "same same, but different":

https://www.fischertechnik.de/-/media/f ... 9v_en.ashx (Feb. 2018)

Anmerkung 2020-07-07 125658.png (68.38 KiB) 4483 mal betrachtet

https://www.fischertechnik.de/-/media/f ... h_neu.ashx (Sep. 2019)

Anmerkung 2020-07-07 130816.png (60.11 KiB) 4483 mal betrachtet

Kind Regards,
Helmut

[fotoopa]

Thanks for both pictures with the data of the FT motors.

I understand they mention 21.3 ratio. The error is small so this rounding will give little problems with normal use. I'm staying with my results of the measurements. The max measurement error I can have is +- 1 pulse on a total of 1000000 pulses from the FT encoder. This is because the reference pulses are on the output of the mounted disc. The FT pulses always flotation with respect to my reference. You can also see this when you read out the encoder signals with the scope during the measurements. The reference trigger stands still, the FT pulse shifts. It is always nice to be able to measure correct values and also explain them by the gear reduction ratios.
The 21.1 ratio is totally different with the motor that I bought recently. Sometimes it is still difficult to find correct data!

Frans.

[hamlet]

Hey Frans,
I've never questioned your measurements. I posted those Specs as a further indication that ft has changed the gears, I guess due to a discontinuation. The ft ratios are rounded. They can't be exact as both ratios, 21.1=211/10, 21.3=213/10=3*71/10, contain large primes, 211 and 71. The corresponding gears wouldn't fit into the gear box.
Thus, if anyone is puzzled by unexpected position deviations, the root cause might be the encoder. Just check it.

A summary of our measurements:

Code: Alles auswählen

Encoder Tics per revolution:
Classic (135484)       New (153422)
 75                    ~63.3304     (first series)
~76.1719               ~63.8880     (since 2018/2019?)

Regards,
Helmut