fischertechnik community forum

Hallo...
Ich hab ein etwas "seltsames" Problem.
Ich stelle gerade meine KI Anlage (TXT 4.0) mit der Fabrikation und einer Recycling Analge für die Ausstellung ein.
Ich hab das Ganze nun so, dass es ohne PC läuft - aber wenn man das Programm auf dem TXT 4.0 anhält, laufen die Motoren weiter.
Man kann zwar über Stop am PC die Ausgänge abschalten,wenn es am USB ist , aber trotzdem ohne PC zeigt er an Programm angehalten und das Band läuft weiter.
Nur mal so dumm gefragt. Kann es sein, dass der TXT 4.0 nicht alle Prozesse beendet?
Das Programm von ft ist so, dass das Band erst läuft wenn die Lichtschranke belegt ist. Bei mir nicht, da läuft es mit kleiner Geschwindigkeit, da es Bauteile von der vorherigen Anlage bekommt.
Sprich nur das Hauptprogramm stoppt, das Unterprogramm nicht.
Ich gebe zu ich bin da etwas ratlos - was aber ein hervorragendes Gesprächsthema für die Maker Fair in Hanover ist
Mit freundlichen Grüßen
Holger

Hallo,

fast genau dieses Phänomen habe ich auch. Wenn ein längliches Programm durch Klick auf den Stop-Button angehalten wird, scheint es an dieser Stelle beim erneuten Klicken auf "Start" nicht am Anfang zu starten sondern an der Stop-Stelle weiter zu laufen:

Konkrete Frage: Kann ich auf irgend eine Weise im Programm festlegen, dass alle eventuell laufenden Prozesse beendet werden? Vielleicht durch eine eingebettete Phyton-Anweisung?

Etwas verzweifelt

Horst

Here is a partial answer:

The motor outputs M1-M4 (and also their O1-O8 counterparts), are controlled primarily by firmware code that runs on the real-time Cortex-M4 processor inside the TXT 4.0. On the other hand, your Python program (or your Blockly program translated to Python) runs on the Cortex-A7 processor under Linux.

If your Python program on the Cortex-A7 processor does not send a stop command to the Cortex-M4 firmware (using Motor.stop() or some such call), perhaps because the program crashed or was terminated before it had a chance to do so, then the motor or output might not be reset.

There is a safety mechanism: when the Motor or EncoderMotor Python instance is released, then the lower-level C library that implements the communication with the Cortex-M4 side resets the "in use" flag for the motor(s) that your application used, which will eventually cause the Cortex-M4 firmware to reset those outputs.

However, all that communication is a bit fragile, so it is possible that under some circumstances it simply doesn't happen. In that case --and your description sounds like it-- the Cortex-M4 firmware doesn't know that the motor should be stopped and leaves it running.

In other words: it is not necessarily a question of "processes not being stopped"; it might just as well be that your visible (Linux/Cortex-A7) application process is stopped, but that the Cortex-M4 side was never informed that the motor or other output is no longer used.

If you would like to read more about this, then please check out my new book about the TXT 4.0 internal operation.

• Chapter 4 is the general software overview: Cortex-A7 versus Cortex-M4.
• Chapter 9 is about the motor and general outputs.
• Chapter 14 explains how the low-level C functions communicate with the Cortex-M4.
• Chapter 26 is about the Python Motor classes.

The eBook version can be freely downloaded from https://tarma.com/embedded/txt4book

Hope this helps,
-- David

Heute habe ich die Lösung für mein am 27. Juli geschildertes Problem gefunden:
Mit der eingebetteten PYTHON-Anweisung quit() oder exit() wird ein laufendes Programm sofort angehalten.
Ich brauche das, wenn ein Prozess ausser Kontrolle geraten ist und eine weitere Ausführung sinnlos ist. Leicht zu finden durch einfaches googeln.
Horst

Hi David,

I just stumbled over your book on the internals of TXT 4.0, and I have to say it’s outstanding! The depth of detail and clarity of your explanations are spot on—I really appreciate how accessible and comprehensive the content is.

Best regards,
David