Re: [Orocos-users] New pull request for modifying the updateHook() behavior.
Willy Lambert <[email protected]> Mon, 13 Apr 2015 22:58:38 +0200
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <CAKvQZ_0phUXOd98BMeJBK48oaVd62fugv_jVfMHuGBgbn8FDSw@mail.gmail.com> |
--===============0170237683==
Content-Type: multipart/alternative; boundary=089e01177917cfbdb30513a160af
--089e01177917cfbdb30513a160af
Content-Type: text/plain; charset=UTF-8
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 <[email protected]>:
> 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
> [email protected]
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
--089e01177917cfbdb30513a160af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Waiting this for soooooooo long ;p In my case, I=
have periodic components that are trigerred out of the periodic refresh wh=
ich breaks my scheduling. For instance it happens when a OwnThread method i=
s called whereas I'd expect it to wait next period.<br><br></div>Meanwh=
ile I'm using a workaround to quit the updateHook when it's not exp=
ected :<br><br></div>//waiting a 2.7 toolchain patch<br><div>=C2=A0=C2=A0=
=C2=A0 if( NewData !=3D inPeriod.readNewest(attrPeriod) )<br>=C2=A0=C2=A0=
=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return;<br>=C2=A0=C2=
=A0=C2=A0 }<br><br></div><div>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.<br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-04-13 10:12 GMT+02:00 =
Peter Soetens <span dir=3D"ltr"><<a href=3D"mailto:peter@thesourceworks.=
com" target=3D"_blank">[email protected]</a>></span>:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Last year, we did a first attempt t=
o describe and solve the issues users are having with updateHook() semantic=
s ( <a href=3D"https://github.com/orocos-toolchain/rtt/pull/70" target=3D"_=
blank">https://github.com/orocos-toolchain/rtt/pull/70</a> ). The major cul=
prit was that updateHook() is called 'any time the component's Exec=
utionEngine is stepped' which is a highly unpredictable event.=C2=A0<di=
v><br></div><div>Users expected that updateHook() is stepped at the compone=
nt's period, or when they did a trigger()/update() in case of non-perio=
dic or slave components.=C2=A0=C2=A0The 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 unpredictabl=
e) updateHook().</div><div><div><br></div><div><a href=3D"https://github.co=
m/orocos-toolchain/rtt/pull/91" target=3D"_blank">https://github.com/orocos=
-toolchain/rtt/pull/91</a> offers what I believe the first mergable candida=
te to solve these issues. To show how it works, two drawings were made, inc=
luded in this PR. We would make these part of the Orocos Component Builder&=
#39;s manual once the PR is merged.<br></div></div><div><br></div><div>Plea=
se report back how this patch is affecting your applications in a good/bad =
way.</div><div><br></div><div>Thanks,</div><div>Peter</div><div><br></div><=
div><br></div></div>
<br>--<br>
Orocos-Users mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]=
ech.kuleuven.be</a><br>
<a href=3D"http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users" tar=
get=3D"_blank">http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users<=
/a><br>
<br></blockquote></div><br></div>
--089e01177917cfbdb30513a160af--
--===============0170237683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
--===============0170237683==--