Hello,
I am reusing some software developed in the BRICS research camp on Control
and Coordination last year.
In the "deploy.lua" file there is a "Supervisor" that is an
OCL::LuaComponent and a "Timer" component.
The "Supervisor" is a state machine doing coordination and is connected to
the "Timer" component that runs at a fixed frequency.
The output of the "Timer" is connected to an event based input port of the
"Supervisor" to wake it up at the same frequency.
My question is - Why don't we just attach a periodic activity to the
"Supervisor" component and don't use the "Timer" component? Why cant the
activity be used as the heartbeat? Am I missing on something here?
Best Wishes
Shashank
Need of Timer heart beat component for Coordinator in FSM
On Mon, 18 Jun 2012, shashank sharma wrote:
> Hello,
>
> I am reusing some software developed in the BRICS research camp on Control
> and Coordination last year.
>
> In the "deploy.lua" file there is a "Supervisor" that is an
> OCL::LuaComponent and a "Timer" component.
>
> The "Supervisor" is a state machine doing coordination and is connected to
> the "Timer" component that runs at a fixed frequency.
>
> The output of the "Timer" is connected to an event based input port of the
> "Supervisor" to wake it up at the same frequency.
>
> My question is - Why don't we just attach a periodic activity to the
> "Supervisor" component and don't use the "Timer" component? Why cant the
> activity be used as the heartbeat? Am I missing on something here?
The Timer can be more flexible than just sending out _one single_ periodic heartbeat...
But inside, a Timer component _is_ of course connected to the (operating
system) clock, providing services on top of that.
> Best Wishes
> Shashank
Herman
Need of Timer heart beat component for Coordinator in FSM
On Mon, Jun 18, 2012 at 02:55:29PM +0200, Herman Bruyninckx wrote:
> On Mon, 18 Jun 2012, shashank sharma wrote:
>
> > Hello,
> >
> > I am reusing some software developed in the BRICS research camp on Control
> > and Coordination last year.
> >
> > In the "deploy.lua" file there is a "Supervisor" that is an
> > OCL::LuaComponent and a "Timer" component.
> >
> > The "Supervisor" is a state machine doing coordination and is connected to
> > the "Timer" component that runs at a fixed frequency.
> >
> > The output of the "Timer" is connected to an event based input port of the
> > "Supervisor" to wake it up at the same frequency.
> >
> > My question is - Why don't we just attach a periodic activity to the
> > "Supervisor" component and don't use the "Timer" component? Why cant the
> > activity be used as the heartbeat? Am I missing on something here?
>
> The Timer can be more flexible than just sending out _one single_ periodic heartbeat...
> But inside, a Timer component _is_ of course connected to the (operating
> system) clock, providing services on top of that.
That's true, but the main reason is that in RTT you can't combine an
event driven component with a periodic activity, and most of the time
we want to wake up on asynchronous events and not periodically. The
timer component only triggers periodic low frequency events to get
timeouts etc processsed.
Markus
Need of Timer heart beat component for Coordinator in FSM
On Mon, 18 Jun 2012, Markus Klotzbuecher wrote:
> On Mon, Jun 18, 2012 at 02:55:29PM +0200, Herman Bruyninckx wrote:
>> On Mon, 18 Jun 2012, shashank sharma wrote:
>>
>>> Hello,
>>>
>>> I am reusing some software developed in the BRICS research camp on Control
>>> and Coordination last year.
>>>
>>> In the "deploy.lua" file there is a "Supervisor" that is an
>>> OCL::LuaComponent and a "Timer" component.
>>>
>>> The "Supervisor" is a state machine doing coordination and is connected to
>>> the "Timer" component that runs at a fixed frequency.
>>>
>>> The output of the "Timer" is connected to an event based input port of the
>>> "Supervisor" to wake it up at the same frequency.
>>>
>>> My question is - Why don't we just attach a periodic activity to the
>>> "Supervisor" component and don't use the "Timer" component? Why cant the
>>> activity be used as the heartbeat? Am I missing on something here?
>>
>> The Timer can be more flexible than just sending out _one single_ periodic heartbeat...
>> But inside, a Timer component _is_ of course connected to the (operating
>> system) clock, providing services on top of that.
>
> That's true, but the main reason is that in RTT you can't combine an
> event driven component with a periodic activity,
Which, by the way, was one of the fundamental errors we made in the
original RTT design: time interrupts are just one case of events, and
giving one type of event a special role leads to lots of problems. FOr
example: the periodic activity "event" is acting behind the screens, not
visible at the port level, hence violating the port-based approach that we
claim to follow.
Note that I use the term "port based" and not "component based", because
the real fundamental aspect of the approach is that _every behaviour
influencing_ information in a design should be visible via the ports, and
not via interactions hidden somewhere in the inside of components.
Explicit use of a Timer component resolves this fundamental problem. At
least when the component has ports to configure its timing properties.
> and most of the time
> we want to wake up on asynchronous events and not periodically. The
> timer component only triggers periodic low frequency events to get
> timeouts etc processsed.
>
> Markus
Herman
Need of Timer heart beat component for Coordinator in FSM
Hello Markus,
This sounds a nice solution for further scenarios where one could have
similar situations of combining periodic behavior with event based
components.
But do you think it is more of a hack/work around for getting the desired
behavior. Would'nt it be a good idea to have such a feature to already
exist as a core feature in RTT rather than doing this lets say "work
around"?
Thanks
Shashank
On Mon, Jun 18, 2012 at 7:27 PM, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, Jun 18, 2012 at 02:55:29PM +0200, Herman Bruyninckx wrote:
> > On Mon, 18 Jun 2012, shashank sharma wrote:
> >
> > > Hello,
> > >
> > > I am reusing some software developed in the BRICS research camp on
> Control
> > > and Coordination last year.
> > >
> > > In the "deploy.lua" file there is a "Supervisor" that is an
> > > OCL::LuaComponent and a "Timer" component.
> > >
> > > The "Supervisor" is a state machine doing coordination and is
> connected to
> > > the "Timer" component that runs at a fixed frequency.
> > >
> > > The output of the "Timer" is connected to an event based input port of
> the
> > > "Supervisor" to wake it up at the same frequency.
> > >
> > > My question is - Why don't we just attach a periodic activity to the
> > > "Supervisor" component and don't use the "Timer" component? Why cant
> the
> > > activity be used as the heartbeat? Am I missing on something here?
> >
> > The Timer can be more flexible than just sending out _one single_
> periodic heartbeat...
> > But inside, a Timer component _is_ of course connected to the (operating
> > system) clock, providing services on top of that.
>
> That's true, but the main reason is that in RTT you can't combine an
> event driven component with a periodic activity, and most of the time
> we want to wake up on asynchronous events and not periodically. The
> timer component only triggers periodic low frequency events to get
> timeouts etc processsed.
>
> Markus
>
Need of Timer heart beat component for Coordinator in FSM
On Mon, Jun 18, 2012 at 08:08:34PM +0200, shashank sharma wrote:
> Hello Markus,
>
> This sounds a nice solution for further scenarios where one could have similar
> situations of combining periodic behavior with event based components.
>
> But do you think it is more of a hack/work around for getting the desired
> behavior. Would'nt it be a good idea to have such a feature to already exist as
> a core feature in RTT rather than doing this lets say "work around"?
Can you explain why you think this is a hack? Which feature exactly do
you propose for RTT?
Markus
Need of Timer heart beat component for Coordinator in FSM
As you said earlier "in RTT you can't combine an event driven component
with a periodic activity".
To me this statement implies that if I have a component and attach a
periodic activity to it. Now if I have event based ports also added to this
component. Suppose the activity fires the component at every 0.5 seconds
and also that an event occurs at the event based input port at say 0.3
seconds starting from time equal to zero. This would mean that the
component is fired at the 0.5 second and perhaps the event is either lost
or will be processed after 0.5 seconds. So there is not a possibility of an
event based system. To realize the correct behavior you used the timer and
used only an event based design without activities so that the component
could be woken in real time when an event occurs and also has a behavior
similar to that of a periodic activity attached to it.
Please let me know if my understanding of the system/statement is correct.
If you say it is correct then perhaps it would be better to implement such
a behavior without the need of this external timer component. In short a
component should be able to behave as if a periodic activity is attached to
it and should also be able to react to event based ports without the need
of this external timer component. This could be added as a feature in the
RTT.
Lastly, if my understanding of the system/statement is not correct then it
would be nice to inform me about the correct meaning.
Br,
Shashank
On Mon, Jun 18, 2012 at 8:33 PM, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:
> On Mon, Jun 18, 2012 at 08:08:34PM +0200, shashank sharma wrote:
> > Hello Markus,
> >
> > This sounds a nice solution for further scenarios where one could have
> similar
> > situations of combining periodic behavior with event based components.
> >
> > But do you think it is more of a hack/work around for getting the desired
> > behavior. Would'nt it be a good idea to have such a feature to already
> exist as
> > a core feature in RTT rather than doing this lets say "work around"?
>
> Can you explain why you think this is a hack? Which feature exactly do
> you propose for RTT?
>
> Markus
>
Need of Timer heart beat component for Coordinator in FSM
Hi Shashank,
On Mon, Jun 18, 2012 at 9:22 PM, shashank sharma
<sonicboomshanky [..] ...>wrote:
> As you said earlier "in RTT you can't combine an event driven component
> with a periodic activity".
> To me this statement implies that if I have a component and attach a
> periodic activity to it. Now if I have event based ports also added to this
> component. Suppose the activity fires the component at every 0.5 seconds
> and also that an event occurs at the event based input port at say 0.3
> seconds starting from time equal to zero. This would mean that the
> component is fired at the 0.5 second and perhaps the event is either lost
> or will be processed after 0.5 seconds. So there is not a possibility of an
> event based system. To realize the correct behavior you used the timer and
> used only an event based design without activities so that the component
> could be woken in real time when an event occurs and also has a behavior
> similar to that of a periodic activity attached to it.
>
> Please let me know if my understanding of the system/statement is correct.
> If you say it is correct then perhaps it would be better to implement such
> a behavior without the need of this external timer component. In short a
> component should be able to behave as if a periodic activity is attached to
> it and should also be able to react to event based ports without the need
> of this external timer component. This could be added as a feature in the
> RTT.
>
> Lastly, if my understanding of the system/statement is not correct then it
> would be nice to inform me about the correct meaning.
>
You're entirely correct. We had this discussion before, and we even
discussed and agreed on the correct semantics, or at least, how the first
patch should look like. See this thread:
http://www.orocos.org/forum/rtt/rtt-dev/changing-behaviour-updatehook
In addition to that, your use case of triggering on both a periodic event
and an event port depends on fixing the above, and was discussed before as
well (don't have a link).
I have not had the liberty to implement this, since it requires a few days
of attention and evaluation.
Peter
Need of Timer heart beat component for Coordinator in FSM
On Jun 18, 2012, at 08:55 , Herman Bruyninckx wrote:
> On Mon, 18 Jun 2012, shashank sharma wrote:
>
>> Hello,
>>
>> I am reusing some software developed in the BRICS research camp on Control
>> and Coordination last year.
>>
>> In the "deploy.lua" file there is a "Supervisor" that is an
>> OCL::LuaComponent and a "Timer" component.
>>
>> The "Supervisor" is a state machine doing coordination and is connected to
>> the "Timer" component that runs at a fixed frequency.
>>
>> The output of the "Timer" is connected to an event based input port of the
>> "Supervisor" to wake it up at the same frequency.
>>
>> My question is - Why don't we just attach a periodic activity to the
>> "Supervisor" component and don't use the "Timer" component? Why cant the
>> activity be used as the heartbeat? Am I missing on something here?
>
> The Timer can be more flexible than just sending out _one single_ periodic heartbeat...
> But inside, a Timer component _is_ of course connected to the (operating
> system) clock, providing services on top of that.
Well ... true ... but you can also more easily modify the Timer to do things like having a variable period, than you can with an Activity. And in this case, Timer wasn't directly connected to the O/S clock.
But I think that the thing to take away is that using Timer can be more flexible (in _some_cases) than using an Activity. It all depends on what your application requires.
S
Need of Timer heart beat component for Coordinator in FSM
Thank you all for the advice!
Br,
Shashank
On Mon, Jun 18, 2012 at 3:13 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>
> On Jun 18, 2012, at 08:55 , Herman Bruyninckx wrote:
>
> > On Mon, 18 Jun 2012, shashank sharma wrote:
> >
> >> Hello,
> >>
> >> I am reusing some software developed in the BRICS research camp on
> Control
> >> and Coordination last year.
> >>
> >> In the "deploy.lua" file there is a "Supervisor" that is an
> >> OCL::LuaComponent and a "Timer" component.
> >>
> >> The "Supervisor" is a state machine doing coordination and is connected
> to
> >> the "Timer" component that runs at a fixed frequency.
> >>
> >> The output of the "Timer" is connected to an event based input port of
> the
> >> "Supervisor" to wake it up at the same frequency.
> >>
> >> My question is - Why don't we just attach a periodic activity to the
> >> "Supervisor" component and don't use the "Timer" component? Why cant the
> >> activity be used as the heartbeat? Am I missing on something here?
> >
> > The Timer can be more flexible than just sending out _one single_
> periodic heartbeat...
> > But inside, a Timer component _is_ of course connected to the (operating
> > system) clock, providing services on top of that.
>
> Well ... true ... but you can also more easily modify the Timer to do
> things like having a variable period, than you can with an Activity. And in
> this case, Timer wasn't directly connected to the O/S clock.
>
> But I think that the thing to take away is that using Timer can be more
> flexible (in _some_cases) than using an Activity. It all depends on what
> your application requires.
> S
>