Shutdown mehrerer Prozesse

[DoDi]

Nun habe ich mein erstes Pneumatik-Modell gebaut, den Druckluftmotor. Und weil das zu einfach war, wollte ich noch eine Anfahr-Routine und Drehzahlüberwachung/-regelung einbauen. Die Drehzahlsteuerung (über den "Zündzeitpunkt") funktioniert auch schon, man kann auf diese Weise sogar die Drehrichtung beeinflussen

Die Drehzahlüberwachung (Messung und Anzeige) sollte wohl am besten in einem eigenen Prozess laufen, doch dann läßt sich das Programm nicht mehr einfach beenden.

Was ist die cleverste Methode, ein Programm mit mehreren Prozessen per Software zu beenden?
Z.B. wenn ein "Notaus" Knopf gedrückt wird oder die Drehzahlüberwachung einen Stillstand feststellt, wie kann man dann alle Prozesse abwürgen?

[steffalk]

Tach auch!

Eine Möglichkeit ist eine globale Variable, die Du bei "Not aus" setzt, und die im anderen Prozess periodisch geprüft wird. Wenn sie gesetzt ist, muss der Prozess zu seinem Ende-Symbol verzweigen.

Gruß,
Stefan

[Dirk Fox]

Hallo DiDo,

Was ist die cleverste Methode, ein Programm mit mehreren Prozessen per Software zu beenden?

es gab hier mal einen längeren Thread dazu - vielleicht findest Du dort eine passende Idee:
http://forum.ftcommunity.de/viewtopic.php?f=8&t=1069

Gruß, Dirk

[DoDi]

es gab hier mal einen längeren Thread dazu - vielleicht findest Du dort eine passende Idee

Danke, sehr interessant

Unterm Strich bleibt wohl, daß eine Prozeß-/Threadsteuerung in RoboPro fehlt. Es gibt kein Create/KillThread, und kein Suspend/Resume, wie das sonst so üblich ist. Zudem sollte sich diese Steuerung auch auf mehrere (alle angeschlossenen) Controller auswirken, das wurde noch garnicht angesprochen. Vielleicht sollte sowas ja mal in Level 5: Objekte kommen, doch dazu habe ich noch keinerlei Doku oder erkennbare Änderung in der Oberfläche gefunden.

In einer Echtzeitumgebung ist es oft keine Lösung, einfach nur den Stecker zu ziehen. Stattdessen sollten alle Prozesse aller Controller auf ein (Shutdown...) Signal sofort reagieren, egal was sie gerade tun (Warten!?), und sich dann in einen sicheren Zustand versetzen. Ich bin mir allerdings nicht sicher, wie das in die graphische Oberfläche überhaupt integriert werden kann, dazu müßte ja jeder Prozess mit einem eigenen Signal-Handler verknüpft werden...

[UMueller]

Hallo,

man kann die parallen Prozesse in ein Unterprogramm verlagern (Als grüne Männchen Threads). Mit Ende des vom HP aufgerufenen UPs werden dann auch die Grünen Männchen beendet).

Gruß Ulrich Müller

PS : Du kannst auch einfach mal das UP PosXYZ vom ft Beispielprogramm 3-Achs-Robotoer ansehen

Oder auch http://www.ftcommunity.de/ftComputingFinis/rbthread.htm

[DoDi]

man kann die parallen Prozesse in ein Unterprogramm verlagern (Als grüne Männchen Threads). Mit Ende des vom HP aufgerufenen UPs werden dann auch die Grünen Männchen beendet).

Wow, das ist schon mal interessant

PS : Du kannst auch einfach mal das UP PosXYZ vom ft Beispielprogramm 3-Achs-Robotoer ansehen

Da habe ich schon mal reingeschaut, aber ohne Kenntnis des Modells und der Dokumentation wird es schwierig, alleine den Sinn hinter den verschiedenen Versionen zu erkennen. Zudem beenden sich dort alle Prozesse selbst, da ist es nicht selbstverständlich, daß sie auch beim Verlassen des Unterprogramms beendet werden.

Ausprobiert:

Ein Prozess muß sich nicht selbst beenden.
Prozesse in Unterprogrammen werden beendet, wenn das Unterprogramm verlassen wird.
Im Hauptprogramm ist es umgekehrt, dort wird das Programm erst beendet, wenn sich alle seine Prozesse beendet haben.

Die Eigenschaft "Prozess starten wenn" ist ziemlich wirkungslos, ein Prozess wird immer in dem Fenster (Haupt-/Unterprogramm) gestartet, in dem er liegt.
Ein Prozess kann in einem eigenen (Unterprogramm-)Fenster liegen, das kein Unterprogramm enthält. Dann fehlen dem Programmelement Ein- und Ausgänge - ist das dann ein "Objekt"?. Zur Aktivierung kann es einfach in einem Haupt- oder Unterprogramm abgelegt werden.

Auch Datenflüsse können einfach in ein Fenster gelegt werden, z.B. Variable--->Anzeige. Gilt das auch für Befehlsfilter?

Danke für die Tips, wieder viel dazugelernt

[vleeuwen]

Processes (workflows) are running autonomously. When a work flow process has been started only the process self can decide to continue in the direction of a termination (red person).
This is an abstract nation.
Each work flow process (starts with a green person and ends with a red person.) can be situated in a main or subprogram but they are still autonomous.

Data flow is used for process synchronization.
Based on a general data value, let say "stop" with a value of "1" or "0", each autonomous process could decide to continue his workflow into a termination direction.
It is to a workflow process itself to terminated (or the user can terminate the program brute by stopping/killing the program; however this has less to do with the notion of work flow processes).

The problem starts in case you mix up in a subroutine, processes (green and red person) and parts of processes ("entry" and "exit")

[DoDi]

This is incorrect:

Each work flow process (starts with a green person and ends with a red person.) can be situated in a main or subprogram but they are still autonomous.

A process can be endless (no red person). When located in a subroutine, a process is started on entry and terminated on exit of the subroutine.
Once a process has been started, it runs in parallel to all other processes, of course.

[vleeuwen]

@Dodi,
a)
Sorry Dodi but I tested it.
You probably did not set the properties of the "green man" right.

I put a global process (endless with a escape switch) in a subroutine. (Process is containing an increment of a global counter)
I set the properties of this process (properties of the green man) on "main program starts" or "Object has been constructed".

I both cases this process was not be terminated by leaving the sub program part in the subroutine.

b)
An endless process is the same as a process with a escape switch.

repeat ........... until (EndProcess);
or in your case
repeat ........... until (false);

[vleeuwen]

The concept of RoboPro is independent work flow processes with data flow for inter-process synchronization and communication.
It is the task of a work flow to check the condition to progress, or not. And if not, terminate the process in a well controlled manner.
Terminating a process from the outside in a not-controller manner can be dangers (in case of professional process and control engineering).
In case of an emergency stop, all the actuators need to be placed in a save positions and locked otherwise unpredictable (and dangers) effects could take place.

Compare this with good programming practice in software engineering to make full use of the exception mechanism.

In Robopro this is already possible.

[steffalk]

Tach auch!

Dieser Thread hat ja mit der originalen Anfrage, die sich ja offenbar auf RoboPro bezieht, nicht mehr viel zu tun. Die Ur-Anfrage ist ja hinreichend beantwortet. Das ist die "Bedienungsanleitung", wie das in RoboPro geht.

Das hat mit Mutexten, Semaphoren und echten Männern, die ja so toll Bugs in C programmieren können, nichts zu tun. Und Fords Vorschlag, der Hauptprozess könne ja die Motoren abschalten, finde ich so lala. Bei ordentlichem Design weiß der Hauptprozess nämlich gar nicht, in welchem Zustand das Unterprogramm gerade ist und was gerade aufzuräumen ist und was nicht. Es geht den Hauptprozess nichts an. "Informationskapselung"

Gefährlichkeits-Argumente gegen diese Methode fallen mir durchaus ein: a) Mieses Design. Ein Haufen globaler Variablen, über die der Hauptprozess von Interna des Unterpogramms wissen muss, koppeln beide stark aneinander. Willst Du am UP was ändern, musst Du auch immer darauf achten, das im Hauptprogramm ggf. zu berücksichtigen. b) Der Hauptprozess oder ein anderes UP könnte ja globale Variablen versehentlich verändern und damit beliebiges Chaos anrichten. Das kann ja schon durch eine versehentlich gleich geschriebene Variable sein, weil man keine verschiedenen namespaces dafür hat.

Also: In RoboPro geht's ja eh nicht per Mutex o.ä. steuerbar, weil es sowas da gar nicht gibt. Da sind die Antworten oben bestimmt die richtigen. Auf anderen, "nativeren" Plattformen muss man halt schauen, wie es da am besten zu machen ist. Aber auch da könnte man ja ein wenig "Berufsehre" haben und nicht gerade wie in 1969 rumpfuschen

Gruß,
Stefan

[steffalk]

Tach auch!

Du darfst doch alles tun, was Du magst, Ford. Wie jedes andere System hat aber auch RoboPro a) den Zweck, für den es gemacht wurde und b) die entsprechenden Beschränkungen. Das haben wir hier doch schon so oft diskutiert. In RoboPro den Menüpunkt "Semaphore" zu suchen läuft bei mir halt einfach unter "Bedienungsanleitung nicht gelesen" Nimm ein beliebiges in C programmierbares Board (schau nur die tollen Lösungen in den letzten ft:pedias an) und programmiere ganz nach Belieben!

Gruß,
Stefan

[vleeuwen]

Keep in mind that the discussion is at the abstract level of RoboPro, work flow oriented design and programming, and not at the lower C level.
For me the question is, how to deal with stopping (shutting down) one or more workflow processes, and this in a decent way. In a way that fits into the work flow concept.

How this has been implemented in C and/or the lower level API is not so relevant.
RoboPro and his work flow concept operates on a high abstract level concerning the creation of relations between sensors and actuators.
So a shutdown or termination of a work flow process needs to be realize at that abstract level.

Normally a good intelligent actuator knows a locale emergency procedure incase of power or hardware failure.
But this only in case of the control logic fails to deal with the exceptions.

A "semaphore" at low level C programming has been implemented (abstraction) in RoboPro with the data flow concept.
Designing for work flow programming asks for a different mind set.

A higher abstraction of work flow design and programming is for example Message oriented design and programming.
In that case you will have "Join messages " and "Merge messages" as representation of inter process synchronization and communication.

[vleeuwen]

As continuation of StefFalk's comment:

Ford,
Each programming paradigm has it's own pro's and con's.
If you don't like work flow oriented design and programming than don't use it.
But respect people who are trying to make use of it and try to think and reason at that level.

For discussion about the quality of OOP languages, there exists some very nice forum sites and LinkedIn groups.
But that is not the subject here.

[vleeuwen]

@Ford
Basically your have right,
Every program language, even assembler, will be break down into a sequence of "1" and "0". Von Neuman machine data and instruction are mixed up.
The time that we were loading paper tapes on a PDP 11 industrial process system has been past a long time ago.
The invention of the BIOS based PC introduced a very new concept in the end eighties.
I refuse here to go into details of the most lower level of programming.

The beauty of high level abstract concepts and languages is that the user does not preoccupy himself with all the lower level issues.
Long live the intelligent compilers!

A low level termination of the processor task has noting to do with work flow design and programming.
Resetting the CPU or shut down the power supply has also to do with work flow design and programming.
When designing at work flow level ask to find solution at that abstract level. That is the challenge.

In case you like to design and programming at C or assembly level, the challenge will be finding solution for the problem at that level.
At embedded C level you will find hardware interrupts, or at C# level there are Events. They are also not available at work flow level, you don't miss them too?

The same for the discussion about the GOTO <label> statement that is missing in most of the higher level programming languages.
This has also to do with the idea that these kind of lower level programming habits do not belong on a higher level of abstraction.
There is no need for that statement because the language allowed better ways to programming a "Goto" action.

[Rolf B]

Moin,

@Ford: Es IST KINDERKRAM, dafür wurde es entwickelt und als solches wird es auch verkauft!
Merkst Du das irgendwann?
Wenn Du mehr willst, dann gibt es auf dem Markt genug Lösungen die alles das können was Du Dir wünscht. Warum muss die Sau hier nun unbedingt Kuhmilch geben?

Gruß Rolf

[vleeuwen]

The question of how to (emergency) stop different work flow tasks in a work flow oriented way has been discussed now.
This including the absent of a low level kill instruction in RoboPro.

The next has less to do with the main discussion subject, but.....
@Ford
We all know that you prefer C, we have seen you personal LEGO forum in the past.
However there is more on this world. And some people are probably stupid enough to prefer an different approach and level for discovering and describing their solution for their robotic problems.
Fischertechnik is offering you the option to program in C (imperative oriented approach; on line and off line) , so you can be happy.
Fischertechnik is also offering work flow oriented approach with RoboPro, message flow oriented approach with MS Robotics Developer Studio and event driven oriented approach with C#/VB.NET (.Net framework).
All these different approaches make people happy, so respect their chooses.

And you have reason, Fischertechnik is not LEGO. This is making the most of fischertechnik fans happy.

Note about Labview (National Instruments):
Labview knows a imperative approach. (See for example http://www.ni.com/getting-started/labview-basics/)
This is essential different from the work flow approach in RoboPro or the message flow approach in MS-Robotics Developer Studio.
Also comparing imperative, work flow and message flow is less useful because they are complete different concepts.
It has nothing to do with a programming language but with a way of thinking and reasoning; and problem decomposition.

Note about OOP languages:
What you think of C#, object oriented including some functional issues like lambda expression in it.
Java is a little bit behind, not standardize by an independent organization or comity; it is fully under control of ORACLE.
C# has been standardize by the ECMA organization and is not under control of a commercial organization;(C# it is not owned by Microsoft!)

[vleeuwen]

As you probably know, Labview has been based on the data flow programming paradigm and the program language G.
It does not support work flow.

[Masked]

Jungs, beendet bitte diese Diskussion hier. Alle.
Wer noch was zum eigentlichen Thema beizutragen hat, kann das gerne tun. Alles Andere werden wir verschieben oder löschen.
Grüße,
Martin

[vleeuwen]

Ford 42,
keep you to the subject of this thread, that is all people are asking you.