Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 05 Apr 2020, 01:26

Hallo...
Also es funktioniert. Man kann einen Arduino oder ftduino mit RoboPro steuern.

Ja, ich werde nun mal ein paar Tester hiermit suchen.
-Aber- erst noch mal ein paar Fragen an euch:

Counter<> Genauigkeit
Die Frage ist: Wie genau soll ein "Counter" sein?
Hintergrund: Man kann im ftduino einen Encodermotor eine Strecke (Impulse) fahren lassen.
Nun läuft der Motor jedoch nach, egal ob mit oder ohne Bremse. Die ftduino.h macht leider keinen Unterschied bei Countern und Distanz.
Ich vermute das es ehr von der Arduino-Programmierung kommt als von ft.
Nun hab ich das Problem, wenn ich von RoboPro eine Distanz vom ftduino fahren lasse, wird scheinbar beim ftduino Counter
der zufahrende Wert (z.B. 10) von Null abgezogen und dann der Counter bis 0 gefahren und dann gestoppt (+ ein paar Impulse).
Somit steht er dann z.B. auf 11.
Somit driftet die wirkliche Position, weil ja beim nächsten fahren der Wert ja wieder von Null aus gemessen.
Auch geht der "mitzählende" Counter verloren.
Es ist die Frage ob ich mir die Arbeit machen soll, einen extra mitzählenden Counter zu programmieren.
Wie oft braucht man so etwas bei einem ft-Modell, wo sowieso ein Nullpunkt-Taster da ist?
Der Aufwand ist momentan gerade etwas hoch. Oder doch? (11 zu 190 bei einer Motor Umdrehung)

Art der Eingänge
Es ist die Frage ob man "Anfängern" zumuten kann, die Eingänge per Arduino IDE umzustellen.
Hintergrund: Man hat 8 Eingänge die einen (digitalen) Taster oder ein Widerstand einlesen und mit:
ftduino.input_set_mode(Ftduino::I1, Ftduino:: SWITCH);
ftduino.input_set_mode(Ftduino::I1, Ftduino:: RESISTANCE);
umgestellt werden.
Die Auswertung der Umschaltung ist bisher nicht drin. Für -mich- ist das nun kein großes Problem.
Ich hatte zwischenzeitlich einfach die letzten beiden Eingänge beiden als Widerstand laufen lassen.
Nur tauchen dann bei dem Interfacetest von RoboPro bei unbeschalteten Eingängen manchmal Werte auf und die Taster sind auf 1.


Alles in allem ist es ja nur ein TX "Light" Interface. Somit laufen nur die überwiegende Sachen.
Ich denke das so 95% der "normalen" ft Modelle laufen (wenn nicht noch mehr).
Ich habe aber nicht alle fertigen Programme getestet - auch weil ich nicht die CDs von allen Kästen und damit die Programme habe
bzw. weil ich nicht alle Modelle aufbauen und testen kann.

Die nächste Sache ist die Anleitung. Ich muss die noch mal überarbeiten.
Es sind momentan zwei (und die noch gemischt), wobei ich mehrere Bereiche habe u.a.:
Arduino Uno
Arduino Uno; ohne alles weitere; Steuerung "nur" von z.B. LEDs... über RoboPro (sehr Gut zum Lernen mit Elektronik) (kleine Sachen auch ohne Netzteil)
Arduino Uno; mit Motortreiber (H-Brücken); (teilweise mit ft nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; (Motor, Lampen,... auch fremde Motoren mit viel höherer Spannung nutzbar)
Arduino Uno; mit Adafruit Motortreiber Shield 2.0; mit Eingangsbeschaltung (Eigentlich erst ab hier voll mit ft nutzbar) -- ("Umbau" genannt)
Arduino Uno; mit Seeed Grove - Baseborad und den "normalen" Sensoren und Actoren und dem OLED-Display (Anzeige der Zustände der Ein- und Ausgänge)
Sondermodell Arduino Uno mit Adafruit Motortreiber Shield 2.0 und HC05 Bluetooth für mobile Roboter.

Die Funktion beim Uno ist jedoch eingeschränkt, z.B. die Counter. Der Uno hat nur einen Mega hat drei. "Man" könnte die noch dazu dichten, hab ich aber bisher nicht. Der "Umbau" bezieht sich auf Widerstände für die Eingänge. Meine Erfahrungen ist, dass das ft-Modell nahe beim Monitor steht und der Stört sehr stark. Deswegen muss man Widerstände "dazu zuschalten". Entweder man schraubt sie in die ft-Stecker oder halt eleganter man lötet die auf das Adafruit Motortreiber Shield 2.0 mit drauf. Ich hab zusätzlich eine 20pol. Buchse drauf gelötet und kann so das Kabel mit der Buchsenleiste vom alten parallelen PC/C64/Atari... Interface nutzen. Auch hab ich die Bezeichnung so gelassen. M1 ist auch M1, I1 ist E1 usw. .
Ich hab auch eine Anleitung dazu gemacht und ein paar Modelle beschrieben die bisher eingesetzt habe z.B. Ampel mit Auto-Sensor...
Die Modelle laufen nun schon einige Zeit im "Schulbetrieb" (Schulpausenbetrieb) und haben auch schon ein paar Modellschauen, wo Besucher selber programmieren konnten überlebt. Somit sollte das auch bei anderen laufen.

ftduino der eigentliche TX Light.
Ist am weitesten mit der Programmierung.
Jedoch (bisher) kein: I2C, Display, Umschaltung der Eingänge, Counter Reset, Ultraschallsensor (hier nur die fehlende Umschaltung der Eingänge, sollte laufen, habe es aber nicht ausprobiert, weil ich meinen Sensor nicht finde :-( )
Ansonsten sollte der TX Light auf dem ftduino laufen.

Der Arduino / ftduino simuliert einen TX Controller am PC und dem RoboPro.

Hinweise:
Die Steuerung geht über RoboPro - über USB Kabel und eine Spannungsversorgung.
Einmaliges Aufspielen der Software über die Arduino IDE.
Speziell Arduino Uno:
-Einschalten: 1. Spannungsversorgung, dann 2. der USB Anschluss
-Ausschalten 1. der USB Anschluss dann 2. die Spannungsversorgung

Bisher getestet unter der RoboPro Version 3.1.2. (CD-TX Explorer) oder der neusten, Stand 5.4.20.

Mein Projekt habe ich von:
https://github.com/mr-kubikus/fx1-arduino-parser
übernommen. Ich habe also nicht alles neu gemacht.
Die ftduino - Variante hat eigentlich nur noch die Kommunikation mit dem PC gemeinsam.
Insgesamt ist es immer noch nicht 100% fehlerfrei, aber so -ohne- Abstürze (bei mir) lauffähig.

Ich denke es ist nun sinnvoll, wenn ein paar Leute das mal bei sich testen würde. Insgesammt währe es Schade wenn es mit mir einschlafen würde.
Da steckt ja viel Arbeit drin.
Ich denke das wir mal mit der ftduino - Version anfangen. Oder doch lieber mit der Arduino - Variante?
Es soll zumindest so sein, dass ich nicht mit so vielen Meldungen bombardiert werde.
Bei dem ftduino TX Light Programm ist meine Beschreibung im Programm besser und man hat halt keinen weiteren Umbau.
Zudem sollte es am besten erst mal über E-Mail laufen. Danach kann es ja über das Forum laufen.
Hier nun sofort alles online zustellen und auch Anfängerfragen bis ins letzte Detail hinien zu klären, geht (denke ich) über meine Möglichkeiten hinaus. Deswegen besser diesen Weg.
Also wer hätte Interesse und einen ftduino?


Mit freundlichen Grüßen
fishfriend
Holger Howey

PS Bitte RoboPro Version angeben. Etwas Erfahrung bei der Arduino IDE sollte auch vorhanden sein.

PPS
Um es noch mal klarzustellen. Der TX-Light ist kein 100% Ersatz für einen fischertechnik TX oder TXT Controller.
Es ist auch -nicht- als Konkurrenz gedacht. Es sollten die vorhandenen Arduino Unos, an der Schule, für die nicht mehr
vorhandenen ft Interfaces genutzt werden. Auch als Grund war fischertechnik als DIE Alternative zu Scratch, Arduino IDE und ("Baller-") Spielen einzusetzen. Das Ganze dann ab Klasse 5. Ziel war es erst nur Eingänge und Ausgänge zu steuern und damals "vorhandene" ft Modell anzusteuern.
Ich habe dann nur noch meine ft Modelle benutzt.

PPPS
Es kann ja sein, dass z.B. 4 Counter bei der und der RoboPro Version nicht laufen. Das kann es ja dazu führen, dass z.B. Counter rausgenommen
werden. Ob und wie weit nun z.B. I2C Unterstützung mit reinkommt, kann das ja dann auch von anderen Programmieren kommen. Mal schauen.

fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 07 Apr 2020, 00:03

Hallo...
OK testen wir den ftduino als erstes. Wer möchte testen?

Momentan ist die neutse Version ftduino 7_3 für RoboPro Version 4.6.6. (neuste RoboPro Version, ist für "TX-Light" aber eh egal)

Vorraussetzungen:
Den ftduino "normal" laut ftduino-Anleitung installieren
Treiber laufen, evtl. einige Experimente gemacht...
Verschiedene Arduino Programme schon mal augespielt.
RoboPro installiert

Kurzanleitung:
Die ZIP-Datei entpacken und mit der Arduino IDE auf den ftduino laden.
RoboPro starten
RoboPro auf TX stellen
Bei Interface/Schnittstelle Robo TX... Controller,
OK
Bluetooth - Alle COM Schnittstellen anzeigen
COM ... (ftduino bootlader) anklicken // COM-Nummer ist vom Rechner abhängig
OK
Das wars, du hast ein Arduino/ftduino RoboPro Interface! ...

Funktionstest:
RoboPro Interface Test, ftduino ohne weitere Anschlüsse
Wenn du M1 auf rechts / links stellst wird die rote LED auf dem ftduino ein und ausgestellt.

... und das Interface läuft sogar... :-)

#############
Erste Macke :-(. Der Counter will mit einem Encodermotor, wenn er nur mit M1 betrieben wird, nicht zählen.
Man muss momentan am Anfang einmal z.B. "M1 auf Distanz 10" fahren, 3 sec stoppen, dann "Distanz M1 Stop" machen.
Dann läuft der Counter auch mit einem "normalen" Motor. (kommt noch in die Initialisierung)
Todo:
Display am ftuino, Counter Reset und Umschaltung der Eingänge sind noch nicht drin.

Traut euch!!

Mit freundlichen Grüßen
fishfriend
Holger Howey

sven
Beiträge: 2152
Registriert: 18 Okt 2010, 18:13
Wohnort: Rahden
Kontaktdaten:

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von sven » 07 Apr 2020, 08:50

Hallo!

Das hört sich sehr gut an und möchte gerne unterstützen!

Ich habe ja sogar einen ft-Duino mal auf ner Nordconvention gekauft und somit am Lager.
Leider kam ich bisher nicht wirklich dazu den mal zu nutzen, weil ich mich eben nicht mit C-Programmierer usw. auskenne.
Daher finde ich die Ansteuerung mit RoboPro eine super Sache, auch wenn das natürlich kein Ersatz für TX oder TXT ist.
Aber wenn das gut funktioniert, kann das ja sicherlich noch weiter entwickelt werden.
Der ft-Duino ist günstig und für einfache stationäre Modelle eine super Sache.
Vor allem mit RoboPro ist der EInstieg dann sehr leicht zu bewältigen.
Auch kann man direkt ft Komponenten anschließen und muss sich nicht erst noch irgendwie ein Gehäuse basteln!

Ich versuche mal mir das heute noch in Ruhe anzuschauen und ans laufen zu bringen.
Gebe dann hier eine Rückmeldung.

Gruß
sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!

jodeka
Beiträge: 20
Registriert: 10 Dez 2019, 22:09

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von jodeka » 07 Apr 2020, 19:26

Hallo,

klingt ambitioniert Dein Projekt.

Ich möchte nur folgende Anmerkung machen.

Meiner Meinung nach ist das Protokoll für das Robo-Interface oder
Intelligent Interface wesentlich einfacher und auch gut beschrieben.

Auch die Übertragungsraten an der seriellen Schnittstelle sind nicht
hoch.

Steuerungen mit 8 Eingängen sowie 8 Ausgängen lassen sich ohne Probleme
realisieren. (Dazu könnte man noch 2 Analogeingänge dazu packen)

Bei der Firma Didacta (Kroatien) gibt es jetzt auch Arduino-Shields für
Fischertechnik.

Wenn du jemanden zum Testen suchst, kann ich Dir (Dank Corona) helfen.

LG jode

fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 07 Apr 2020, 23:52

Hallo...
@ jodeka
Hast du etwas mehr Infos zu dem Shield? Ich finde gerade nichts darüber.
Also das Protokoll selbst steht ja fest. Etwas dumm ist nur dass manche Beschreibungen im www sich nicht auf den letzten Stand beziehen. Klar kann man auch andere nehmen. Das andere Problem war dass auf manchen Schulservern es nicht so einfach is,t ein Update einzuspielen. Somit hatte ich schon mal verschiedene Versionen.
Möchtest du die Arduino Version probieren oder die für den ftduino?

Am besten schreib mir eine PM / e-Mail.
Mit freundlichen Grüßen
fishfriend
Holger Howey

PS
Also auf folgenden Systemen läuft es schon mal: Vista Win7 Win8 und Win8.1

jodeka
Beiträge: 20
Registriert: 10 Dez 2019, 22:09

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von jodeka » 08 Apr 2020, 09:43

Hallo,

die Web-Seite von Didacta erreicht man unter:
http://www.didacta.hr/index.php?jezik=1

Ich habe schon ein Modul für den Micro:Bit.
(zum Fernsteuern über Bluetooth)

Zum Betatesten werde ich Dir noch ein E-Mail
schreiben.

LG jode

fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 08 Apr 2020, 10:35

Hallo...
Ok, danke für die Info. Werd ich mir näher anschauen.
Mit freundlichen Grüßen
fishfriend
Holger Howey

sven
Beiträge: 2152
Registriert: 18 Okt 2010, 18:13
Wohnort: Rahden
Kontaktdaten:

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von sven » 11 Apr 2020, 11:00

Hallo!

So, ich bin jetzt voran gekommen.

Bei mir läuft das soweit, auch unter Mac OSx in einer Windows VM.
Via Interface-Test kann ich Taster, Motor, Lampe usw. steuern.
Alles weitere teste ich noch in Ruhe durch.

@Holger:
Wie hast Du das denn mit Extension geplant?
Koppelt man dann mehrere ftDuino via I2c?

Gruß
sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!

fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 11 Apr 2020, 14:03

Hallo....
Na siehste, geht doch.
Eigendlich soll das Ganze Grundsätzlich laufen.
Was ich z.B. nicht so schön finde ist die Vermischung von Distanz und Counter.
Jedesmal wenn der Befehl Distanz aufgerufen wird sind die alten Werte vom Counter weg.
Kann man mit leben und betrift warscheinlich nur 0,01% der User. Aber OK.

Tja die Extension... Also mit dem UNO geht da so garnichts. Zu viele Variabelen, zu wenig Speicher...
Was man mit dem UNO aber machen kann ist jedem M-Ausgang einen Schrittmotor zu spendieren oder man kann
z.B. Beine mit 3 Servos machen - je M-Ausgang (Hallo Spinnen...)
Steuerung ist halt über I2C.

Kopplung, tja. Das blöde ist halt das ich die TX-Extension nicht hin bekomme. Zum Sniffen fehlt mir momentan einfach die Zeit.
Die "Lösungen" im www sind meist nur für den 485-Bus Master-Slave nicht jedoch davor, also die Kommunikation zwischen dem PC
und dem ersten TX. Da bin ich für jeden Tipp dankbar.
Auch mehrere Haupinterfaces gehen so nicht. Der ft-Treiber trennt hier, nicht der Arduinotreiber (so wie ich das sehe, bin aber noch am testen).
Mag auch sein das der 20ms Event vom PC (Abfrage TX) eine Rolle spielt.
Ich hatte mir eine größere Industrieanlage überlegt die nur mit UNOs läuft.
Die Industrieanlage von ft hat ja auch ein spezielle Kommunikation unter den TXT.
Ich hatte mir das mal kurz angeschaut, bin da aber noch nicht weiter.

Mit freundlichen Grüßen
fishfriend
Holger Howey

sven
Beiträge: 2152
Registriert: 18 Okt 2010, 18:13
Wohnort: Rahden
Kontaktdaten:

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von sven » 11 Apr 2020, 15:24

Hallo!

Geht es denn nicht wenn man einfach mehrere ftDuinos an den USB hängt?
Die würde dann ja an verschiedenen COMs hängen.
So müsste man die doch irgendwie ansteuern können.
Das würde ja schon reichen. Bei ner Kopplung via I2C wird man vermutlich die angekoppelten ftDuinos nicht als Extension ansprechen können.

Na ja, vielleicht bekommst Du das ja noch hin oder jemand anderes der sich da auskennt kann helfen.

Gruß
sven
Dieses Posting gibt ganz allein meine persönliche Meinung wieder!

Benutzeravatar
ski7777
Beiträge: 847
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von ski7777 » 11 Apr 2020, 19:20

Hallo Holger,

Guck Mal in die ft:pedia: https://neu.ftcommunity.de/ftpedia/2018 ... 2018-2.pdf
Ab Seite 60 findest du alles zur Kommunikation. Solltest du noch Detailinfos brauchen, melde dich einfach.
Das was dort steht ist sozusagen die Zusammenfassung aus allen (teilweise veralteten) Infos, die man aktuell so findet. Funktionieren tut es ganz sicher :D

Viele Grüße
Raphael

fishfriend
Beiträge: 484
Registriert: 26 Nov 2010, 11:45

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von fishfriend » 11 Apr 2020, 22:58

Hallo...
Eigendlich wird es hier OT aber OK, ich hoffe das sich die ftduino Tester die sich evtl. noch melden nicht abgeschreckt werden.


Ich kämpfe damit, dass sich manche Veröffentlichungen auf alte Versionen beziehen oder fehlerhaft waren und die damalige Entwicklung weiter ging.

Ein Beispiel ist das Display. Ich kann Dinge auf den Display darstellen OK. Wenn ich RoboPro benutze hat der TX ja die entsprechende Firmware drauf.
In den Beispielen ist erst gar nichts, dann 76 Zeichen, dann mehr Zeichen und dann auch Grafik. Ähnlich ist es beim I2C...

Auch muss man manchmal verstehen, dass einige Aufgaben der TX (ftduino) für sich macht. (Stopp mal einen Motor der über Distanz angesteuert wird)
Auch der Counterreset gehört dazu: Anforderung von RoboPro -> TX führt ihn aus und gibt Bestätigung an RoboPro. (OK das ist jetzt nicht so schwer).
Da kommt aber noch der momentane Zustand vom Counter dazu, der aber nur alle 20ms abgefragt wird. Auch ist ja klar das der erste Counter die Nummer 0 hat, also von 0-3, die Anzahl die angegeben wird ist 4 und der ftduino hat die Nummerierung von 1-4. ...
Auch startet der nur wenn man einmal den Counter über Distanz anspricht... Aber OK ich arbeite mich dadurch.

Ich habe nun ein Projekt vom Arduino Uno weiterentwickelt und auch auf den ftduino übertragen. Hier wird der ganze Datenstrom in einen Speicherbereich geschrieben. Über einen Pointer werden nun alle Variablennamen darübergelegt. Dumm nur wenn sich das Verschiebt, weil z.B. die Anzahl der Displayzeichen sich geändert hat. Da sind neue Funktionen mit neuen Variablen dazugekommen und auch Reserve wird anders genutzt.
Ich denke ich hab die meisten Sachen zum laufen gebracht. Wenn ich aber mir die "alten" anschaue und versuche diese zu übertragen, muss ich wissen wo die nun stehen.

So, nun die Extension. (Ich muss zugeben, dass ich momentan nicht 100% drin bin)
Das Interface muss mitteilen das einen Extension da ist.
Hier wird vom RoboPro eine Abfrage gestartet ob sich die Hardware geändert hat.
Es kommt nun eine Antwort (welche?) vom Masterinterface.
Das Datenpacket ändert sich und nun wird nach dem TA-Local "die" TA-EXT_n gesendet. Vom 485-Protokoll hab ich in Erinnerung, dass alle vom Master gesendet werden. Ist halt die Frage ob der Master auch alle an den PC sendet obwohl nur eine dran hat.
Nun kommt aber wieder diese Sache mit den darüber gelegten Variablennamen wieder.
Ich muss also die Struktur der Variablen "umschalten" oder ich lege fest, dass von Anfang an z.B. 2 Extension da sind und passe die Variablenstruktur darauf an. Nur momentan krieg ich es nicht gebacken, RoboPro zusagen, hey da hängt mehr dran. So dass er mir zumindest im Interfacetest die Extension anzeigt. Mal schaun...

Mit freundlichen Grüßen
fishfriend
Holger Howey

Benutzeravatar
ski7777
Beiträge: 847
Registriert: 22 Feb 2014, 14:18
Wohnort: Saarwellingen

Re: Arduino, ftduino mit RoboPro steuern und Betatester gesucht

Beitrag von ski7777 » 11 Apr 2020, 23:26

Also...

Solltest du es noch nicht getan haben, dann lies am besten den ft:pedia-Artikel komplett durch und schau dir auch gerne den Source Code dazu an.
Ich weiß, dass wahrscheinlich vieles schlecht verständlich ist. Deshalb gerne hier weitere Erläuterungen

Ich werde jetzt immer von Codes sprechen. Hierfür einfach ab Seite 62 nachlesen.
ROBOPro macht am Anfang eine Abfrage mit Code 7. Darauf musst du mit Code 107 antworten. Wie beschrieben, musst du dort entsprechend die Bytes für die Extensionen auf 1 setzen, wenn diese verfügbar sind.
Für die Kommunikation würde ich folgendes vorschlagen:
Der Master sollte die Daten aller Extensionen kennen. ROBOPro teil mit Code 2 mit, welche Extensionen es gerne auslesen würde und du musst entsprechend mit 102 antworten. Wie immer steht in jedem Datenblock am Anfang die ID der Extension (0=Master, 1=EXT, ...)
Mit dem 2/102er würde ich ähnlich verfahren. ROBOPro sendet die die Konfigurationen und du speicherst die einfach ab und quittierst dies. Die interne Kommunikation mit den Extensionen musst du dann händeln.
Counter Reset ID: Du hast einen initialen Wert (0). Solange ROBOPro einen höheren Wert als deinen sendet, musst du resetten. Du darfst den Wert, mit dem du antwortest nur dann mit dem zuletzt empfangenen gleichsetzen, wenn du seit der letzten Erhöhung seitens ROBOPro auch einen Reset durchgeführt hast.
Motor Command ID: Hier gilt das gleiche, wobei es von ROBOPro etwas unfair wäre, die ID zu erhöhen, während der Motor noch fährt. Grundsätzlich gilt aber: Du darfst erst gleichziehen, wenn du mit der Aktion fertig bist. Wie du den beschriebenen worst Case händelst, bleibt die überlassen.

Wenn es weiterhin Probleme gibt, kannst du mich gerne per IRC/Riot kontaktieren oder meldest dich bei mir per E-Mail zwecks Austausch von Handynummern.

Gruß
Raphael

P.S.: Sofern I²C das ganze von der Geschwindigkeit und der Arduino mit der Speicherplatz schaffen, können wir natürlich mehr Extensionen anschließen. Die TA_ID hat 32 bit, Code 107 leider nur Platz für 24, den könnte man aber auch noch durch einen neuen Code ersetzen :D

Antworten