Encoder problem

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

Moderator: Jan3D

Forumsregeln
Bitte beachte die Forumsregeln!
fotoopa
Beiträge: 312
Registriert: 05 Okt 2017, 11:44
Wohnort: Belgie
Kontaktdaten:

Encoder problem

Beitrag von fotoopa » 15 Jun 2020, 13:04

Fischertechnik TXT Smart Home set with 2 encoder motors.
Today I wanted to use my new encoder motor from the Smart Home set. I'm sorry, but it wouldn't run. As an old technician you're going to see what's going on inside. To my big surprise I saw that the connection pins of the motor as well as the shielded wire were never soldered. Normally you would have to send that back but to keep it simple I will solder them myself.

Bild

After soldering these 3 points, the motor runs perfectly again.
Soon I'm going to measure the encoder. Then I will be able to display the correct number of pulses per revolution and the gear reduction ratio.
First results:
Motor gives 3 pulses/rev. With a gear ratio of 21,333 this gives 64 pulses per revolution of the output shaft. Speed without load measured 215tr/min.

Frans.

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

Re: Encoder problem

Beitrag von fotoopa » 17 Jun 2020, 19:43

The encoder test.
The purpose of this test is to measure how many pulses/revolutions the encoder gives out. It also measures the correct gear reduction ratio. To measure this correctly, I placed an encoder disc on the output shaft. Connected to it is a quadrature decoder. The disc has 25 magnets so the number of pulses per revolution is 100.
The FT encoder is connected to the first hardware 20 bit counter. The second 20 bit hardware counter is connected to the quadrature encoder. This counters are located in an FPGA module that works via an I2C connection to the TXT-Controller. Via the Robopro software the motor parameters can be passed on. The motor itself is fully controlled by the FPGA. A Soll value of 1000000 is given by the TXT and the motor will run until this number is reached. Both 20 bit counters are displayed by the TXT.
The number of quadrature pulses of 1000000 corresponds exactly to 10000 revolutions of the motor shaft. By now also reading the number of pulses from the 20 bit hardware counter of the motor encoder itself, we know how many pulses per revolution the FT motor gives. Immediately we also know what the gear reduction should be.
The photo makes the results clear:

Bild
Hd picture on Flickr: https://www.flickr.com/photos/fotoopa_hs/50016668946

The number of pulses per revolution is therefore not 64 as some documents indicate, but 63,8880 which gives a gear reduction of 21,296 (not 21.3). The motor runs approximately 180 rpm in this setup ( no load ).
Note:
To be able to display the 20 bit counters via the TXT, I split ( inside the FPGA in realtime) the two counters into a high and low part each 10 bit. In this way I can still display the 20 bits as integer on the screen.
Verilog code example to split the 20 bit counters:
quad_pos_high <= motor_pos/1000;
quad_pos_low <= motor_pos-(quad_pos_high*1000);
edge_pos_high <= edge_pos/1000;
edge_pos_low <= edge_pos-(edge_pos_high*1000);

Frans.

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

Re: Encoder problem

Beitrag von fotoopa » 18 Jun 2020, 10:51

Encoder motor old type FT-135484.
The purpose of this test is to measure how many pulses/revolutions the encoder gives out. It also measures the correct gear reduction ratio. To measure this correctly, I placed an encoder disc on the output shaft. Connected to it is a quadrature decoder. The disc has 25 magnets so the number of pulses per revolution is 100.
The FT encoder is also connected to a hardware counter. Per revolution the quadrature encoder will give 100 pulses on a 20 bit hardware counter. A second 20 bit hardware counter measures the pulses of the FT motor. This counters are located in an FPGA module that works via an I2C connection to the TXT-Controller. Via Robopro the motor parameters can be passed on. The motor itself is fully controlled by the FPGA. A Soll value of 1000000 is given by the TXT and the motor will run until this number is reached. Both 20 bit counters are displayed by the TXT.
The number of quadrature pulses of 1000000 corresponds exactly to 10000 revolutions of the motor shaft. By now also reading the number of pulses from the 20 bit hardware counter of the motor encoder itself, we know how many pulses per revolution the FT motor gives. Immediately we also know what the gear reduction should be.

Bild
Hd picture on Flickt: https://www.flickr.com/photos/fotoopa_hs/50018648096

The number of pulses per revolution is 76,1719 which gives a gear reduction of 25,3906333. The motor runs approximately 330 rpm in this setup ( no load ).
Note:
To be able to display the 20 bit counters via the TXT, I split ( inside the FPGA in realtime) the two counters into a high and low part each 10 bit. In this way I can still display the 20 bits as integer on the screen.

Frans.

Benutzeravatar
uffi
Beiträge: 404
Registriert: 24 Jan 2014, 16:21
Wohnort: München

Re: Encoder problem

Beitrag von uffi » 19 Jun 2020, 12:58

very interesting results, Frans.
First of all it is really astonishing, that Fischertechnik delivers such unsoldered electronics part. It clearly shows they do not have reasonable electrical testing in place or rely on insufficient quality of their suppliers.

Regarding the gear ratio: you have to keep in mind, that these gears are made using ratios of whole numbers of teeth per wheel und that the total number of wheels and teeth is limited. The gear ratio must be equal to a division of two whole numbers, which are the result of multiplying smaller whole numbers. Therefore, I doubt the correctness of your gear ratios. You certainly have minor error counts in your measurement.

best regards, Dirk

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

Re: Encoder problem

Beitrag von fotoopa » 19 Jun 2020, 14:22

uffi hat geschrieben:
19 Jun 2020, 12:58
very interesting results, Frans.
First of all it is really astonishing, that Fischertechnik delivers such unsoldered electronics part. It clearly shows they do not have reasonable electrical testing in place or rely on insufficient quality of their suppliers.
I'm rather generous in the judgment. I worked in a development lab for 26 years and also had to deal with production and testing. Sometimes unsoldered points escape the output control because they are just making contact with the metallization at that moment. Later, as a result of vibrations, this error occurs.
uffi hat geschrieben:
19 Jun 2020, 12:58
Regarding the gear ratio: you have to keep in mind, that these gears are made using ratios of whole numbers of teeth per wheel und that the total number of wheels and teeth is limited. The gear ratio must be equal to a division of two whole numbers, which are the result of multiplying smaller whole numbers. Therefore, I doubt the correctness of your gear ratios. You certainly have minor error counts in your measurement.
I was expecting this reaction. I also didn't believe at first that the measurements were correct. I also wondered how many reduction blocks would be in it and what value would correspond to my result.
Nevertheless, I am convinced that the values are correct. All pulses are counted by hardware counters. They can handle very high pulse speeds of up to 20,000 per second. By the way, a quadrature counter makes no mistakes even if you have vibrations. The FT pulse data could make mistakes here because it does not have a rotation direction info.

At the start and stop you may have a pulse uncertainty. I can see this in multiple tests and this remains +/-1 pulse. That's why I made tests for 100, 1000 and 10000 revolutions. The quadrature decoder is used for this purpose. He can't make mistakes. The quadrature pulses have been checked with a scope and are perfectly tuned. Because the pulses are also made by neodym magnets and hall detectors, they have an automatic built-in hysteresis. Also the FT motor signals come from a hall detector and have the same properties. I also checked them with the scope and the signals are perfect. I've repeated all measurements several times and the results are stable. There are no higher deviations than 1. By measuring more revolutions my measuring accuracy increases because that max deviation is only 1 pulse. The run time for 10,000 rpm (1.000.000 pulses) at 330 rpm is more than 30 min.

I would also like to know what the gear reductions are and if there would be values that would confirm my results. But for the time being, I don't see any measurement errors here. Who knows, somebody might have opened a reduction unit like that...

Frans.

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

Re: Encoder problem

Beitrag von hamlet » 19 Jun 2020, 18:06

Hello Frans,
Yes I know, this sight is hard to bear, but the patient survived (-;
EncoderSurgery.jpg
EncoderSurgery.jpg (162.05 KiB) 7850 mal betrachtet
My little surgery - I counted twice - resulted an exact 1/25 ratio, at least with one of mine old type encoders.
Best Regards,
Helmut

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

Re: Encoder problem

Beitrag von fotoopa » 19 Jun 2020, 19:41

hamlet hat geschrieben:
19 Jun 2020, 18:06
Hello Frans,
Yes I know, this sight is hard to bear, but the patient survived (-;
My little surgery - I counted twice - resulted an exact 1/25 ratio, at least with one of mine old type encoders.
Helmut
I have no reason to doubt your count.
I adjusted my measuring setup to connect the FT encoder on 9V. My previous measurements were on 5V. Again I measure no difference. I also added an extra digital filter to the FPGA so the signals should have a minimu high and low time. All without result, my measurements remain. I can't explain it for the moment, I would have preferred the value of 25 because it sounds so logical.

This will give me a sleepless night, and tomorrow I don't see a solution, because then we will be married exactly 50 years. We'll have a little party with the kids and grandchildren.

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

Re: Encoder problem

Beitrag von hamlet » 19 Jun 2020, 20:53

Dear Frans,
50 years definitely count more than a silly gear ratio of 1/"whatever" (-;
Congratualions! I wish you all the best, sleep well and have a lovely party with your family!
Helmut

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

Re: Encoder problem

Beitrag von H.A.R.R.Y. » 20 Jun 2020, 12:53

Hell Frans,

my best wishes to your marriage anniversary!

When you would like to come back to the topic: I am wondering about your measurements taken.
First I understand you have a disc with 25 "teeth" and use a quadrature sensor to get 100 counts
per output shaft rotation.

I miss a little your figure of "teeth" on the input shaft. How many do we have here?

Next is your Verilog code:

Code: Alles auswählen

quad_pos_high <= motor_pos/1000;
quad_pos_low <= motor_pos-(quad_pos_high*1000);
edge_pos_high <= edge_pos/1000;
edge_pos_low <= edge_pos-(edge_pos_high*1000);
The calculations work, indeed. But doing these divisions and multiplications might infer lots of FPGA ressources and cause timing violations.
To split up a wide vector of bits into narrower portions (or vice versa) I prefer something like this usually:

Code: Alles auswählen

input   [19:0] a;       // 20-bit input
outputL [9:0] resultL;  // 10-bit output
outputH [9:0] resultH;  // 10-bit output
assign resultL = a[9:0];
assign resultH = a[19:10];
Of ocurse, this also works with reg-type. The pieces then you convert back on the receiver side by calculating

Code: Alles auswählen

result = resultH << 10 | resultL;
But now to the biggest issue. Your two impulse counters are synchronized by mechanics. At one certain position of the output shaft you receive the conincidence of the exact fraction. Everywhere in between you suffer from the fact that you receive different counts of edges giving a variation in the quotient! I will try an example:
Output shaft gives 100 counts per its own revolution. Input shaft gives 6 pulses (3 rising, 3 falling edges) per its own revolution. With a gear ratio of 2/25 (output/input) you get 3 * 25 = 75 pulses on the input shaft for 100 pulses of the output shaft. You might get something like this:

Code: Alles auswählen

output    _____       _____       _____
I      __/     \_____/     \_____/
         :   _____   :   _____   :   __
Q      _____/     \_____/     \_____/
       0 :1 :2 :3 :4 :5 :6 :7 :8 :9 :10
         |<-  2/25 Revolutions ->|

       0 1  1  2  3  3  4  5  6  7   7
       - -  -  -  -  -  -  -  -  -  --
       0 1  2  3  4  5  6  7  8  9  10

input     ___     ___     ___     ___
       __/   \___/   \___/   \___/   \_
       0 :1  :2  :3  :4  :5  :6  :7  :8
         |<--  1 Revolution   -->|
The gear reduction thus can get calculated by (counts on input shaft / counts on output shaft) * (counts per 1 rev of output / counts per 1 rev of input) and for the example this is (counts on input shaft / counts on output shaft) * 100 / 6). Now take the momentary quotients from above and calculate for each. You will get the sequence of results:

Code: Alles auswählen

1/1 = 16,6667
1/2 =  8,3333
2/3 = 11,1111
3/4 = 12,5000
3/5 = 10,0000
4/6 = 11,1111
5/7 = 11,9048
6/8 = 12,5000
7/9 = 12,9630
7/10= 11,6667
Now take a look on the error and then you might find that your uncertainty always is a certain fraction of the output shaft revolution. You might expect the error to be less than 1 % since your resolution is 100 pulses per revolution (output). But please calculate the error of the momentary results and you see the issue yourself. With 10000 revolutions of the output shaft you receive 125000 revolutions of the example input shaft (250000 with the "old" encoder). Based on your measurement setup you might get the residual error smaller and smaller, but you never will reach 0.

Do you gate both counters and stop counting input pulses when the output gives its 1000000th pulse?

And one more thing: The motor itself might produce erratic pulses due the commutator sparks. Eventually those little beasts give you some extra hazzle with counting the pulses?

The ultimate method to determine a gear reduction ratio indeed is counting the teeth - like hamlet already did.

Regards
H.A.R.R.Y.
[42] SURVIVE - or die trying

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

Re: Encoder problem

Beitrag von hamlet » 21 Jun 2020, 13:15

Hey Frans,
This is a tricky and fun one problem!
I remembered one of your older posts on this topic: Your FT135484 encoder Motor seems to be equipped with a Kinmore KM-20A130F-25.4. And the gear ratio of 1/25.4 is quite close to your measurement. It looks like that once upon a time ft has changed the motor/gearbox supplier.
But the given ratio can't be exact, because in this ratio 1/25.4 = 10/254 = (2*5) / (2*127) is that nasty prime 127, and a gear with 127 teeth wouldn't fit into the gearbox.

Assuming a four stage gear box I hacked down a not very elegant brute force trial and error approach, to check if there exists a gear box setup that is compatible with your measurement.

Code: Alles auswählen

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <cmath>

int main( int argc, char* args[] ){
	// brute force search for a four stage gear ratio 
	// n1/d1 * n2/d2 * n3/d3 * n4/d4
        //closest to the given ratioRound
	const double counts = 761719.0;
	const double ratioRound = counts / 3e4;
	//const double ratioRound = 25.4;	
	const uint32_t dMin = 9;   // denominator teeth range, i.e. the smaller gear of the gear pairings
	const uint32_t dMax = 20;
	const uint32_t nMin = 15;  // nominator teeth range, i.e. the larger part of the gear pairings
	const uint32_t nMax = 35;
	const uint32_t tMin = 25;  // range of the sum of teeth of each gear pairing
	const uint32_t tMax = 50;
	double minDiff = 1e6;
	for(uint32_t n1=nMin; n1<=nMax; ++n1){
		for(uint32_t d1=dMin; d1<=dMax; ++d1){
			if(n1<=d1 || n1+d1>tMax || n1+d1<tMin) continue;
			for(uint32_t n2=nMin; n2<=nMax; ++n2){
				for(uint32_t d2=dMin; d2<=dMax; ++d2){
					if(n2<=d2 || n2+d2>tMax || n2+d2<tMin) continue;
					for(uint32_t n3=nMin; n3<=nMax; ++n3){
						for(uint32_t d3=dMin; d3<=dMax; ++d3){
							if(n3<=d3 || n3+d3>tMax || n3+d3<tMin) continue;
							for(uint32_t n4=nMin; n4<=nMax; ++n4){
								for(uint32_t d4=dMin; d4<=dMax; ++d4){
									if(n4<=d4 || n4+d4>tMax || n4+d4<tMin) continue;
									double ratio = double(n1*n2*n3*n4)/double(d1*d2*d3*d4);
									double diff = fabs(ratio-ratioRound);
									if( diff<minDiff){
										minDiff = diff;
										double cnt = ratio * 3e4;
										printf("%2u   %2u   %2u   %2u\n", n1,n2,n3,n4);
										printf("-- * -- * -- * -- = %f deltaRatio=%f  => counts=%.2f  countDiff=%.2f\n", ratio, diff, cnt, counts-cnt);
										printf("%2u   %2u   %2u   %2u\n\n", d1,d2,d3,d4);
									}
								}
							}
						}
					}
				}
			}
		}
	}
	return 0;
}
and the result:

Code: Alles auswählen

...

15   15   29   35
-- * -- * -- * -- = 25.375000 deltaRatio=0.015633  => counts=761250.00  countDiff=469.00
10   10    9   10

15   16   28   34
-- * -- * -- * -- = 25.386667 deltaRatio=0.003967  => counts=761600.00  countDiff=119.00
10    9   10   10

15   18   32   32
-- * -- * -- * -- = 25.388430 deltaRatio=0.002204  => counts=761652.89  countDiff=66.11
10    9   11   11

15   19   28   35
-- * -- * -- * -- = 25.390909 deltaRatio=0.000276  => counts=761727.27  countDiff=-8.27
10   10   10   11

16   31   32   35
-- * -- * -- * -- = 25.390557 deltaRatio=0.000076  => counts=761716.71  countDiff=2.29
 9   11   17   13

23   29   31   31
-- * -- * -- * -- = 25.390652 deltaRatio=0.000018  => counts=761719.55  countDiff=-0.55
 9   11   15   17

25   25   26   27
-- * -- * -- * -- = 25.390625 deltaRatio=0.000008  => counts=761718.75  countDiff=0.25
 9   10   12   16

Maybe it's the last gear combination, at least it looks realizable and it deviates just a quarter of a tic from your measurement result.
Have fun,
Helmut


EDIT:
By the way there are myriads of possible gear combinations that exactly match your measurements for the new encoder type, e.g.

Code: Alles auswählen

28   22   22   22
-- * -- * -- * -- = 21.296000 deltaRatio=0.000000  => counts=638880.00  countDiff=0.00
10   10   10   14

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

Re: Encoder problem

Beitrag von fotoopa » 21 Jun 2020, 17:41

Hello Helmut,

Thank you very much for the many details. Sorry about my late reaction. Because of the party yesterday, the grandchildren only returned home this afternoon.
I've been able to make some new tests to see if there were any measurement errors. I can confirm that my results are still stable and appear to be correct. I'm someone who's also looking if something's wrong, why it could go wrong.

Just one more clarification. I use a 3D printed encoder disk with 25 neodym magnets in it. On the track with 25 magnets there are 2 hall chips that give the quadrature pulses for the counter inputs encA and encB. These are connected to my 24 input box. This input box is read every 16 usec by the FPGA. This already works as a filter, you are not sensitive to very short interference pulses. From this you can determine the max input frequency. I calculate at least 2x high and 2x low together 64 usec. This corresponds to 15 Khz max processing speed. The counter itself is 20 bit and is used for the motor control. This is also included in this FPGA module. You have a Soll value and motor speed. The module calculates the direction and controls the motor. Typical parameters are: run speed 100%, brake speed 20%, brake distance 40 pulses. The motor rotates at full speed up to 40 pulses before the end point and then slowly moves to the final value. By setting brake distance and brake speed you can achieve a very gentle approach to the final value.
The quadrature counter is a full 20 bit. All controls are adjusted accordingly. The breakdown to 2 x 10 bit is only for the TXT, not for the measurement itself. By the way, a hardware counter does not interfere with timing problems like micro crontroller with interrupt routines. Everything here runs parallel and very fast. Everything is synchronous and runs on 1 MHz clock. Every update is 1 usec, also the conversion for the TXT.
An extra magnet is placed on an additional track on the 3D encoder disk. This can be used as a home pulse.
I can optionally use this input as an encD signal and send it to a separate counter in the 24 input box. This allows me to count the correct number of revolutions. I have already done tests to see if the total required revolutions correspond with the measured home pulses and that too was correct every time. There are no deviations here, error must be zero. I can also check this accuracy visually. I made a mechanical ref point. If you ask for any number of revolutions, this point has to stop on the same spot every time. This is also the case even after 10,000 revolutions. These tests are also running correctly.

The FT motor has 6 internal magnets, with alternating poles. The hall decoder will give 3 pulses per revolution. I measured this value today by opening the encoder motor again! The FT output of this encoder also goes to my 24 input box, signal is encC. In my FPGA there is an extra 20 bit counter which is set to count on every rising pulse. Also this encoder input is read every 16 usec by the FPGA via the SPI box. Mistakes due to bad edges are hereby excluded. By the way, I did tests with different pullup resistors on the hall output but there is no difference in the result.

Your search for a possible gear reduction seems very correct to me. By the way on the motor housing is the value 25.4. It will be slightly different but your calculations give plausible results.

I think I can conclude that your research and my measurements are correct. In any case, I am very pleased that someone is making so much effort to help with these measurements. For this I thank you once again.

Detail encoder disk:

Bild
HD picture Flickr: https://www.flickr.com/photos/fotoopa_hs/50030513977

Frans.

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Encoder problem

Beitrag von Karl » 22 Jun 2020, 00:52

Hallo,
möchte mal gerne wissen wie die Getriebe-Untersetzung 25,4 : 1 realisiert wurde ?
Viel Platz steht doch nicht zur Verfügung, für ein 127er Zahnrad sicherlich auch nicht.

Hello,
would like to know how the gear reduction 25,4 : 1 was realized ?
There is not much space available, and certainly not for a 127 teeth gear.

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

Re: Encoder problem

Beitrag von fotoopa » 22 Jun 2020, 09:06

hamlet hat geschrieben:
21 Jun 2020, 13:15
Hey Frans,
This is a tricky and fun one problem!

Code: Alles auswählen

25   25   26   27
-- * -- * -- * -- = 25.390625 deltaRatio=0.000008  => counts=761718.75  countDiff=0.25
 9   10   12   16
Maybe it's the last gear combination, at least it looks realizable and it deviates just a quarter of a tic from your measurement result.

By the way there are myriads of possible gear combinations that exactly match your measurements for the new encoder type, e.g.

Code: Alles auswählen

28   22   22   22
-- * -- * -- * -- = 21.296000 deltaRatio=0.000000  => counts=638880.00  countDiff=0.00
10   10   10   14
These 2 results correspond to the measured results. If I had to measure factor 10x longer you would really see the error converge to zero. But 10.000.000 pulses would take just over 5 hours!
@ Karel,
The gear box consists of a few stages. The construction does need to be adjusted if you assume that the motor shaft is in line with the output shaft. But also this is not really necessary if you make the housing correct. Also the mechanical position of the intermediate conversions can be adjusted. These are so of the fine mechanical puzzles. I think Helmut has found the right box for both motor.

Frans.

Benutzeravatar
uffi
Beiträge: 404
Registriert: 24 Jan 2014, 16:21
Wohnort: München

Re: Encoder problem

Beitrag von uffi » 23 Jun 2020, 14:12

So then the conclusion would be, that the older encoder motors of Frans and Helmut differ in gear ratio, i.e. 1:25.39 versus 1:25.
Could you both please disclose the date of purchase for your encoder motors? Or the production number shown on the red guarantee paper?
Maybe this brings some light into the topic.

Thanks, Dirk

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

Re: Encoder problem

Beitrag von fotoopa » 23 Jun 2020, 14:51

The old version encoder motor was delivered by Amazon on 22 April 2018. From the Fischertechnik 511933 - TXT Automation Robots.
Motor reducion: 25,3906. Picture show the wrong ration of 25,4!
Fischertechnik encoder motor FT-135484
Detail of the motor:
Bild
Flickr: https://www.flickr.com/photos/fotoopa_hs/43941681551

The new encoder motor was delivered by Amazon on 5 juni 2020 from the Fischertechnik - 544624 Robotics TXT Smart Home.
Motor reduction: 21,2960.
Fischertechnik encoder new motor FT-153422

Frans.

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

Re: Encoder problem

Beitrag von H.A.R.R.Y. » 23 Jun 2020, 15:45

Hello all,

this indeed would explain some distortion effects to me:
135484 delivered with different gear boxes - 1:25 originally and 1:25.39... (~25.4) later on. The difference is roughly 1.6 %.

Running a certain (and always the same) control code on a model using different 135484 explains why there are differences in the positions achieved.

What I really hate is getting pricey encoder motors with insufficient (or wrong) gear ratio data. Every measure taken, relying on the gear ratio, is getting a hoax and waste of effort concerning the wrong ratio. This means I have to spend lots of effort on my special Knobloch-Quadrature-Encoder-Motors being close similar devices to the 135484. Or is someone out there who already has precise and reliable gear ratio for those 75150 ones?

Kind regards
H.A.R.R.Y.
[42] SURVIVE - or die trying

Benutzeravatar
uffi
Beiträge: 404
Registriert: 24 Jan 2014, 16:21
Wohnort: München

Re: Encoder problem

Beitrag von uffi » 23 Jun 2020, 15:50

Thank you, Frans.

Now it is obvious that the two older Encoder motors owned by you and Helmut differ indeed!

Thanks for clarification and confirmation!

Best regards, Dirk

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

Re: Encoder problem

Beitrag von hamlet » 27 Jun 2020, 15:16

Hello forum,
I'm sure that ft has delivered also the new encoder type with different gear boxes. The series I purchased in Nov. 2015 is equipped with a "Kinmore KM-25A370-21.1-09209". The given ration of 21.1 differs significantly from the 21.296 Frans has measured. And 21.1 cannot be the exact ratio because 211 is a prime.
… So also I did some measurements but with a rather simple setup:
20200627_125851 (Groß).jpg
20200627_125851 (Groß).jpg (123.03 KiB) 7358 mal betrachtet
Both, the encoder and the revolution counter switch, are connected to the TX fast digital inputs that are sampled with 1kHz. The program waits for a rising edge of the revolution switch, reads out the encoder tics, calculates the encoder tics increment with respect to the last revolution and sums up these increments to the total encoder count in a RoboPro float. Here the "unsigned integer to float" cast function is used as it can cope with the revolving 16bit signed integer encoder values. With their 32bit mantissa the RoboPro floats are exact for integers up to ~4e9. From the total encoder count and the revolution counter the mean Counts Per Revolution (CpR) is calculated. The encoder increments per revolution are monitored. Each time a rising edge, e.g. 63->64 is detected, the program estimates the lower and upper bound of the CpR value. The CpR result from the 64 count revolution is taken as the upper bound and the CPR result from the 63 count revolution just before edge is taken as lower bound.
The program provides valid results only on the TX in offline mode, because in this setup the RoboPro thread is called with a rate of 1kHz. On the TXT this rate is a non-exact 100Hz and in offline mode it's even worse. Then the revolution switch trigger for the encoder readout jitters too much and the measured encoder increments per revolution fluctuate.

The program is available here: https://1drv.ms/u/s!AjSvbnB4EKxJmSR7Om9 ... 1?e=Y84wRi

The resulting Counts per revolution for my new type encoder is somewhere in between 63.33041 < CpR < 63.33047
maybe it's

Code: Alles auswählen

30   25   23   28
-- * -- * -- * -- = 21.11014 => counts=63.33042  
10   13   16   11
20200627_143808 (Klein).jpg
20200627_143808 (Klein).jpg (47.02 KiB) 7358 mal betrachtet
The display:

Code: Alles auswählen

min: lower CpR bound
CpR: Mean value for counts per revolution CpR=cnt/rev
max: upper bound
cnt: total encoder counts
rev: number of revolutions      
tm: time per revolution measurement in ms
hgh: expected upper limit for encoder increments and total count of revolutions with this value   
low: expected upper limit for encoder increments and total count of revolutions with this value
(… low and hgh are swapped in the picture)
KO: total number of revolutions with different counts (should be small or zero)
With my old encoders the program shows an exact 75 from the first revolution on … at slightly reduce speed (~300ms per revolution).

BTW: I had severe problems with the RoboPro display functions. After some time the TX display freezes, went blank and once it died in a rather fancy manner:
20200625_201059 (Klein).jpg
20200625_201059 (Klein).jpg (38.02 KiB) 7358 mal betrachtet
A power cycle fixes it. I tried to increase the stack size, added wait states between the print commands, moved the display stuff into a function and reduced the display update rate, … nothing helped. An inspection of the RoboPro XML source revealed that not all of the global variable instances had a unique ID. After copying the RoboPro diagrams and the display setup manually into a new empty RoboPro program the program did at least one very long run w/o problems. Weird issue …
Best Regards,
Helmut

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: Encoder problem

Beitrag von vleeuwen » 27 Jun 2020, 17:50

For me it is not so clear what you are doing.
The fast counters are only working as fast counters in case of the enhanced used; the black box before the Transfer area.
When a Counter input is used in the same way as a Input (binary input), the sample rate for both are the same.
To test the exact behaviour, there is no need for full speed. The only thing that count is that:
1) the high part is >10ms
2) the low part is also >10 ms.
A bad placed switch can have a full puls time of 20 ms but when the low or high part is smaller then 10 ms the system will be instable.

In the past I perform tests with the encoder motors too.
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.
A long worm gives a very good accuracy.
The distance can be compared with the result of the Cx fast counter black box or a normal C or I counting.
With this setup, there are two different systems of measurement available.
This setup makes it also possible have long duration test with for example: 100 times 1500 pulses CW and CCW (up and down). This could give a indication of drift too.

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

Re: Encoder problem

Beitrag von fotoopa » 28 Jun 2020, 10:32

Hello, Helmut,
You make great efforts to determine the correct reduction factor of the engine. You try it with only a software solution. The weak point is still the TX or TXT controller. They are not suitable to measure reliable pulses at a higher speed. A second weak point is your mechanical switch which you use as a reference pulse of your output shaft. There you should use a hall type switch. They don't exert any pressure on your shaft and have a built-in threshold when switching from high to low and vice versa.
Calculating those averages also remains an approximation. However, many measurements do give you a plausible value.
With pulse measurements I assume that your counter must be correct. Just like a measuring instrument, you have to be able to rely on it within the given accuracy. This is a job for the hardware. I understand that this is more difficult to achieve with a software-oriented user.

If you want to measure the reliability, you can do so as Vleeuwen indicates with a long spindle. Even if you move back and forth 100 times, it must always stop in the same place. But here it's mainly about determining the gear ratio of the reduction box. The best way then remains a reliable pulse measurement with a sufficiently large range of the counter. That is the advantage of an FPGA hardware counter. There you can choose the length of the counters yourself. The width of the counter has no influence on the processing speed. I am therefore going to remake my measurement setup. It was already removed in the meantime. I'm going to bring the counter to 24 bit so I can count up to more than 10.000.000 pulses. For the readout on the TXT I'm going to split the values into 2 parts, the height 14 bit, the lowest 10 bit. Then I don't have to make the division internally in the FPGA. That saves me some resources. The results are then modulo 1024 and not 1000. But that you then convert yourself.

A good point with your measurement is the flying start before starting the measurement. This reduces the one-time error due to the slack in the reduction box. Once the motor keeps running into the same direction, this error will not occur. I will also make a flying stop that stops all counters at the same time when the desired number of pulses is reached. I am going to take 10.000.000 pulses from the quadrature counter which corresponds to a measurement of over 5 hours! I expect to be able to give the results of the first motor test tomorrow. Now I will adjust the FPGA module for the new functions.

Frans.

Antworten