> Hi Johannes,
>
> Wouldn't it be better if you replied/forwarded to the mailing list
> (reply to all) ?
>
> Thanks,
> Peter

Okay!

On Tue, Nov 10, 2009 at 18:21, Johannes Meyer <Meyer [..] ...> wrote:
> Hello Peter,
>
>> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=731
>>
>>
>> Peter Soetens <peter [..] ...> changed:
>>
>>            What    |Removed                     |Added
>> -----------------------------------------------------------------------
>> -----
>>          Resolution|                            |FIXED
>>              Status|NEW                         |RESOLVED
>>
>>
>>
>>
>> --- Comment #2 from Peter Soetens <peter [..] ...>  2009-11-
>> 10 17:02:38 ---
>> (In reply to comment #0)
>> > The RTT::ExecutionEngine::startContexts() method is responsible to
>> call the
>> > owner's and all childrens' startHook() methods in the correct order
>> and to
>> > rewind all TaskCores correctly, if one of them fails. However, there
>> is no
>> > update of the mTaskState field for the children. As a consequence the
>> childrens'
>> > updateHook() method will never be called. The same holds for
>> activating children
>> > in case of startContexts() has been called during activation of the
>> > ExecutionEngine.
>>
>> You are correct. The implementation is wrong and should have updated
>> the state.
>
> Ok, thanks for the provided patch. However, I think it does not work correctly for the case the child TaskCore is still in PreOperational state (the first case in the if expression) when startContexts() is called. Sorry I cannot provide a patch directly at the moment, I have to look into that diff/patch thing one day.
>
>>
>> >
>> > Perhaps I misinterpreted the whole thing. There is almost no
>> documentation
>> > dealing with TaskCores being children of another ExecutionEngine.
>> However, if I
>> > change the mTaskState flag to Running in the user-implemented
>> startHook()
>> > method, everything works as expected.
>>
>> The reason its not so much documented is that it was only meant for
>> power
>> 'embedded' users that wanted to save as many bytes as possible, and we
>> wanted
>> to hide it from the ordinary people :-) Normal users would use
>> SlaveActivity
>> instead to serialize the execution of multiple TaskContexts.
>>
>> This sharing of EE's has only one reason: saving memory (and a bit on
>> execution
>> time). You only need one activity, one EE and any number of
>> taskcontexts.
>>
>> I was wondering in RTT 2.0 if we would still allow this. The
>> alternative is to
>> make the EE very small and memory efficient. But even then, we will
>> need at
>> least two lists: one for executing single shot stuff (actions,
>> commands,
>> events,...) and one for executing programs (scripting, state machines
>> etc).
>> This may already be too much in certain setups.
>>
>> What was your reason to share EE's ?
>
> I have created a kind of SlaveTaskContext class, whose instances are aware of their parent TC and add theirself as a child of their parent's ExecutionEngine in the contructor. I don't know if there is a better way to implement this, but it was the most obvious way as far as I understood RTT. The children can be member variables of their parent.
>
> The situation is as follows: In our group we have designed a controller board for an autonomous aerial vehicle which interfaces all the hardware and which is connected to a small SBC running Linux/Xenomai via Ethernet. Therefore, we implemented an Interface TC, which is responsible for the general handling of the socket communication (using RTnet). It has several children, which are implementing interfaces for the different sensors and actors connected to the board. These can be quite non-trivial, for example for the GPS device connected to the serial port of the controller. The SlaveTaskContexts provide their own OperationInterface, but use the ExecutionEngine and data ports of their parent, so that the exact source of the data is hidden for other components that just want to access the sensory data. In this way we are able to replace the interface component by other implementations, e.g. for replaying data from logfiles or for different configurations of the hardware (there exists a common abstract base class). Furthermore, the children's properties are accessible additionally as a Property<PropertyBag> of the parent, holding a reference to the child's PropertyBag, so that reading and writing the properties of the parent also works recursively for all of its children.
>
> Of course, the "slave" TC could also have their own ExecutionEngine run by a SlaveActivity without forego the awareness of its parent. I cannot remember at the moment what exactly has driven us not to choose that possibility. As you already mentioned, the only drawback would be the increased memory consumption (which we have a lot of). But as the parent-children-relationship was already implemented for the ExecutionEngine in RTT, I considered it to be easier to re-use that one instead of the parent having to deal with the correct starting, execution and stopping of his children, and there is no need for different activity patterns at the moment.
>
> Thanks a lot for providing this great piece of software, which simplified our work enormously. I really enjoy working with Orocos since three or four months now.
>
> Johannes
>
>
> --
> Dipl.-Inform. Johannes Meyer
> Technische Universität Darmstadt
> Department of Mechanical Engineering
> Institute of Flight Systems and Automatic Control
> Petersenstrasse 30
> 64287 Darmstadt, Germany
>
> Phone:  +49 6151 / 16-6738
> Fax:    +49 6151 / 16-5434
> E-Mail: meyer [..] ...
> URL:    http://www.fsr.tu-darmstadt.de
>
>
>
>