On 16.09.2014 13:49, Sylvain Joyeux wrote:
> When using pull connections, such a problem should not happen. The
> only bit missing was to not send notifications (needed for
> port-triggered tasks) when they are not needed, but I've seen a pull
> request a while ago fixing that
>
> Just had a quick look. A leftover is the call to #state and #states in
> http://goo.gl/6Mt0H3 and http://goo.gl/fBXb8n. These are actually a
> port read, so here's one non-pull connection. Given that I know that
> your code is usually spamming with state changes, that is definitely
> one possible culprit.
Unfortunately, the real problem is coming from:
https://github.com/rock-core/tools-orocosrb/blob/master/lib/orocos/async...

Here, the worker thread is triggering "states" every second. A
workaround would be to remove this peace from the watch_dog and use
Sylvain suggestion.

Greets
Alex

>
> You can try the following: get rid of #process_states and define
> #on_state_change with
> https://gist.github.com/doudou/0ff1b3ac8f2d397c0307. This is
> completely untested. You will probably have to define an attr_reader
> :state_symbols on Orocos::TaskContext. The documentation says that you
> can listen to states by doing obj.state { |s| ... } but I can't see
> where this comes from.
>
> Sylvain
>
> PS: The proper fix (that I wanted to implement for a long, long time)
> would be to have multiple corba dispatchers. It would allow to isolate
> priorities (high RT priority for in-robot com, low non-RT priority for
> GUI) and completely isolate different domains in general.
>
> On Tue, Sep 16, 2014 at 5:15 AM, Matthias Goldhoorn
> <matthias [dot] goldhoorn [..] ...> wrote:
>> I thougt this was fixed by adding the :pull flag to the connection.
>> That the data are activly requested instead pushed from the system.
>> I know what you suggest solves, but if the network connection is
>> unstable or overloaded i got the same problems again...
>>
>> ;-(
>>
>> Matthias
>>
>>
>>
>> On 16.09.2014 09:39, Janosch Machowinski wrote:
>>> Hey,
>>> if I recall it correct, there is one receiver and one
>>> sender thread per task, that pulls/pushes the data from/to
>>> the connections. (I included orocos-dev to confirm this)
>>>
>>> In your usecase the cable to the UAV is disconnected,
>>> while the task-inspector is connected to the tasks on
>>> your system.
>>> This means, that all connections to the task-inspector
>>> time out, making the sender thread block. Thus you also
>>> get no data any more on the 'internal' connections.
>>>
>>> For your case, it should help to disconnect all task
>>> inspectors, before unplugging the Ethernet cable.
>>> Greetings
>>> Janosch
>>>
>>> Am 14.09.2014 um 16:23 schrieb Matthias Goldhoorn:
>>>> Hi Dev's
>>>> It still seems that the Task Inspector influences the task execution.
>>>> I thoug this was fixed by the async api? (and pull?)
>>>>
>>>> This is a critical bug for us currently...
>>>>
>>>> Best,
>>>> Matthias
>>
>> --
>> --
>> Matthias Goldhoorn
>> Unterwasserrobotik
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 218-64100
>> Fax: +49 (0)421 218-64150
>> E-Mail: robotik [..] ...
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -----------------------------------------------------------------------
>> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>> (Vorsitzender) Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>> Amtsgericht Kaiserslautern, HRB 2313
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> USt-Id.Nr.: DE 148646973
>> Steuernummer: 19/673/0060/3
>> -----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev [..] ...
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
> _______________________________________________
> Rock-dev mailing list
> Rock-dev [..] ...
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

I thougt this was fixed by adding the :pull flag to the connection.
That the data are activly requested instead pushed from the system.
I know what you suggest solves, but if the network connection is
unstable or overloaded i got the same problems again...

;-(

Matthias

On 16.09.2014 09:39, Janosch Machowinski wrote:
> Hey,
> if I recall it correct, there is one receiver and one
> sender thread per task, that pulls/pushes the data from/to
> the connections. (I included orocos-dev to confirm this)
>
> In your usecase the cable to the UAV is disconnected,
> while the task-inspector is connected to the tasks on
> your system.
> This means, that all connections to the task-inspector
> time out, making the sender thread block. Thus you also
> get no data any more on the 'internal' connections.
>
> For your case, it should help to disconnect all task
> inspectors, before unplugging the Ethernet cable.
> Greetings
> Janosch
>
> Am 14.09.2014 um 16:23 schrieb Matthias Goldhoorn:
>> Hi Dev's
>> It still seems that the Task Inspector influences the task execution.
>> I thoug this was fixed by the async api? (and pull?)
>>
>> This is a critical bug for us currently...
>>
>> Best,
>> Matthias
>