Encoder problem

Ersatz- und Fremdteile, Modifikationen, etc.
Special Hints - Spare- & foreign parts, Modifications, etc.

Moderator: Jan3D

Forumsregeln
Bitte beachte die Forumsregeln!
hamlet
Beiträge: 329
Registriert: 12 Jan 2011, 21:41

Re: Encoder problem

Beitrag von hamlet » 28 Jun 2020, 18:11

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
20200628_170858 (Groß).jpg (144.86 KiB) 337 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.

Benutzeravatar
Dirk Fox
ft:pedia-Herausgeber
Beiträge: 1364
Registriert: 01 Nov 2010, 00:49
Wohnort: Karlsruhe
Kontaktdaten:

Re: Encoder problem

Beitrag von Dirk Fox » 29 Jun 2020, 09:17

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
Beiträge: 329
Registriert: 12 Jan 2011, 21:41

Re: Encoder problem

Beitrag von hamlet » 29 Jun 2020, 20:22

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
20200629_195119 (Groß).jpg (152.46 KiB) 210 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

Benutzeravatar
H.A.R.R.Y.
Beiträge: 924
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: Encoder problem

Beitrag von H.A.R.R.Y. » 29 Jun 2020, 20:58

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.
[42] SURVIVE - or die trying

hamlet
Beiträge: 329
Registriert: 12 Jan 2011, 21:41

Re: Encoder problem

Beitrag von hamlet » 29 Jun 2020, 21:35

Hey H.A.R.R.Y.
Good point!
Two old type encoders:
20200629_212757 (Klein).jpg
20200629_212757 (Klein).jpg (64.04 KiB) 190 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

Benutzeravatar
H.A.R.R.Y.
Beiträge: 924
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: Encoder problem

Beitrag von H.A.R.R.Y. » 30 Jun 2020, 16:16

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.
[42] SURVIVE - or die trying

fotoopa
Beiträge: 220
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Re: Encoder problem

Beitrag von fotoopa » 30 Jun 2020, 17:06

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.

Bild
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

Antworten