Is there a way to do something like the following, with the existing State Machine implementation?
{{{
StateMachine MyStateMachineDefinition
{
transitions {
// and have transitions here that apply to all states of this machine?
}
...
state A {
...
}
}
}}}
Possible to do transitions per state machine, and not per state?
On Thursday 01 May 2008 18:59:46 S Roderick wrote:
> Is there a way to do something like the following, with the existing State
> Machine implementation?
>
> {{{
> StateMachine MyStateMachineDefinition
> {
> transitions {
> // and have transitions here that apply to all states of this
> machine? }
Do you have any idea how to formulate in UML state charts ?
> ...
> state A {
> ...
> }
> }
> }}}
No there isn't. But there is a work around. You can define a parent state
machine of the one above which has the transitions statement and changes the
child (using requestState or so).
{{{
StateMachine MyParent
{
SubMachine MyStateMachineDefinition mySMD;
initial state X {
transitions {
if ( c ) then {
do mySMD.requestState("A");
}
}
}
}
}}}
But this is far from optimal. The 'current' state in mySMD must define a
transition to "A" for requestState to succeed. So in practice, you could only
call 'mySMD.requestFinalState()' from MyParent, because a transition to the
final state is always allowed.
Peter
Possible to do transitions per state machine, and not per state?
On May 4, 2008, at 15:54 , Peter Soetens wrote:
> On Thursday 01 May 2008 18:59:46 S Roderick wrote:
>> Is there a way to do something like the following, with the
>> existing State
>> Machine implementation?
>>
>> {{{
>> StateMachine MyStateMachineDefinition
>> {
>> transitions {
>> // and have transitions here that apply to all states of this
>> machine? }
>
> Do you have any idea how to formulate in UML state charts ?
Yes. A transition from a parent composite state down into a child
state. This then applies to all other children of that parent state.
The particular example I'm looking at has several different arm
controllers, each as its own state. Rather than doing the ~ N^2
transitions between each, you simply model N transitions as one
transition from the parent state into the controller state. Nice to
model, harder to implement. See attached.
Oh well ... thought I would ask.
Thanks
S
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Possible to do transitions per state machine, and not per state?
On Monday 05 May 2008 14:16:44 S Roderick wrote:
> On May 4, 2008, at 15:54 , Peter Soetens wrote:
> > On Thursday 01 May 2008 18:59:46 S Roderick wrote:
> >> Is there a way to do something like the following, with the
> >> existing State
> >> Machine implementation?
> >>
> >> {{{
> >> StateMachine MyStateMachineDefinition
> >> {
> >> transitions {
> >> // and have transitions here that apply to all states of this
> >> machine? }
> >
> > Do you have any idea how to formulate in UML state charts ?
>
> Yes. A transition from a parent composite state down into a child
> state. This then applies to all other children of that parent state.
>
> The particular example I'm looking at has several different arm
> controllers, each as its own state. Rather than doing the ~ N^2
> transitions between each, you simply model N transitions as one
> transition from the parent state into the controller state. Nice to
> model, harder to implement. See attached.
Ok. Thanks for clarifying. I don't see it as a big hurdle to implement this.
The parser can already read transition {} statements, the StateMachine class
can already evaluate them. We only need to make them 'global' in the
statemachine instead of being tied to a state. It should be <100 lines of
code adding/changing to get this functionality in the parser.
In the same effort, event transitions could be done statemachine-wide as well.
Peter
Possible to do transitions per state machine, and not per state?
On May 5, 2008, at 11:34 , Peter Soetens wrote:
> On Monday 05 May 2008 14:16:44 S Roderick wrote:
>> On May 4, 2008, at 15:54 , Peter Soetens wrote:
>>> On Thursday 01 May 2008 18:59:46 S Roderick wrote:
>>>> Is there a way to do something like the following, with the
>>>> existing State
>>>> Machine implementation?
>>>>
>>>> {{{
>>>> StateMachine MyStateMachineDefinition
>>>> {
>>>> transitions {
>>>> // and have transitions here that apply to all states of this
>>>> machine? }
>>>
>>> Do you have any idea how to formulate in UML state charts ?
>>
>> Yes. A transition from a parent composite state down into a child
>> state. This then applies to all other children of that parent state.
>>
>> The particular example I'm looking at has several different arm
>> controllers, each as its own state. Rather than doing the ~ N^2
>> transitions between each, you simply model N transitions as one
>> transition from the parent state into the controller state. Nice to
>> model, harder to implement. See attached.
>
> Ok. Thanks for clarifying. I don't see it as a big hurdle to
> implement this.
> The parser can already read transition {} statements, the
> StateMachine class
> can already evaluate them. We only need to make them 'global' in the
> statemachine instead of being tied to a state. It should be <100
> lines of
> code adding/changing to get this functionality in the parser.
>
> In the same effort, event transitions could be done statemachine-
> wide as well.
Currently, we're almost universally only using event transitions -
either cascading state machines, or user "events" entering that way.
If this is a big deal, don't worry. It's only saving us typing the
same thing a few times over. But if you can do it ... :-)
S
Possible to do transitions per state machine, and not per state?
On Monday 05 May 2008 23:51:12 S Roderick wrote:
>
> Currently, we're almost universally only using event transitions -
> either cascading state machines, or user "events" entering that way.
>
> If this is a big deal, don't worry. It's only saving us typing the
> same thing a few times over. But if you can do it ... :-)
Oh well.... here you go.
$ diffstat < state-machine-transitions.patch
src/StateMachine.cpp | 97 +++++++++++++++++++++++++++++++----
src/scripting/ParsedStateMachine.cpp | 3 -
src/scripting/StateGraphParser.cpp | 48 ++++++++++-------
tests/state_test.cpp | 82 ++++++++++++++++++++++++++---
tests/state_test.hpp | 3 +
5 files changed, 193 insertions(+), 40 deletions(-)
Both 'global' condition and event transitions have been tested in state_test.cpp.
Your turn to test it in the field I guess.
Peter
Possible to do transitions per state machine, and not per state?
Works for me :-)
Thanks!