Hallo zusammen, ich wollte mal fragen, ob und wie man denTXT und den TXT 4.0 Controller verbinden kann Es gibt ja in ROBOPro die Option "Senden/Empfangen". Da dachte ich das würde bestimmt auch ,mit dem TXT 4.0 Controller funktionieren.
Viele Grüße, Tom
TXT und TXT 4.0 Controller verbinden
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
Re: TXT und TXT 4.0 Controller verbinden
Hallo Tom,
für solche Fragen wäre der Service von Fischertechnik eigentlich die richtige Adresse.
Antworten doch sehr schnell, zuverlässig und kompetent betreffend Probleme mit
deren Hard- und Software.
für solche Fragen wäre der Service von Fischertechnik eigentlich die richtige Adresse.
Antworten doch sehr schnell, zuverlässig und kompetent betreffend Probleme mit
deren Hard- und Software.
Re: TXT und TXT 4.0 Controller verbinden
Hallo Tom,
grundsätzlich können die TXTs und TXT4.0s auf verschiedene Arten miteinander kommunizieren.
Die Frage ist, wie du die beiden Controller programmieren willst. Willst du den TXT mit RoboPro und den TXT4.0 Blocky programmieren, oder beide mit Python oder C/C++?
Vielleicht kannst du mal etwas genauer erläutern, was du dir vorstellst, dann können wir dir besser weiterhelfen.
Viele Grüße,
Cody
grundsätzlich können die TXTs und TXT4.0s auf verschiedene Arten miteinander kommunizieren.
Die Frage ist, wie du die beiden Controller programmieren willst. Willst du den TXT mit RoboPro und den TXT4.0 Blocky programmieren, oder beide mit Python oder C/C++?
Vielleicht kannst du mal etwas genauer erläutern, was du dir vorstellst, dann können wir dir besser weiterhelfen.
Viele Grüße,
Cody
Re: TXT und TXT 4.0 Controller verbinden
Hallo,
diese Frage von Tom interessiert mich im Grunde auch.
Habe allerdings (noch) keinen TXT 4.0.
Die Kommunikation zwischen TXT und TXT4.0 mit den von Fischertechnik erhältlichen
"Bordmitteln", also TXT mit RoboCoding und TXT4.0 mit RoboPro.
Am simpelsten wäre sicherlich eine Verbindung ähnlich dem uralten RS232-Protokoll.
Gut, die Pegel wären nicht normgerecht aber sollte auch z. B. mit TTL-Pegeln oder den
Fischertechnik 9V Pegeln funktionieren.
Wäre für mich z. B. als Programmier-"Dummy" wohl am einfachsten.
Wenn ich noch weitere Programmiersprachen und dazu noch einen "Riesenhaufen" an Hardware
brauche, verliere ich todsicher die Lust.
Programmierbeispiele in beiden "Programmier-Bild-Sprachen" wären für ein anfängliches Verständnis
angebracht.
Eigentlich sollte die Kommunikation zwischen den beiden unterschiedlichen Controllern unabhängig von
der an den Controllern von Fischertechnikern drangebastelter Fischertechnik-Hardware sein.
diese Frage von Tom interessiert mich im Grunde auch.
Habe allerdings (noch) keinen TXT 4.0.
Die Kommunikation zwischen TXT und TXT4.0 mit den von Fischertechnik erhältlichen
"Bordmitteln", also TXT mit RoboCoding und TXT4.0 mit RoboPro.
Am simpelsten wäre sicherlich eine Verbindung ähnlich dem uralten RS232-Protokoll.
Gut, die Pegel wären nicht normgerecht aber sollte auch z. B. mit TTL-Pegeln oder den
Fischertechnik 9V Pegeln funktionieren.
Wäre für mich z. B. als Programmier-"Dummy" wohl am einfachsten.
Wenn ich noch weitere Programmiersprachen und dazu noch einen "Riesenhaufen" an Hardware
brauche, verliere ich todsicher die Lust.
Programmierbeispiele in beiden "Programmier-Bild-Sprachen" wären für ein anfängliches Verständnis
angebracht.
Eigentlich sollte die Kommunikation zwischen den beiden unterschiedlichen Controllern unabhängig von
der an den Controllern von Fischertechnikern drangebastelter Fischertechnik-Hardware sein.
Re: TXT und TXT 4.0 Controller verbinden
Grundsätzlich bieten sich Sockets und I2C für die Kommunikation zwischen den beiden Controller an.
Wenn du allerdings auf RoboPro und RoboProCoding setzen willst, wird es etwas schwieriger.
RoboPro bietet einen direkten Zugang zu I2C, d.h. du kannst Daten an beliebiger Adresse lesen und schreiben. In RoboProCoding (mit Blocky) ist der I2C Zugang eingeschränkt. Dort hat man die Auswahl aus den 3 ft-I2C-Sensoren (Kombisensor, Umweltsensor und Gestensensor) und kann diese über eine Schnittstelle ansteuern, aber du kannst weder ein beliebiges Gerät adressieren noch beliebige Daten lesen oder schreiben. Das ist wahrscheinlich über eigenen Python Code möglich, den du in Blocky integrieren kannst (habe ich allerdings noch nicht versucht) oder du schreibst ein reines Python Programm.
Die Nutzung einer socketbasierten Kommunikation, beispielsweise über MQTT, ist in RoboProCoding sehr einfach. Es gibt dafür die entsprechenden Blocky Elemente. Allerdings gibt es unter RoboPro für den TXT keinen direkten Support dafür. Möglich ist das aber über SLI-Blöcke. Diese in C/C++ programmierten Schnittstellen erlauben unter anderem die Einbindung von MQTT in RoboPro. Carel hat das mal implementiert, es gibt meines Wissens nach aber keinen Sourcecode dafür (siehe viewtopic.php?f=8&t=7391).
Am einfachsten wäre vermutlich auf beiden Controllern Python zu nutzen (mit ftrobopy auf dem TXT). Damit hast du sowohl auf I2C als auch auf sockets Zugriff und kannst dann das nutzen, was sich bei deinem Modell gerade anbietet.
Wenn du allerdings auf RoboPro und RoboProCoding setzen willst, wird es etwas schwieriger.
RoboPro bietet einen direkten Zugang zu I2C, d.h. du kannst Daten an beliebiger Adresse lesen und schreiben. In RoboProCoding (mit Blocky) ist der I2C Zugang eingeschränkt. Dort hat man die Auswahl aus den 3 ft-I2C-Sensoren (Kombisensor, Umweltsensor und Gestensensor) und kann diese über eine Schnittstelle ansteuern, aber du kannst weder ein beliebiges Gerät adressieren noch beliebige Daten lesen oder schreiben. Das ist wahrscheinlich über eigenen Python Code möglich, den du in Blocky integrieren kannst (habe ich allerdings noch nicht versucht) oder du schreibst ein reines Python Programm.
Die Nutzung einer socketbasierten Kommunikation, beispielsweise über MQTT, ist in RoboProCoding sehr einfach. Es gibt dafür die entsprechenden Blocky Elemente. Allerdings gibt es unter RoboPro für den TXT keinen direkten Support dafür. Möglich ist das aber über SLI-Blöcke. Diese in C/C++ programmierten Schnittstellen erlauben unter anderem die Einbindung von MQTT in RoboPro. Carel hat das mal implementiert, es gibt meines Wissens nach aber keinen Sourcecode dafür (siehe viewtopic.php?f=8&t=7391).
Am einfachsten wäre vermutlich auf beiden Controllern Python zu nutzen (mit ftrobopy auf dem TXT). Damit hast du sowohl auf I2C als auch auf sockets Zugriff und kannst dann das nutzen, was sich bei deinem Modell gerade anbietet.
Re: TXT und TXT 4.0 Controller verbinden
It also possible to create on the TXT and on the TXT4.0 a Berkeley-socket or a Web socket.
(with one port for a client/server configuration or two ports for a symmetrical connection)
On the TXT you can use the Civetweb libraries (C++, SLI) and on the TXT4.0 the Python libraries.
A long time ago I have publish an example with a web socket (one port) and a virtual joystick.
The principal is the same
But for this the TXT (4.0)'s need to be in a subdomain with different IP addresses.
Another option could be to use an I2C-RS232 converter on each TXT (4.0).
Then you can have a full duplex connection
But you need to create drivers for it.
Example:
https://coptonix.com/en/products/i2c-rs ... ter-slave/
https://www.mikroe.com/rs232-to-i2c-click
(with one port for a client/server configuration or two ports for a symmetrical connection)
On the TXT you can use the Civetweb libraries (C++, SLI) and on the TXT4.0 the Python libraries.
A long time ago I have publish an example with a web socket (one port) and a virtual joystick.
The principal is the same
But for this the TXT (4.0)'s need to be in a subdomain with different IP addresses.
Another option could be to use an I2C-RS232 converter on each TXT (4.0).
Then you can have a full duplex connection
But you need to create drivers for it.
Example:
https://coptonix.com/en/products/i2c-rs ... ter-slave/
https://www.mikroe.com/rs232-to-i2c-click
Re: TXT und TXT 4.0 Controller verbinden
Hallo,
mmh..., wenn ich die Antworten auf meine Frage mit den zwei unterschiedlichen Controllern lese scheint es "mal so einfach eben"
mit "Bordmitteln" nicht zu funktionieren. Wundert mich letztendlich weil fast jeder dämliche Billigst-Mikrocontroller-Chip schon RX und TX
an Bord hat. I2C oder TWI wären noch akzeptabel aber wenn der neuere Ft-Controller nur die drei Sensoren serienmäßig über diese Schnittstelle unterstützt, finde ich für so ein hochpreisiges Teil schon merkwürdig. Nicht jeder möchte sich noch mit zusätzlichen Programmiersprachen oder sich mit dem ganze Socket-Gedöns und MQTT-Gedöns sich befassen. Ist zwar alles "hochmodern" aber letztendlich werden doch nur einige wenige Daten zwischen den Controllern ausgetauscht.
Klar, für grogrammiermäßig vorbelastete und mehr an Programmierung interessierte Hobbiesten geht eine Implementierung gewisser Funktionen leichter von Hand.
Fazit..., "da habe ich mir zwei Controller zu nacheinander folgenden Modell-Zeitpunkten von ein- und derselben Firma für um die 500 € bis 800 € neu gekauft und kann die noch nocht einmal so ohne weiteres mit einfachen "Bordmitteln" miteinander kommunizieren lassen. Dazu noch blödsinnigerweise zwei nacheinander erschienene Modelltypen wie "TXT" und "TXT4.0".
mmh..., wenn ich die Antworten auf meine Frage mit den zwei unterschiedlichen Controllern lese scheint es "mal so einfach eben"
mit "Bordmitteln" nicht zu funktionieren. Wundert mich letztendlich weil fast jeder dämliche Billigst-Mikrocontroller-Chip schon RX und TX
an Bord hat. I2C oder TWI wären noch akzeptabel aber wenn der neuere Ft-Controller nur die drei Sensoren serienmäßig über diese Schnittstelle unterstützt, finde ich für so ein hochpreisiges Teil schon merkwürdig. Nicht jeder möchte sich noch mit zusätzlichen Programmiersprachen oder sich mit dem ganze Socket-Gedöns und MQTT-Gedöns sich befassen. Ist zwar alles "hochmodern" aber letztendlich werden doch nur einige wenige Daten zwischen den Controllern ausgetauscht.
Klar, für grogrammiermäßig vorbelastete und mehr an Programmierung interessierte Hobbiesten geht eine Implementierung gewisser Funktionen leichter von Hand.
Fazit..., "da habe ich mir zwei Controller zu nacheinander folgenden Modell-Zeitpunkten von ein- und derselben Firma für um die 500 € bis 800 € neu gekauft und kann die noch nocht einmal so ohne weiteres mit einfachen "Bordmitteln" miteinander kommunizieren lassen. Dazu noch blödsinnigerweise zwei nacheinander erschienene Modelltypen wie "TXT" und "TXT4.0".
Re: TXT und TXT 4.0 Controller verbinden
Right, that‘s why I haven’t specified the type of socket, because there are several options. I mentioned MQTT since there are readymade blocks for that.
Naja, wie gesagt, I2C ist an Bord, da sind RX und TX m.E. nicht unbedingt notwendig (wobei alle Universaleingänge als RX für Halbduplexübertragungen theoretisch verwendbar wären). Dazu ist ja nicht das Problem, dass keine Kommunikationsschnittstelle vorhanden ist, sondern dass diese nicht vollumfänglich in der Entwicklungsumgebung implementiert ist. Und du hast ja über Python vollen Zugriff auf I2C, nur eben nicht aus direkt Blocky. Wobei du das über einen Python-Block einfügen kannst.
Blocky ist ja ohnehin eher als Einstieg gedacht, für fortgeschrittene Projekte empfiehlt sich Python, da es deutlich flexibler und bei größeren Projekten übersichtlicher ist. RoboProCoding ist zudem recht jung und dass dann alle möglichen fortgeschrittenen Features nicht von Anfang an implementiert sind, ist m.E. verständlich. Ich gehe aber davon aus, dass eine generische I2C Schnittstelle in Blocky irgendwann noch kommt.
Genau wie RoboPro ist RoboProCoding erweiterbar, damit man all das, was man braucht, genauso wie man es braucht, ergänzen kann. Und wenn man eine Lösung braucht, welche nicht standardmäßig verfügbar ist, und man selbst nicht in der Lage ist, sowas zu implementieren, kann man immer noch hier im Forum fragen, es finden sich bestimmt Leute, die einem da weiterhelfen können.
Naja, wie gesagt, I2C ist an Bord, da sind RX und TX m.E. nicht unbedingt notwendig (wobei alle Universaleingänge als RX für Halbduplexübertragungen theoretisch verwendbar wären). Dazu ist ja nicht das Problem, dass keine Kommunikationsschnittstelle vorhanden ist, sondern dass diese nicht vollumfänglich in der Entwicklungsumgebung implementiert ist. Und du hast ja über Python vollen Zugriff auf I2C, nur eben nicht aus direkt Blocky. Wobei du das über einen Python-Block einfügen kannst.
Blocky ist ja ohnehin eher als Einstieg gedacht, für fortgeschrittene Projekte empfiehlt sich Python, da es deutlich flexibler und bei größeren Projekten übersichtlicher ist. RoboProCoding ist zudem recht jung und dass dann alle möglichen fortgeschrittenen Features nicht von Anfang an implementiert sind, ist m.E. verständlich. Ich gehe aber davon aus, dass eine generische I2C Schnittstelle in Blocky irgendwann noch kommt.
Genau wie RoboPro ist RoboProCoding erweiterbar, damit man all das, was man braucht, genauso wie man es braucht, ergänzen kann. Und wenn man eine Lösung braucht, welche nicht standardmäßig verfügbar ist, und man selbst nicht in der Lage ist, sowas zu implementieren, kann man immer noch hier im Forum fragen, es finden sich bestimmt Leute, die einem da weiterhelfen können.
Re: TXT und TXT 4.0 Controller verbinden
Hallo Mitstreiter,
danke erstmal für eure Antworten. Die Hilfsbereitschaft in einigen Foren finde ich bewundernswert und schätze die auch.
Schnittstellen über Software an diversen I/O-Pins zu legen sind mir auch bekannt. Manchmal mehr oder weniger problematisch.
Da bin ich mal gespannt ob der Hersteller seine grafische Programmiermöglichkeiten irgendwann erweitert. Hege zwar meine
Zweifel aber die Hoffnung stirbt ja zuletzt. Eigenartigerweise sind bei einigen grafischen Programmiersprachen viele Dinge für
Microcontroller schon implementiert wovon Fischertechnik, wahrscheinlich aus Kostengründen, noch "träumt".
Wäre vielleicht besser bekannte preiswerte Systeme, wie z. B. Arduino, Raspberry Pi, zu nutzen und einfache Hardware als Zubehör
für Anpassungen an herstellereigene Baugruppen oder Bauteile anzubieten.
Nachtrag:
Habe zwischenzeitlich einen interessanten Link gefunden und mir den "Download" angeschaut. Sieht gar nicht mal so schlecht aus,
basiert wahrscheinlich auch auf ""Python" in "graphisch"". Entspricht grob überschaut zumindest teilweise meinen Erwartungen.
Läuft anscheinend auch auf einen ESP32. Ist zwar nicht direkt für die Fischertechnik-Hardware sofort einzusetzen aber man könnte es
schon irgendwie preisgünstig hinbiegen. Vielleicht "MOCs" arduinomäßigen Controller als Hardware-Adapter zu Fischertechnik. Wäre insgesamt mit einem z. B. ESPxxxx immerhin preislich noch sehr weit von dem höheren Origtinal-Anschaffungspreis eines TXT4.0 entfernt.
Interessand finde ich in dem graphischen Programmier-Programm die implementierten Möglichkeiten. Ob die Funktionen alle hundertprozentig funktionieren lasse ich erstmal dahingestellt.
https://mpyblockly.github.io/mpyblockly/
danke erstmal für eure Antworten. Die Hilfsbereitschaft in einigen Foren finde ich bewundernswert und schätze die auch.
Schnittstellen über Software an diversen I/O-Pins zu legen sind mir auch bekannt. Manchmal mehr oder weniger problematisch.
Da bin ich mal gespannt ob der Hersteller seine grafische Programmiermöglichkeiten irgendwann erweitert. Hege zwar meine
Zweifel aber die Hoffnung stirbt ja zuletzt. Eigenartigerweise sind bei einigen grafischen Programmiersprachen viele Dinge für
Microcontroller schon implementiert wovon Fischertechnik, wahrscheinlich aus Kostengründen, noch "träumt".
Wäre vielleicht besser bekannte preiswerte Systeme, wie z. B. Arduino, Raspberry Pi, zu nutzen und einfache Hardware als Zubehör
für Anpassungen an herstellereigene Baugruppen oder Bauteile anzubieten.
Nachtrag:
Habe zwischenzeitlich einen interessanten Link gefunden und mir den "Download" angeschaut. Sieht gar nicht mal so schlecht aus,
basiert wahrscheinlich auch auf ""Python" in "graphisch"". Entspricht grob überschaut zumindest teilweise meinen Erwartungen.
Läuft anscheinend auch auf einen ESP32. Ist zwar nicht direkt für die Fischertechnik-Hardware sofort einzusetzen aber man könnte es
schon irgendwie preisgünstig hinbiegen. Vielleicht "MOCs" arduinomäßigen Controller als Hardware-Adapter zu Fischertechnik. Wäre insgesamt mit einem z. B. ESPxxxx immerhin preislich noch sehr weit von dem höheren Origtinal-Anschaffungspreis eines TXT4.0 entfernt.
Interessand finde ich in dem graphischen Programmier-Programm die implementierten Möglichkeiten. Ob die Funktionen alle hundertprozentig funktionieren lasse ich erstmal dahingestellt.
https://mpyblockly.github.io/mpyblockly/