Supervision Task
Crux
✭
I was reading the manual (rapid overview) and I found this :
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?)
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 : - 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.
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?)
Tagged:
0
Comments
-
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).
1
Categories
- All Categories
- 5.5K RobotStudio
- 396 UpFeed
- 18 Tutorials
- 13 RobotApps
- 297 PowerPacs
- 405 RobotStudio S4
- 1.8K Developer Tools
- 250 ScreenMaker
- 2.8K Robot Controller
- 316 IRC5
- 60 OmniCore
- 7 RCS (Realistic Controller Simulation)
- 797 RAPID Programming
- AppStudio
- 3 RobotStudio AR Viewer
- 18 Wizard Easy Programming
- 105 Collaborative Robots
- 5 Job listings