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. 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 <[email protected]> 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: [email protected] > > 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 > [email protected] > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
