fischertechnik community forum

Hi, I have connected 3 TX controllers and 1 TXT controller via USB within RoboPro. I can run both the TX and the TXT commands in 1 program. But what I am unable to do, is gettting the i2c displays I have working. Both the TX and the TXT are set as the main controller and I suspect that something is going wrong there, but you have to set it this way otherwise you cannot operate them in 1 program (In Online mode).

Does anyone have an idea if it is possible to get the i2c displays working in this setting? If I only use the TX controllers, with the FT-extender, the displays work fine.

Thanks in advance!

Hi Mark,

Could you please share more details how you connected the TXTs with each other?

Do you use the extension port to connect some slave TXTs to a master and did you connect the master to your PC?

Or do you connect all TXTs to the PC and there is no interconnection between the TXTs.

Did you ever tried to run your program in offline more / without a PC connected?

Best regards

Stefan

Hi Stefan,

I connected the 3 tx controllers (1 master, 2 slaves) with cables with each other via the EXT port. Also on the TX Master i have connected the FT-extender. The master is connected via USB on my PC.
The TXT is also connected on my PC with USB.

This works well, i can run all programms in online mode and in Offline mode. When i have not connected the TXT, so just a program for the 3 TX controllers, the I2C displays work fine in online (for testing, slow) and in download (quick).

Only when i add the TXT, the i2c display don't respond/work. Maybe because there is one TX in master mode and one TXT in master mode at the same time?

See also this post: https://forum.ftcommunity.de/viewtopic. ... %3F#p60243

Kind regards, Mark

Hi Mark,

I never tried this combination.

My first idea was, you tried to connect TX and TXT with a ribbon cable and/or ftextender. In that case you would block the i2c bus on a hardware level. But TXT is connected via USB. Fits to your referenced ftc forum topic.

Beside i2c, you're fixed in that setup to online mode. Your PC is the bridge to both sides.

Running the TX part offline on the TXs including i2c seems to be fine. That's expected, because you're in one ecosystem.

Looking at the online mode using i2c. There had been some guys decoding the protocol. It seems, that robo pro is completely running on your PC, just sending io commands via USB to your controller.

I2c is the same. Just an io command.

In case of motor commands, the robopro command knows the port (and the controller where the port is). So it's easy to send the io command to the correct controller via USB.

But with the i2c commands there is no choice which controller should be used. From a logical point of view, robopro has to decide if it uses the TX or the TXT. If it sends the io command to the TXT your programm will fail.

It's not proven or tested. Just an idea.

Connect an i2c device to the TXT. Run a dry run just using the TXT only. If all is good, connect a TX as well. Try i2c via TXT and an use a tx motor output as well.

Hope this helps,

Stefan

Hi Stefan,

Thank you, that sounds as a possibility. I'll try that. First I have to order some cables somewhere to connect the ft extender to the TXT. I'll let know when I have them and tried

Kind regards, Mark

On the TXT the I2C interface has been implemented as a SLI.
De SLI manager knows a issue: it stop working after 4 to 5 secs inactivity.
A dummy "keep alive" process will resolve this problem.
See old publications about this issue and also:
https://forum.ftcommunity.de/viewtopic. ... I+2#p64668
and
https://github.com/fischertechnik/txt_d ... own-issues
under "known issues"

The I2C implementation on the TXT is also not so fast and always working with 400Khz clock.

Also don't forget that the signal level is 3.3V and the connector doesn't offer 3.3V power supply.
And it is also "not 5V" tolerant, be aware of this.

With the TXT, probably the I2C interface SLI runs only on the master and not on the slaves.

The original thread is in English. I’ll chime in here with something that hopefully isn’t too far off-topic...

I’m comparing the (historical) I2C pinout and voltages of the TX, TXT, and, for example, the ftExpander with the pinout (or “connector orientation”) of the TXT4.0. I’m doing this because I want to create a 6-pin (2x3) Dupont connector for this that’s as practical as possible for my current development project. Of course, there’s the choice between 5 volts (TX and ftDuino) and/or 3.3 volts (TXT and TXT 4.0), but there’s also something else that stands out to me and confuses me.

On the flat cable Dupont connectors, the odd-numbered pins (1, 3, and 5) are on the side of the notch that prevents reverse insertion. This was always (for TX, ftDuino, and TXT) the GROUND. So GROUND is on pin 1 and the + (5 or 3.3 volts) is on pin 2. See the pinout for the TX, ftDuino, and TXT in the images below. This actually resulted in the counterintuitive phenomenon where the first wire of the flat cable, marked in red, on pin 1 was actually ground instead of the more intuitive positive terminal.


However, the connector on the TXT 4.0 appears to have been flipped along its longitudinal axis. Pin 1 (the red, marked, wire of the flat cable) is now actually the positive terminal. This means that SDA and SCL have also been reversed!


Am I misunderstanding something, or is it true that sensors cables or, for example, cables to the ftExtender—which used to be compatible with the TX, ftDuino, and TXT—can no longer be connected to the TXT 4.0 without further ado? And that anyone who wants to use the ftExtender with the TXT 4.0, for instance, needs a (mirroring) converter for this?

In Richard’s photo (https://forum.ftcommunity.de/viewtopic.php?f=8&t=9650), I think I see something like that; I’ll ask him the question as well because I’m now unsure which connectors—and consequently which pinout—I should choose.

To avoid confusion when connecting, I’m now leaning toward choosing the same connectors I’ve already used on previous modules (including my ‘Zauberling’). After some research, I opted for the (at least in terms of pinout) compatible ‘Grove/Seeed’ 4-pin JST-PH connectors. Since they take up relatively little space, they could then be used directly for 5 and 3.3 volts, respectively.

Finally... I see there’s a lot of ftExtender expertise here (I don’t own one myself, and I see that the documentation was last updated in 2018, before the TXT 4.0 was released). I’ve gone over the website, GitHub, manual, and the article in ft:pedia 2/2018 again, but I still don’t understand what the three “shields” in the 14-pin connectors are for. Is this some kind of block to prevent certain connectors from being plugged in? It’s not a big deal, but maybe someone knows why this is in the product photo and whether it serves a practical purpose. Just curious...

Hello everyone,

I am just a simple user of fischertechnik and mainly have knowledge of Robopro and building hobby projects. It is a shame, but also understandable with progress that not everything can work with each other or is compatible. I was hoping that it would be easier (read, for someone like me) to get it working. For now I will stick with the TX controllers, the displays work well with them and the FT-extender. The 3 TXT controllers will remain in a drawer for the time being. In any case, thanks for your thoughts, but this is getting too technical for me

Kind regards, Mark

Hallo...
Sorry for my bad english...
All the Controller "can" controll 3 satelite in an stabil orbit, but its only control a ft-model.
What we do is to communicate with "older" hardware on that way (I2C).
The TXT 4.0 has CAN... and it never use in any ft-Model.
But sometimes on of us uses it.
Wiht best regards
Holger

Hello,

it seems the thread is getting into two discussions.

To close the second one about the ftExtender:

During design, the objective was to have a simple converter between the different logic levels. Since it's bidirectional, you could use it with TX and TXT easily. That's why we added 6pin and 10 pin . The 14 pin plugs provides both levels in one plug. We used smd plugs, which simplified the production process. The plates are just helpers to grap and place them by a robot. When we took this foto, we forgot to pull the plates first.

It's crazy, that fischertechnik mirrored the plug at TXT4.0. Since it's easy to configure these ribbon cables with channellocks, you could even cross the first and last cables on your own. You just need some spare plugs, since you will brake the first one.

Best regards,

Stefan

Hello Mark,

now back to your initial thread. Hope you won't chuck it in.

Since you're already using a ftExtender, you just need a 1:1 10 pin ribbon cable to connect the 10 pin TXT extension port with a 10 pin ftExtender port. Don't connect a TX by 6 pin in parallel. It would block your communication, but won't harm the hardware.

Now you could run both tests easily.

Have fun,

Stefan

elektrofuzzis hat geschrieben: ↑

14 Apr 2026, 22:51

It's crazy, that fischertechnik mirrored the plug at TXT4.0. Since it's easy to configure these ribbon cables with channellocks, you could even cross the first and last cables on your own. You just need some spare plugs, since you will brake the first one.

Ah, thanks for confirming that! Yes, it is indeed strange that the connector on the TXT 4.0 is mirrored. You’d almost want to include connectors for both connections (when designing something new). Or, as I’m considering, just use a completely different connector so there can be no confusion. However, this has the disadvantage that you’d have to make adapter cables for it.

(Crazy idea: a 3x3-row Dupont connector, if such a thing exists. You could then plug in the 2x3 connector from the flat cable in two different ways to “mirror” the pins. )

-------------------------------------------------------------------------------

Ah, danke für die Bestätigung! Ja, es ist in der Tat seltsam, dass der Stecker beim TXT 4.0 dann seitenverkehrt ist. Man würde fast (wenn man etwas Neues entwirft) Anschlüsse für beide Anschlüsse einplanen. Oder, wie ich es in Erwägung ziehe, einfach einen ganz anderen Anschluss verwenden, damit es auch keine Verwechslungen geben kann. Das hat allerdings den Nachteil, dass man dafür Adapterkabel anfertigen muss.

(Eine verrückte Idee: ein Dupont-Stecker mit 3×3 Reihen, falls es so etwas gibt. Dann könnte man den 2×3-Stecker des Flachkabels auf zwei verschiedene Arten einstecken, um die Pins zu „spiegeln“ )

fishfriend hat geschrieben: ↑

14 Apr 2026, 17:55

The TXT 4.0 has CAN... and it never use in any ft-Model.

Absolutely, there’s also the CAN bus. But for the design I’m currently working on, that would require an additional CAN bus driver anyway. That’s why I think I2C is fine and more universal. And 400 kbit/s is fast enough. I’ve already got this working in both directions between the TXT 4.0 and my own “slave” device. Multiple servos are moving without any visible latency, so the whole system is fast enough!

My question was about my observation—or rather, my surprise—that the I2C connector on the TXT 4.0 is “reversed,” which means the ftExtender cannot be used without modifying the flat cable. I now understand that this is indeed the case....

-------------------------------------------------------------------------------

Ja, natürlich gibt es auch noch den CAN-Bus. Aber für das Projekt, an dem ich gerade arbeite, würde das ohnehin einen zusätzlichen CAN-Bus-Treiber erfordern. Deshalb erscheint mir I2C gut geeignet und universeller. Und die 400 kbit/s sind schnell genug. Ich habe das mittlerweile in beide Richtungen zwischen dem TXT 4.0 und meinem eigenen „Slave“-Gerät zum Laufen gebracht. Mehrere Servos bewegen sich ohne sichtbare Latenz, das Ganze ist also schnell genug!

Meine Frage bezog sich auf meine Feststellung bzw. mein Erstaunen darüber, dass der I2C-Anschluss beim TXT 4.0 „gespiegelt“ ist und der ftExtender daher ohne Anpassungen am Flachkabel nicht verwendet werden kann. Wie ich inzwischen verstanden habe, ist dies tatsächlich der Fall....