Supervision Task

Crux

I was reading the manual (rapid overview) and I found this : 

When you specify task priorities, you must think about the following:
- Always use the interrupt mechanism or loops with delays in supervision tasks.Otherwise the FlexPendant will never get any time to interact with the user. And if the supervision task is in foreground, it will never allow another task in background to execute.

I am not sure of getting this... well my questions are :
1) Is it a good practice to design the program having a set of tasks which are defined as supervisors? 
2) what is actually meant by supervision task, can someone make an example of real wolrd application with this implementation? (What might this mean, maybe catching all possible interrupts in this separate set of tasks?)

soup

The use of the word "supervision" in that statement is confusing to me too. My guess: the primary motion task is typically the foreground task and the background task or tasks is what they're calling a "supervision task." The "time to interact" part I'm guessing is referring to the need for some kind of delay so the task doesn't loop so often that it ties up the entire CPU -- taking all the processing power away from any other task.

An example of this would be a background task set to a run mode of continuous (so it keeps looping) could include a "WaitTime 0.1;" at some point so this 100 ms pause will set the pace of the task so it doesn't attempt to loop a billion times a second and take all of the processing power of the controller. The most popular use of a background task is to mock a *slow* PLC so no major delays should be used so that all the inputs can be checked and outputs can be set quickly without hanging the program pointer up on one part of the program.

Example:

Setup a background task to run continuous.

    PROC main()
       WaitTime 0.1;
       Lights;
       Door;
    ENDPROC

    PROC Lights()
        IF SystemStop=1 THEN
             SetDO doLight_Red,1;
        ELSE
             SetDO doLight_Red,0;
        ENDIF

        IF SystemWarning=1 THEN
             SetDO doLight_Yellow,1;
        ELSE
             SetDO doLight_Yellow,0;
        ENDIF

        IF SystemRunning=1 THEN
             SetDO doLight_Green,1;
        ELSE
             SetDO doLight_Green,0;
        ENDIF
    ENDPROC

    PROC Door()
        IF DOutput(doDoorPB)=1 AND diDoorOpened=0 THEN
            PulseDO\High\PLength:=0.5,doDoorOpen;
            Reset doDoorPB;
        ELSEIF DOutput(doDoorPB)=1 AND diDoorClosed=0 THEN
            PulseDO\High\PLength:=0.5,doDoorClose;
            Reset doDoorPB;
        ENDIF
    ENDPROC

Note the 100 ms delay (WaitTime 0.1;) and how similar this looks to typical PLC logic.

It should be noted that you can have background task(s) with WaitUntils and other delays if you're okay with the program pointer getting stuck at that point in the program. An example of this would be a situation which is less like a check inputs and fire outputs PLC-like loop. Examples: Set an output, wait up to 5 seconds for the input to go high, else error. Or, if output goes high, Write something to a file (which could take a second or two depending on write speed).