fischertechnik community forum

Hallo zusammen,

ich habe folgende Frage: Wie gut passen der neue Robo TXT Controller und der TX Controller zusammen? Lassen sie sich ähnlich wie zwei TX Controller koppeln, damit man sie für größere Modelle einsetzen kann? Könnte man beispielsweise einen TXT Controller als Master definieren und einen TX Controller gleichzeitig als Extension?

Vielen Dank im Voraus
David

Hallo!

Nein das geht nicht.
TX und TXT sind zwei unterschiedliche Systeme.
Du kannst nur in RoboPro mehrere Controller gleichzeitig ansprechen, also ohne das die gekoppelt sind.
Das geht aber nur im Online-Betrieb.
Koppeln kannst Du nur TX untereinander, oder nur TXT untereinander.
Wobei man ja beim TXT max. 1x Master und 1x Slave nutzen kann.

Gruß
Sven

Hi,

eventuell geht ja später auch mal was über I2C oder BT, wird aber sicher noch dauern.

Gruß,
Thomas

Danke für eure Antworten!

Wobei man ja beim TXT max. 1x Master und 1x Slave nutzen kann.

Alles andere wäre auch etwas kostspielig
Ein günstigeres Erweiterungsmodul wie die alte I/O Extension wäre für große Modelle sehr praktisch...

Gruß, David

Auch wenn der Thread schon etwas älter ist; Es wäre wirklich an der Zeit, dass Fischertechnik das Problem löst. Immerhin ist das letztlich ein ganz triviales Softwareproblem, denn der TXT hat ja einen USB-Hostanschluss. Es ist kaum nachzuvollziehen, dass hier keine älteren Interfaces anzuschließen sind - hardwaretechnisch wären alle Fischertechnik Interfaces seit dem Intelligenz Interface abschließbar, sie würden aus ihrer Sicht schlicht im Onlinemodus laufen. Es wäre bloß eine entsprechende Einbindung in der Firmware erforderlich - und ggf ein USB-Hub.
Ganz nebenbei dann noch Unterstützung des Interfaces des 3D-Druckers, um den aus dem Stand-alone Nieschendasein herauszuholen und die Schrittmotoren auch in anderen Modellen nutzbar zu machen.
Fischertechnik könnte ja auch noch einen andockbaren USB-Hub auf den Markt schmeißen, Abmessungen 9*3*1,5, der direkt an den TXT angesteckt wird und aus der gleichen 9V-Quelle gespeist.

Hallo Andre,

Andre hat geschrieben:Auch wenn der Thread schon etwas älter ist; Es wäre wirklich an der Zeit, dass Fischertechnik das Problem löst. Immerhin ist das letztlich ein ganz triviales Softwareproblem, denn der TXT hat ja einen USB-Hostanschluss.

Naja, auch unter Linux müßte ein Hardwaretreiber dafür entwickelt werden - daß das da irgendwie besonders einfach wäre, habe ich noch nicht gehört. Davon abgesehen ist USB in einem ft-Modell ein sperriger Fremdkörper.

Ich frage mich eher, warum man diese roten Erweiterungsmodule mit ihrer I²C-Anbindung nicht gangbar gemacht hat und ft sie nicht einfach weiterhin produziert und verkauft. Wegen des TXT-Controllers müßten sie allerdings heute auch mit 3 V auf dem I²C-Bus klarkommen. Diese starke Erweiterbarkeit des damaligen Basismoduls war doch einfach nur genial. Gibt es eigentlich etwas Vergleichbares als I²C-Modul, selbst wenn dann nur ein oder zwei Ausgänge für Gleichstrommotore und weniger Eingänge verfügbar sind? In jedem Falle müßte ft hier softwareseitig nur auf eigene Kompetenzen zurückgreifen und halt sog. ROBOPro-Treiber, also zweckmäßige I²C-ansprechende Unterprogramme mitliefern.

Andre hat geschrieben:Ganz nebenbei dann noch Unterstützung des Interfaces des 3D-Druckers, um den aus dem Stand-alone Nieschendasein herauszuholen und die Schrittmotoren auch in anderen Modellen nutzbar zu machen.

Lt. c't-Test (c't 26, S. 60 f.) gibt es eine Anwendung für die Community-Firmware, die auf der Basis des TXT-Controllers dann auch Standalone-Betrieb und Nutzung von SD-Karten erlaubt.

Andre hat geschrieben:Fischertechnik könnte ja auch noch einen andockbaren USB-Hub auf den Markt schmeißen, Abmessungen 9*3*1,5, der direkt an den TXT angesteckt wird und aus der gleichen 9V-Quelle gespeist.

Och nö. Bitte nicht nur an die Erbauer stationärer Industrie-Simulationen denken, sondern auch an mobile Roboter, die aus dem Akku leben müssen. Und der ft-Akku hat gerade mal die halbe Kapazität von dem eines leistungsfähigen Smartphones. Da wüßte ich BTW gerne mal, ob ich die im Betrieb, also beim Entladen parallelschalten darf. Beim Laden dürfte es selbstverständlich nicht gehen, es sei denn, die Ladeschaltung befindet sich im Akkupack selbst - was schlauer wäre.

Mit freundlichen Grüßen
und den besten Wünschen für ein schönes Weihnachtsfest
Lars

Der USB-Anschluss von Intelligent-Interface, Robo Interface, Robo TX und TXT ist gegenüber dem Host ein USB-Seriell-Wandler. Wird bei Anschluss an Windows PCs daher auch als Com-Schnittstelle angezeigt. Da braucht niemand mehr einen Treiber zu entwickeln, die verwendeten USB-Seriellchips werden bereits unter Linux unterstützt.
Das einzige, was fehlt, ist die Möglichkeit, vom TXT aus die passenden Steuerbefehle und Abfragen über diese Schnittstelle zu senden. Das ist aber nicht Treiberebene, sondern Anwendungsebene.

Die roten Extensions sind nicht i2c, sondern SPI (RS485 mit Adressierung). Ganz andere Adress- und Übertragungslogik. Gilt übrigens auch bei TX zu TX und TXT zu TXT, dass SPI eingesetzt wird - allerdings jeweils mit unterschiedlichem Protokoll bzw Detailausgestaltung. Für RoboExtension an TX hat immerhin jemand eine TX-Bridge entwickelt.

Per i2c kann man fast alles realisieren - ein Arduino Mini kostet mit Versand aus China ca 1,70€, eine Doppelte H-Bridge (4-Lampen bzw. 2 Motorausgänge) ca. 1€. Den als i2c-Slave programmiert, und schon hat man eine halbe Extension. Das Aufwändigste wäre, die Symbole für RoboPro zu malen - das teuerste die 2,6 mm Zwergbuchsen.

Finanziell und funktionell zwar interessant, aber massentauglich? Wohl eher nicht, denn wer so in die Mikroelektronik einsteigt, braucht eigentlich weder TX, noch TXt usw.

TX, TXT und RoboInterface ziehen nur den Strom für den USB-Seriellwandler aus der USB-Schnittstelle. Wir reden also von wenigen mA.

Der Vergleich der Akku Kapazität hinkt, weil "Kapazität" nicht die Energie, sondern nur die Ladung bezeichnet. 8,4 V bei 1500 mAh wären, wenn man den Spannungsabfall vernachlässigt, 12,6 Wh. Smartphones laufen mit 3,7V Nennspannung. Der Spannungsabfall ist bei den LiPos aber deutlich größer als bei NiMh. Rein praktisch haben ein 4000mAh LiPo mit 3,7V Nennspannung für Smartphones und die 1500mAh NiMh mit 8,4V Nennspannung annähernd die gleiche Energie.

Parallelschaltung beim Entladen ist bei NiMh eigentlich kein Problem, solange es nicht darum geht, den maximalen Entladestrom erhöhen zu wollen. Übrigens auch beim Laden nur etwas nachteilig für die Lebensdauer der Zellen, aber nicht tödlich für den Akku.

Bei Stand-alone Nieschendasein hast Du mich Missverstanden. Es geht nicht um Stand-alone-Betrieb, sondern darum, dass das Set "3DDrucker" alleinstehend neben der übrigen Fischertechnik steht, da man die teuersten Komponenten für nix anderes als 3d-Druck einsetzen kann. Beim Extruder noch verständlich, aber wieso kann man die Schrittmotoren nicht in eigenen Modellen einsetzen und den Controller des 3D-Druckers als reine "Extension" zur Ansteuerung der Schrittmotoren nutzen?

Moin,

das Robo-Interface nutzt - genauso wie die I/O-Extension und der LT-Controller - *keinen* virtuellen COM-Port über USB sondern einen eigenen Treiber.
Die Übertragung zwischen TX Master und Extension geschieht *nicht* per SPI, sondern RS-485. Auch beim TXT ist *kein* SPI im Master/Extension Betrieb beteiligt.
Richtig ist, dass die Robo IO-Extensions eine synchrone serielle Übertragung nutzen (siehe http://ft-fanpage.de/roboint-old/roboext.html) durchaus mit SPI vergleichbar.
Weder in TX, TXT noch in Robo-Interface sind "USB-Seriellwandler" verbaut, sowas gibt es nur bei Arduino
Außerdem hat SPI mit RS485 nichts zu tun, das sind zwei völlig unterschiedliche Übertragungswege.

Hallo Andre,

Andre hat geschrieben:Per i2c kann man fast alles realisieren - ein Arduino Mini kostet mit Versand aus China ca 1,70€, eine Doppelte H-Bridge (4-Lampen bzw. 2 Motorausgänge) ca. 1€. Den als i2c-Slave programmiert, und schon hat man eine halbe Extension.

Schon klar, aber eigentlich nutze ich ft, um sozusagen von handwerklichem Geschick und auch viel Zeitaufwand absehen zu können. Als Jugendlicher habe ich viel gelötet, aber ich habe keinerlei Werkzeug und womöglich auch nicht mehr das Geschick bzw. die Geduld für die heutigen SMD-Bauteile. Da bin ich vermutlich nicht der Einzige, genau das bringt ja Angebote wie beispielsweise die "Breakout-Boards" von Adafruit auf den Plan, die könnte ich mit meinen Mitteln verarbeiten.

Andre hat geschrieben:TX, TXT und RoboInterface ziehen nur den Strom für den USB-Seriellwandler aus der USB-Schnittstelle. Wir reden also von wenigen mA.

Zu den USB-Seriell-Wandlern hat Dir thkais bereits geschrieben. Unabhängig davon paßt USB aber auch räumlich nicht gut in ft-Modelle.

Andre hat geschrieben:Der Vergleich der Akku Kapazität hinkt, weil "Kapazität" nicht die Energie, sondern nur die Ladung bezeichnet. 8,4 V bei 1500 mAh wären, wenn man den Spannungsabfall vernachlässigt, 12,6 Wh. Smartphones laufen mit 3,7V Nennspannung. Der Spannungsabfall ist bei den LiPos aber deutlich größer als bei NiMh. Rein praktisch haben ein 4000mAh LiPo mit 3,7V Nennspannung für Smartphones und die 1500mAh NiMh mit 8,4V Nennspannung annähernd die gleiche Energie.

Ok, hier war ich nachlässig und hinsichtlich des mobil verfügbaren Energiegehaltes sieht es besser aus als von mir dargestellt. Allzu rosig ist es aber nicht, denn selbst die Spannung des voll geladenen Akkus bewegt sich für den TXT-Controller im unteren Bereich des Erforderlichen.

Andre hat geschrieben:Parallelschaltung beim Entladen ist bei NiMh eigentlich kein Problem, solange es nicht darum geht, den maximalen Entladestrom erhöhen zu wollen.

Es geht mir dabei lediglich um eine Kapazitätserweiterung mit parallellaufender Entladung beider Akku-Packs. Es ist unpraktisch, wenn mal der eine und mal der andere nachgeladen werden muß, weil sie unterschiedlich "durstige" Verbraucher versorgen. Da aber weder zwei Zellen und erst recht keine zwei Akku-Packs exakt gleich sind, könnte es doch dazu kommen, daß der etwas stärkere den etwas schwächeren lädt, wenn auch vielleicht nur ganz langsam. Vielleicht sollte der Modell-Hauptschalter sie elektrisch voneinander trennen, wenn ausgeschaltet wird.

Andre hat geschrieben:Übrigens auch beim Laden nur etwas nachteilig für die Lebensdauer der Zellen, aber nicht tödlich für den Akku.

An einem zweiten Ladegerät bzw. einem zweiten Akku-Set anstelle von lediglich einem weiteren Akku als Einzelteil soll es natürlich nicht scheitern.

Andre hat geschrieben:Bei Stand-alone Nieschendasein hast Du mich Missverstanden. Es geht nicht um Stand-alone-Betrieb, sondern darum, dass das Set "3DDrucker" alleinstehend neben der übrigen Fischertechnik steht, da man die teuersten Komponenten für nix anderes als 3d-Druck einsetzen kann. Beim Extruder noch verständlich, aber wieso kann man die Schrittmotoren nicht in eigenen Modellen einsetzen und den Controller des 3D-Druckers als reine "Extension" zur Ansteuerung der Schrittmotoren nutzen?

Für die Schrittmotoren würde ich dann lieber auf Elektronik z.B. von Adafruit zurückgreifen, der Controller des 3D-Druckers ist einfach monströs flächig.

Mit freundlichen Grüßen
Lars

Andre hat geschrieben:... da man die teuersten Komponenten für nix anderes als 3d-Druck einsetzen kann. Beim Extruder noch verständlich, aber wieso kann man die Schrittmotoren nicht in eigenen Modellen einsetzen und den Controller des 3D-Druckers als reine "Extension" zur Ansteuerung der Schrittmotoren nutzen?

Wieso kann man das nicht? Was hält Dich davon ab, die Schrittmotoren in ein anderes Modell einzubauen und dann mit dem 3D-Controller vom TXT aus zu steuern? Technisch steht dem nix im Wege: https://www.youtube.com/watch?v=f048F6rwEW4 Einen per 3D-Controller gebauten Roboterarm zu bauen und am TXT zu betreiben ist prinzipiell möglich.

Man könnte FT höchstens vorwerfen, dass sie generell nicht bewerben, dass man auch Ihre Elektronik-Konponenten (TX, TXT, RoboLT, Print-Controller) frei kombinieren kann. Aber wenn sie das täten würde hire wahrscheinlich der Unmut über fehlenden Modellbeispiele recht groß sein ...

Lars hat geschrieben: Für die Schrittmotoren würde ich dann lieber auf Elektronik z.B. von Adafruit zurückgreifen, der Controller des 3D-Druckers ist einfach monströs flächig.

Hast Du jemals einen gesehen? 15 x 9 cm ist der groß. "Monströs flächig"? Hast Du Fotos von Deiner Adafruit-Lösung? Wieviel kleiner ist die denn?

thkais hat geschrieben:Moin,
das Robo-Interface nutzt - genauso wie die I/O-Extension und der LT-Controller - *keinen* virtuellen COM-Port über USB sondern einen eigenen Treiber.

O.K., beim alten Robo-Interface habe ich das noch nicht nachgeprüft, vom Aufbau sah es mir aber ziemlich nach einem Chip aus - wäre da aber egal, da das Robo-Interface auch einen RS232-Eingang hat, also jederzeit per USB-Serielkabel angesprochen werden kann, also auf jeden Fall mit einem virtuellen-Com-Port lauffähig ist.
Der Robo TX nutzt definitiv eine USB-Serielwandlung - einfach mal unter Windows die Treibereigenschaften anschauen, da steht unter Treiberdetails "usbser.sys". Der "Treiber" ist nur die .inf, welche die normale, bei Windows mitgelieferte usbser.sys für das Gerät läd und den Namen im Gerätemanager setzt.
USB-Vendor-ID und Geräte-ID sagen erstmal nichts über das Protokoll aus, es kann dahinter auch ein Standard USB-Seriellkonverter stehen. Übrigens auch bei Arduinos, der Leonardo ist im ATmega32u4 eine USB-Schnittstelle integriert, welche sich softwareseitig sowohl als Serielle USB-Schnittstelle, aber auch als HID-Device nutzen lässt. Ob es ein physikalisch getrennter Konverter oder eine Softwareemulation eines solchen Chips im eigentlichen Controller ist, ändert nichts daran, dass die Schnittstelle extern per USB-Serielltreiber ansprechbar ist. Zumindest beim hier angesprochenen TX-Controller ist es definitiv so, dass windowsseitig die usbser.sys verwendet wird - und damit auch unter Linux ein entsprechender äquivatenter Treiber verfügbar ist.

Meine Ergänzung um die RS485 hatte sich mit der Antwort überschnitten, ich war erst gedanklich nur bei der Verbindung zur Robo I/O. War etwas unglücklich flasch formuliert und nicht vollständig überarbeitet.


Für die Nutzung von i2c muss man nicht SMD löten (allenfals die Steckleisten an den Arduino mini, aber man kann auch einen nano nehmen, an dem eine USB-Seriell-Schnittstelle und die Leisten schon dran sind) - die Preise sind für fertige Breakout-Bords, die Stiftleisten bzw. Anschlussklemmen haben. Sie werden eben nur nicht als als teures Aufsteckboard, sondern eben zum Verbinden mit Dupond-Kabeln geliefert.

Aber eben, weil selbst dass nichts für jeden ist, meine ich, dass Fischertechnik in den TXT eine Möglichkeit vorsehen sollte, dass man per USB andere Interfaces wie eine Extension ansprechen kann. USB würde ich inzwischen auch nicht mehr als fischertechnikfremd einstufen, seitdem Fischertechnik beim TXT für alle möglichen Sensorfunktionen in eine USB-Cam verwendet.

Dass USB räumlich nicht ideal ist, ist klar - deshalb auch mein Wunsch nach einem eigenen USB-hub in einem Fischertechnik Gehäuse.

Was die Akkus angeht: 7 NimH Babyzellen in zwei alte, miteinander verbundene Babyzellenhalter. Am günstigen bekommt man die Zellen aus Racings-Packs für ca. 13€ aus China (6 Zellen je Racing-Pack). Da kann man dann 5000 mAh nutzen. Ist natürlich sprerriger und hat mehr Gewicht. Alternativ geht ggf. auch LiIon oder LiPo, man braucht wegen des doch sehr starken und schnellen Spannungsabfalls aber einen Drop-DownConverter mit geringem Energieverlust. Außerdem ein spezielles Ladegerät fürs Load-Balancing. Man darf nicht auf die Akkus für Fahradbeleuchtung reinfallen - 8,4V liefern die nur 9 Minuten lang, dann gehts rapide auf ca. 7V runter. Man müsste die Zellen anders anordnen, und 12,6 V Spitzensannung haben - was ein Lowdrop DC-DC-Konverter erfordert.

Bezüglich der Größe müsstest Du den 3D-Controller mit den ansonsten benötigten 2 Extensions vergleichen - 4 Schrittmotoren * 4 Ausgänge = 16 Ausgänge, die geschaltet werden. Da ist der Fischertechnik 3-d-Controller echt kompakt, vor allem, da die Schrittmotoren eine höhere Leistung erfordern.

i2c-Selbstbauextensions mit gleicher Ausgangsleistung wie die orgiginalen Controller passen zusammen mit einem Arduino Mini in eine 60*60*30 Teilebox. Allerdings hat man nur 6 PWM-Ausgänge, zwei wären nur an/aus (wobei: eigentlich reichen auch 4* PWM für 4 Motoren, wenn je Motor nur ein Anschluss PWM-moduliert wird, um die Geschwindigkeit zu regeln - man müsste die Ansteuerung nur so machen, dass bei umgekehrter Laufrichtung der Wert des PWM-Anschlusses invertiert wird). Will man (für Schrittmotoren) eine höhere Ausgangsleistung, so wird es aber eng in der Teilebox, da braucht man eine je Schrittmotor.
Wie gesagt, alles steck-, schraub und ggf. quetschbar, ganz ohne Löten, wenn man möchte. Etwas Bohren/Sägen im Deckel der Teilebox, für die Anschlüsse, ist das Aufwändigste. Etwas Heißkleber oder Epoxydharz zum Fixieren der Platinen. Das Warten auf die Teile aus China das langwierigste. Meine Arduino Minis sind noch auf dem Weg...

Nichtsdestotrotz: In die Firmware des TXT gehört das Ansprechen älterer Kontroller, um sie ohne Bastelarbeit als Extension nutzen zu können.

Hallo MasterOfGizmo,

MasterOfGizmo hat geschrieben:Hast Du jemals einen [Controller der ft-3D-Druckers] gesehen? 15 x 9 cm ist der groß.

Ja, das ist zumindestens für viele mobile Modelle recht groß. Und wenn es nur um die Ansteuerung eines Motors geht, ist es sogar besonders groß.

MasterOfGizmo hat geschrieben:Hast Du Fotos von Deiner Adafruit-Lösung? Wieviel kleiner ist die denn?

"Meine" Adafruit-Lösung habe ich noch nicht gefunden. Ich wünsche mir eine Lösung, die den Raum von vielleicht zwei BS30 einnimmt und jeweils einen einzigen Motor treiben muß. Man könnte dann eine busförmige und dadurch einfachere Verkabelung von Treiberbaustein zu Treiberbaustein führen, nämlich den I²C-Bus des TXT-Controllers und die 9V-Stromversorgung, aus der sich auch die Treiberlogik speisen sollte. Diese Lösung sollte natürlich auch die ft-Encodermotore abdecken.

Das wäre für mich eine smarte, weil stärker ausbaufähige und zugleich strom- und platzsparendere Alternative zum Erwerb eines weiteren TXT-Controllers. Mit einem weiteren TXT-Controller käme ich bei meinen Plänen zwar über die Runden, aber er wäre unterfordert und würde unnötig viel Strom verbrauchen - von so kleinen Lästigkeiten wie dem auch nicht unerheblichen Platzbedarf und dem separaten Einschalten mal ganz abgesehen.

Mit freundlichen Grüßen
Lars