---------- Forwarded message ----------
From: Nicola Preda <nicola [dot] preda [..] ...>
Date: 2012/7/2
Subject: Re: [Orocos-users] rFSM - Simultaneous events
To: Herman Bruyninckx <herman [dot] bruyninckx [..] ...>
I need to generate events from a periodic component and to send them on the
input (EventPort) of an aperiodic component, so I was trying to understand
what is the time limit that I need to respect in order to avoid the
ambiguity between two really simultaneous events and two consecutive events
interpreted as simultaneous.
Nicola
2012/7/2 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Mon, 2 Jul 2012, Nicola Preda wrote:
>
> Hi,
>> I'd like to ask you something about the acquisition of events in rFSM: I
>> looked at the code in *rfsm_rtt.lua* and specifically at this function:
>>
>>
>>
>> function gen_read_str_events(...)
>> local str_ev = rtt.Variable("string")
>> local function read_events(tgttab, port)
>> local fs
>>
>> while true do
>> *fs = port:read(str_ev)*
>>
>> if fs == 'NewData' then tgttab[#tgttab+1] = str_ev:tolua()
>> else break
>> end -- OldData or NoData
>>
>> end
>> end
>> local ports = {...}
>> assert(#ports > 0, "no ports given")
>> -- check its all ports
>> return function ()
>> local res = {}
>> for _,port in ipairs(ports) do read_events(res, port) end
>> return res
>> end
>> end
>>
>>
>> from what I understood, two events are considered simultaneous when they
>> are sent in a time shorter than the one needed to execute the first line
>> of
>> the while loop of the code above (i.e. *fs = port:read(str_ev))*. Am I
>>
>> wrong? And if it is true, isn't this kind of mechanism quite hardware
>> dependent? What I mean is that if you send two consecutive*
>> events.write("e_foo")* you will have two simultaneous events but you will
>>
>> have the same behaviour if you send events from a periodic component to an
>> another at a frequency greater than 1KHz (at least on mine machine). Does
>> it make sense to you?
>>
>
> I think your analysis is correct. And that's fine: an event-based system
> Coordination should be _robust_ against timing issues. In other words, if
> your discrete event logic depends on timing, your system is prone to lots
> of difficult to trace error behaviours.
>
> Is this the case you are confronted with?
>
>
> Thank you for your attention.
>>
>> Best regards,
>> Nicola Preda
>>
>
> Herman
>
Fwd: rFSM - Simultaneous events
Hi Nicola,
On Mon, Jul 02, 2012 at 12:14:33PM +0200, Nicola Preda wrote:
> I need to generate events from a periodic component and to send them on the
> input (EventPort) of an aperiodic component, so I was trying to understand what
> is the time limit that I need to respect in order to avoid the ambiguity
> between two really simultaneous events and two consecutive events interpreted
> as simultaneous.
Herman is right, for that standard getevents function you can't really
rely on whether multiple (triggering) events will be picked up as one
or multipe events. Best is indeed to design the SC such that that
doesn't matter, but if it does then you should explicitely model it.
Markus
Fwd: rFSM - Simultaneous events
Fine, I imagined that I would have to manage the events in some way in
order to have the certainty of the simultaneity of two or more events. I
could store the incoming events inside a table until I receive a handshake
and then pass the whole table to the input of the state machine as a list
of simultaneous events. It should be definitely more robust.
Nicola
2012/7/2 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> Hi Nicola,
>
> On Mon, Jul 02, 2012 at 12:14:33PM +0200, Nicola Preda wrote:
>
> > I need to generate events from a periodic component and to send them on
> the
> > input (EventPort) of an aperiodic component, so I was trying to
> understand what
> > is the time limit that I need to respect in order to avoid the ambiguity
> > between two really simultaneous events and two consecutive events
> interpreted
> > as simultaneous.
>
> Herman is right, for that standard getevents function you can't really
> rely on whether multiple (triggering) events will be picked up as one
> or multipe events. Best is indeed to design the SC such that that
> doesn't matter, but if it does then you should explicitely model it.
>
> Markus
>
Fwd: rFSM - Simultaneous events
On Mon, 2 Jul 2012, Nicola Preda wrote:
> Fine, I imagined that I would have to manage the events in some way in
> order to have the certainty of the simultaneity of two or more events. I
> could store the incoming events inside a table until I receive a handshake
> and then pass the whole table to the input of the state machine as a list
> of simultaneous events. It should be definitely more robust.
Handshakes _are_ part of the Coordination that the state machine is
responsible for! So, don't wipe this essential part of the behaviour under
the carpet of your implementation...
> Nicola
Herman
> 2012/7/2 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
>> Hi Nicola,
>>
>> On Mon, Jul 02, 2012 at 12:14:33PM +0200, Nicola Preda wrote:
>>
>>> I need to generate events from a periodic component and to send them on
>> the
>>> input (EventPort) of an aperiodic component, so I was trying to
>> understand what
>>> is the time limit that I need to respect in order to avoid the ambiguity
>>> between two really simultaneous events and two consecutive events
>> interpreted
>>> as simultaneous.
>>
>> Herman is right, for that standard getevents function you can't really
>> rely on whether multiple (triggering) events will be picked up as one
>> or multipe events. Best is indeed to design the SC such that that
>> doesn't matter, but if it does then you should explicitely model it.
>>
>> Markus
>>
>
Fwd: rFSM - Simultaneous events
On Mon, Jul 02, 2012 at 01:02:10PM +0200, Nicola Preda wrote:
> Fine, I imagined that I would have to manage the events in some way in order to
> have the certainty of the simultaneity of two or more events. I could store the
> incoming events inside a table until I receive a handshake and then pass the
> whole table to the input of the state machine as a list of simultaneous events.
> It should be definitely more robust.
Hmm, this sounds a bit like a hack :-), but you havn't given any
details on your application, so I can't really comment. But in any
case, if your application is emitting multiple events simultaneously
and you require them to be treated as such, then I would indeed model
that: for instance in RTT you could send an array of strings instead
of a string only, and define a new getevents that deals with
that. Note that the functions in rfsm_rtt are just "often" applicable,
not to be interpreted as "the single best way".
Markus
Fwd: rFSM - Simultaneous events
Yes, it looks like a bit "hacky", I think that the approach that you have
suggested could be a more elegant solution to the problem also because in
this case I would not need a handshake system: I will try it!
Nicola
2012/7/2 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> On Mon, Jul 02, 2012 at 01:02:10PM +0200, Nicola Preda wrote:
> > Fine, I imagined that I would have to manage the events in some way in
> order to
> > have the certainty of the simultaneity of two or more events. I could
> store the
> > incoming events inside a table until I receive a handshake and then pass
> the
> > whole table to the input of the state machine as a list of simultaneous
> events.
> > It should be definitely more robust.
>
> Hmm, this sounds a bit like a hack :-), but you havn't given any
> details on your application, so I can't really comment. But in any
> case, if your application is emitting multiple events simultaneously
> and you require them to be treated as such, then I would indeed model
> that: for instance in RTT you could send an array of strings instead
> of a string only, and define a new getevents that deals with
> that. Note that the functions in rfsm_rtt are just "often" applicable,
> not to be interpreted as "the single best way".
>
> Markus
>