ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo liebe ft-Freunde,
ich versuche mich gerade an meinen ersten python Schritten zusammen mit dem TX-Pi, an dem über den Pi-Hat ein ftDuino hängt.
Dank der community-Firmware war die Einrichtung des TX-Pi (Raspi 4) ein Kinderspiel.
Wenn ich den ftDuino mittels USB-Kabel an den TX-Pi anschließe und den Sketch ftduino_direct nutze klappt alles perfekt. Ich kann testweise auf die IOs des ftDuino zugreifen bzw. diese steuern. So weit so gut.
Mein Zielsetup war aber eine Verbindung von TX-Pi und ftDuino über i2c + zus. Spannungsversorgung. Hierfür habe ich den Sketch I2cSlave mit Standardadresse 43 hochgeladen.
Auf den ersten Blick scheint auch die Verbindung zu klappen. Wenn ich mit dem I2C Scanner das "/dev/i2c-1" auswähle blinkt die rote LED des ftDuino kurz auf und die Adressen 2b und 3c werden initialisiert. Also wird die 43 auch korrekt erkannt. Hat jemand einen Tipp wo die 60 noch herkommt? Ist das der Pi-Hat?
Problem:
Wenn ich Tills App "ftDuino I2C" starte, bekomme ich dort die Fehlermeldung: "Unable to connect to the ftDuino. Make sure one is connected to the TXTs EXT port and runs the I2cSlave sketch."
Ich hatte vermutet, das der TX-Pi hier analog zum TXT mit der App funktionieren müsste. Muss ich hier noch etwas einstellen? Gibt es alternativ eine einfache Möglichkeit den korrekten Zugriff vom Pi auf den ftDduino per i2c zu testen? Ich wäre über einen Tipp dankbar.
Das Ganze ist nicht Eilig, da die Verbindung über USB ja funktioniert. Aber was funktionieren sollte, soll auch funktionieren.
Danke & LG
Uwe
ich versuche mich gerade an meinen ersten python Schritten zusammen mit dem TX-Pi, an dem über den Pi-Hat ein ftDuino hängt.
Dank der community-Firmware war die Einrichtung des TX-Pi (Raspi 4) ein Kinderspiel.
Wenn ich den ftDuino mittels USB-Kabel an den TX-Pi anschließe und den Sketch ftduino_direct nutze klappt alles perfekt. Ich kann testweise auf die IOs des ftDuino zugreifen bzw. diese steuern. So weit so gut.
Mein Zielsetup war aber eine Verbindung von TX-Pi und ftDuino über i2c + zus. Spannungsversorgung. Hierfür habe ich den Sketch I2cSlave mit Standardadresse 43 hochgeladen.
Auf den ersten Blick scheint auch die Verbindung zu klappen. Wenn ich mit dem I2C Scanner das "/dev/i2c-1" auswähle blinkt die rote LED des ftDuino kurz auf und die Adressen 2b und 3c werden initialisiert. Also wird die 43 auch korrekt erkannt. Hat jemand einen Tipp wo die 60 noch herkommt? Ist das der Pi-Hat?
Problem:
Wenn ich Tills App "ftDuino I2C" starte, bekomme ich dort die Fehlermeldung: "Unable to connect to the ftDuino. Make sure one is connected to the TXTs EXT port and runs the I2cSlave sketch."
Ich hatte vermutet, das der TX-Pi hier analog zum TXT mit der App funktionieren müsste. Muss ich hier noch etwas einstellen? Gibt es alternativ eine einfache Möglichkeit den korrekten Zugriff vom Pi auf den ftDduino per i2c zu testen? Ich wäre über einen Tipp dankbar.
Das Ganze ist nicht Eilig, da die Verbindung über USB ja funktioniert. Aber was funktionieren sollte, soll auch funktionieren.
Danke & LG
Uwe
- PHabermehl
- Beiträge: 2439
- Registriert: 20 Dez 2014, 22:59
- Wohnort: Bad Hersfeld
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo Uwe,
mein spontaner Gedanke, nachdem ich gerade mal auf GitHub in den Quellcode vom Scanner und ftDuino I2C geschaut habe.
Der I2C Slave hat tatsächlich Adresse 43.
Und im Quellcode der cfw-App steht: I2C-Adresse 42...
Gruß
Peter
mein spontaner Gedanke, nachdem ich gerade mal auf GitHub in den Quellcode vom Scanner und ftDuino I2C geschaut habe.
Der I2C Slave hat tatsächlich Adresse 43.
Und im Quellcode der cfw-App steht: I2C-Adresse 42...
Gruß
Peter
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo Peter,
bei den Vorgonen, auf die 42 hätte ich auch selbst kommen können.
Das wars, damit klappt jetzt die Verbindung!
Dann werde ich mich morgen mal an ein paar einfachen Beispielen probieren.
Ich Danke Dir.
So long, and thanks for all the fish
Uwe
bei den Vorgonen, auf die 42 hätte ich auch selbst kommen können.
Das wars, damit klappt jetzt die Verbindung!
Dann werde ich mich morgen mal an ein paar einfachen Beispielen probieren.
Ich Danke Dir.
So long, and thanks for all the fish
Uwe
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Es gibt zwei I2C-Client-Sketches für den ftDuino. Einen ganz einfachen, als Beispiel, wie sowas prinzipiell funktioniert unter:
https://github.com/harbaum/ftduino/blob ... cSlave.ino
und einen mit allen möglichen Funktionen eher zur direkten Benutzung unter:
https://github.com/harbaum/ftduino/tree ... C/I2cSlave
Ersterer kann nur einen Ausgang an oder aus schalten und nutzt Adresse 42. Letzterer kann alle Ein- und Ausgänge bedienen und nutzt Adresse 43.
Die TX-Pi-App wurde für den ersten geschrieben. Es macht ggf. Sinn, die zu erweitern, so dass sie auch den erweiterten Slketch unter Adresse 43 ansteuern kann. Welche Variante angeschlossen ist kann man ja eben genau an der Adresse erkennen. Im zweiten Fall ist das zu sendende Kommando etwas komplexer.
Die Adresse 60 ist die Adresse eines OLED-Displays. Du hast wohl einen ftDuino mit eingebautem Display. Du könntest Dir den Spass machen, das OLED vom Pi aus anzusteuern. Diese Anleitung müsste dafür gehen: https://learn.adafruit.com/adafruit-pio ... -pi/usage
https://github.com/harbaum/ftduino/blob ... cSlave.ino
und einen mit allen möglichen Funktionen eher zur direkten Benutzung unter:
https://github.com/harbaum/ftduino/tree ... C/I2cSlave
Ersterer kann nur einen Ausgang an oder aus schalten und nutzt Adresse 42. Letzterer kann alle Ein- und Ausgänge bedienen und nutzt Adresse 43.
Die TX-Pi-App wurde für den ersten geschrieben. Es macht ggf. Sinn, die zu erweitern, so dass sie auch den erweiterten Slketch unter Adresse 43 ansteuern kann. Welche Variante angeschlossen ist kann man ja eben genau an der Adresse erkennen. Im zweiten Fall ist das zu sendende Kommando etwas komplexer.
Die Adresse 60 ist die Adresse eines OLED-Displays. Du hast wohl einen ftDuino mit eingebautem Display. Du könntest Dir den Spass machen, das OLED vom Pi aus anzusteuern. Diese Anleitung müsste dafür gehen: https://learn.adafruit.com/adafruit-pio ... -pi/usage
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
...dabei weiß doch jeder, dass die Antwort auf alle wichtigen Fragen die "42" ist...
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hups ... wie konnte mir das denn passieren? So ein Zufall ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Das musst Du übrigens mal laut verkünden. Der Lars glaubt manchmal, dass wir kaum TX-Pi-User haben. Und demnächst hängen wir uns mit dem TX-Pi an RoboPro-Coding ran. Das wird ein Spass ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo,
Raspberry Pi 400-Kit kpl. da, TX-Pi sowie großen 22er Monitor für meine alten "Guckerchen" auch schon vorhanden.
Fehlt nur noch Robo-Pro-Coding und das Flachkabel welches ich noch herstellen muß, - Entwicklungssystem, wenn
das "Robo-Pro-Coding" auch unter dem Raspberry-Betriebssystem läuft, fertig.
Dann noch einen "Controllino" auf Mega2560 Basis als Slave für TTL und 24 V.... Ports haufenweise.
Mehr bräuchte der Großteil der Menschheit für Hobby und Industrie eigentlich nicht. Da fallen dem großen
Klemmbaustein-Hersteller bestimmt die Augen aus.
Leider in den meisten Fällen für stationäre Anwendungen. Für kleinere Mobilteile müsste man sich dann
etwas einfallen lassen...., Pi Zero, kl. I/O-Baugruppen etc.
Na ja, hat auch noch ein bischen Zeit. Muß noch viel sortieren und eine IKEA-Einkaufstüte in blau voll
mit Fischertechnik-Mix wartet auch noch auf das Selektieren.
Wow, da freue ich mich schon, hoffentlich nicht vergebens.Und demnächst hängen wir uns mit dem TX-Pi an RoboPro-Coding ran. Das wird ein Spass ...
Raspberry Pi 400-Kit kpl. da, TX-Pi sowie großen 22er Monitor für meine alten "Guckerchen" auch schon vorhanden.
Fehlt nur noch Robo-Pro-Coding und das Flachkabel welches ich noch herstellen muß, - Entwicklungssystem, wenn
das "Robo-Pro-Coding" auch unter dem Raspberry-Betriebssystem läuft, fertig.
Dann noch einen "Controllino" auf Mega2560 Basis als Slave für TTL und 24 V.... Ports haufenweise.
Mehr bräuchte der Großteil der Menschheit für Hobby und Industrie eigentlich nicht. Da fallen dem großen
Klemmbaustein-Hersteller bestimmt die Augen aus.
Leider in den meisten Fällen für stationäre Anwendungen. Für kleinere Mobilteile müsste man sich dann
etwas einfallen lassen...., Pi Zero, kl. I/O-Baugruppen etc.
Na ja, hat auch noch ein bischen Zeit. Muß noch viel sortieren und eine IKEA-Einkaufstüte in blau voll
mit Fischertechnik-Mix wartet auch noch auf das Selektieren.
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Wie ich schon schrieb: "wir". Ob das vergebens ist hängt u.a. davon ab, ob Leute wie Du sich bei "wir" ausnehmen und die anderen eher als Dienstleister verstehen oder selbst was beitragen wollen.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo,
ich brauche nochmal Eure Hilfe. Ich habe nun meine ersten Python Programmierversuche unternommen. Ich bin weiter beim Eingangs beschriebenen Setup und verwende den umfangreicheren I2cSlave Sketch, diesmal mit der Standardadresse 43. Am ftDuino hängt an M1 ein einfacher ft-Motor und an O3 und O4 je eine Lampe. Der unten gezeigte Python-Code soll den Motor für 4 Sek. drehen lassen und gleichzeitig die Lampen abwechselnd blinken lassen.
Das Ganze funktioniert in 3 von 4 Fällen perfekt. Sowohl vom TX-Pi direkt gestartet, als auch per ssh Console. Leider kommt es sporadisch zu Aussetzern, die mir Kopfzerbrechen bereiten. Der Code scheint hängen zu bleiben, an völlig unterschiedlichen Stellen. Das sieht man am Modell, die Lampe bleibt dauerhaft brennen und Motor läuft dauerhaft weiter, und auf der Console wird der Fehler auch bei verschiedene Zeilen ausgeworfen. Z.B.:
Traceback (most recent call last):
File "/opt/ftc/apps/user/0640ad90-88f1-11eb-b538-0800200c9a66/test.py", line 40, in <module>
bus.write_byte_data(CLIENT, 0x06, 0x01);
OSError: [Errno 121] Remote I/O error
Habt Ihr Eine Idee was die IO Schluckaufs verursachen könnte?
Zusatzfrage:
Beim Abbremsen des Motors bin ich ins Grübeln geraten, was ich neben dem Mode auch für einen PWM Ausgangswert mitgeben muss und ob bzw. wie lang ich warten muss. Ich vermute ich muss Power mitgeben (ff) um den Motor mit max. Kraft abzubremsen und dem Prozess auch etwas Zeit lassen. Passt das oder bin ich hier auf dem Holzweg?
Danke & LG
Uwe
ich brauche nochmal Eure Hilfe. Ich habe nun meine ersten Python Programmierversuche unternommen. Ich bin weiter beim Eingangs beschriebenen Setup und verwende den umfangreicheren I2cSlave Sketch, diesmal mit der Standardadresse 43. Am ftDuino hängt an M1 ein einfacher ft-Motor und an O3 und O4 je eine Lampe. Der unten gezeigte Python-Code soll den Motor für 4 Sek. drehen lassen und gleichzeitig die Lampen abwechselnd blinken lassen.
Das Ganze funktioniert in 3 von 4 Fällen perfekt. Sowohl vom TX-Pi direkt gestartet, als auch per ssh Console. Leider kommt es sporadisch zu Aussetzern, die mir Kopfzerbrechen bereiten. Der Code scheint hängen zu bleiben, an völlig unterschiedlichen Stellen. Das sieht man am Modell, die Lampe bleibt dauerhaft brennen und Motor läuft dauerhaft weiter, und auf der Console wird der Fehler auch bei verschiedene Zeilen ausgeworfen. Z.B.:
Traceback (most recent call last):
File "/opt/ftc/apps/user/0640ad90-88f1-11eb-b538-0800200c9a66/test.py", line 40, in <module>
bus.write_byte_data(CLIENT, 0x06, 0x01);
OSError: [Errno 121] Remote I/O error
Code: Alles auswählen
if bus:
print("Client gefunden, lasse Lampe an Ausgang O1 blinken ...");
# Motor an M1 starten
bus.write_byte_data(CLIENT, 0x00, 0x12);
bus.write_byte_data(CLIENT, 0x01, 0xff);
#Lampen an O3 und O4 abwechselnd für 4 Sek blinken lassen
for i in range(10):
bus.write_byte_data(CLIENT, 0x04, 0x01);
bus.write_byte_data(CLIENT, 0x05, 0xff);
bus.write_byte_data(CLIENT, 0x06, 0x01);
bus.write_byte_data(CLIENT, 0x07, 0x00);
time.sleep(0.2)
bus.write_byte_data(CLIENT, 0x04, 0x01);
bus.write_byte_data(CLIENT, 0x05, 0x00);
bus.write_byte_data(CLIENT, 0x06, 0x01);
bus.write_byte_data(CLIENT, 0x07, 0xff);
time.sleep(0.2)
#Motor M1 gebremst abschalten
bus.write_byte_data(CLIENT, 0x00, 0x11);
bus.write_byte_data(CLIENT, 0x01, 0xff);
time.sleep(0.2)
# alle Ausgänge ausschalten -> 16 0-Bytes senden
bus.write_block_data(CLIENT, 0x00, [ 0x00 ]*16 );
else:
Zusatzfrage:
Beim Abbremsen des Motors bin ich ins Grübeln geraten, was ich neben dem Mode auch für einen PWM Ausgangswert mitgeben muss und ob bzw. wie lang ich warten muss. Ich vermute ich muss Power mitgeben (ff) um den Motor mit max. Kraft abzubremsen und dem Prozess auch etwas Zeit lassen. Passt das oder bin ich hier auf dem Holzweg?
Danke & LG
Uwe
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
So ein I²C-IO-Error kann auftreten, wenn der Client dem Host nicht schnell genug reagiert. Und der ftDuino als Client kann schonmal recht langsam sein, da er I²C zum Teil in Software macht und nebenbei noch ein paar andere Dinge tut.
Das kann man nun untersuchen. Tritt das mit dem alten 0x42-Sketch auch auf? Der ist einfacher und macht weniger nebenbei. Tritt das mit einem anderen (ggf. älteren und langsameren) Pi auch auf? Kann natürlich auch ein wackeliges I²C-Kabel, schlechte Stromversorgung und alles mögliche andere sein.
Mein erster Versuch, das in den Griff zu bekommen wäre, um "bus.write_byte_data(CLIENT, a, b)" eine kleine Funktion zu basteln, die den Fehler per "try/except" abfängt. Interessant wäre dann, ob es dann nach so einem Fehler trotzdem problemlos weiterläuft, also ob irgendwas dauerhaft klemmt. Wenn das nur einzelne Aussetzer sind, weil zufällig der Pi wenig Geduld hat und der ftDuino gerade mit anderen Tasks abgelenkt ist, dann sollte ein einfaches Retry an der Stelle eigentlich helfen.
Wie Du den Motor bremst ist Deine Entscheidung, ob Du ihn langsam auslaufen lassen willst oder ob Du ihn aktiv bremsen willst. Und wie lange das dauert hängt dann auch davon ab, was an dem Motor so mechanisch dran hängt. Im ftDuino-Handbuch gibt es dazu ein Experiment.
Das kann man nun untersuchen. Tritt das mit dem alten 0x42-Sketch auch auf? Der ist einfacher und macht weniger nebenbei. Tritt das mit einem anderen (ggf. älteren und langsameren) Pi auch auf? Kann natürlich auch ein wackeliges I²C-Kabel, schlechte Stromversorgung und alles mögliche andere sein.
Mein erster Versuch, das in den Griff zu bekommen wäre, um "bus.write_byte_data(CLIENT, a, b)" eine kleine Funktion zu basteln, die den Fehler per "try/except" abfängt. Interessant wäre dann, ob es dann nach so einem Fehler trotzdem problemlos weiterläuft, also ob irgendwas dauerhaft klemmt. Wenn das nur einzelne Aussetzer sind, weil zufällig der Pi wenig Geduld hat und der ftDuino gerade mit anderen Tasks abgelenkt ist, dann sollte ein einfaches Retry an der Stelle eigentlich helfen.
Wie Du den Motor bremst ist Deine Entscheidung, ob Du ihn langsam auslaufen lassen willst oder ob Du ihn aktiv bremsen willst. Und wie lange das dauert hängt dann auch davon ab, was an dem Motor so mechanisch dran hängt. Im ftDuino-Handbuch gibt es dazu ein Experiment.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Danke für die Rückmeldung. Ich habe noch etwas experimentiert, musste aber einsehen, dass ich mich erst mal etwas besser in Python einarbeiten muss um mich solchen Problemen zielführend anzunähern. Daher habe ich das Thema zunächst zurückgestellt.
Stattdessen habe ich den TX-Pi jetzt per USB mit dem ftDuino verbunden und arbeite mit dem ftduino_direct Sketch. Mit meinen Jungs habe ich erst eine Ampel und dann eine Schiebetür mit Lichtschranke aufgebaut und die Programmierung im ersten Schritt per Brickly umgesetzt. Das funktioniert perfekt und ohne IO-Schluckaufs und führte nicht nur bei den Kids zu leuchtenden Augen.
Im nächsten Schritt versuche ich das Schritt für Schritt in Python zu schreiben. Anhand von ein paar Beispieldateien aber vor allem von Python Tutorials. Danach mangelt es auch nicht an Ideen und Bauteilen das weiter auszubauen . Ggf. komme ich dann nochmal mit der ein oder anderen Frage um die Ecke.
Danke auch für den Hinweis zum ftDuino-Handbuch mit der Motorbremse. Das Kapitel hatte ich leider nicht mehr auf dem Schirm. Aber mit der skizzierten Funktionsweise ist auch klar was ich für Parameter mitgeben muss.
LG
Uwe
Stattdessen habe ich den TX-Pi jetzt per USB mit dem ftDuino verbunden und arbeite mit dem ftduino_direct Sketch. Mit meinen Jungs habe ich erst eine Ampel und dann eine Schiebetür mit Lichtschranke aufgebaut und die Programmierung im ersten Schritt per Brickly umgesetzt. Das funktioniert perfekt und ohne IO-Schluckaufs und führte nicht nur bei den Kids zu leuchtenden Augen.
Im nächsten Schritt versuche ich das Schritt für Schritt in Python zu schreiben. Anhand von ein paar Beispieldateien aber vor allem von Python Tutorials. Danach mangelt es auch nicht an Ideen und Bauteilen das weiter auszubauen . Ggf. komme ich dann nochmal mit der ein oder anderen Frage um die Ecke.
Danke auch für den Hinweis zum ftDuino-Handbuch mit der Motorbremse. Das Kapitel hatte ich leider nicht mehr auf dem Schirm. Aber mit der skizzierten Funktionsweise ist auch klar was ich für Parameter mitgeben muss.
LG
Uwe
- H.A.R.R.Y.
- Beiträge: 1083
- Registriert: 01 Okt 2012, 08:38
- Wohnort: Westpfalz
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Hallo Zusammen,
Ist das bei der USB-Verbindung auch so?
Grüße
H.A.R.R.Y.
Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?
Grüße
H.A.R.R.Y.
[42] SURVIVE - or die trying
-
- Beiträge: 472
- Registriert: 03 Jan 2018, 22:04
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Jein. Sofern der ftDuino an einer weiteren Stromquelle angeschlossen ist, um die Aktoren versorgen zu können, laufen die Aktoren weiter, wenn man das USB-Kabel trennt. Dient allerdings nur der USB-Port als Stromquelle, ist der Effekt nach Trennung der USB-Verbindung nicht mehr sichtbar.H.A.R.R.Y. hat geschrieben: ↑22 Mär 2021, 06:14Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?
Viele Grüße
Lars
- MasterOfGizmo
- Beiträge: 2722
- Registriert: 30 Nov 2014, 07:44
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
Das kommt drauf an, wie man es macht. Das Verhalten des TXT ist ab Werk fest einprogrammiert. Beim ftDuino programmiert man dagegen alles selbst und da kommt es drauf an, was man macht. Programmiert man ein "Keep-Alive", dann kann man den ftDuino machen lassen, was man will, wenn die Kommunikation ausfällt. Man könnte einen Roboter bei Kommunikationsausfall z.B. auch in eine "sichere Position" fahren lassen.H.A.R.R.Y. hat geschrieben: ↑22 Mär 2021, 06:14Wie jetzt: Wenn die Kommunikation via I²C zwischen Host und Device ausfällt, laufen die Aktoren des Slave / Device einfach weiter?
Ist das bei der USB-Verbindung auch so?
Das ist ja der Trick am ftDuino: Es gibt kaum vorgefertigtes Verhalten und damit z.B. auch nicht sowas wie den I²C-5-Sekunden-Bug des TXT, der seinen Ursachen ggf. in genau so einem Mechanismus hat.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
-
- Beiträge: 472
- Registriert: 03 Jan 2018, 22:04
Re: ftduino am TX-Pi per i2cslave mit Verbindungsproblem
tintenfisch hat geschrieben: ↑22 Mär 2021, 08:07Jein. Sofern der ftDuino an einer weiteren Stromquelle angeschlossen ist, um die Aktoren versorgen zu können, laufen die Aktoren weiter, wenn man das USB-Kabel trennt. Dient allerdings nur der USB-Port als Stromquelle, ist der Effekt nach Trennung der USB-Verbindung nicht mehr sichtbar.
Das stimmt, meine Antwort bezog sich auf die Programmierung via ftduino_direct. Dort würde der jetzige Status, vor Trennung des Kabels / der Kommunikation, beibehalten werden, weil, ohne ftduino_direct anzupassen, eine Überprüfung, ob die Verbindung aktiv ist, nicht stattfindet somit auch das System nicht in einen "sicheren Zustand" zurückgefahren werden kann.MasterOfGizmo hat geschrieben: ↑22 Mär 2021, 08:25[...] Programmiert man ein "Keep-Alive", dann kann man den ftDuino machen lassen, was man will, wenn die Kommunikation ausfällt. Man könnte einen Roboter bei Kommunikationsausfall z.B. auch in eine "sichere Position" fahren lassen.
Das wäre aber m.E. auch mit ftduino_direct machbar, sofern man das Sketch entsprechend anpassen würde.