Bug in Robo Pro / Fragen+Komentare

[hamlet]

Liebes Fischertechnik-Team,

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?

Fragen zu undokumentierten RoboPro Funktionen:

• 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

Yagarto C-Compiler Tool Chain:
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.

[niekerk]

Hi all,

My very short reaction to the above well written posting: +1

Paul

[peter.poetzi]

Stimmt:

0 - (-1) = -1 (siehe Bild)
0 - 1 = -1 (auch getestet)
das ist 100%ig ein Fehler

Wenn man alles in Integer rechnet kommt das richtige heraus!

PS: Ich habe die aktuellste Beta-version

[Janosch Kuffner]

Guten Tag,

vielen Dank für das ausführliche Posting.

Wie Sie in Ihrem Posting bereits schreiben sind einige Fragen und Kommentare zusammengekommen. Wir möchten auf möglichst alle Ihre Fragen und Kommentare einzugehen. Daher bitten wir Sie um Verständnis dafür, dass wir noch etwas Zeit benötigen um eine ausführliche Antwort zusammenzustellen.

Der von Ihnen gemeldete Fehler des Minus Operators ist uns bekannt und die Lösung für das Problem liegt bereits vor, so dass dieser Fehler mit dem nächsten Softwareupdate behoben werden kann.

freundliche Grüße

Janosch Kuffner
fischertechnik-Team

[Dirk Haizmann ft]

@ Janosch
DANKE für diese Info!

ft

[hamlet]

Hallo
mir ist ein weiteres Problem in RoboPro aufgefallen:
Der Abstands-Befehl der erweiterten Motorsteuerung wird von einem Unterprogramm-Befehlsausgang nicht korrekt weitergeleitet.
Wenn ich einen "Abstand"-Befehl aus einem Unterprogramm über einen Befehlsausgang an einen Motorausgang weiterleite, scheint er ignoriert zu werden. Wenn ich den Befehl hingegen innerhalb des Unterpogrammes dierekt mit einem Motoraugang verbinde, verhält sich das Programm wie erwartet.
Beste Grüße,
Helmut

[vleeuwen]

Are you able to show a image of you test program?
Or send me the .rpp file with the isolated problem by e-mail.

[hamlet]

Hello,
the simple program below demonstrates the problem:
Subroutine "OK" works as expected, it runs the motor for 500 ticks, whereas subroutine "KO" does not start the motor at all. The only difference between the two sub-programs is that in "OK" the distance command is connected directly to the motor otput, whereas in KO it is linked to the motor output via the sub program command output.
The program rpp is available here http://www.alice-dsl.net/helmut.schmuec ... blem01.zip
cheers,
Helmut

[vleeuwen]

1)
The problem with the -1 is an old one.
2)
In 2.1.4.2 are some issues related with the extended motor control.
I am only able to test your program with the RoboRpo beta 308.
The extended motor control seems to be redesigned in this version.
The program runs two times. with no problems.

General remark:
Some issues are partial resolve in some betas.
But sometimes there are arriving new issues.
Beta versions are basically not reliable and not suitable for end-users.
Also the documentation is not always up to date.

I only react on this problem to indicate that it could be an issue in the last official version but that it also has had attention.

[Dirk Fox]

Hallo Robo-Pro-Fans,

es gibt noch eine ganze Reihe weiterer kleiner Hässlichkeiten in Robo Pro - vielleicht lassen die sich hier einmal auflisten, in der Hoffnung, dass sie in der nächsten Version bereinigt sind?

Ich mache einmal den Anfang mit ein paar Fehlerchen im Zusammenhang mit dem Liste-Element:

- Fließkommazahlen werden von Robo Pro in amerikanischer Schreibweise mit einem "." als Dezimaltrennzeichen geschrieben; in einer CSV-Datei gespeichert lassen sich solche Werte nur mit Aufwand weiterverwenden. Das schränkt die Eignung des TX für Messreihen leider erheblich ein.

- In den Eigenschaften des Liste-Elements kann für eine CSV-Datei auch der Titel einer Wertespalte festgelegt werden; wie das geht, muss man aber erraten: in der Dokumentation findet sich kein Hinweis darauf (Tipp: man versuche es mit dem rechten Freitext-Eingabefeld unter "In .CSV Datei speichern")

- Will man mehrere Listen in einer Datei speichern, so muss man festlegen, welche Daten in welche "Ergebnisspalte" eingetragen werden. Das lässt sich ebenfalls einstellen, nämlich an dem Auswahlfeld mit der Eingabemöglichkeit 1-20; ein weiteres "undokumentiertes Feature".

- In den Liste-Eigenschaften kann man zwar als Trennzeichen ein Semikolon oder einen Tabulator wählen; das ignoriert Robo Pro aber geflissentlich, und verwendet munter ein Komma. Ärgerlich beim Import der CSV-Datei in ein Tabellenkalkulationsprogramm (wenn es sich auch mit etwas Fummelei lösen lässt).

Soviel erstmal zu dieser Baustelle

Beste Grüße,
Dirk

[Janosch Kuffner]

Guten Tag,

@ hamlet:
Uns liegt bereits eine Beta-Version der ROBO Pro Softtware vor, in der das von Ihnen beschriebene Problem behoben ist. Diese Korrektur wird mit dem nächsten ROBO Pro Update implementiert.

@ Dirk Fox
Vielen Dank für Ihre Verbesserungsvorschläge zum Liste-Element. Wir werden diese Punkte in unserer entsprechende Datenbank aufnehmen.


freundliche Grüße

Janosch Kuffner
fischertechnik-Team

[Janosch Kuffner]

Guten Tag,

nachfolgend eine ausführliche Antwort auf das ursprüngliche Posting dieses Threads:

Ich habe einfach dieses Forum gewählt, um über den Fehler zu informieren. Gibt es zu diesem Zweck ein spezielles Portal?

Um über Fehler in der ROBO Pro Software zu informieren gibt es kein spezielles Portal. Fehler können über dieses Forum oder direkt über info@fischertechnik.de gemeldet werden.

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

Eine derartige Liste gibt es momentan nicht.

Gibt es schon eine Version in der der Bug gefixt ist?

Der Fehler ist bekannt und es liegt uns bereits eine Beta-Version vor, in der dieser Fehler behoben ist. Mit dem nächsten Softwareupdate wird dieser Fehler behoben.

Wird es Dokumentation zum Objekt-Level 5 geben?

In Level 5 kann man Variablen mit Typ "Objekt" anlegen. Dies entspricht einer Membervariablen in objektorientierten Programmiersprachen.
Wenn ein Unterprogramm Objektvariablen hat, kann man im Aufruf des Unterprogramms angeben, welchen Typ die Objektvariablen des Unterprogramms aus Sicht des aufrufenden Programms haben sollen. Variablen vom Typ Objekt funktionieren, aber es sind noch einige Optimierungen nötig. Insbesondere sollten mehrere Unterprogramme zu einer Klasse zusammengefasst werden können und so auf gemeinsame Objektvariablen zugreifen können. Daher gibt es für den Level 5 noch keine Beschreibung.

Welchem Zweck dient die Option "Standard Platzierung" (Dynamisch/Statisch) unter dem Reiter "Eigenschaften"?

Das ist ein historisches Artefakt und nur noch zur Kompatibilität mit alten Programmen vorhanden. Früher konnte man hier einstellen, ob ein Unterprogramm standardmäßig lokal oder statisch platziert wird. Mittlerweile trifft die Entscheidung ROBOPro automatisch und für alle mitgelieferten Bibliotheksunterprogramme richtig.

Wozu dient die Option "Debug" beim Pseudo-Daten-Eingang der Motorsteuerung?

Diese Option wurde zum Debuggen der Motorsteuerung benutzt. Mit dem nächsten Softwareupdate wird diese Option entfernt werden.

Welche genauen Auswirkungen auf den Programmablauf haben die
o Verbindungsoptionen bei Unterprogramm-Befehseingängen,
o die Lebensdaueroptionen bei Operatoren/Variablen
o 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.:
o 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?

Orange Leitungen werden evaluiert, wenn sich ein Eingang ändert. Bei = Befehlen wird der letzte Wert z.B. von Eingängen nicht aktiver Unterprogramme gespeichert und beim Start des UPs ein entsprechender = Befehl gesendet. Bei anderen Befehlen ist das nicht so.

Zur Lebensdauer von Eingängen: Wenn diese "lokal" ist, kann das Unterprogramm über den Eingang nur Werte oder Befehle empfangen, wenn sich der Programmfluss im Unterprogramm befindet. Wenn diese auf "objekt" steht, kann das Unterprogramm über den Eingang empfangen, solange der Objektkontext der Unterprogramme besteht. Statisch wird im Moment nicht unterstützt (man bekommt eine Fehlermeldung). Da es das aber früher mal gab, gibt es die Option noch im Dialog, um das bei alten Programmen ändern zu können.

o 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?
o 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

Die Schleifen sollten zuverlässig sein, wenn sie Operatoren enthalten. Wenn bei der Evaluierung ein Operator ein 2. mal angetroffen wird, stoppt die Evaluierung dort. Das reicht aus, um z.B. Flip-Flops aus Gattern zu konstruieren. Schleifen die nur Variablen enthalten führen zu einem Stack-Overflow. Es gibt eine Bibliothek mit Flip-Flops. Eine andere sinnvolle Anwendung ist uns bisher noch nicht eingefallen. Übrigens kann man auch Unterprogramme ganz ohne Programmfluss (nur orange) machen.
Die Ausführung ist im Moment auf einen Elementstrang (bis zu einer Verzweigung) pro Prozess pro Millisekunde beschränkt. Befehle (orange Netze) werden aber immer aus Sicht des Programmflusses atomar abgearbeitet. Im Downloadmodus werden auch Befehle in Gruppen bis zu einer Verzweigung oder einem Wartelement atomar abgearbeitet. Im Onlinemodus ist das aber nicht so (weil man da Elemente single-steppen kann). Die Begrenzung auf 1x pro Millisekunde könnte man ändern, ist aber nicht ganz ungefährlich, weil bei einer Zeitscheibenüberschreitung von ROBOPro das OS crashen würde. Zur Hintergrundinfo: ROBOPro läuft auf dem embedded OS mit sehr hoher Priorität, um die Real-Time Fähigkeit sicher zu stellen. Eine preemption ist bei dieser Priorität im OS nicht vorgesehen.

Yagarto C-Compiler Tool Chain:
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.

Die Struktur der ROBo TX Controller Downloadprogramme ist auf die ROBO Pro Software abgestimmt. Das Downloadprogramm muss alle 1ms dran kommen, um die Echtzeitfähigkeit sicherzustellen und das ROBO TX Controller Betriebssystem folgt genauso einem 1ms-Takt (ähnlich wie eine SPS), um z.B. die Extension-Ports und den Multiplexer für die analogen Eingänge abzufragen. Also endet man zwangsläufig bei diesem 500µs ping-pong-Spiel, weil die Aufgabe ist, zwei Echtzeit-Prozesse miteinander zu synchronisieren. Das ist der Tribut an ein Echtzeitsystem.

Nun ist es natürlich so, dass der C-Programmierer den Nachteil der langsameren Ausführungszeit einfach durch die Verwendung einer Hochsprache hat. Man kann in C in der Tat nicht soviel machen, wie ein übersetztes ROBO Pro-Downloadprogramm in Maschinensprache. Insofern ist für uns nicht klar, was Sie meinen, wenn Sie sagen dass Sie in C schneller sind als ROBOPro. Trotzdem zeigen letztlich auch unsere Beispiele, dass bei richtiger Programmierung schon einiges auch in C möglich ist.

Andere Dinge für das Anwenderprogramm wie Multitasking, Scheduler, Interrupts sind für den Echtzeitbetrieb absolut kontraproduktiv und deswegen nicht realisiert.

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? [...]

Diese Anregung wurde an die entsprechende Stelle weitergeleitet. Momentan können wir aber keine Aussage dazu treffen ob bzw. wann eine entsprechende Veröffentlicheung möglich ist.


Vielen Dank auch für Ihre Verbesserungsvorschläge für ROBO Pro. Wir werden diese in unsere entsprechende Datenbank aufnehmen.


freundliche Grüße

Janosch Kuffner
fischertechnik-Team

[TST]

Hallo Janosch

Ja, das nenne ich mal ausführlich......

MFG
Andreas
TST

[hamlet]

Guten Tag,

ganz herzlichen Dank für die ausführlichen Antworten!
Wann in etwa steht denn eine neue offizielle RoboPro Version zur Verfügung? Tage, Wochen ... Monate?

Nun ist es natürlich so, dass der C-Programmierer den Nachteil der langsameren Ausführungszeit einfach durch die Verwendung einer Hochsprache hat. Man kann in C in der Tat nicht soviel machen, wie ein übersetztes ROBO Pro-Downloadprogramm in Maschinensprache. Insofern ist für uns nicht klar, was Sie meinen, wenn Sie sagen dass Sie in C schneller sind als ROBOPro.

Da habe ich mich nicht ganz klar ausgedrückt. Ob generell der von RoboPro oder der vom gcc C-cross-compiler erzeugte Maschinen-Code performanter auf dem RoboTX läuft, kann ich nicht beurteilen. Der Performance-Unterschied hängt von der Anwendung ab. Schleifen und Verzweigungen im Programmfluss sind in RoboPro auf Grund der Architektur langsam:
Ein kleines und zugegebenermaßen etwas synthetisches Beipiel: Aufsummieren aller 1000 Einträge eines integer arrays in einer Schleife
C-compiled: 131µs
RoboPro: Nicht weniger als 2000ms
=> Das entspricht einem Faktor von ~15000. Das meine ich mit "schneller". Wenn man in die Schleife noch ein paar Verzweigungen einfügt, wie es etwa beim Sortieren einer Liste nötig ist, ist der Unterschied wahrscheinlich noch größer. RoboPro bleibt halt im Prozess bei der ersten Verzweigung stehen, und lässt die verbleibende Laufzeit des zur Verfügung stehenden time slots ungenutzt verstreichen. Es wäre klasse, wenn man die Evaluierung/Prozessabarbeitung in RoboPro mehrfach anstoßen könnte.

Andere Dinge für das Anwenderprogramm wie Multitasking, Scheduler, Interrupts sind für den Echtzeitbetrieb absolut kontraproduktiv und deswegen nicht realisiert.

Es ist gängige Praxis, Echtzeit-Systeme mit diesem Ansatz zu designen. Wenn man alle zeitkritischen Betriebssystem-Services und das Daten-Sampling auf Interrupt Service Level und tasks hoher Priorität realisiert, dem Anwendercode hingegen tasks mit niedrigerer Priorität zugesteht, ist es auch nicht mehr möglich das Betriebssytem durch zu laufzeithungrigen Anwendercode abzuschießen.

Beste Grüße,
Helmut

[vleeuwen]

The TX-C has been design as general purpose toy like interface, that can be use in the online and offline mode.
The specification of 10ms refresh rate is for that target group very acceptable.
If you increase the refresch rate you will also need sensors and actors that can deal with that speed too.

However National Instruments has a nice and very fast interface for (industrial) Robot control.
Maybe an alternative for hamlet's problem?

[hamlet]

Dear ft-Team,
the problem described below has not been solved with the new RoboPro release 3.1.
The behaviour is the same as in release 2.4.2.1.
Best Regards,
Helmut

Hallo
mir ist ein weiteres Problem in RoboPro aufgefallen:
Der Abstands-Befehl der erweiterten Motorsteuerung wird von einem Unterprogramm-Befehlsausgang nicht korrekt weitergeleitet.
Wenn ich einen "Abstand"-Befehl aus einem Unterprogramm über einen Befehlsausgang an einen Motorausgang weiterleite, scheint er ignoriert zu werden. Wenn ich den Befehl hingegen innerhalb des Unterpogrammes dierekt mit einem Motoraugang verbinde, verhält sich das Programm wie erwartet.
Beste Grüße,
Helmut

Hello,
the simple program below demonstrates the problem:
Subroutine "OK" works as expected, it runs the motor for 500 ticks, whereas subroutine "KO" does not start the motor at all. The only difference between the two sub-programs is that in "OK" the distance command is connected directly to the motor otput, whereas in KO it is linked to the motor output via the sub program command output.
The program rpp is available here http://www.alice-dsl.net/helmut.schmuec ... blem01.zip
cheers,
Helmut

@ hamlet:
Uns liegt bereits eine Beta-Version der ROBO Pro Softtware vor, in der das von Ihnen beschriebene Problem behoben ist. Diese Korrektur wird mit dem nächsten ROBO Pro Update implementiert.

[vleeuwen]

I removed this contribution because it is not relevante anymore.

[hamlet]

Hi Carel,
many thanks for your prompt reply. It seems to be a really weird problem. Following your advice I have added the recommended "Motor Stop" and "Distance Clear" commands after the "Wait for Position Reached". Unfortunately this has not solved the problem. Ihave also added some 100ms delays between the commands, because I assumed that a timing problem could be the root cause. But also this did not help.
RoboPro version: official 3.1
TX-C board version: C
firmware v1.24
TX-C PC connection: USB
online mode: Process flow simply jumps trough the KO sub routine.
download mode: motor is started in KO and then runs forever ... until I powered off the TX-C, and at least this evening I keep this damned thing off.

It seems that the "old foum" contains lots of valuable information. Is there any way to get access to it?

Best Regards,
Helmut

[vleeuwen]

Removed because it has no more relevance.

[vleeuwen]

Removed because it has no more relevance.