Why not USB? (again)

I've just read, that USB's Interrupt transfer mode can guarantee latency of 125uS. So why can't it be used for CNC control?

If that is true then it is within our timing limits.
Do enough USB devices support transfer mode?
The biggest obstacle is just finding someone who will build a working system.

reference:
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2HardwareDesign

Yes, you can set uFrame times of USB 2.0 to 125 uSec but I dont think that you can actually guarantee 125 uSec latency especially if the USB system is not totally dedicated to motion control.
(it would be almost impossible to share the USB system with non real time tasks)

BigJohnT wrote:

Do you have a link to this info?

John

www.embeddedsys.com/subpages/resources/i...InterruptsAndUSB.pdf

BigJohnT wrote:

It seems to say that maximum latency is 125 usec to 4 seconds on high speed and says the smallest possible interrupt is 125 usec... I don't see anything that says it guarantees a steady 125 usec latency.

John

That lack of guarantee is and always has been the problem.

Doug

BigJohnT wrote:

It seems to say that maximum latency is 125 usec to 4 seconds on high speed and says the smallest possible interrupt is 125 usec... I don't see anything that says it guarantees a steady 125 usec latency.
John

I was thinking about soft-realtime. Anyway there's hard realtime implementation of USB 1.1 stack for RTAI www.xenomai.org/index.php/Weblinks#USB_for_Real-Time .
I think I will go for RTnet. These USB issues are causing me a headache.

PCW wrote:

Yes, you can set uFrame times of USB 2.0 to 125 uSec but I dont think that you can actually guarantee 125 uSec latency especially if the USB system is not totally dedicated to motion control.
(it would be almost impossible to share the USB system with non real time tasks)

Little deeper analysis, when working on closed loop more amount of latency is important but when working on open loop mode no one cares on latency. Practical example, when you are listening music you can't care less when your computer sends bits out to audio card, there could be one second buffer latency and you don't notice it at all. If you are in closed loop mode like playing software synthesizer, 100ms latency is too much because there is closed loop from your ears to your fingers to play tune.

When we think stepper interface, it is open loop, we send out step and direction pulses to steppers. Pulses are calculated every 50us but so long than all pulses are sent to machine, but machine does not care how long time earlier pulses are calculated. So, you could record pulse stream with digital recorder and machine works.

Only special case is when you home your machine to home micro switches, it is closed loop and you cant send out next pulse before previous one is sent to stepper and you have checked the state of switch, this is closed loop special case.

So, we could make so that we have stepgen calculating pulses for one millisecond per time and then send this frame out via USB and controller at other end of USB controller just plays pulse stream out. Other more generic solution would be moving stepgen or servo HAL module to USB microcontroller. In this case we just need to send position commands calculated every millisecond vie USB and then closed loop part in servo case lives on microcontroller.

we dont need any special expensive hardware but just ordinary and cheap Arduino boards could be used. They have new boards coming that has native USB device controllers, ARM based Due and AVR based Leonardo. These boards are not yet out but ARM based fork Mapple has been out a while and Mapple has also USB.

As USB modes, there is isochronous mode that has guaranteed bandwidth and bounded latency. Isochronous mode is used normally with audio devices. There is two options, either use isochronous mode or then have few frames (milliseconds) frame buffer in USB device.

There are several parts of EMC that need real time response:

Servo loop
rigid tapping
threading
probing
limit switches
homing

And of course you would not want to limit the
ability to add additional real time components

The problem with USB is that it is nowhere near real time (This problem is made worse by the fact that the USB hardware on the host is shared so if you want any of your normal USB peripherals to work you have a very interesting driver to create. There's a reason most real time USB implementations have been stalled in alpha for 5 or more years)

Because of these limitations, to make a reliable USB motion controller you end up creating a buffered
system. For a small range of problems this is fine, but as soon as you want one of EMCs more sophisticated functions, you are in trouble. For example if you wanted to do threading, you would most likely have to implement EMCs threading code on the remote buffered motion controller. Eventually you end up re-implementing EMC on the remote device. This is going to require fast floating point and a real time environment.

At this point you might as well stay with EMCs simple, powerful, flexible, single locus of control model
rather than a complicated inflexible buffered system