Hi all,
I have few tasks in the same program.
The most important task is aperiodic and trigger itself at a certain time.
[The next update time is calculated by the task itself during its execution.
At the calculated time the task trigger itself to start another time
the updatehook. ]
It's working well but I would like to synchronise this task with other tasks.
My question is: which is the correct way to do that?
-I have to use events ports between the most important task and the others?
-I have to use SlaveActivity even if I'm not interested in having the
most important task executing the others with its own thread?
-I have to do that using the TimeService somehow in the other tasks?
Thanks for any hint
Luca
How to synchronise tasks?
Hi Luca,
On Fri, Jun 22, 2012 at 12:28 PM, Luca Magnabosco <magnabosco [dot] luca [..] ...
> wrote:
> Hi all,
> I have few tasks in the same program.
> The most important task is aperiodic and trigger itself at a certain time.
> [The next update time is calculated by the task itself during its
> execution.
> At the calculated time the task trigger itself to start another time
> the updatehook. ]
> It's working well but I would like to synchronise this task with other
> tasks.
>
> My question is: which is the correct way to do that?
> -I have to use events ports between the most important task and the others?
>
If you use an event port, with an aperiodic activity, you'll have to set
priorities right such that the scheduler knows it has to schedule the
controller after the 'hardware' thread. This is somewhat fragile since any
process/thread in your system with higher priority than the controller, but
lower than the hardware, running on the same core, will disturb this
balance.
> -I have to use SlaveActivity even if I'm not interested in having the
> most important task executing the others with its own thread?
>
This at least guarantees that your controller is as performant as your
hardware task, but indeed is fragile as well since your controller only
gets as much time as the hardware task and doesn't scale over multiple
cores !
> -I have to do that using the TimeService somehow in the other tasks?
>
I don't think this will buy you much in this example.
Another solution would be an RTT patch making the EDF scheduler[1] of Linux
available to components. This would allow your controller to set a deadline
equal to the next start period of the hardware component.
I think the short-term solution is using the ORO_SCHED_FIFO, using event
ports and setting priorities. If your CPU can do it, and no other processes
come in between, it will do what you expect it does.
Much more tweaking is probably not going to gain you anything measurable,
unless this constraint comes from a hardware constraint in which case you
must use Herman's approach: all in 1 component.
> Thanks for any hint
>
> Luca
>
Peter
[1] http://lwn.net/Articles/356576/ and other articles on the net
How to synchronise tasks?
On Fri, 22 Jun 2012, Luca Magnabosco wrote:
> Hi all,
> I have few tasks in the same program.
> The most important task is aperiodic and trigger itself at a certain time.
> [The next update time is calculated by the task itself during its execution.
> At the calculated time the task trigger itself to start another time
> the updatehook. ]
> It's working well but I would like to synchronise this task with other tasks.
>
> My question is: which is the correct way to do that?
> -I have to use events ports between the most important task and the others?
> -I have to use SlaveActivity even if I'm not interested in having the
> most important task executing the others with its own thread?
> -I have to do that using the TimeService somehow in the other tasks?
These are three different approaches, that all have their merits... (Except
maybe the first one, since, as was discussed some days ago, mixing
periodically triggered taskcontexts with events is not easy to get right.)
So, you must explain better what your "synchronisation" needs are exactly:
- exact time synchronisation?
- (partial) ordering of execution?
- application-dependent logical dependencies in the functionality running
inside your tasks?
- ...
In other words: you ask about the best _mechanism_, but this question is
difficult to answer if we don't know about what _policy_ your application
needs.
In yet other words: you bring up the term "most important", but that term
can have many meanings.
> Thanks for any hint
>
> Luca
Herman
How to synchronise tasks?
Hi Herman,
>In other words: you ask about the best _mechanism_, but this question is
>difficult to answer if we don't know about what _policy_ your application
>needs.
>In yet other words: you bring up the term "most important", but that term
>can have many meanings.
Of course the term "most important" quite useless to explain the problem.
I will try to explain the problem better:
I have a task (the so called "most important" task) that has to
communicate with the hardware.
It's the only task that really access the hardware so I can name it
"Hardware_communicating_task" maybe..?
Then I have others task that read the data that this
"Hardware_communicating_task" present to its ports.
I would like that these other tasks have the last data as possible.
[So i have to synchronise the tasks]
These others task has to use these data to calculate new control data
and send them another time to the "Hardware_communicating_task".
In other words: I have a control purpose. I need to read last data
form the hardware, calculate how to control and send control data.
The problem is that the component that communicate with the hardware
doesn't have a control purpose. The control is "centralised".
An example could be done thinking to SOEM/Orocos_master:
This component reads data from EtherCAT slaves [hardware] but doesn't
generate the control command.
The control command could be generated form a component linked to the
Master that receive data and decide how to control the slaves.
Control data are then passed to the master that send it to the slaves.
Another thing that has to be considered is that the master "has to run
with its particular period" * while the controller can have any period
but the components have to be synchronised.
*Using DC clock this period it's not fixed but can change a bit to
keep the master synchronised with the Slave's "DC signal".
This part of the synchronisation between the Master and the hardware
slaves has been already solved.
I hope to have explain the problem in a better way.
Best regards
Luca
How to synchronise tasks?
On Fri, 22 Jun 2012, Luca Magnabosco wrote:
> Hi Herman,
>
>> In other words: you ask about the best _mechanism_, but this question is
>> difficult to answer if we don't know about what _policy_ your application
>> needs.
>
>> In yet other words: you bring up the term "most important", but that term
>> can have many meanings.
>
> Of course the term "most important" quite useless to explain the problem.
> I will try to explain the problem better:
>
> I have a task (the so called "most important" task) that has to
> communicate with the hardware.
> It's the only task that really access the hardware so I can name it
> "Hardware_communicating_task" maybe..?
Maybe. But also "maybe" you will add other hardware-interfacing components
to your system later, so a more descriptive naming could be more reusable :-)
> Then I have others task that read the data that this
> "Hardware_communicating_task" present to its ports.
> I would like that these other tasks have the last data as possible.
> [So i have to synchronise the tasks]
Not really: you can use a data flow communication where the data ports on
the data consuming components are configured to keep only the last arrived
data from the hardware interfacing component.
> These others task has to use these data to calculate new control data
> and send them another time to the "Hardware_communicating_task".
>
> In other words: I have a control purpose. I need to read last data
> form the hardware, calculate how to control and send control data.
> The problem is that the component that communicate with the hardware
> doesn't have a control purpose. The control is "centralised".
If your system is rather "centralized" you could do the whole thing (read
hardware, compute control action, output to hardware again) in one single
component. If you design all the computational functions that you use is a
very decoupled way, you will have no problem to put them in separate
components later one, when really needed.
> An example could be done thinking to SOEM/Orocos_master:
> This component reads data from EtherCAT slaves [hardware] but doesn't
> generate the control command.
> The control command could be generated form a component linked to the
> Master that receive data and decide how to control the slaves.
> Control data are then passed to the master that send it to the slaves.
> Another thing that has to be considered is that the master "has to run
> with its particular period" * while the controller can have any period
> but the components have to be synchronised.
The _data exchange_ has to be "synchronized", but that does not mean that
running all the _components_ have to be synchronized. In other words, a
system design is thinkable where all your components do their thing
whenever they can, using the latest available data. RTT in-process data
communication and data ports allow you to configure an optimally performing
solution.
> *Using DC clock this period it's not fixed but can change a bit to
> keep the master synchronised with the Slave's "DC signal".
> This part of the synchronisation between the Master and the hardware
> slaves has been already solved.
>
> I hope to have explain the problem in a better way.
>
> Best regards
>
> Luca
Herman
How to synchronise tasks?
>>Then I have others task that read the data that this
>>"Hardware_communicating_task" present to its ports.
>>I would like that these other tasks have the last data as possible.
>>[So i have to synchronise the tasks]
>Not really: you can use a data flow communication where the data ports on
>the data consuming components are configured to keep only the last arrived
>data from the hardware interfacing component.
Well, I understand that I haven't expressed the problem in the correct
way, sorry.
Data ports are already configured to keep the last arrived data but
what I mean is that
I would avoid lose potentially useful cycles of the
"Hardware_communicating_task".
I would receive data,calculate and answer not only with the last
arrived data but also as fast as I can*.
*Here I'm supposing that the calculation time (of the "Controller
task") is smaller than the "updatekook time"
of the "Hardware_communicating_task".
Supposing that I have only an "Hardware_communicating_task", at the moment,
and that I don't want to put the control inside this component, to
make the component
more reusable [the control, in the future, can be done receiving
information from various
"Hardware_communicating_task"...SOEM/Orocos EtherCAT master, a camera,...]
As at the moment I have only an "Hardware_communicating_task" that
runs as fast as it can
I would that "Controller task" reads data every cycle of the
"Hardware_communicating_task" so that
its answer can be received (by the Hardware_communicating_task) in the
next cycle.
>The _data exchange_ has to be "synchronised", but that doesn't mean that
>running all the _components_ have to be synchronised. In other words, a
>system design is thinkable where all your components do their thing
>whenever they can, using the latest available data. RTT in-process data
>communication and data ports allow you to configure an optimally performing
>solution.
Maybe I'm not considering the problem from the right point of view,
but I think that at the moment ,as I have only an
"Hardware_communicating_task" I could
synchronise the "updatehook cycle" of the "Controller task" with the
"updatehook cycle" of the
"Hardware_communicating_task".
I would like to avoid losing "Hardware_communicating_task" updatehook
transmitting to
the hardware latest computed data that haven't been calculated with
the last (as possible) read data
from the hardware.
In my mind a complete sequence would be:
-"Hardware_communicating_task" read data from hardware and present
them to its output port
at the beginning of its updatehook.
-"Controller task" reads the data calculate and write them in its output port.
(connected with the input port of the "Hardware_communicating_task")
-new control data (from the "Controller task") will be read from the
"Hardware_communicating_task"
in the next cycle and transmitted to the hardware.
In my mind, in this way there will be a delay of only a cycle (as the
"Hardware_communicating_task"
in the present cycle will send to the hardware control data calculated
in the previous cycle).
So my questions are:
Can I do it in a better way? [Without putting the controller in the
"Hardware_communicating_task"]
How to syncronise the updatehook of the controller so that it will
start just when new data
from the "Hardware_communicating_task" are written in its output port?
Of course when I will have more than an "Hardware_communicating_task"
I will have to decide if synchronise
the controller with one of them (supposing it the critical one) or let
it free to consume and produce data with
its own "updatehook time".
Thanks for any hint.
Best regards
Luca
How to synchronise tasks?
On Sun, 24 Jun 2012, Luca Magnabosco wrote:
>>> Then I have others task that read the data that this
>>> "Hardware_communicating_task" present to its ports.
>>> I would like that these other tasks have the last data as possible.
>>> [So i have to synchronise the tasks]
>
>> Not really: you can use a data flow communication where the data ports on
>> the data consuming components are configured to keep only the last arrived
>> data from the hardware interfacing component.
>
> Well, I understand that I haven't expressed the problem in the correct
> way, sorry.
>
> Data ports are already configured to keep the last arrived data but
> what I mean is that
> I would avoid lose potentially useful cycles of the
> "Hardware_communicating_task".
> I would receive data,calculate and answer not only with the last
> arrived data but also as fast as I can*.
>
> *Here I'm supposing that the calculation time (of the "Controller
> task") is smaller than the "updatekook time"
> of the "Hardware_communicating_task".
>
> Supposing that I have only an "Hardware_communicating_task", at the moment,
> and that I don't want to put the control inside this component, to
> make the component
> more reusable [the control, in the future, can be done receiving
> information from various
> "Hardware_communicating_task"...SOEM/Orocos EtherCAT master, a camera,...]
> As at the moment I have only an "Hardware_communicating_task" that
> runs as fast as it can
> I would that "Controller task" reads data every cycle of the
> "Hardware_communicating_task" so that
> its answer can be received (by the Hardware_communicating_task) in the
> next cycle.
>
>> The _data exchange_ has to be "synchronised", but that doesn't mean that
>> running all the _components_ have to be synchronised. In other words, a
>> system design is thinkable where all your components do their thing
>> whenever they can, using the latest available data. RTT in-process data
>> communication and data ports allow you to configure an optimally performing
>> solution.
>
> Maybe I'm not considering the problem from the right point of view,
> but I think that at the moment ,as I have only an
> "Hardware_communicating_task" I could
> synchronise the "updatehook cycle" of the "Controller task" with the
> "updatehook cycle" of the
> "Hardware_communicating_task".
> I would like to avoid losing "Hardware_communicating_task" updatehook
> transmitting to
> the hardware latest computed data that haven't been calculated with
> the last (as possible) read data
> from the hardware.
>
> In my mind a complete sequence would be:
> -"Hardware_communicating_task" read data from hardware and present
> them to its output port
> at the beginning of its updatehook.
> -"Controller task" reads the data calculate and write them in its output port.
> (connected with the input port of the "Hardware_communicating_task")
> -new control data (from the "Controller task") will be read from the
> "Hardware_communicating_task"
> in the next cycle and transmitted to the hardware.
>
> In my mind, in this way there will be a delay of only a cycle (as the
> "Hardware_communicating_task"
> in the present cycle will send to the hardware control data calculated
> in the previous cycle).
Indeed. But loosing a cycle just because you want to put computations
inside an RTT component makes not much sense, in general. So, optimal
performance can be achieved by doing everything inside the thread/component
that deals with the hardware. The code to do this can very well be kept
reusable, since reusability is not linked to only TaskContext primitives,
not at all.
In other words: don't use RTT's TaskContexts to encapsulate any kind of
functionality that you want to reuse. Use the right tools for the right
tasks...
> So my questions are:
> Can I do it in a better way? [Without putting the controller in the
> "Hardware_communicating_task"]
Why would you not want to do this? If you are looking for optimal
performance, you will have to.
> How to syncronise the updatehook of the controller so that it will
> start just when new data
> from the "Hardware_communicating_task" are written in its output port?
By letting the data ports trigger the execution of the "receiving"
component.
Maybe Markus "FBsched" example is what you are looking after...?
<http://lists.mech.kuleuven.be/pipermail/orocos-users/2012-March/005138.html>
> Of course when I will have more than an "Hardware_communicating_task"
> I will have to decide if synchronise
> the controller with one of them (supposing it the critical one) or let
> it free to consume and produce data with
> its own "updatehook time".
>
> Thanks for any hint.
>
> Best regards
>
> Luca
>
Herman
How to synchronise tasks?
>>So my questions are:
>>Can I do it in a better way? [Without putting the controller in the
>>"Hardware_communicating_task"]
>Why would you not want to do this? If you are looking for optimal
>performance, you will have to.
So when I have only an "Hardware_communicating_task" I have to put the
control in it, ok.
But what I have to do if there are more "Hardware_communicating_tasks"?
[Others person are working for the general project and various
data_source and hardware will be added]
Suppose I'm using SOEM/OROCOS EtherCAT master and a component that
read data from a camera.
To send control data to the slaves (motors) connected through EtherCAT
I need the data from the camera
and from the slaves' encoders, calculate and send.
The optimal strucuture would be encapsulate everything in only one component?
>>How to syncronise the updatehook of the controller so that it will
>>start just when new data
>>from the "Hardware_communicating_task" are written in its output port?
>By letting the data ports trigger the execution of the "receiving"
>component.
>Maybe Markus "FBsched" example is what you are looking after...?
> <http://lists.mech.kuleuven.be/pipermail/orocos-users/2012-March/005138.html>
You mean that every time, when I "compulsory" have more then a
component that has to work
synchronously with others, I have to use this component to synchronise them?
Thanks for all your useful suggestions.
Best regards
Luca