Timer timeouts

Submitted by Klaas Gadeyne on Thu, 2010-02-04 15:32

Orocos-users

Hi,

consider the FSM in attach. It should switch to the second state
after 4 seconds (which it does), and to the 3 state after 14 seconds
(4+10). However, it also switches to state 3 after 4 seconds (i.e.
immediately).
I have tested with both 1.8 and 1.10. Component and deployers file attached.

What am I doing wrong here?

Thx,

Klaas

Attachment	Size
TimerTest.xml	1.82 KB
TimerTest.osd	1.18 KB
TestTimerComponent.cpp	1.6 KB

Timer timeouts

Submitted by snrkiwi on Thu, 2010-02-04 16:40.

On Feb 4, 2010, at 10:25 , Klaas Gadeyne wrote:

> Hi,
>
> consider the FSM in attach. It should switch to the second state
> after 4 seconds (which it does), and to the 3 state after 14 seconds
> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
> immediately).
> I have tested with both 1.8 and 1.10. Component and deployers file attached.
>
> What am I doing wrong here?
>
> Thx,
>
> Klaas

Peter and I made a bunch of fixes to the OCL timer code some months back. I'm not sure if they in 1.8 or 1.10, but we did fix issues just like this. One thing I do is use separate ID's for everything, as well as ensure the timeout ID matches the transition. As follows ...

	state X
	{
		entry 
		{ 
			// set timeout	   
			do Timer.arm(ID_X, 10.0)
		}
		run
		{
			// ...
		}
		exit
		{
			// in case still running
			do Timer.killTimer(ID_X)
		}
		transition Timer.timeout(timerID) if timerID == ID_X then select Y
		// ...
	}

HTH
Stephen

Timer timeouts

Submitted by snrkiwi on Thu, 2010-02-04 17:16.

On Feb 4, 2010, at 11:01 , Klaas Gadeyne wrote:

> On Thu, Feb 4, 2010 at 4:54 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
>> On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
>>> Hi,
>>>
>>> consider the FSM in attach. It should switch to the second state
>>> after 4 seconds (which it does), and to the 3 state after 14 seconds
>>> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
>>> immediately).
>>> I have tested with both 1.8 and 1.10. Component and deployers file
>>> attached.
>>>
>>> What am I doing wrong here?
>>
>> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
>> 1.12 to fix it. Stephen discussed this at length already on this list.
>
> I read Stephens posts (at least I think I do, I guess you refer to
> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
> before coming here but they somehow seemed unrelated. The bug (it
> seems to be a bug, see below) seems to be more related to (the closed
> issue)
> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
>
> Now for the "workaround": Changing the ID in between _and_ checking
> the ID when the event is fired solves the issue. Just changing the
> timerID in between or just checking doesn't solve the issue. My
> components are still both non-periodical.
>
> @Stephen: Do you see a relationship between bug #703 and this case?

Possibly, yes (and one of my replies to you about this still hasn't come thru the ML, huh!). This looks a lot like some of the tests cases I tried out, when originally working 703.

The old implementation that you are using is seriously broken, Peter and I verified that. Can you try your original test against OCL trunk and see what happens?

HTH
S

Timer timeouts

Submitted by sspr on Thu, 2010-02-04 15:56.

On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
> Hi,
>
> consider the FSM in attach. It should switch to the second state
> after 4 seconds (which it does), and to the 3 state after 14 seconds
> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
> immediately).
> I have tested with both 1.8 and 1.10. Component and deployers file
> attached.
>
> What am I doing wrong here?

Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
1.12 to fix it. Stephen discussed this at length already on this list.

Peter

Timer timeouts

Submitted by Klaas Gadeyne on Thu, 2010-02-04 21:24.

On Thu, Feb 4, 2010 at 4:54 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
> On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
>> Hi,
>>
>> consider the FSM in attach. It should switch to the second state
>> after 4 seconds (which it does), and to the 3 state after 14 seconds
>> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
>> immediately).
>> I have tested with both 1.8 and 1.10. Component and deployers file
>> attached.
>>
>> What am I doing wrong here?
>
> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
> 1.12 to fix it. Stephen discussed this at length already on this list.

I read Stephens posts (at least I think I do, I guess you refer to
<http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
before coming here but they somehow seemed unrelated. The bug (it
seems to be a bug, see below) seems to be more related to (the closed
issue)
<https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.

Now for the "workaround": Changing the ID in between _and_ checking
the ID when the event is fired solves the issue. Just changing the
timerID in between or just checking doesn't solve the issue. My
components are still both non-periodical.

@Stephen: Do you see a relationship between bug #703 and this case?

Klaas

Timer timeouts

Submitted by snrkiwi on Thu, 2010-02-04 15:44.

On Feb 4, 2010, at 10:25 , Klaas Gadeyne wrote:

Also, we run the Timer component as a periodic activity. That might be due to the fixes we implemented.
S

Timer timeouts

Submitted by Klaas Gadeyne on Thu, 2010-02-04 22:24.

On Thu, Feb 4, 2010 at 6:29 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Feb 4, 2010, at 11:35 , Klaas Gadeyne wrote:
>
>> On Thu, Feb 4, 2010 at 5:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>> On Feb 4, 2010, at 11:01 , Klaas Gadeyne wrote:
>>>
>>>> On Thu, Feb 4, 2010 at 4:54 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
>>>>> On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
>>>>>> Hi,
>>>>>>
>>>>>> consider the FSM in attach. It should switch to the second state
>>>>>> after 4 seconds (which it does), and to the 3 state after 14 seconds
>>>>>> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
>>>>>> immediately).
>>>>>> I have tested with both 1.8 and 1.10. Component and deployers file
>>>>>> attached.
>>>>>>
>>>>>> What am I doing wrong here?
>>>>>
>>>>> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
>>>>> 1.12 to fix it. Stephen discussed this at length already on this list.
>>>>
>>>> I read Stephens posts (at least I think I do, I guess you refer to
>>>> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
>>>> before coming here but they somehow seemed unrelated. The bug (it
>>>> seems to be a bug, see below) seems to be more related to (the closed
>>>> issue)
>>>> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
>>>>
>>>> Now for the "workaround": Changing the ID in between _and_ checking
>>>> the ID when the event is fired solves the issue. Just changing the
>>>> timerID in between or just checking doesn't solve the issue. My
>>>> components are still both non-periodical.
>>>>
>>>> @Stephen: Do you see a relationship between bug #703 and this case?
>>>
>>> Possibly, yes (and one of my replies to you about this still hasn't come thru the ML, huh!). This looks a lot like some of the tests cases I tried out, when originally working 703.
>>>
>>> The old implementation that you are using is seriously broken, Peter and I verified that. Can you try your original test against OCL trunk and see what happens?
>>
>> Trunk doesn't seem to fix it. I'm seeing the exact same thing: when I
>> don't alter the timerID in between, I'm f*cked.
>> Can I conclude it's a different thing from what you've fixed?

> Maybe, I'm not sure. One of my projects generates state machines where you have several move states, followed by a find state (for want of a better term). Each move state uses multiple Timer.wait() commands with one ID, but we _had_ to use a different ID for the find state (which is the one I sent to the ML earlier) that uses Timer.arm() like your example. I never got it to work using the same ID, that I remember (this was middle of last year, when Peter and I were beating up the state machine implementation).
>
> This might be the same issue that was simply never solved, but this particular aspect of it I don't think ended up in the forum.

ACK. I'm gonna put in in bugzilla anyway. Just cross checked on mac
os x and I can reproduce it here too.

Klaas

Timer timeouts

Submitted by Klaas Gadeyne on Fri, 2010-02-05 09:00.

On Thu, Feb 4, 2010 at 11:21 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...> wrote:
[...]
>>>>>> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
>>>>>> 1.12 to fix it. Stephen discussed this at length already on this list.

My guess is now that it ain't related to the TimerComponent (see below).

>>>>> I read Stephens posts (at least I think I do, I guess you refer to
>>>>> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
>>>>> before coming here but they somehow seemed unrelated. The bug (it
>>>>> seems to be a bug, see below) seems to be more related to (the closed
>>>>> issue)
>>>>> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
[...]

I've reread bug #703 and stumbled upon
<https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703#c11>. I've
skipped that yesterday due to Peter's quote

<quote>
I'm not expecting anyone to understand this :-)
<quote>

And who was I to doubt that :-)
But on second thought, that particular comment may be the cause of
what I'm seeing.

[...]
>>> Can I conclude it's a different thing from what you've fixed?
>
>> Maybe, I'm not sure. One of my projects generates state machines where you have several move states, followed by a find state (for want of a better term). Each move state uses multiple Timer.wait() commands with one ID, but we _had_ to use a different ID for the find state (which is the one I sent to the ML earlier) that uses Timer.arm() like your example. I never got it to work using the same ID, that I remember (this was middle of last year, when Peter and I were beating up the state machine implementation).
>>
>> This might be the same issue that was simply never solved, but this particular aspect of it I don't think ended up in the forum.

When I, despite Peters warnings :-), try to interpret comment 11, I
would guess that the test scenario for solving the problems with the
TimerComponent revealed a new bug in the C++ statemachine class.
So Stephen's patch has probably fixed the timerComponent (at least in
the 1.x mainline), but the problem with the statemachine is still
there.

Now all the above contains a lot of "I guess and I suppose"...

@Peter, in the comment you specified that you were "still assessing
which is the fasted path to solution." [*] Has anything changed
meanwhile (apparently not in trunk, but maybe in the 2.x
implementation?) or can you suggest a solution?

Thx,

Klaas

[*] "Someone" once mentioned on this ML: If I can't find it using
google, it doesn't exist. Luckily I could find it this time ;-P

Timer timeouts

Submitted by sspr on Tue, 2010-03-09 10:48.

On Friday 05 February 2010 09:56:07 Klaas Gadeyne wrote:
> On Thu, Feb 4, 2010 at 11:21 PM, Klaas Gadeyne <klaas [dot] gadeyne [..] ...>
> wrote: [...]
>
> >>>>>> Unless I'm mistaken, the TimerComponent is broken in these versions.
> >>>>>> We need a 1.12 to fix it. Stephen discussed this at length already
> >>>>>> on this list.
>
> My guess is now that it ain't related to the TimerComponent (see below).
>
> >>>>> I read Stephens posts (at least I think I do, I guess you refer to
> >>>>> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-c
> >>>>>ommands-do-not-work-are-running-non-periodic-activity> before coming
> >>>>> here but they somehow seemed unrelated. The bug (it seems to be a
> >>>>> bug, see below) seems to be more related to (the closed issue)
> >>>>> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
>
> [...]
>
> I've reread bug #703 and stumbled upon
> <https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=703#c11>. I've
> skipped that yesterday due to Peter's quote
>
> <quote>
> I'm not expecting anyone to understand this :-)
> <quote>
>
> And who was I to doubt that :-)
> But on second thought, that particular comment may be the cause of
> what I'm seeing.
>
> [...]
>
> >>> Can I conclude it's a different thing from what you've fixed?
> >>
> >> Maybe, I'm not sure. One of my projects generates state machines where
> >> you have several move states, followed by a find state (for want of a
> >> better term). Each move state uses multiple Timer.wait() commands with
> >> one ID, but we _had_ to use a different ID for the find state (which is
> >> the one I sent to the ML earlier) that uses Timer.arm() like your
> >> example. I never got it to work using the same ID, that I remember (this
> >> was middle of last year, when Peter and I were beating up the state
> >> machine implementation).
> >>
> >> This might be the same issue that was simply never solved, but this
> >> particular aspect of it I don't think ended up in the forum.
>
> When I, despite Peters warnings :-), try to interpret comment 11, I
> would guess that the test scenario for solving the problems with the
> TimerComponent revealed a new bug in the C++ statemachine class.
> So Stephen's patch has probably fixed the timerComponent (at least in
> the 1.x mainline), but the problem with the statemachine is still
> there.
>
> Now all the above contains a lot of "I guess and I suppose"...
>
> @Peter, in the comment you specified that you were "still assessing
> which is the fasted path to solution." [*] Has anything changed
> meanwhile (apparently not in trunk, but maybe in the 2.x
> implementation?) or can you suggest a solution?

There is no solution to this problem in 1.x. In 2.x, the TimerComponent will
send out timeout events on its output port. This solves the issues Stephen
noted in comment #9 of bug #703. Meaning, you'll be able to re-use the same
timer ID after a timer expired.

Peter

Timer timeouts

Submitted by Klaas Gadeyne on Thu, 2010-02-04 16:36.

On Thu, Feb 4, 2010 at 5:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Feb 4, 2010, at 11:01 , Klaas Gadeyne wrote:
>
>> On Thu, Feb 4, 2010 at 4:54 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
>>> On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
>>>> Hi,
>>>>
>>>> consider the FSM in attach. It should switch to the second state
>>>> after 4 seconds (which it does), and to the 3 state after 14 seconds
>>>> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
>>>> immediately).
>>>> I have tested with both 1.8 and 1.10. Component and deployers file
>>>> attached.
>>>>
>>>> What am I doing wrong here?
>>>
>>> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
>>> 1.12 to fix it. Stephen discussed this at length already on this list.
>>
>> I read Stephens posts (at least I think I do, I guess you refer to
>> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
>> before coming here but they somehow seemed unrelated. The bug (it
>> seems to be a bug, see below) seems to be more related to (the closed
>> issue)
>> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
>>
>> Now for the "workaround": Changing the ID in between _and_ checking
>> the ID when the event is fired solves the issue. Just changing the
>> timerID in between or just checking doesn't solve the issue. My
>> components are still both non-periodical.
>>
>> @Stephen: Do you see a relationship between bug #703 and this case?
>
> Possibly, yes (and one of my replies to you about this still hasn't come thru the ML, huh!). This looks a lot like some of the tests cases I tried out, when originally working 703.
>
> The old implementation that you are using is seriously broken, Peter and I verified that. Can you try your original test against OCL trunk and see what happens?

Trunk doesn't seem to fix it. I'm seeing the exact same thing: when I
don't alter the timerID in between, I'm f*cked.
Can I conclude it's a different thing from what you've fixed?

Klaas

Timer timeouts

Submitted by snrkiwi on Thu, 2010-02-04 22:40.

On Feb 4, 2010, at 11:35 , Klaas Gadeyne wrote:

> On Thu, Feb 4, 2010 at 5:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Feb 4, 2010, at 11:01 , Klaas Gadeyne wrote:
>>
>>> On Thu, Feb 4, 2010 at 4:54 PM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
>>>> On Thursday 04 February 2010 16:25:24 Klaas Gadeyne wrote:
>>>>> Hi,
>>>>>
>>>>> consider the FSM in attach. It should switch to the second state
>>>>> after 4 seconds (which it does), and to the 3 state after 14 seconds
>>>>> (4+10). However, it also switches to state 3 after 4 seconds (i.e.
>>>>> immediately).
>>>>> I have tested with both 1.8 and 1.10. Component and deployers file
>>>>> attached.
>>>>>
>>>>> What am I doing wrong here?
>>>>
>>>> Unless I'm mistaken, the TimerComponent is broken in these versions. We need a
>>>> 1.12 to fix it. Stephen discussed this at length already on this list.
>>>
>>> I read Stephens posts (at least I think I do, I guess you refer to
>>> <http://www.orocos.org/forum/rtt/rtt-dev/bug-703-new-timercomponent-commands-do-not-work-are-running-non-periodic-activity>
>>> before coming here but they somehow seemed unrelated. The bug (it
>>> seems to be a bug, see below) seems to be more related to (the closed
>>> issue)
>>> <https://svn.fmtc.be/bugzilla/orocos/show_bug.cgi?id=450>.
>>>
>>> Now for the "workaround": Changing the ID in between _and_ checking
>>> the ID when the event is fired solves the issue. Just changing the
>>> timerID in between or just checking doesn't solve the issue. My
>>> components are still both non-periodical.
>>>
>>> @Stephen: Do you see a relationship between bug #703 and this case?
>>
>> Possibly, yes (and one of my replies to you about this still hasn't come thru the ML, huh!). This looks a lot like some of the tests cases I tried out, when originally working 703.
>>
>> The old implementation that you are using is seriously broken, Peter and I verified that. Can you try your original test against OCL trunk and see what happens?
>
> Trunk doesn't seem to fix it. I'm seeing the exact same thing: when I
> don't alter the timerID in between, I'm f*cked.
> Can I conclude it's a different thing from what you've fixed?
>
> Klaas

Maybe, I'm not sure. One of my projects generates state machines where you have several move states, followed by a find state (for want of a better term). Each move state uses multiple Timer.wait() commands with one ID, but we _had_ to use a different ID for the find state (which is the one I sent to the ML earlier) that uses Timer.arm() like your example. I never got it to work using the same ID, that I remember (this was middle of last year, when Peter and I were beating up the state machine implementation).

This might be the same issue that was simply never solved, but this particular aspect of it I don't think ended up in the forum.

HTH
Stephen