Implementing test jobs in the device supervisors

This is a summary of how the test jobs are implemented in the ECALBase and can be used by the DeviceSupervisors

The implementation of a standard way to submit test jobs in a detached way from the sequential flow of an application (i.e. running in threads or workloops) has been coded by P. Musella and P. Silva in the ECALBase package of the ECALSoftware.

To submit a job to a workloop one has first to define a method to be called whenever the job is requested. This method, by default, must be declared as returning a boolean and having a pointer to a workloop as argument, p.e.:

 bool MyApplication::executeSequence(toolbox::task::WorkLoop *){
     ... define your job...
}

After the method is implemented one must then bind it to a task which will return an action signature object, p.e.:

toolbox::task::ActionSignature *executeSequenceJob 
   = toolbox::task::bind(this,&MyApplication::executeSequence,"executeSequence");

Now, every time you want to start a new sequence job you just need to submit it's action signature to the workloop you are using, p.e.:

wl_->submit(executeSequenceJob_); 

To generalize this procedure a wrapper class was created in the ecalBase so one can define test sequences with more arguments than the pointer to the workloop. This class is the TestJobWrapper and it's constructor takes as arguments:

• a pointer to the application's infospace
• a pointer to the client class
• a pointer to the method that's to be submitted to the workloop
• a pointer to a void context (variable)

The TestJobWrapper 's constructor defines and binds a job method in the usual way (described above). It is this job method which is, in reality, submitted to the workloop and calls, the test job wrapped at the time of construction of the wrapper. In short, when one wants to define a test job using this wrapper, one can proceed as follows:

• define a method that returns void and takes has arguments a pointer to void (which you might re-cast then) and a pointer to the infospace where results are to be published:

void MyApplication::testJob(void *pointer, xdata::InfoSpace *pointerToInfospace){
   ... implement the job sequence...
}

• submit your test job by calling the method submitTestJob (inherited from the ECALBase)

submitTestJob(this, &MyApplication::testJob,  (void *) pointerToAnArgument);

The method submitTestJob takes care of creating a test job wrapper for you passing to it the 4 arguments needed . After wrapping your testJob it tries to submit it to one of the 3 test workloops that are created whenever the application is enabled for test. These workloops are created during the TestSetup transition of the TestStateMachine. At the time a job is submitted a job counter is incremented and the same counter is decremented whenever the job finishes. This way the application automatically fires a TestDone transition when the test jobs have finished.
Below it's skecthed how this test job submission works each time a TestStart transition is fired from the Test Supervisor.

• Schema to submit test jobs:
  

As the test jobs have a pointer to the test infospace they can update it with the results of the executed job.
You can find some examples of this in the examples directory of the Test Supervisor or in DeviceSupervisorTestExample.

• See also Workloops Toolbox task Toolbox

-- PedroSilva - 25 Aug 2006