Please, question about "out events"

252 views
Skip to first unread message

Rubén Pérez

unread,
May 2, 2013, 12:07:35 PM5/2/13
to yakind...@googlegroups.com
Hi,

By reading the documentation I can't understand how "out events" are intended to work. Also, I can't see any example with them in use.

My State2 is never reached no matter what I do in the simulation.


Are out events only meant to be used as a pulling mechanism from the client code (the code that uses the resulting thing from the statechart)? Can out events commute events?


Another question, regarding the local events, as far as I understand they can only be raised from the statechart description language, and they are not visible to the outside, is it?



Rubén Pérez

unread,
May 2, 2013, 12:12:42 PM5/2/13
to yakind...@googlegroups.com

At the end, the problem that I'm having is that I get a stackoverflow with this:


Why??

Axel Terfloth

unread,
May 2, 2013, 6:09:58 PM5/2/13
to yakind...@googlegroups.com
Hi Rubén,

our documentation is still not complete - but it will surely improve with the next versions...

So regarding out events - an 'out event' is an event that is raised by the state machine and intended to be consumed by the the statecharts client while a 'in event' is raised outside and consumed by the the state machine. This direction has an impact on the API of the generated state machine. 

In your exampe you never reach the State2 since the execution semantics currently only supports single step semantics. What roughly means that only a single transition will be taken within a run-to-completion step of the state machine. So in your case State1 is initially active. On 'signal' a transition to State3 will be performed an the 'hello' event will be raised and the cycle is finished. Since it is a 'out' event it may be consumed by the client code but it will be available within the next step.  To a certain degree you can react to out (and local) events within orthogonal regions. Here is an example:


Region r1 will be evaluated first. So 'i' triggers the transition from A to B and raises 'o'. Then r2 will be evaluated - now 'o' will trigger the transition to D. This only works within lower priority regions. Local events work in the same way and you are right - since they are local they are not available to the client code.  We plan to introduce a delay property for local events which means that it can be specified if the events will be visible immediately (delay 0) or within the next or any other later cycle (delay 1 or higher) so you can react to raised events in any region.

Best regards,
Axel






--
You received this message because you are subscribed to the Google Groups "YAKINDU User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yakindu-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 


Axel Terfloth

unread,
May 2, 2013, 6:44:50 PM5/2/13
to yakind...@googlegroups.com
Hi Rubén,

that is an interesting case and you obviously came across a validation bug. 

The problem is that the statechart is invalid and the validation mechanism should have detected the error:

A transition from an initial node to its parent state is illegal. The purpose of the initial entry is to indicate what child state should be entered when the parent state is entered so must 'point to' a state in the same region. In your case the The following happens:

1. enter 'Loaded' and since it is a composite state the initial sub state must be entered so
2. enter 'Stopped' and since it is a composite state enter the state the initial entry points to so 
2. enter 'Stopped' and since it is a composite state enter the state the initial entry points to so 
2. ...

So we are in an infinite loop. Due to the construction of the interpreter you get a stack overflow .... Of course you should get error markers that indicate that problem.

It is important to be aware of a fundamental property of composite states: If a state is active and contains child states than for each containing region exactly one child state must be active and an active child state also implies that all parent states are active as well. In your case that means that an active state 'Stopped' also implies that 'Starting' is active what i assume is not you intention... 

A possible constructions with hierarchical states is :


... and an equivalent flat statechart is:



Best regards,
Axel


Rubén Pérez

unread,
May 3, 2013, 4:36:56 AM5/3/13
to yakind...@googlegroups.com
Thank you, it has been very useful your help :)
Reply all
Reply to author
Forward
0 new messages