>> In our control application we feel the need tob e able to run
components
>> on two types of "events" in the same thread.
>
>What is the precise semantics of 'to run a component'?

In practice a component would be a RTT::TaskCOntext. Basicaly 'to run a
component' means to run a RTT::TaskCOntext's ExecutionEngine.

>
>> The first one being a certain period, the second being an actual
event.
>> On the periodic "event" every component of the thread should be run,
on
>> the other event only the components registered to the event may run.
>>
>What's wrong with the 'second component' just being the "other" event
>handler? (I guess there might be a problem with the thread context not
>being the right one...)
>
>Is it important that this 'second component' is an active object in
itself?
>If so, give it an event handler that switches the TaskContext's state
>machine to a state where both components are active, and the 'other
event
>component' switches the state machine back to the state where only the
>first component runs.
>
There will more than two components. Anyway I think you might have
missed the point since I don't get your remark. I'll try to clarify:

Now we have a situation we are forced to run a component on a high
frequency (1 kHz) just to be able to react within time to (only) one of
its inputs. Now the idea has risen to make that one input event driven
(still polling the others). So we can lower the component's frequency to
100 Hz. But to make the component respond in time we have to run the
component as fast as possible after the input-event is fired. So e we
need a mix of a Periodic- and NonPeriodicActivity.

We could use a synchronious event handler to react fast on a change of
input. But this means possible problems with data used within the
components normal (periodic) operation. By running the component in the
same thread by making the thread active before the thread's period
expires solves this...

Sander.

>>
>> Any way, I thought I get better results; Already 50 % cpu is used,
and
>> there is no application yet! It turns out that queueing and
dequeueing
>> events consume way too much cpu.
>
>Which events are queued/dequeued ? The tick event * 64 ?
>
Yep, a component connects an ASYNC event handler to a 'tick' event.

>>
>> Now we are thinking about:
>> - 1 ExecutionEngine / NonPeriodicActivity, running multiple
components
>> and periodically triggerd by a 'tick task'.
>> - 1 or more Events per component to trigger execution.
>>
>> This means in case of an Event that apart from the events also the
>> update() off every child component is run by the ExecutionEngine.
This
>> is not per definition a problem, but how could we optimize this? And
>> call only the update() if the component has to handle an event?
>
>1. Do you require updateHook() to be called or can you put all your
>application code in an event handler/hook ?
The updateHook() should be called periodically only, except if an
event/command for that component is queued/executed.

>2. Did you take a look at the pending patch for 1.4 which introduces
>an 'active' state (opposed to running), which handles only events and
>commands but no updateHook() ? Does this solve your problem ?
>
I haven't looked into it in detail but it could be a solution. I can set
the EE to 'running' in my tick task before triggering the task the EE is
running in. I have to set the EE to active again when the updates are
called.

Sander.

>
>Sander,
>I'm not sure I understand it (completely), but would it be a solution
>if you would create a kind of TimerComponent (connected to a
>PeriodicActivity at 100Hz) that fires events every time it wakes up,
>and make your "true" component (using a Non-Periodic activity) listen
>to both the events of the timer component and the high priority event
>fired by the input?
>
>I'm not even sure if it can be implemented, since a 2 second search in
>the component builders manual did not yield and example of how I could
>create such a component connected to a non-Periodic activity and only
>woken up by the events it is connected to (Peter, I have probably
>overlooked something)?
>
>Klaas

I have an application now that runs 64 components (TaskContexts) in two
NonPeriodicThreads with two ExecutionEngines. The compoents register to
a 'tick event' that is fired every 10 ms. The connected functions are
handled in the NonPeriodicActivities. Is this what you proposed?

Any way, I thought I get better results; Already 50 % cpu is used, and
there is no application yet! It turns out that queueing and dequeueing
events consume way too much cpu.

Now we are thinking about:
- 1 ExecutionEngine / NonPeriodicActivity, running multiple components
and periodically triggerd by a 'tick task'.
- 1 or more Events per component to trigger execution.

This means in case of an Event that apart from the events also the
update() off every child component is run by the ExecutionEngine. This
is not per definition a problem, but how could we optimize this? And
call only the update() if the component has to handle an event?

Sander.

>
>But you can share execution engine's between components. If all code is
in
>an
We already share one ExecutionEngine for multiple components. Looking at
the ExecutionEngine code it appears to me that when no Owner is defined
nor Children are added to the EE, update won't be called at all. This is
what I want. Do you see any downsides?

>event handler function, one thread can run your whole application which
>only
>reacts to events and another thread just runs the Timer component. I
wonder
>if both could be merged, but I think not as mixing rates in one thread
is a
>bad idea.
>
Indeed, we want to run all the code of one Component in one thread.

Sander.

>Now for a solution, I believe Klaas his proposal comes closest. Use
>the 'Timer' class of RTT 1.4, or TimerComponent of OCL which can be
armed
>to
>emit events (a-)periodically (it uses a non periodic activity, with a
timed
>semaphore for this). Make your application's TaskContext non periodic
and
>let
>it subscribe to the event of the TimerComponent. Next, move the
updateHook()
>code from your TaskContext to an event handler, which is attached to
the
>Timer's event. Attach your other (IO) event handlers to their events.
Now
>you
>have the following situation :
>
>* Both Timer(Component) and your TaskContext have non periodic
activities.
>* Every 10ms: the Timer emits an event, which wakes your component and
>calls
>the 'periodic' event handler function.
>* Every time IO changes: Your IO function hook is called, but not the
>periodic
>update function.
>* Both events will never interfere and will be serialised.
>
>This is the cleanest solution I could think of. Maybe the
TimerComponent is
>opening a new usage pattern in Orocos of 100% event-driven activities.
>
This is what I have in mind too. Unforunately we have some prehistoric
trunk version of OROCOS. So we don't have the Timer(Component) but I
created TimedEvents that address the same problem.

So we will end up with one Periodic tick task and a couple
"ControlThreads" who run components depending on the priority.

Thanx for the input!

Sander.

On Thursday 18 October 2007 16:35:19 Vandenbroucke Sander wrote:
> >Sander,
> >I'm not sure I understand it (completely), but would it be a solution
> >if you would create a kind of TimerComponent (connected to a
> >PeriodicActivity at 100Hz) that fires events every time it wakes up,
> >and make your "true" component (using a Non-Periodic activity) listen
> >to both the events of the timer component and the high priority event
> >fired by the input?
>
> Klaas,
>
> This is what I thought of too, but a NonPeriodicActivity can only handle
> one RunnableInterface (base of ExecutionEngine). This would mean a
> thread per component; Not desired.

But you can share execution engine's between components. If all code is in an
event handler function, one thread can run your whole application which only
reacts to events and another thread just runs the Timer component. I wonder
if both could be merged, but I think not as mixing rates in one thread is a
bad idea.

>
> Now I'm thinking on a NonPeriodicActivity witch has a 'RunList'. An
> Event (could be from a Timercomponent) would then call a function
> sheduleRunner(RunnableInterface*) to an item to the RunList and
> trigger() the activity. Then the activity walks through the RunList
> removing runners once they have been run.
>
> But maybe this is far fetched...

Just move your code outside updateHook and inside an event handler and you'll
have your solution.

Peter

>> This is what I thought of too, but a NonPeriodicActivity can only
handle
>> one RunnableInterface (base of ExecutionEngine). This would mean a
>> thread per component; Not desired.
>
>Do you mean that is undesired due to embedded constraints, i.e. you
>loose too much stack space since there would be too many components?
>

In our OS, every task has its own priority. So it's a question of memory
and available priorities.

Sander.

On Thu, 18 Oct 2007, Vandenbroucke Sander wrote:
>>> Now we have a situation we are forced to run a component on a high
>>> frequency (1 kHz) just to be able to react within time to (only) one
> of
>>> its inputs. Now the idea has risen to make that one input event
> driven
>>> (still polling the others). So we can lower the component's frequency
> to
>>> 100 Hz. But to make the component respond in time we have to run the
>>> component as fast as possible after the input-event is fired. So e we
>>> need a mix of a Periodic- and NonPeriodicActivity.
>>>
>>> We could use a synchronious event handler to react fast on a change
> of
>>> input. But this means possible problems with data used within the
>>> components normal (periodic) operation. By running the component in
> the
>>> same thread by making the thread active before the thread's period
>>> expires solves this...
>>
>> I'm not sure I understand it (completely), but would it be a solution
>> if you would create a kind of TimerComponent (connected to a
>> PeriodicActivity at 100Hz) that fires events every time it wakes up,
>> and make your "true" component (using a Non-Periodic activity) listen
>> to both the events of the timer component and the high priority event
>> fired by the input?

> This is what I thought of too, but a NonPeriodicActivity can only handle
> one RunnableInterface (base of ExecutionEngine). This would mean a
> thread per component; Not desired.

Do you mean that is undesired due to embedded constraints, i.e. you
loose too much stack space since there would be too many components?

Klaas