ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
gunnersson
Beiträge: 19
Registriert: 01 Jul 2016, 17:56

ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von gunnersson » 05 Jul 2016, 05:16

Moin,

noch bin ich recht neu hier im Forum und ich habe mich gerade erst wieder ft zugewandt: ich fand die Murmelbahnen einfach zu nett und habe mir Dynamic S für meinen Schreibtisch gekauft. :-)

Wie meine anderen beiden Themen schon andeuten, möchte ich wieder ft aufleben lassen und damit spielen. Und zwar mit meinem Computing Baukasten und dem Trainigsroboter.

Vom Computing Baukasten habe ich noch das alte ft Universal Interface. Und die Schrittsteuerung beim Trainigsroboter lief mittels Lichtschranken mit Impuls-Rädern. Die Räder hatten 64 (2*32) oder 32 (2*16) Balken, das weiß ich jetzt gerade nicht. Mit dem alten Interface klappte das.

Aber ich habe irgendwo --- leider habe ich keinen Link mehr --- eine Information gefunden, dass das so mit neueren Interfaces nicht mehr klappt. Ich kann mich jetzt allerdings nicht erinnern, ob TX oder TXT. Gibt es zwischen TX und TXT einen Unterschied bezüglich "schneller" Zähler?

Und wie funktionieren die Encoder-Motoren allgemein? Der zusätzliche Impuls-Ausgang erinnert mich an meine Lichtschranken. Wie viele Impulse/U geben die denn? Wie harmoniert das mit den Interfaces (Universal, TX, TXT)?

Das sind so die Fragen fürs Erste... Lohnt es sich, nach den wesentlichen Unterschieden zwischen TX und TXT zwecks einer Neuanschaffung zu fragen?

Danke für Eure Antworten und viele Grüße,

Gunner

vleeuwen
Beiträge: 1067
Registriert: 31 Okt 2010, 22:23

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von vleeuwen » 22 Aug 2016, 23:53

The old computer interface was able to deal with a higher sample rate then the new one's.
The actual sample rate is 10 ms. This means that the number of count pulses per second can not be to high.
If the frequency of the pulses is too high. the interface will not notice it.

Benutzeravatar
ski7777
Beiträge: 831
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von ski7777 » 23 Aug 2016, 00:04

Schade, dass ich diesen Thread übersehen habe und du nun schon so lange auf eine Antwort warten musstest.

Am TX und am TXT sind die Eingänge C1 bis C4. An diesen kannst du ganz normale Taster, Lichtschranken und auch Encodermotoren anschließen. Die Eingänge können bis zu 1000 Impulse pro Sekunde empfangen. Die Encodermotoren sind ganz normale Motoren, welche pro Umdrehung 78? Impulse über einen Inkrementalgeber an den TX oder TXT sendet. Ob du nun den TX oder den TXT nutzt, ist für die Motoren vollkommen egal.

Für dich als OpenSourceentwickler wäre natürlich der TXT mit der Community Firmware perfekt.

Raphael

vleeuwen
Beiträge: 1067
Registriert: 31 Okt 2010, 22:23

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von vleeuwen » 23 Aug 2016, 11:26

C1..C4 is an internal counter. The puls events are not external real time available, only the black box.
The results are only asyncronous (like a black box).
And not usable in closed control loops.
This techniques has more to do with control engineering then with programming.

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

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von hamlet » 23 Aug 2016, 15:33

EDIT
Hi Gunnar,
MasterOfGizmo hat in seiner kurzen und prägnanten Antwort zu Deiner ursprünglichen Frage absolut recht: Die erweiterte Motorsteuerung ist wahrscheinlich genau das, was dir weiterhelfen könnte. Mein Beitrag hier ist eher "off topic". Kiek doch mal in die RoboPro Hilfe Kapitel "12.6 Schnelle Zähleingänge und erweiterte Motorsteuerung".
Beste Grüße,
Helmut
Hi vleeuwen,

I think your statement is a bit too general.

In RoboPro the "fast counter" values are available via the RoboPro Input interface element. On the TX in Offline mode the 4NetOS operating system (It claims to be a Real Time Operating System (RTOS)) executes the RoboPro user code once per millisecond with relatively low jitter. RoboPro's timer variables provide a resolution of one millisecond. Both, the timers and the counters, are updated in each 1ms time slice the user code is executed. Based on this it is indeed possible to implement e.g. a motor speed closed control loop (CCL).

In fact I did this and it worked quite well. (Unfortunately it was my very first CCL programming attempt and I was new to RoboPro. I have never refactored that stuff nor have I documented it and thus I have never published it.)

Of course it didn't run satisfactorily in "online" mode due to the large latency and jitter added by the PC-TX-communication.

On the TXT the story is a bit different. The Linux based OS executes the RoboPro code in offline mode with a period of 10ms on average and I'm afraid that this period shows a rather large jitter: viewtopic.php?f=8&t=3312&p=22998#p22998 . Also the timers, RoboPro's new "time input" and the "timer variables", exhibit some unpredictable and inconsistent behavior: viewtopic.php?f=21&t=3315&p=23019#p22579

Here I agree that it will be hard to get some quickly responding CCL stuff running stably.

Best Regards,
Helmut
Zuletzt geändert von hamlet am 23 Aug 2016, 16:40, insgesamt 1-mal geändert.

Benutzeravatar
MasterOfGizmo
Beiträge: 1804
Registriert: 30 Nov 2014, 07:44

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von MasterOfGizmo » 23 Aug 2016, 16:15

The TXT can run endoder motors a given distance. Assuming that the distance is maintained on the motor board this should be exactly what you are asking for and would neither involve the Linux based main CPU nor would you have to code any control loop in robopro.
ftDuino, der Arduino für fischertechnik: http://ftduino.de

vleeuwen
Beiträge: 1067
Registriert: 31 Okt 2010, 22:23

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von vleeuwen » 24 Aug 2016, 17:31

@Hamlet,
My point of view has been based on the API and the transfer area description.
The information about the OS is very limited.
There are some doubts about the real time implementation.
One CPU has to do all the work, not only sampling the inputs bat also take care of the communication.
The sample rate internal is 1 ms. however to reach the maximum speed, the shape of the input signal needs to be symmetrical.
With the fischertechnik switch and pulse wheel this is not the case.

gunnersson
Beiträge: 19
Registriert: 01 Jul 2016, 17:56

Re: ft Univ. Interf. vs TXT / Lichtschr. vs Encoder-Motoren

Beitrag von gunnersson » 17 Sep 2016, 12:16

Vielen Dank für alle Antworten! :-)

Antworten