Brickly und ROBO-IF

[Severin8b]

Hallo zusammen!

Die Möglichkeit Brickly für den TXT verwenden zu können ist verdammt cool und da RoboPro mir jetzt nicht mehr genug Spielraum für Ideen mit dem guten alten Robo-IF lässt wollte ich fragen ob "ihr" evtl. auch Unterstütztung für das Robo-IF implementieren könntet.
Die Grenze an die ich in RoboPro geraten bin betrifft speziell die serielle Schnittstelle des Robo-If viewtopic.php?f=8&t=4048, die seit dem aussterben der Com-Schnittstelle am PC (fast) sinnlos geworden ist. Das Intelligent Interface hat nur RS232 und dürfte bei den Besitzern, u.a. wegen fehlendem Offlinemodus, ungenutzt rumliegen. Verbinde ich das Intelligent Interface mit einem gekreuztem Kabel mit der sowieso immer freien Schnittstelle des Robo-IF, hätte man bis zu 24 Motoren, 48 Eingänge und 9 Analog Inputs

Edit: Das Robo-IF per USB am TXT wäre auch eine sehr tolle Sache. Da der Com-Port des Robo-If im Online Modus nicht ansprechbar ist, lässt sich eine Kette aus drei Interface Generationen dann aber nicht realisieren.

Edit2: Mir wurde gefüstert dass das Protokoll am COM-Port nicht von Robopro, sondern vom IF selbst kommt. Klingt dann doch komplizierter als gedacht

Edit3: Eine Verbindung von TXT per USB-Seriell Adapter oder der RS232 am Ext-Port zum Intelligent Interface sollte allerdings einfach machbar sein. Ist auch eine schöne Möglichkeit der Erweiterung.

[TiniTech]

Zu Edit3 - Intelligent Interface am TXT kann ich vielleicht was beitragen:

Ich hatte diesbezüglich ja schon vor längerer Zeit darum gebeten, dass am TXT das PySerial-Module aktiviert wird. Das ist m.E. mittlerweile der Fall; darüber ließe sich ein serielles Intelligent Interface ansteuern.
Hardwareseitig müsste man darauf achten, einen USB-to-Serial-Adapter zu verwenden, der die "klassischen" +/-12V-Pegel verwendet. Die meisten ganz billigen Platinen von eBay haben m.E. nur 0/5V-TTL-Level. Wobei da nach meinem Verständnis im schlimmsten Fall der USB-to-Serial-Adapter futsch geht oder sich einfach nix tut.

Ich habe auch schon ein Projekt für eine Python-Klasse angefangen, mit der sich das Intelligent Interface aus Python heraus ansteuern lässt. Das funktioniert "im Prinzip" auch schon; allerdings sind noch einige Ungereimtheiten drin, v.a. wenn die Funktionen mit unsinnigen Werten aufgerufen werden. Auch von den Analogeingängen bekomme ich keine sinnvollen Werte - über die RoboConnectBox aber schon; ich bin noch nicht dahintergekommen, woran das liegt und komme leider gerade nicht dazu, mehr zu machen. Grundlegendes Ansteuern von Motoren und Auslesen der Digitaleingänge geht aber.

Getestet habe ich bisher nur unter Windows auf meinem Entwicklungsrechner - ich habe die Komponente aber so aufgebaut, dass es eine neue ftIntIF-Klasse gibt, die mit der seriellen Schnittstelle initialisiert wird, die verwendet werden soll. Daher müsste der Umzug auf den TXT in dieser Hinsicht ohne Anpassungen machbar sein.

Wenn das jeman "jetzt sofort" in Angriff nehmen möchte: Bevor sie/er bei Null anfängt, stelle ich mein Python-Quelltext gerne zur Verfügung; auf GitHub hochladen wollte ich das aber erst, wenn ich eine Fassung habe, bei der die Grundfunktionen vorhanden und dokumentiert sind.

Für die eigene Weiterentwicklung nehme ich auch gerne Tipps/Unterstützung zu folgenden Themen an:
- Tastendrücke werden vom Hauptthread "verpasst": Idee ist, dass es einen Thread gibt, der im Hintergrund die Eingänge abfragt; wenn ich dann in der "Nutzanwendung" eine Schleife schreibe, die so lange laufen soll, bis ein Schalter gedrückt wurde (in meinem Fall sähe das so aus: while not intIF.getInputDigital(2): [...]), kann sein, dass die nie endet, weil der Schalter nicht im richtigen Moment abgefragt wird. Scheint mir eher ein Grundsätzliches Problem zu sein, das auch bei RoboPro auftaucht - da würde ich gerne eine Funktion "Eingang hatte Flanke 0-1 [bzw. 1-0] seit letzter Abfrage" oder ähnliches implementieren (ist nur noch nicht passiert...). Scheint euch das sinnvoll? Wie macht ftRoboPy das?

- PyDoc unter Eclipse: Wie krige ich denn eine Dokumentation "gerendert" damit ich mal "ohne störenden Quelltext" sehen kann, wo ich noch nachbessern muss...

[Torsten]

Hallo TiniTech,

Für die eigene Weiterentwicklung nehme ich auch gerne Tipps/Unterstützung zu folgenden Themen an:
- Tastendrücke werden vom Hauptthread "verpasst": Idee ist, dass es einen Thread gibt, der im Hintergrund die Eingänge abfragt; wenn ich dann in der "Nutzanwendung" eine Schleife schreibe, die so lange laufen soll, bis ein Schalter gedrückt wurde (in meinem Fall sähe das so aus: while not intIF.getInputDigital(2): [...]), kann sein, dass die nie endet, weil der Schalter nicht im richtigen Moment abgefragt wird. Scheint mir eher ein Grundsätzliches Problem zu sein, das auch bei RoboPro auftaucht - da würde ich gerne eine Funktion "Eingang hatte Flanke 0-1 [bzw. 1-0] seit letzter Abfrage" oder ähnliches implementieren (ist nur noch nicht passiert...). Scheint euch das sinnvoll? Wie macht ftRoboPy das?

in ftrobopy läuft ein Hintergrund-Thread, der "ungefähr" alle 10 ms die aktuellen Daten vom TXT (im TXP/Socket-Modus), bzw. der TXT-Motorplatine (im direct-Modus), abholt. Die Firmware der TXT-Motorplatine ist (im Gegensatz zur TXT-Linux-Platine) echtzeitfähig und scannt die Hardware-Eingänge mit einer Frequenz von 1kHz. Das ist z.B. für die schnellen Counter des TXTs notwendig.

Weder MS-Windows auf einem typischen PC noch das Linux des TXTs sind "echtzeitfähig", d.h. es gibt dort keine garantierten Antwortzeiten. Im Extremfall kann es also auch mal vorkommen, dass die Daten vielleicht erst nach 50 ms (oder noch länger) abgeholt werden. Da die TXT-Motorplatine die Ereignisse nicht puffert, kann es also durchaus zu "verloren gegangenen" Schalt-Ereignissen kommen, sowohl in ftrobopy als auch in ROBOPro (beide laufen ja nicht auf der Motorplatine, sondern nur unter Linux oder Windows).

Ausweg in ftrobopy Python-Programmen: man sollte immer dafür sorgen, dass der (unsichtbare) Hintergrund-Thread "ausreichend" Zeit für den Datenaustausch mit dem TXT (bzw. der TXT-Motorplatine) bekommt. Dies erreicht man am Einfachsten über kurze time.sleep(0.01) Befehle im Python-Hauptprogramm. Während dieser "sleep"-Zeiten bekommt der Hintergrund-Prozess CPU-Zeit, um einen Datenaustausch vorzunehmen.

die Abfrage eines Tasters sollte z.B. niemals so aussehen:

Code: Alles auswählen

while taster.status()==0:
  pass

(in diesem Fall würde der Hintergrund-Thread nicht genügend Zeit abbekommen, weil der Hauptprozess den Schalterstatus -unnötigerweise- mit einer sehr hohen Frequenz abfragt)

sondern immer so:

Code: Alles auswählen

while taster.status()==0:
  time.sleep(0.01) # wait 10ms

Vielleicht helfen Dir diese Tipps ja schon etwas weiter.

Viele Grüße
Torsten

[MasterOfGizmo]

Das sollte alles prinzipiell kein großes Problem darstellen. Alles was sich irgendwie aus Python ansprechen lässt kann man mit relativ geringem Aufwand aus Brickly ereichbar machen. Zum einen habe ich selbst keines der besagten Interfaces und zum zweiten ist die Zielgruppe natürlich eher klein, so dass sowas in der normalen Ansicht vielleucht nicht direkt sichtbare sein sollte, da das 99% der User verwirrt und nur 1% etwas damit anfangen kann. Aber das lässt sich schon irgendwie machen. Notfalls z.B. durch ein zusätzliches verstecktes Skill-Level oder indem man solche Sachen erst via BrickMCP einschaltet.

Wenn die Anleitung von Esther halbwegs fertig ist werde ich mal ein Tutorial machen, wie man selbst Erweriterungen in Brickly einbaut. Das ist gar nicht so schwierig.

[PHabermehl]

Hallo MoG,

das wäre eine Idee: Über BrickMCP Addons mit Custom-Blöcken installieren/deinstallieren...

Ist das denkbar, daß wir da ähnlich wie mit den Projekten einfach Daten hin- und herschieben?

Gruß
Peter

Nebenbei, die LibRoboInt für Linux zum ansteuern des Robo Interface gibt's ja schon seit Jahren. Auch mit dazugehörigem Python-Modul...
Das müßte nur noch in die cfw integriert werden, da träume ich auch von.
Dann könnte man zeitkritische Tanks auf dem TXT laufen lassen und Nebensächlichkeiten, wie Lampen, Kompressor usw. mit Robo IF bzw. IO -Extension bedienen...

[MasterOfGizmo]

das wäre eine Idee: Über BrickMCP Addons mit Custom-Blöcken installieren/deinstallieren...

Im Prinzip ist das machbar. Man muss ein paar Dinge dafür basteln:

• Brickly muss auf Javascript-Seite nach Erwiterungspaketen z.B. in Form von custom_blocks_roboif.js suchen und alles was es findet laden
• Brickly muss ab einem bestimmten Skill-Level dynamisch Kategorien zur Toolbox z.B. aus custom_blocks_roboif.xml hinzu laden, damit die neuen Blöcke dann in einem eigenen Menüpunkt links erscheinen
• Die Brickly-App muss nach passendem Python-Code suchen und dann z,B. eine Datei custom_blocks_roboif.py laden und dort steht dann TXT-seitig drin, was die Blöcke auf dem TXT auslösen sollen.

Nebenbei, die LibRoboInt für Linux zum ansteuern des Robo Interface gibt's ja schon seit Jahren. Auch mit dazugehörigem Python-Modul...

Ist auch machbar, hiesse aber, dass man diese C-Lib übersetzen und mitliefern muss. Es dürfte definitjv machbar ein, das RoboIF direkt aus Python anzusprechen. Wäre auf jeden Fall der leichter wartbare Weg, weil die ganze RoboIF-Anbindung dann einfach im Python-Teil der Brickly-Erweiterung stecken könnte.

[PHabermehl]

Hi Till,
Es eilt ja nicht, aber die plug in Idee finde ich sehr gut - das passt ja auch zu deiner grundsätzlichen Philosophie, weniger benötigte Funktionen auszulagern.
Gruß
Peter