fischertechnik community forum

Hallo Helmut,
ich habe diese Funktion extern in mein Modell eingebunden. Hierzu habe ich jeder Achse 4 Taster zur Verfügung gestellt. 2 für das RoboPro Programm (intern) und 2 für die externe Überwachung. Einen Crash gibt es bei diesem Modell nicht mehr. Sollte die NotAus Funktion nicht verfügbar sein, kann man das Programm nicht starten. Es beendet sich dann sofort wieder. Als Basis dient hier ein Arduino Uno mit einem 4-Kanal Relais Modul Shield und einer entsprechenden Oberfläche für die Visualisierung einer NotAus Situation, das Überbrücken dieser und das alles wird signalisiert über den I²C Bus an das laufende Programm, damit dieses dann entsprechend reagieren kann für einen Wiederanlauf.

Ich habe mir das eigentliche Steuerungsprogramm der Motoren aus deinem Programm noch nicht genauer angesehen. Das zu verstehen, bedeutet wohl einigen Zeitaufwand für mich. Aber nichtsdestotrotz die Frage: Welcher Teil von MPos reguliert den eigentlichen Spielausgleich? Kannst du mir den entsprechenden Code einmal markieren?

Ach ja, noch zum Schluss die Anmerkung, dass dein Programm nicht sauber terminiert. Du beendet den Thread MPos nicht, was bedeutet, dass das Main Programm zwar endet aber diese nicht signalisieren kann, weil der MPos Thread noch läuft.Ich denke, dass dir das nicht aufgefallen ist, da du geschrieben hast

Ich wusste gar nicht, dass Interface Test und Programm parallel laufen können

Gruß,
Joachim

Hi Joachim,

ch habe diese Funktion extern in mein Modell eingebunden. ...
... , damit dieses dann entsprechend reagieren kann für einen Wiederanlauf.

Wow, das hört sich kompliziert an. Ich kann Dir da aber nicht ganz folgen.

... Frage: Welcher Teil von MPos reguliert den eigentlichen Spielausgleich? Kannst du mir den entsprechenden Code einmal markieren?

Das sind die Stellen, an denen die Variablen "bl" (backlash), "dir" (direction) und "lstDir" (last direction) auftauchen. Einmal im rechten Prozesspfad bei der regulären Positionierungssequenz und einmal in der Mitte beim optionalen Anfahren des Nullpunkt-Offsets ("zo" Zero Offset) nach dem Durchlauf der Nullpunkt-Initialisierung im Pfad auf der linken Seite. Ein paar Hinweise zur Implementierung finden sich unten im Beschreibungs Tab des "MPos"-Objekts.

Ach ja, noch zum Schluss die Anmerkung, dass dein Programm nicht sauber terminiert. Du beendet den Thread MPos nicht, was bedeutet, dass das Main Programm zwar endet aber diese nicht signalisieren kann, weil der MPos Thread noch läuft.

Ups, ja das stimmt. Das hat mich tatsächlich nie gestört. Ich hab meine Programme immer mit dem roten "Stopp"-Button in RoboPro oder am Controller beendet. Das funktioniert sowohl bei "online" wie "offline" laufenden Programmen und beendet auch die "MPos"-Objekt Prozesse. Tatsächlich hat mir der Button sogar als "NotAus" ausgereicht.
Falls eine vollständige Terminierung aller Prozesse notwendig ist, kannst Du die "MPos"-Objekte samt der Anweisungen des Hauptprozesses in ein Unterprogramm verschieben. Im "Main program" startet man dann den Hauptprozess, der dann das Unterprogramm einsteigt. Wenn man den Hauptprozess, nach Verlassen des Unterprogramms in "Main" terminiert, werden auch alle im Unterprogramm gestartetet Prozesse terminiert.
Siehe auch hier viewtopic.php?f=8&t=2516 und und darin referenziert http://forum.ftcommunity.de/viewtopic.php?f=8&t=1069.
Darin hab ich folgende bestechend simple und robuste "NotAus"-Umsetzung entdeckt. Das funktioniert immer!
Grüße,
Helmut

Hallo Helmut,
danke für die Threads Hinweise. Die Lösungen in diesen Threads habe ich nicht weiter verfolgt, weil ich eine externe Überwachung haben wollte, die unabhängig/zusätzlich von RoboPro liegen sollte. Diesen Ansatz gab es auch in einem dieser von dir referenzierten Threads.

Für die Steuerung innerhalb von RoboPro Programmen laufen meine Threads in der Regel initiiert durch das Hauptprogramm (HP) oder in einem Unterprogramm (UP), in dem sie sich allerdings beenden, wenn sie nicht mehr benötigt werden. Ein grünes Männchen ohne ein rotes Männchen in diesen Threads gibt es in meinen Modellen nicht. Sollte ein UP einen Zustand entdecken, der einen ordentliche Beendigung des HP erforderlich macht, wird das durch einen Rückgabewert der UPs signalisiert. Deshalb fragen alle meine UPs/HP diesen Rückgabewert ab.

Sollte das HP beendet werden, werden die durch das HP initiierten Threads mittels einer globalen Variablen beendet, die beständig im Thread abgefragt wird. Damit würde ich auch Threads erreichen, die beständig, ausgelöst in UPs laufen.

Gruß
Joachim

Hallo zusammen,

hamlet hat geschrieben: ↑

12 Jun 2020, 08:16

eine universell einsetzbare Library zur Encodermotor-Positionierung

Die aktuelle Version RoboPro-Bibliothek zur Encoder-Positionierung findet Ihr jetzt auf unserer Webseite.
Herzlichen Dank an Helmut (hamlet)!
Gruß
Esther

Hallo Dirk,
ich muss noch eine Bemerkung bezüglich deiner Antwort für die Korrektur des Spiels geben. Du hattest mit deiner Aussage vollkommen recht. Sorry, dass ich das in meinem ersten Test nicht bestätigen konnte. Habe das jetzt einmal vollständig programmiert und getestet und es läuft genau so, wie du es gesagt hast.

Gruß
Joachim