USB works similar to the Master and Slave architecture. There is an Host which is manage the bus as like a Master. There can be various "devices" which is managed by host like slaves. I wonder that whether USB can be used in real-time motion control or not. For a real-time job, you need an deterministic interface. USB working principle is similar to the Master & Slave architecture. So this means that USB completely deterministic solution, right? At most how much cycle time can be reached by USB ? What is the drawback of USB for real-time motion control?
Say a system consist of one Host and 16-devices. Devices can be servo-drives and a few sensors (encoders, gyros etc.). For instance, I want to send motion commands to these servo-drives and receive back sensors feedback through the same USB interface. I probably would like to see sub miliseconds cycle-time such as 500 uS (2kHz), 250 uS (4kHz). USB interface can handle the these requirements? I concern about the delay of USB. Is it deterministic or non-deterministic?
Best Answer
The concept of "real time" is a stretchable thing. If your controlled object is, say, a metallurgical oven, then, depending on the size of it the real control time may be from seconds to minutes or even hours. So you need to define more clearly what kind of sampling rate is sufficient to make a robust and stable control for your object. To determine which time-cycle do you need, you need careful analysis of dynamics and stability of your control loop.
Now, the question is good, but it needs to be re-formulated. It should be something like, what is the overall latency of USB system, the time from issuing an API call from some software control algorithm, to actual change in some GPIO pins on the side of USB-connected device. The chain of events is long, it goes through API, several layers of drivers, filling various TRBs structures in main memory, then the hardware gets involved, ringing the bell register initiating DMA access by xHCI controller and streaming data across several elasticity buffers into actual USB PHY, then waiting for protocol response. And then something similar happens inside the USB device itself before actually toggling some GPIO pin. I don't know the answer to this question. But it is quite clear that the desirable sub-ms loop latency is impossible.