Kommunikation TXT zu TXT

[Pinot]

Hallo Gemeinde,

wie kommunizieren denn zwei TXT miteinander? Ich dachte ueber I2C, aber das ist es sicher nicht. Mittlerweile hab ich herausgefunden, dass fuer die Kommunikation zwei der drei EXT-Pins genutzt werden. Damit scheidet SPI auch aus. Zwei Leitungen riecht nach UART. Wenn ja, kennt da jemand die Parameter? Und ist da ein Protokoll zu veroeffentlicht?

[vleeuwen]

(compressed, binary) transfer area (TA). synchronous with the update cycle of the TA on the master. (compressed) transfer area (TA). in sink with the update cycle of the TA on the master.
refresh rate 10 ms or faster. Refresh rate 10 ms or faster. I think your assumption is correct, they use the serial communication (UART). Private protocol.

++++++++++++
(komprimierter, binärer) Transferbereich (TA). synchron mit dem Aktualisierungszyklus des TA auf dem Master. (komprimierter) Transferbereich (TA). in Senke mit dem Aktualisierungszyklus des TA auf dem Master.
Bildwiederholfrequenz 10 ms oder schneller. Aktualisierungsrate 10 ms oder schneller. Ich denke, Ihre Annahme ist richtig, sie verwenden die serielle Kommunikation (UART). Privates Protokoll.

[MasterOfGizmo]

Ich meine, dass es RS485 ist.

[vleeuwen]

See: https://github.com/fischertechnik/FT-TX ... nux-FAQ.md
From the documentation:
For flashing the firmware they are using a PLX 2303 adapters (with RS232 protocol).
But with 0-3,3V, so it looks like a simple USART and not the real line driver RS232 or RS485 voltage levels.

[Pinot]

Soweit ich verstanden habe kann man doch einen ftduino mittel Level-Shifter an einen TXT haengen. Dafuer muss doch das Protokoll im Detail bekannt sein. Oder liege ich da einfach falsch und ein ftduino kann nur mit ftduinos kommunizieren? Denn eigentlich war mein Plan mir ein (paar) ftduino(s) zuzulegen um damit Aktoren anzusteuern. Die Basis wuerde aber ein (oder zwei) TXT bleiben.

[Bjoern]

Hallo Pinot,

die ftDuinos schließt du per I2C an. Dafür gibt es dann auch eine RoboPro Erweiterung, wenn du das nutzen möchtest.

Björn

[fishfriend]

Hallo...
Es gibt einen Unterschied zwischen der elektrischen Schnittstelle RS485 und der Softwareschnittstelle. Den ftduino kann man auch mit RS485 ausstatten. Da gibt es fertige Adapter für Arduinos, Shields...

Kurzfassung
Nur der Master spricht mit dem PC. Der Master sammelt alle notwendigen Daten der anderen Slaves um sie in einem Rutsch an den PC zu senden. Er verteilt auch die Daten vom PC an die anderen. Dazu wird eine "Kurzversion" der TA verwendet.
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Bjoern]

Hallo Holger,

ich bin mir nicht sicher ob Pinot nicht RS485 und I2C durcheinander bringt. Wenn er einfach nur eine beliebige Anzahl von ftDuinos zum ansteuern von Aktuatoren anschließen will und von einem Level Shifter spricht, könnte er auch einfach I2C meinen. Und dafür gibt es ja schon Lösungen.

Björn

[Pinot]

Neee, der Thomas (Pinot) bringt ganz sicher nicht I2C und UART durcheinander, ganz sicher nicht Ich kenn sogar den Unterschied zw. RS232 und RS485 …

Mich interessiert nur wie kommunizieren:

TXT mit TXT
TXT mit ftduino
ftduino mit ftduino

Vielleicht hab ich das etwas zu verschwurbelt gefragt.

Mein Ziel (falls technisch überhaupt möglich): zwei TXT mittels dem Ext-Port zu koppeln (klappt natürlich heute schon) und zusätzlich an den Ext-Port den einen oder anderen ftduino zu hängen (daher der Verweis auf den Levelshifter). Ich dachte das würde alles über die gleichen Pins und das gleiche Protokoll abgewickelt. Aber dem ist offensichtlich nicht so.

TXT mit TXT, so verstehe ich, ist wohl RS232 mit proprietärem Protokoll, während TXT mit ftduino (und ftduino unter sich) I2C und dokumentierten Protokoll ist.

[Bjoern]

Hallo Thomas,

TXT mit TXT, so verstehe ich, ist wohl RS232 mit proprietärem Protokoll, während TXT mit ftduino (und ftduino unter sich) I2C und dokumentierten Protokoll ist.

So sehe ich das auch. Und zum ansteuern des ftDuino vom TXT gibt es schon was fertiges für RoboPro, sofern du das nutzen möchtest.
Und ich denke das Master/Slave Demo von Till hilft dir schon mal bezüglich ftDuino/ftDuino.

TXT/TXT geht über Ext Port und du hast dann im RoboPro eine Extension zum auswhählen.
Wenn du einen ftDuino an einen TXT hängst, dann ist der TXT immer I2C Master.

Nimmst du 2 ftDuino, dann kannst du dir aussuchen wer davon Master oder Slave ist.

Björn

[PHabermehl]

edit: Björn hat schon ähnlich geantwortet, während ich getippt habe, ich sende meinen Senf aber trotzdem noch...


Hallo Thomas,

da wäre dann noch die Frage, wie Du das Ganze programmieren willst.

Aus technischer Sicht würde ich alle Geräte an den I²C-Bus hängen, ein TXT macht den Master, alle anderen Geräte Slaves.

Wie Carel schon schrieb, kann man aus RoboPRO eben auch auf den I²C-Bus zugreifen. Ich würde dann aber den 2. TXT nicht als Slave des 1. über's ft-Protokoll anbinden, sondern, wie schon gesagt, eine I²C-Kette aufbauen.

Ehrlich gesagt weiß ich nicht, ob es möglich ist, 2 TXTs im Master-Slave-Betrieb mit RoboPRO zu steuern und dann, mit einem selbstgebauten Kabel, auch noch I²C-Kommunikation zu betreiben. Theoretisch müsste das gehen, das hast Du ja selbst schon erkannt.

Meine Wahl wäre die Community Firmware auf den TXTs, programmiert in Python, TXT 1 als Master, TXT2 und die ftDuinos als Slaves am I²C.

Gruß
Peter

[Bjoern]

Hallo Peter,

2xTXT über ft-Protokoll und dazu I2C sollte m.E. auf jeden Fall gehen.

Die Frage wäre nur warum Thomas das tun sollte. Im Prinzip kann der ftDuino ja fast alles was der TXT kann. Auf jeden Fall als Slave.
Und Thomas ging es ja nur darum mehr Aktoren anzuschließen.

Also eher TXT + diverse ftDuino

Und das evtl. 2x

@Pinot
Verrate uns doch mal in welchem Umfang du das machen willst. Gehen sollte es auf jeden Fall.
Also wie viele Aktoren. Was du für Inputs brauchst und mit welcher Programmiersprache du arbeiten möchtest.
Peter bringt CFW und Phyton ins Spiel, vielleicht magst du aber auch einfach nur mit RoboPro arbeiten.
Beides sollte auf jeden Fall gehen.

Björn

[Pinot]

Erstmal Danke an Bjoern und Peter, Ihr bringt Licht in mein Dunkel

Warum ich zwei TXT nutze? Weil sie vor mir liegen. Und warum will ich da noch ftduinos dranhaengen? Weil mir an den TXTs die Ausgaenge ausgehen. Zwar kann man sich auch mit I2C-Chips wie dem PCF8574 et al weiterhelfen, RoboPro-Bibliotheken gibt's ja dafuer auch. Aber das Ganze wird doch ein grosses Gebastel. Und wenn man dann noch steuerbare Ausgaenge, z.B. fuer Motore haben will, wird's ein noch groesseres Gebastel. Da scheinen mir die ftduinos doch deutlich eleganter zu sein. Vor allem wenn ich sie am I2C-bus skalieren kann.

Aktore werden das locker ueber 20. Motore fuenf bis zehn. Und wozu? Siehe den Thread zu meinem Protalkran Das Ganze soll ueber die IR-Fernsteuerung bedient werden. Dazu arbeite ich (noch) in RoboPro, was ich eigentlich ganz schick finde. "Eigentlich" desshalb, da ich langsam Zweifel an der Performance bekomme. Zum "Performance-optimierten" Programmieren in RoboPro hatte ich einen Thread gestartet, aber der Stein der Weisen wurde dort nicht gefunden. Mal sehen wie weit ich mit RoboPro komme. Ansonsten waere dann Python i.d.T. die Alternative. Wobei "Performance" und "Python" ja auch so zwei ungleiche Geschwister sind

Gruesse, Thomas

[Pinot]

@Peter

Du schreibst: "Ich würde dann aber den 2. TXT nicht als Slave des 1. über's ft-Protokoll anbinden, sondern, wie schon gesagt, eine I²C-Kette aufbauen."

D.h. einen zweiten TXT kann man ueber den I2C ansprechen? Dazu braucht's dann auch nen Befehlssatz. Wo ist der dokumentiert? Und wie bekommt der (oder die) TXTs ihre I2C-Bus-Adresse?

Gruesse, Thomas

[Torsten]

Hallo Pinot,

ich hätte noch eine weitere Option für Dich:

falls Python ok wäre, könntest Du auch mehrere TXTs (soviele Du hast ) als Clients in Deinem WLAN einbinden und diese dann mit einem einzigen Python-Script, das auf einem bel. der TXTs oder auf Deinem PC läuft, ansteuern. (Irgendwann wird diese Option mit dem ftrobopy_server sogar mit ROBOPro, das auf einem PC läuft, funktionieren. Möglicherweise sogar auch noch mit ftDuinos, die an die TXTs per i2c angeschlossen sind. Ich bin aber noch nicht fertig damit).

Viele Grüße
Torsten

[MasterOfGizmo]

D.h. einen zweiten TXT kann man ueber den I2C ansprechen? Dazu braucht's dann auch nen Befehlssatz. Wo ist der dokumentiert? Und wie bekommt der (oder die) TXTs ihre I2C-Bus-Adresse?

M.E. kann sich der TXT nicht als I²C-Slave ausgeben.

Aber ich wüsst auch nicht, was gegen Deinen ursprünglichen Plan spricht. Zwei TXTs einfach wie von ft vorgesehen koppeln (das passiert dann nicht über I²C, sondern so, wie ft sich das gedacht hat). Und dann gleichzeitig den I²C des ersten TXT für ftDuinos nutzen. Hast Du schon irgendwelche I²C-Geräte für den TXT? Dann kannst Du ja testen, ob das gleichzeitig geht, ohne ftDuinos kaufen zu müssen. Ich wüsste aber nicht, was dagegen spricht ... außer dass Du passende Kabel auftreiben musst.

Nachtrag: Wenn man zwei TXTs mit den üblichen Kabeln koppelt, dann hat man beide I²C-Busse ebenfalls verbunden. Also sollte sich der zweite TXT auf dem I²C-Bus zurückhalten, wenn man den am ersten nutzen möchte.

[Pinot]

@MoG

Ja, genau den Weg werde ich jetzt verfolgen. Und wenn man den I2C-Leverlshifter verwendet, wird das mit dem Kabeln ganz einfach.

TXT <-> TXT <-> (10pol.Buchse)Levelshifter(6pol.Buchse) <-> ftduiono <-> ftduino <-> ...

Und an die 14pol Buchsen des Levelshifter koennte ich dann noch anderen I2C-Kram klemmen. Aber wie geschrieben, ist mir das eigentlich zu viel Gebastel.

Auch wuesste ich nicht, warum die beiden TXTs nicht per I2C Kontakt haben sollten. Wenn sie sich als Slave sowieso nie angesprochen fuehlen (und fuer Multimaster sind sie iirc nicht ausgelegt), dann sollte da nichts passieren.

@Torsten

Nee, Kopplung ueber WLAN mag ich gar nicht. Das Ganze soll auch ohne Netz funktionieren. Am liebsten mittels Download. Aber da hab ich schon die enttaeuschende Erfahrung gemacht, dass man, wenn zwei TXT gekoppelt sind, nur noch online arbeiten kann und ein Download nicht moeglich ist. Die Erkenntnis war maximal enttaeuschend. Oder mach ich was falsch?

[vleeuwen]

The TXT can only function as an I2C master and cannot even function as an I2C multi-master.
There is a difference between 2 TXTs in a master extension (synchronous) relationship (private protocol fischertechnik) or 2 or more TXTs, all as master (asynchronous) in a network.
In the latter case, several masters can communicate with each other quite easily via, among others: Berkeley sockets, web sockets (embedded Civet server) or MQTT; this is over IP (LAN not WLAN) with a small WIFI-router. What you use depends on the desired speed.
All three options can also be used within a RoboPro program via a RoboPro SLI extension.
In the same way, you can even communicate with another device (laptops, Raspberry Pis, etc.).
The local TA (transfer Area) can be accessed directly or via local intelligence (programmed functionality) from outside.
Which solutions can be used depends strongly on the actual application.
==================
Es wird unterschieden zwischen 2 TXTs in einer Master-Extension (synchron) Beziehung (privates Protokoll fischertechnik) oder 2 oder mehr TXTs, alle als Master (asynchron) in einem Netzwerk.
Im letzteren Fall können mehrere Master ganz einfach miteinander kommunizieren, unter anderem über: Berkeley Sockets, Web Sockets (Embedded Civet Server) oder MQTT; hier geht es um IP. Was Sie verwenden, hängt von der gewünschten Geschwindigkeit ab.
Alle drei Optionen können auch innerhalb eines RoboPro-Programms über die RoboPro SLI-Erweiterung verwendet werden.
Auf die gleiche Weise können Sie sogar mit einem anderen Gerät (Laptops, Raspberry Pis usw.) kommunizieren.
Auf den lokalen TA (Transferbereich) kann direkt oder über lokale Intelligenz (programmierte Funktionalität) von außen zugegriffen werden.

[PHabermehl]

Wobei "Performance" und "Python" ja auch so zwei ungleiche Geschwister sind

Oh, das ist zwar richtig, aber letztlich hängt es von einer geschickten Verteilung der Funktionalitäten auf die verschiedenen Controller ab, wie performant das Gesamtsystem ist.

Ein ftDuino kann quasi echtzeitfähig sein...

Gruß
Peter

[Bjoern]

Hallo Pinot,

hatte noch mal kurz in den anderen Thread geschaut. So ganz klar sind mir deine ganzen Berechungen noch nicht.

Ich würde noch mal alle Anforderungen aufschreiben. Dann kann man noch mal drüber nachdenken.

Du könntest natürlich auch eine Lastverteilung über die jeweiligen Controller machen.
Wenn du z.B. Motoren und deren Steuerung gruppieren kannst, dann kannst du auch die Last verteilen. Wobei ich mir jetzt nicht so sicher bin, ob das dann nachher noch so einfach mit RoboPro geht. Denn hier vermute ich mal läuft die Anwendung auf dem einen TXT und alles anderen sind nur I/Os.

Etwas herausfordernder wäre es evtl. die grobe Logik im RoboPro zu haben und du überträgst dann Teilfunktionen auf die ftDuinos. Da bräuchtest du dann aber eine Erweiterung von deren Sketches.

Aber irgendwie verstehe ich noch nicht wie du mit der einen Fernbedienung alle Motoren steuerst und warum dies dann so in die Knie geht. Oder führt ein Steuerbefehl dann indirekt zur Ansteuerung weiterer Motoren?

Björn