I have fixed that up in player trunk. If possibly can you try out the fix and confirm it works for you?

Toby

2009/12/9 Giri_Nathan <Giri.Pushpanathan@mdacorporation.com>


I found a potential bug with the RFLEX driver. I did a code comparison
between version 1.6.5 and 2.1 and this bug was introduced in 2.1. Notice how
the start time is initialized.

In the rflex_commands.cc, there is function cmdSend:

       timeval now;
       timeval start = {0,0}; // in the old code gettimeofday(&start,NULL);
       do
       {
               count = clear_incoming_data(fd);
               gettimeofday(&now,NULL);
               if (count > 0 )
                       start = now;
               count = (now.tv_sec - start.tv_sec) * 1000000 + (now.tv_usec -
start.tv_usec);

              // release somewhat so other threads can run.
              usleep(500);
       } while (count < 10000);


I am not sure why the start time is set to 0 as opposed to initializing it
using gettime.
If 0 is used, when the (now.tv_sec - start.tv_sec) * 1000000 computed there
will be an overflow!!!
This will result in a longer time to exit the loop. When I start issuing
move commands, the cmdSend function is called more often resulting in
slowdown in the update rates.


--
View this message in context: http://old.nabble.com/Rflex-Driver-Slows-down-when-commanded-to-Move-tp26598461p26717980.html
Sent from the playerstage-users mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Playerstage-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users