Hi,
As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
This exchange takes place by ports in my case.
But here I have a problem:
I have 2 FSMs that, for this test case, are running at 100Hz each
FSM_1 raises the event "configure_2" and puts it on a port
FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
If I raise put the event manually on the port: it works
If I raise it multiple times in my FSM_1: it works
Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
Has it something to do with:
fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
Nick
lua statemachine interaction
On Mon, Jul 11, 2011 at 03:57:47PM +0200, Dominick Vanthienen wrote:
> Hi,
>
> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
> This exchange takes place by ports in my case.
> But here I have a problem:
> I have 2 FSMs that, for this test case, are running at 100Hz each
> FSM_1 raises the event "configure_2" and puts it on a port
> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
> If I raise put the event manually on the port: it works
> If I raise it multiple times in my FSM_1: it works
>
> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
>
> Has it something to do with:
> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
It might have something to do with what you described in your other
mail. Could it be that it is read but not used? Is there an other
higher priority event in the queue? Have you tried to enable
fsm debugging?
Markus
lua statemachine interaction
On 07/11/2011 03:57 PM, Dominick Vanthienen wrote:
> Hi,
>
> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
> This exchange takes place by ports in my case.
I made a small testcase, that you can download and try: http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
> But here I have a problem:
> I have 2 FSMs that, for this test case, are running at 100Hz each
> FSM_1 raises the event "configure_2" and puts it on a port
the event is "e_a" in the example
> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
it should change to state with name 'stateII' (it will print: "FSM_2: transition to stateII" and "=>FSM_2 stateII entry" when changing to this state)
> If I raise put the event manually on the port: it works
> If I raise it multiple times in my FSM_1: it works
you can do this by uncommenting following line in FSM_1: --gen_raise_event(events_out, fsm)("e_a")
>
> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
>
> Has it something to do with:
> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
>
> Nick
>
lua statemachine interaction
On 07/11/2011 05:07 PM, Dominick Vanthienen wrote:
>
>
> On 07/11/2011 03:57 PM, Dominick Vanthienen wrote:
>> Hi,
>>
>> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
>> This exchange takes place by ports in my case.
> I made a small testcase, that you can download and try: http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
>
>> But here I have a problem:
>> I have 2 FSMs that, for this test case, are running at 100Hz each
>> FSM_1 raises the event "configure_2" and puts it on a port
> the event is "e_a" in the example
>> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
> it should change to state with name 'stateII' (it will print: "FSM_2: transition to stateII" and "=>FSM_2 stateII entry" when changing to this state)
>> If I raise put the event manually on the port: it works
>> If I raise it multiple times in my FSM_1: it works
> you can do this by uncommenting following line in FSM_1: --gen_raise_event(events_out, fsm)("e_a")
>
>>
>> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
>>
>> Has it something to do with:
>> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
btw: you will notice that FSM_1 will get initialized first, although in the deployer, FSM_2 is started first?!
is this 'expected behaviour'?
>>
>> Nick
>>
lua statemachine interaction
On Mon, Jul 11, 2011 at 05:09:29PM +0200, Dominick Vanthienen wrote:
>
>
> On 07/11/2011 05:07 PM, Dominick Vanthienen wrote:
> >
> >
> > On 07/11/2011 03:57 PM, Dominick Vanthienen wrote:
> >> Hi,
> >>
> >> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
> >> This exchange takes place by ports in my case.
> > I made a small testcase, that you can download and try: http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
> >
> >> But here I have a problem:
> >> I have 2 FSMs that, for this test case, are running at 100Hz each
> >> FSM_1 raises the event "configure_2" and puts it on a port
> > the event is "e_a" in the example
> >> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
> > it should change to state with name 'stateII' (it will print: "FSM_2: transition to stateII" and "=>FSM_2 stateII entry" when changing to this state)
> >> If I raise put the event manually on the port: it works
> >> If I raise it multiple times in my FSM_1: it works
> > you can do this by uncommenting following line in FSM_1: --gen_raise_event(events_out, fsm)("e_a")
> >
> >>
> >> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
> >>
> >> Has it something to do with:
> >> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
Ok, some issues:
- gen_raise_event generates a function that you should store in a
variable and then call later with the events as arguments. For
example
raise_event=gen_raise_event(event_out_port, fsm)
and later:
raise_event("e_a").
- the gen_raise_event should be called in the supervisors
configureHook, and importantly _after_ you create the event port. The
problem in your example is that when you call rfsm.load there is no
'event_out' port defined (Lua is lexically, not dynamically
scoped!). Secondly, if you put this call in the supervisor you move
the framework specific code out of the FSM.
> btw: you will notice that FSM_1 will get initialized first, although in the deployer, FSM_2 is started first?!
> is this 'expected behaviour'?
If you start two threads shortly after each other you can generally
not assume that one will begin execution before the other...
However, the behaviour you observe in your example is caused by the
following: When you start Supervisor2 the first time updateHook() is
called, FSM_2 is entered as you specified from 'initial' to
'stateI'. But before that, getevents is called for the first time,
thereby reading your "e_a", which is then dropped. That is why it
works if you send it again: FSM2 is then in "stateI" and reacts
correctly to it.
The solution requires to coordinate your deployment of FSM. You need
to make sure that FSM2 is in stateI before you activate FSM1. You can
do that by examining the current state of FSM2 in the "currentState"
port.
Markus
lua statemachine interaction
On 07/11/2011 07:29 PM, Markus Klotzbuecher wrote:
> On Mon, Jul 11, 2011 at 05:09:29PM +0200, Dominick Vanthienen wrote:
>>
>> On 07/11/2011 05:07 PM, Dominick Vanthienen wrote:
>>>
>>> On 07/11/2011 03:57 PM, Dominick Vanthienen wrote:
>>>> Hi,
>>>>
>>>> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
>>>> This exchange takes place by ports in my case.
>>> I made a small testcase, that you can download and try: http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
>>>
>>>> But here I have a problem:
>>>> I have 2 FSMs that, for this test case, are running at 100Hz each
>>>> FSM_1 raises the event "configure_2" and puts it on a port
>>> the event is "e_a" in the example
>>>> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
>>> it should change to state with name 'stateII' (it will print: "FSM_2: transition to stateII" and "=>FSM_2 stateII entry" when changing to this state)
>>>> If I raise put the event manually on the port: it works
>>>> If I raise it multiple times in my FSM_1: it works
>>> you can do this by uncommenting following line in FSM_1: --gen_raise_event(events_out, fsm)("e_a")
>>>
>>>> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
>>>>
>>>> Has it something to do with:
>>>> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
> Ok, some issues:
>
> - gen_raise_event generates a function that you should store in a
> variable and then call later with the events as arguments. For
> example
> raise_event=gen_raise_event(event_out_port, fsm)
>
> and later:
> raise_event("e_a").
>
> - the gen_raise_event should be called in the supervisors
> configureHook, and importantly _after_ you create the event port. The
> problem in your example is that when you call rfsm.load there is no
> 'event_out' port defined (Lua is lexically, not dynamically
> scoped!). Secondly, if you put this call in the supervisor you move
> the framework specific code out of the FSM.
>
ah indead, I didn't put
raise_event=gen_raise_event(event_out_port, fsm)
in the configureHook, that's why it didn't work!
this part is solved!
>> btw: you will notice that FSM_1 will get initialized first, although in the deployer, FSM_2 is started first?!
>> is this 'expected behaviour'?
> If you start two threads shortly after each other you can generally
> not assume that one will begin execution before the other...
>
> However, the behaviour you observe in your example is caused by the
> following: When you start Supervisor2 the first time updateHook() is
> called, FSM_2 is entered as you specified from 'initial' to
> 'stateI'. But before that, getevents is called for the first time,
> thereby reading your "e_a", which is then dropped. That is why it
> works if you send it again: FSM2 is then in "stateI" and reacts
> correctly to it.
>
> The solution requires to coordinate your deployment of FSM. You need
> to make sure that FSM2 is in stateI before you activate FSM1. You can
> do that by examining the current state of FSM2 in the "currentState"
> port.
I was thinking of FSM2 sending out an event that he's initialised (or better, periodically sending the event, otherwise we'll end up with the same problem)
> Markus
>
>
>
lua statemachine interaction
On 07/12/2011 09:56 AM, Dominick Vanthienen wrote:
>
>
> On 07/11/2011 07:29 PM, Markus Klotzbuecher wrote:
>> On Mon, Jul 11, 2011 at 05:09:29PM +0200, Dominick Vanthienen wrote:
>>>
>>> On 07/11/2011 05:07 PM, Dominick Vanthienen wrote:
>>>>
>>>> On 07/11/2011 03:57 PM, Dominick Vanthienen wrote:
>>>>> Hi,
>>>>>
>>>>> As I mentioned before, I have multiple lua rFSMs that have to interact (= exchange events)
>>>>> This exchange takes place by ports in my case.
>>>> I made a small testcase, that you can download and try: http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
>>>>
>>>>> But here I have a problem:
>>>>> I have 2 FSMs that, for this test case, are running at 100Hz each
>>>>> FSM_1 raises the event "configure_2" and puts it on a port
>>>> the event is "e_a" in the example
>>>>> FSM_2 has a port connected to this outputport of 2 (I can see that the event has arrived), but it doesn't do the expected state change, that should happen with that event ...
>>>> it should change to state with name 'stateII' (it will print: "FSM_2: transition to stateII" and "=>FSM_2 stateII entry" when changing to this state)
>>>>> If I raise put the event manually on the port: it works
>>>>> If I raise it multiple times in my FSM_1: it works
>>>> you can do this by uncommenting following line in FSM_1: --gen_raise_event(events_out, fsm)("e_a")
>>>>
>>>>> Why does it get lost if I raise it once in my FSM_1? I can see it on the port!
>>>>>
>>>>> Has it something to do with:
>>>>> fsm.getevents = rfsm_rtt.gen_read_events(common_events_in)
>> Ok, some issues:
>>
>> - gen_raise_event generates a function that you should store in a
>> variable and then call later with the events as arguments. For
>> example
>> raise_event=gen_raise_event(event_out_port, fsm)
>>
>> and later:
>> raise_event("e_a").
>>
>> - the gen_raise_event should be called in the supervisors
>> configureHook, and importantly _after_ you create the event port. The
>> problem in your example is that when you call rfsm.load there is no
>> 'event_out' port defined (Lua is lexically, not dynamically
>> scoped!). Secondly, if you put this call in the supervisor you move
>> the framework specific code out of the FSM.
>>
> ah indead, I didn't put
>
> raise_event=gen_raise_event(event_out_port, fsm)
> in the configureHook, that's why it didn't work!
> this part is solved!
>
>>> btw: you will notice that FSM_1 will get initialized first, although in the deployer, FSM_2 is started first?!
>>> is this 'expected behaviour'?
>> If you start two threads shortly after each other you can generally
>> not assume that one will begin execution before the other...
>>
>> However, the behaviour you observe in your example is caused by the
>> following: When you start Supervisor2 the first time updateHook() is
>> called, FSM_2 is entered as you specified from 'initial' to
>> 'stateI'. But before that, getevents is called for the first time,
>> thereby reading your "e_a", which is then dropped. That is why it
>> works if you send it again: FSM2 is then in "stateI" and reacts
>> correctly to it.
>>
>> The solution requires to coordinate your deployment of FSM. You need
>> to make sure that FSM2 is in stateI before you activate FSM1. You can
>> do that by examining the current state of FSM2 in the "currentState"
>> port.
> I was thinking of FSM2 sending out an event that he's initialised (or better, periodically sending the event, otherwise we'll end up with the same problem)
I put a corrected version on http://people.mech.kuleuven.be/~dvanthienen/testFSMinteraction.tar.gz
maybe you want to use it for one of your examples?
>> Markus
>>
>>
>>