TXT Controller and I2C speed

[fotoopa]

Today I designed the interface to test my I2C modules on the Fischertechnik TXT Controller. For this I made a simple interface box with Fischertechnik parts to fix the print. The PCB is a simple single side version for mounting and testing the I2C modules. Diagram, layout and installation plan are ready. The layout film is drying, in order to be able to etch early tomorrow. After that, the tests follow.
A few images in advance:

HD: https://www.flickr.com/photos/fotoopa_hs/28495078057


HD: https://www.flickr.com/photos/fotoopa_hs/43363747141


Hd: https://www.flickr.com/photos/fotoopa_hs/28495077607

There was a fourth module, the FRAM, but there is an address issue with the TXT controller ( same internal address range $50-$57) so it could not be connected to it directly on the TXT Controller, however via external hardware it should work anyway. A number of examples for the software I have already found through this forum, so the testing should go pretty well. I will keep you informed of the results (within a few days).

Frans.

[fotoopa]

The PCB has just been etched and the components have been soldered. Everything fits neatly in the Fischertechnik housing. A 10-pin cable is connected directly to the TXT controller. The sensor modules are also soldered and mounted. The power supply voltage has been tested. All modules are supplied with the necessary 3V3 voltage. The real tests with the Robo TXT software will follow tomorrow.
A photo of the interface mounted in the box:

HD version: https://www.flickr.com/photos/fotoopa_hs/41579529110

Frans.

[fotoopa]

Test of the color sensor I2C module TCS34725 connected to the Fischertechnik TXT Controller. With the test program of Dirk Fox I was able to start very quickly. Everything works very well, now I can start a new project to sort colored pearls. The box contains 2300 pieces in 11 different colors. Ideal for designing a sorting robot.
A few images of the test set-up:

HD version: https://www.flickr.com/photos/fotoopa_hs/43400174591


HD version: https://www.flickr.com/photos/fotoopa_hs/28530961997


HD version: https://www.flickr.com/photos/fotoopa_hs/29530035618

Frans.

[fotoopa]

The TCS34725 color I2C chip supports auto increment address mode. You can read all 4 color data registers at once without interruption. You only need 352 usec, otherwise this is 20 msec.
To achieve this, you only need to leave the devices open as shown on the flow:



Frans

[fotoopa]

Test of the TXT Controller for making short pulses. This is not going very well at all. The specified pulse widths and times are incorrect. The Robo software always uses a PWM cycle with a minimum time of 4.78 msec. You can specify a pulse width with a resolution of 512 units. But he doesn't do it that accurately. The minimum value should be 3, even better 4 units. Otherwise, you will not get any pulses at all, or you will get them very irregularly. You need to increase more than 1 unit to sometimes measure an increase. At 4 units the measured pulse time is 353 usec. At 16/512 this is only 406 usec.

Same story for the delay timer. It is not correct either. The requested 10 msec is about 15 msec or more and is not even stable. For short output times, the TXT Controller is not suitable at all! I normally use FPGA hardware and there you have times up to 10 nsec. I wasn't familiar with such bad times as those of the TXT Controller.

The analog signal is also very bad, especially the falling edge. You also have to place a fairly large load on the output, here this is 220 ohms. Without load on the output, you cannot obtain PWM pulses. The measuring signals contain a voltage divider to have a maximum voltage of 4V. The trigger value is set to 2V or 50% of the range.

Results:





Pictures on my Flickr page:
https://www.flickr.com/photos/fotoopa_hs/41683300190
https://www.flickr.com/photos/fotoopa_hs/42586599185

If you want to synchronize on an I2C command it doesn't work either, the timings are not reliable at all. I would have liked to have made a short pulse just before an I2C command and then removed the pulse again but that's not possible. My intention was to turn on a LED for a short time as an exposure.

Frans.

[fotoopa]

Speed test fast input C1C of the TXT Controller. The aim is to determine the maximum pulse cycle that the controller can process. The documentation states that this type of input would work up to 1 Khz. I made a pulse generator with a 9V block wave and a 50% duty cycle. A small program counts the pulses that come in. The Fast C1C input only counts on the rising edge. The result goes up nicely to 100, this is 100Hz, or 10 msec (5msec on, 5msec off). Now comes the surprise. If you increase the frequency, the speed indication will remain at 100. This increase can be made up to 3 msec which should give a speed of 333. But the speed indication remains at 100. Increase your speed even further, pulses smaller than 3 msec that makes the speed display unstable to drop out a little further. Normally you should be able to work pulses up to 1Khz but I can't do that. Either I do something wrong or the TXT Controller can't handle this speed. I performed the tests both online and offline. The results were the same.
I see only reliable reading pulses up to 100 Hz.

Here is a picture of the measurements:


Bigger version: https://www.flickr.com/photos/fotoopa_hs/43514954642

Frans.

[fotoopa]

Additional test to measure the speed of the TXT Controller. One lamp output controls the next input. You can follow the timing on the Logic Analyser. Things are not going very fast. The TXT Controller has an internal multitasking system. Task switch seems to me to be somewhere around 4.78msec. He needs quite a bit of time to control a lamp. On average this is around 33.5 msec +/- 1 task tick time. This is where you can see times of 33.5 and 38.29 msec. To control all 7 outputs, the total time is approximately 235 msec. This is quite slow! If you have everything changed at once, they will go together beautifully. This can be seen on the negative side of all the lamps. The input signal comes from an encoder. This allowed me to control the speed.



HD format: https://www.flickr.com/photos/fotoopa_hs/43089009614

Frans.

[fotoopa]

Running the previous test with the new software version V4.4.3 give the same timing results.
Until now, I don't see any problems with the new software.

Frans.

[fotoopa]

Today I made a test to measure the accuracy of the FT encoder motor FT135484. This is an encoder motor that can only deliver pulses, but contains no direction. The TXT Controller has its own function to control the starting and stopping of the motor. We already know from other reports that this is not always so precise. I have created a small test program and extra hardware for the measurements.

This test measures the FT encoder via the TXT Controller and the FPGA measures the same rotations via a hall quadrature encoder. The FT encoder give 76p/turn, the hall quadrature encoder 40p /turn. The program rotates 2 revolutions forward and 1 revolution backwards each time. After 100 times the program stops. Both encoders can be read in real time. After 100 times we see an error of 9 pulses which is indicated by the hardware encoder. These 9 pulses correspond to (9*76/40) or 17 pulses on the FT encoder. However, it is the FT encoder that is not correct. The FPGA quadrature encoder is error-free. The hardware quadrature encoder does not work with interrupts on the edges of the encoder, but with level changes. There is a home point on my hall encoder disk. Because of this I can see the drift that is developing. The errors occur in the TXT controller when starting and positioning the motor. Sometimes a few pulses are seen too much, sometimes a few too few. The errors are not greater with long rotations. The hardware quadrature encoder is read out via the I2C connection. Errors are not constant. Sometimes the deviation is larger, sometimes smaller. This makes it somewhat unreliable.

Here a picture off the setup:


HD version: https://www.flickr.com/photos/fotoopa_hs/30012681758

The program:


Bigger version: https://www.flickr.com/photos/fotoopa_hs/30012681808

The next test I'm going to make is the synchronous control of 2 motors.
The software version is: RoboPro 4.4.3

Frans.

[hamlet]

Hello Frans,
Nice work, not only your latest measurements, your whole project is simply awesome!
As I know the old ft encoder makes 75 pulses per revolution, as documented in the ft manuals. The new encoder is only 66 1/3 pulses per rev., and here the ft spec states a wrong value of just 66 ppr.
EDIT: The given ratio of 66 1/3 : 1 above is wrong, it's 63 1/3 : 1 ... and ft stated a rounded value of 63:1
The RoboPro enhanced encoder distance control is known to be not always that exact, sometimes the achieved distance is one or even a few pulses off. I guess that this depends on model driven. Changing load, moment of inertia, friction is a challenge for the closed loop motor control. Off course these tiny deviations might cumulate. I expect the TXT/TX pulse measurement to be exact ... hopefully. In fact you can retrieve the counted pulses, i.e. the "real" measured distance, in parallel to the active enhanced motor control by reading the counts from the RoboPro CxCounter input elements and update your current position with this value instead of the requested distance. This should improve the position accuracy. However I'm not that sure that direction changes are always handled correctly, even with this approach.
An encoder positioning lib I have provided here some time ago uses this approach.
Kind Regards,
Helmut

[fotoopa]

Hello Frans,
As I know the old ft encoder makes 75 pulses per revolution, as documented in the ft manuals.

This was a bit scared! I immediately took new measurements with more revolutions. Because I have a visual homepoint on my encoder, I can easily see if there are 75 or 76 pulses per revolution. I have created the test program to run 10 revolutions, or 760 pulses each time. If you use 75 pulses per revolution, the home point is shifted. This way I'm sure my encoder motor really has 76 pulses per revolution. These encoders come from the "ROBO TX Automation Robots" construction kit. The parts list has FT135484. I know there were new encoder motors with 4 connecting wires, so with quadrature encoder. I don't own it, so I can't test it.

I downloaded your lib. That doesn't look very simple. I first have to look at it slowly.
I have just visited, but later more info will follow.

Frans.

[Torsten]

Hi Frans,

I tested the accuracy of the (new) encoder motors as well some time ago:

they give 63 1/3 pulses per revolution. I also observed deviations when setting the distance counters. As Helmut already mentioned, the deviations depend on the friction within the ft-model and thus on the load of the motor. However the measurement of the encoder counters within the TXT is always exact only the starting and stopping of the motor by the internal ROBOPro routines may lead to deviations.
You can easily check that by connecting the counter signal of the encoder motor in parallel to another unused counter input of the TXT and just reading this counter input in parallel (that's what I did and where I observed deviations between the two). I would expect that these values correspond exactly to the values you measure with the FPGA hall sensor.

Best,
Torsten

[fotoopa]

In fact you can retrieve the counted pulses, i.e. the "real" measured distance, in parallel to the active enhanced motor control by reading the counts from the RoboPro CxCounter input elements and update your current position with this value instead of the requested distance. This should improve the position accuracy. However I'm not that sure that direction changes are always handled correctly, even with this approach.

I'm sure it would work perfectly. But I have already provided my FPGA with my own positioning module as an alternative. It only has to be given the new position as a parameter. The deceleration is controlled in the FPGA. If errors do occur, they do not become cumulative. The reading of the counters is always correct as an absolute value. The absolute value is due to a calibration in which the encoder also takes the home point and rotation into account. This calibration is done automatically each time the axis passes over a certain point and in the same direction. In this way, large deviations can never occur and certainly not cumulatively. Speed is never a problem as an FPGA works 1000 times or more faster and everything is processed in parallel. You don't have such a thing as interrupt routines that influence the other tasks. The TXT Controller handles many tasks with intervals of around 5 msec, with an FPGA this is more like 50 nsec but usually I use a clock of 1 MHz or 1usec intervals. The FPGA clock is 50 MHz but any PLL clock can be set to above 300 MHz. For example, my I2C driver in the FPGA works with a 20 MHz clock.

Still, I am looking to use only the TXT controller for certain applications. These would be easier to use for other users. That is why I would still use standard I2C modules such as the colour detector module TSC34725. I have an application to sort color pearls of 10mm. It would be nice if I did not need my FPGA for that. That is my next project. The grandchildren could then select a color and quantity and the pearls would fall into a tray.

Frans.

[fotoopa]

Hi Frans,

I tested the accuracy of the (new) encoder motors as well some time ago:

they give 63 1/3 pulses per revolution. I also observed deviations when setting the distance counters. As Helmut already mentioned, the deviations depend on the friction within the ft-model and thus on the load of the motor. However the measurement of the encoder counters within the TXT is always exact only the starting and stopping of the motor by the internal ROBOPro routines may lead to deviations.

Yes, this is correct. All deviations are caused by starting and stopping. Output loads have indeed a lot of influence on this. Longer or shorter distances have no influence. Unfortunately I did not have a new encoder motor. I also don't know if RoboPro has a lib for a real quadrature encoder. However, I suspect as long as they use edge detection on an interrupt basis that there will always be problems. For years I have worked with quardrature encoders on an industrial hardware basis, EPLD or FPGA even with regular TTL chips in the 1980s. They worked perfectly up to 1 MHz pulses.

Frans.

[fotoopa]

New measurement of the Fischertechnik motor encoder FT134484. For comparison I use my hardware hall encoder via the FPGA. The Ft encoder has 76 cycles/revolution, my hall encoder has 10 cycles but as it uses quadrature detection it corresponds to 40 pulses per revolution. The measurement clearly indicates these values, 76 pulses for the Ft, 40 pulses for the hall encoder.
Results of the logic analyser measurements:


HD version: https://www.flickr.com/photos/fotoopa_hs/28965019107

Frans

[hamlet]

Hi Frans,
This 75 vs. 76 pulse phenomenon is really kind of weird, so I also have done some measurements:

First I requested in a tiny RoboPro program the extended Motor control to drive a distance of 750 pulses and checked the counted pulses provided by the RoboPro Counter input element.
=> The motor does reproducibly 10 revolutions without any visible deviation and the counter input also reports the expected 750 pulses, sometimes 751 … ok.
A 10 count deviation would translate into an obvious 10/75.5*360 = 48° offset. I haven't seen that.
This is absolutely consistent with the ft documentation:

The encoders on the fischertechnik encoder motors generate three pulses with each revolution of the
motor shaft. And because the encoder motors also have a gearbox with a transmission ratio of 25:1
(meaning "25 to 1"), then one revolution of the shaft, which comes out of the gearbox, corresponds to
75 pulses of the encoder.

I have also repeated your independent "logic analyzer" measurement. Ok I took my China scope and a simple one-pulse-per-revolution-reference-encoder, i.e. a ft pushbutton switch as can be seen in the photo, and counted the pulses manually. The motor was running continuously => My result is 75 pulses.

So my encoder does definitely 75 pulses per revolution.

Mhmm, has ft silently replaced the 25:1 by 25 1/3:1 gears? That would be rather mean.

But maybe there's a mechanical problem in your model. The ft encoder is firmly attached directly to the motor shaft, whereas it looks like that your DIY reference encoder is connected via one of those flimsy ft clip couplings to the gears of the motor.

This might cause lots of backlash, from both, the gears and the coupling. This might spoil your measurements when accelerating or braking the motor or even when changing the direction.
But this couldn't explain your 76 counts in your logic analyzer measurement. The pulses are distributed so evenly that I assume that the motor was running at constant speed and that there weren't any backlash caused fake counts. You don’t have any slippage in the drive train?
That's really strange. I would peek into the motor just to see what kind of gears are installed and maybe I would ask ft if they have changed anything.
Kind Regards,
Helmut

[fotoopa]

Hi Helmut,
Many thanks for your new measurements. This morning I took new measurements with both the LA and the scope. I had told you that there was an anomaly, my homepoint was always shifting. even with 76p/turn. To have no more errors at 100 revolutions, I need to enter 76,1666p in the TXT, so 7616 p/100 revolutions. With the scope I can make measurements over 6 revolutions. This brings me to 457 pulses of the TXT Controller. The sync is done with the hall detector homepoint. There is no friction, the encoder distance is 1.5mm.
I have 2 encoder motors (FT135484) and have now measured both of them. The results are the same. I also tested it at lower rotation speeds, even then the results remain constant.
All measurements are made during constant rotation, there are no start or stop periods in the measurements and there are no changes in friction. The encoder for the hall detectors is simply placed on a shaft directly on the motor. As shown in my previous images. I have no explanation for this peculiar value, but 75p is not correct with my encoder motors.

I can follow the real rotation visually via the homepoint. If the hardware counter shows too few impulses, you will see that the disk had too little rotation. If you manually rotate the disk until the homepoint is in the correct position, the hardware counter will give the correct value. My encoder motors were recently purchased (22 Apr 2018) via Amazon.

Because I also had position problems with the robot kit, I controlled the motors from my own hardware. The commands were then transmitted via the I2C connection.
Start, stop and back-slash for the Motors were arranged in the FPGA. If the direction was negative, I first went a little further negative, then again in the other direction. This function was automatically included in the FPGA for each motor. There were adjustable parameters for the distance, and speed control.

Update:
After many tests I still found the exact value to use (I suppose) for the encoder motor FT135484. The real value I measure is 76,16666 pulses per revolution. This perfectly matches my own hardware quadrature encoder mounted on the motor. After 200 revolutions, the error is still zero. I still don't understand how Fischertechnik comes up with this 76,1666 value. But all measurements point in the same direction. I tested 2 different motors, with different set speeds. Every time I arrive at the same results. Even with measurements over very long periods, the results remain the same.
Test setup program:



Frans.

[hamlet]

Hi Frans,
The description of your measurement sounds absolutely reasonable. But a gear ratio of 76.1666...? That looks like 76 1/6 and that is 457/6, where 457 is prime! That's hard to believe. Maybe I'm wrong but a 457 teeth gear would either be too large or too expensive for the ft encoder motor gearbox.
Maybe there's type ID or even a gear ratio printed on the motor or its gearbox. The housing is not that difficult to open, I would have a look.
Kind Regards,
Helmut

[fotoopa]

Hi Helmut,
I got the motor open! Tomorrow I'm going to post a series of photos. It is quite difficult to take pictures.
However, I do have some data:
There is a pcb circuit at the back of the motor. On the end there is a small round black disc completely cast in plastic. With a small screwdriver I find 6 magnet poles. The PCB is equipped with an SMD 504K hall chip. I have already found the datasheet, it just works between 3.8 and 24V. The output is an open collector type.
The motor is labeled : KM-20A130F-25.4 09327
P/N No: 137100/135484 --> he this is the FT nr!
KINMORE 20150514 (production date?)
Body motor has an nr 1411008

I had expected 6 magnets, motor reduction could be 25.4
The pulse calculations = 25.4*6 = 152.4 / 2 = 76.2
Tomorrow I will post more data, now it is too late to make a full report. For some parts I look under the microscope with 30x magnification!

So the real encoder pulses are 76.2/turn.
If just found a KINMORE pdf file with the motors.

Frans.

[fotoopa]

I took some pictures of the Fischertechnik encoder motor FT135484.

Bigger format: https://www.flickr.com/photos/fotoopa_hs/43941681551


Bigger format: https://www.flickr.com/photos/fotoopa_hs/43893298022

There is a magnetic disk mounted on the shaft. At the bottom of the PCB is the Hall chip 504A. This gives 3 pulses per motor rotation. With the resuction of 25.4, the number of pulses per revolution of the output shaft is reduced to 76.2 pulses/rev.
This probably solved the questions about the number of pulses of the encoder, i.e. 76.2 P/T.

Specs:
KM-20A130F-25.4 09327
P/N No: 137100/135484
KINMORE 20150514
Body motor nr 1411008
Motor reduction: 25.4
Encoder pulses: 25.4*3=76.2
Encoder motor type FT:135484

Update:
However, I still have to remark that my measurements with 76.2 have a small deviation. With 76.16 I don't have that mistake. It could be that the motor reduction value is actually rounded off and therefore slightly lower. In a test with 30480 pulses, an error of 13 pulses was measured. With 30467 (76.1666 x 400) pulses the error is null. Smaller distances give proportional results. The error is therefore not caused by starting and stopping.

Frans.