re:Re: usbdux for control

Bernd,

the 5 ms is when I read with a comedi command and write with comedi_data_write.
If I use commands to both read and write (and I copy input to output in
the software), I achieve 1 ms resolution on the output, but it lags behind
over 20 ms. If the usb host controller is to blame, it apparently introduces a 
different delay depending on which comedi output method is used. Seems very strange to me.
I'm under the impression that something somewhere is buffering for some time
before ouput actually begins, and that this doesn't happen with 
comedi_data_write.
The actual delay is not always the same by the way. For different runs of the
program, it varies from just over twenty to over thirty milliseconds. I don't
think this is a thread issue, since my version with comedi_data_write uses
exactly the same threads and thread-synchronisation.

Michael

>Michael,
>
>the delay might come from the USB host controller. When the driver sends 
>out the data to the dux board it's up to the host controller to send it. 
>The driver has no control over that. However, 5ms seems to be too long. 
>The packet should go out within one USB frame, thus, 1ms. The board 
>processes the data frame by frame so the delay should be only one ms. If 
>you need lower latency USB 2.0 might be an option. USB 2.0 works with 
>125us microframes.
>
>/Bernd
>
>Michael Van Damme wrote:
>> 
>> Hi Tao,
>> 
>> thanks for looking into it. I've changed my code as you suggested, and 
>> now I also achieve times of around 5 ms. That's stil a long way from 1 
>> ms though.
>> 
>> I was indeed using two commands simultaneously. I don't think the board 
>> gets reconfigured every time, because I do get 1 ms performance on both 
>> input and output simultaneously. The only problem is that the output 
>> lags by over 20 ms. If the board was reconfigured every time there was a 
>> switch between read and write then probably neither input nor output 
>> would behave smoothly (they do now, the output almost exactly matches 
>> the input, except for the delay).
>> With the 5 ms approach, the output is only a rough approximation of what 
>> I send in.
>> 
>> Thanks,
>> Michael
>> 
>> 
>> 
>> Tao Geng wrote:
>> 
>>> Hi Michael,
>>>
>>> I have just looked at your code, it seems that it runs two 
>>> Comedi_command for read and write alternately. I guess, the problem 
>>> may be that, every time Command is started, it configures the board, 
>>> this cost many time. I am doing a work similar to yours with this 
>>> board, that is, controlling a biped robot walking. I use only one 
>>> Comedi_command to read sensor signals, and use comedi_data_write to 
>>> output to the board. The servo update rate is about 5ms, which means 
>>> that, in 5ms, 7 A/D channels are read, and 4 D/A channels are written. 
>>> I know, this may be not the fastest way to do input and output with 
>>> this board at the same time, but it is fast enough for my robot. If 
>>> you are interested, I can send my code to you. And, you can look at 
>>> the robot walking movies at my page, www.cn.stir.ac.uk/~tgeng/robot 
>>> Hope to be of help.
>>>
>>> Regards.
>>>
>>> Tao
>>>
>>>
>> 
>
>

Received on 2004-10-15Z01:58:55