RoboPro ist eine sehr schön intuitive Entwicklungsumgebung, in die man sich sehr schnell eingearbeitet hat. Dafür ein großes Lob an den/die Entwickler. Allerdings habe ich in RoboPro (V2.1.4.2) folgenden Fehler gefunden: Der Minus Operator arbeitet mit Floats fehlerhaft: 0.0 - (-1.0) = -1.0 Autsch!
Ein sehr gemeiner kleiner Fehler: Nachdem ich alle noch so absurden potentiellen Fehlerquellen ausgeschlossen hatte, veranlaßte mich schließlich die pure Verzweiflung überhaupt in Erwägung zu ziehen, dass eine Programmiersprache der Grundrechenarten nicht mächtig sein könnte.
- Ich habe einfach dieses Forum gewählt, um über den Fehler zu informieren. Gibt es zu diesem Zweck ein spezielles Portal?
- Gibt es eine öffentlich zugängliche Liste bekannter RoboPro Probleme? Dafür wäre ich sehr dankbar. Bei der Durchsicht von Programmbeispielen in diesem Forum habe nämlich festgestellt, dass der Fehler einigen Forumsmitglieder bekannt ist. Leider erst nachdem ich auf diesen Bug hineingefallen bin.
- Gibt es schon eine Version in der der Bug gefixt ist?
- Wird es Dokumentation zum Objekt-Level 5 geben?
- Welchem Zweck dient die Option "Standard Platzierung" (Dynamisch/Statisch) unter dem Reiter "Eigenschaften"?
- Wozu dient die Option "Debug" beim Pseudo-Daten-Eingang der Motorsteuerung?
- Welche genauen Auswirkungen auf den Programmablauf haben die
- Verbindungsoptionen bei Unterprogramm-Befehseingängen,
- die Lebensdaueroptionen bei Operatoren/Variablen
- und die Objektvariable-Optionen bei Unterprogrammaufrufen.
- Ist es möglich, weitergehende Dokumentation der Interna von RoboPro zugänglich zu machen? Augenblicklich ist für mich das Laufzeitverhalten schwer vorhersagbar. Fragen, die sich mir stellen, sind z.B.:
- Wird ein Netz von orangenen Befehls/Daten-Operatoren bei jeder Änderung eines Eingangswertes evaluiert, oder erst wenn der Prozess ein blaues Befehlselement erreicht, dessen Verhalten von einem orangenen Dateneingang abhängt?
- Robo Pro lässt zu, Schleifen in den orangenen Datenfluss einzubauen. Das Verhalten ist dann meist recht eigenwillig, vermutlich undefiniert. Sind diese Schleifen überhaupt zulässig?
- Warum vergehen pro Durchlauf einer Schleife mindestens 2ms, wenn man sie lokal auf dem RoboTX ausgeführt wird? Ein 500Hz Takt für eine leere Schleife auf einer 200MHz ARM9 CPU ist überraschend langsam ... lächerlich lahm. Für manche Anwendungsfälle ist das viel zu langsam. Gibt es irgendeinen Trick diese Einschränkung in RoboPro zu umgehen?
Nun ja, ein Workaround wäre die Ausführng im Online Modus: Dort laufen zwar Schleifen weitaus schneller, allerdings ist erwartungsgemäß die Sampling-Qualität der Messwerte im OnlineModus miserabel. Somit ist auch der Online-Modus für mache Anwendungen unbrauchbar. Meine erste Anwendung war ein kleiner PID-Regler der die Geschwindigkeit der Encoder-Motoren unabhängig von der Last einregelt. Lokal ausgeführt funktioniert der Regler wunderbar, wohingegen er im Online-Modus nicht zu stabilisieren ist.
Zeit zwischen dem Update der Encoder-Motor-Pulszähler im Online-Modus:- Local: dt=2ms
- USB: dt_mean=15ms / dt_max=40ms
- BT: dt_mean=30ms / dt_max=135ms
Mit dieser Tool Chain erstellte Applikationen laufen viel performanter als RoboPro-Programme. Allerdings läßt die Unterstützung durch das 4NetOS Betriebssystem sehr zu wünschen übrig: Keine interrupts, kein task switching, kein scheduler. In der milli-sekündlich aufgerufenen Funktion, in der man seinen eigenen code unterbringt, muss man regelmässig über den system call "IsRunStillAllowed()" überprüfen, ob der zur Verfügung gestellte 500µs time slot schon abgelaufen ist, um dann schnellstmöglich die Funktion zu verlassen. 500µs sind kurz! Sie reichen gerade für ca. 100 Aufrufe von "IsRunStillAllowed()". => Da kann man nicht viel Sinnvolles programieren.
Besteht evtl. die Möglichkeit, dass die fischertechnik GmbH bzw. seine Partner ihren Kunden Dokumentation des RoboTX Controllers und/oder ein API+Doku des 4NetOS zur Verfügung stellen?
Die Frage mag dreist klingen, und wahrscheinlich stehen einer Weitergabe lizenz- und patentrechtliche Gründe entgegen, aber ich denke, dass mit einer mächtigeren Programmierschnittstelle der wirklich toll ausgestattete RoboTX-Controller und Fischertechnik für eine ganz neue Zielgruppe interessant werden könnte: Nicht nur für ambitionierte Hobby-Spielkinder sondern auch für Studenten im Hochschulpraktikum.
Interessant ist diesbezüglich das Thema "Infos zu RoboPro / Yagarto C-Compiler / 4NetOS" im "Robo Pro / Computing / Software" Unterforum: Es gibt durchaus Interesse an einer leistungsfähigeren Programmierschnittstelle und auch die Bereitschaft zur Entwicklung einer solchen beizutragen. Im Forum wurde diesbezüglich auch das frei erhältliche .net micro framework von Microsoft in Betracht gezogen. Leider ist die Diskussion eingeschlafen, vermutlich aus Frustration über die Aussichtslosigkeit eines solchen Projektes wegen der fehlenden Dokumentation des RoboTX-Controllers. Bezeichnenderweise behandeln die letzten Beiträge alternative, besser dokumentierte Controller, z.B. Netduino und Arduino.
Ups, jetzt sind ganz schön viele Fragen und Kommentare zusammengekommen. Ich bin schon für einige wenige Antworten dankbar.
Beste Grüße,
Helmut
und anbei noch ein paar Verbesserungsvorschläge für RoboPro:
- Es wäre hilfreich wenn der Plus/Minus Befehl auch mit Floats funktionierte.
- Anzeigen im RoboPro Bedienfeld oder dem TX-Display können leider nicht direkt mit Floats umgehen. Das wäre beim Debuggen sehr hilfreich. Augenblicklich muss man erst einen Text-Befehl zur Formatierung des Floats in den blauen Prozess Pfad einfügen, was sehr umständlich ist.
- Ein 32-Bit-Integer-Typ wäre fein.
- Toll wäre es wenn man von lokal ausgeführten Programmen Logs/Daten auf ein lokales Dateisystem oder über Blutooth auf den Rechner übertragen könnte.
- Genial wäre es, wenn man eigenen C/C++ code o.ä. in RoboPro einbinden könnte.
- Ist es evtl. möglich, für Prozesse, die in einem Objekt gekapselt sind und nur von objektinternen Variablen abhängen, die Evaluation der Daten und Abarbeitung der Aktionen mehrfach pro Zeitscheibe anzustoßen? Dann könnte eine z.B. eine Schleife lokal sehr viel schneller abgearbeitet werden.