Waiting this for soooooooo long ;p In my case, I have periodic components
that are trigerred out of the periodic refresh which breaks my scheduling.
For instance it happens when a OwnThread method is called whereas I'd
expect it to wait next period.

Meanwhile I'm using a workaround to quit the updateHook when it's not
expected :

//waiting a 2.7 toolchain patch
if( NewData != inPeriod.readNewest(attrPeriod) )
{
return;
}

As my "Main clock" is not triggered by any event, i'm sure data comes at
the right time so I can check for wrong updates testing if no new data is
present.

2015-04-13 10:12 GMT+02:00 Peter Soetens <peter [..] ...>:

> Last year, we did a first attempt to describe and solve the issues users
> are having with updateHook() semantics (
> https://github.com/orocos-toolchain/rtt/pull/70 ). The major culprit was
> that updateHook() is called 'any time the component's ExecutionEngine is
> stepped' which is a highly unpredictable event.
>
> Users expected that updateHook() is stepped at the component's period, or
> when they did a trigger()/update() in case of non-periodic or slave
> components. The same behavior was expected for RTT scripts or Lua rFSM
> state machines. Also callbacks on event ports were not executed at the rate
> of data arriving, but at the rate of (the unpredictable) updateHook().
>
> https://github.com/orocos-toolchain/rtt/pull/91 offers what I believe the
> first mergable candidate to solve these issues. To show how it works, two
> drawings were made, included in this PR. We would make these part of the
> Orocos Component Builder's manual once the PR is merged.
>
> Please report back how this patch is affecting your applications in a
> good/bad way.
>
> Thanks,
> Peter
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

Waiting this for soooooooo long ;p In my case, I have periodic components
that are trigerred out of the periodic refresh which breaks my scheduling.
For instance it happens when a OwnThread method is called whereas I'd
expect it to wait next period.

Meanwhile I'm using a workaround to quit the updateHook when it's not
expected :

//waiting a 2.7 toolchain patch
if( NewData != inPeriod.readNewest(attrPeriod) )
{
return;
}

As my "Main clock" is not triggered by any event, i'm sure data comes at
the right time so I can check for wrong updates testing if no new data is
present.

2015-04-13 10:12 GMT+02:00 Peter Soetens <peter [..] ...>:

> Last year, we did a first attempt to describe and solve the issues users
> are having with updateHook() semantics (
> https://github.com/orocos-toolchain/rtt/pull/70 ). The major culprit was
> that updateHook() is called 'any time the component's ExecutionEngine is
> stepped' which is a highly unpredictable event.
>
> Users expected that updateHook() is stepped at the component's period, or
> when they did a trigger()/update() in case of non-periodic or slave
> components. The same behavior was expected for RTT scripts or Lua rFSM
> state machines. Also callbacks on event ports were not executed at the rate
> of data arriving, but at the rate of (the unpredictable) updateHook().
>
> https://github.com/orocos-toolchain/rtt/pull/91 offers what I believe the
> first mergable candidate to solve these issues. To show how it works, two
> drawings were made, included in this PR. We would make these part of the
> Orocos Component Builder's manual once the PR is merged.
>
> Please report back how this patch is affecting your applications in a
> good/bad way.
>
> Thanks,
> Peter
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>