For more infomation about this bug, visit

Peter Soetens
<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-16 23:37:23 ---
(In reply to comment #0)
> If you call a command from within the entry program of the initial state of a
> state machine, _and_ that state machine is started and activated by the
> startHook() of a component, the command silently does not occur. I would guess

silently: what does 'list mystatemachinename' give you on the taskbrowser
prompt (use tab completion) ?

> this because the command processor hasn't yet been started, or something
> similar?

The the receiving taskcontext should be running, otherwise, your state machine
will go into error status. In case you send a command to yourself from the
entry hook of the initial state, while the state machine is activated in
startHook(), the command will likely fail (because the processors are not yet
started). Although even I am unsure about this without digging in the code.

>
> So when I deploy a component that needs to run a state machine, how can I start
> the state machine so that this works? Due to bug 552 a deployed state machine
> can't be auto-started, but now the component that the state machine is loaded
> into can't start it either. Is there an alternative?

Make your initial state empty and use a default 'select' to the state doing the
real work. Then you can use activate() and start() from the startHook().

>
> This does work with a command if there is code to load the state machine, start
> the component, and then start/activate the state machine. This doesn't occur in
> a deployed situation (unless I write extra code ...).
>
> This does work if you use a method instead of a command and start the state
> machine in startHook(), but that may not work for all situations for obvious
> reasons.
>
> Thoughts?

You're reaching the edges of sane behaviour of the RTT scripting language :-)
Commands were really a pain when writing the state machine processing, as they
may make any transition of program execution 'halt' for some time. This means
any request to the state machine may be non atomic and take time to complete.
Hence, it is possible that it's not yet allowed to call start() directly after
an activate(). Really annoying. Such a concept is completely left out from UML.
OR you call something synchronous, and it is assumed that this completes
immediately OR you send someting in case you don't wait for nor get the result
(afaik). For activate() to be atomic, you can leave the entry {} program of
your initial state empty....

There are many discussions about these short commings. We tag them all with
'RTT 2.0'. There is some intention to generate code from UML state machines
using an open source tool (like PapyrusUML), but this is still unsure and not
finished this year. The Orocos 'StateMachine' class will need to change for
being UML compliant, and maybe also the way we use commands... as they are the
main culprit for lots of code complexity.

Peter