Does linuxcnc support USB

Hi,

I am new to EMC. From the documentation, I found out that EMC works with Parallel port. Does it also support USB?


Best Regards,

USB is not supported at this time.
there is a lot of information as to why located around the Wiki and the Forum .

I'm wondering if there is a solution to make usb card compatible with linuxcnc

thanks

andypugh wrote:

No, because the USB protocol allows for many milliseconds of delay between data being transmitted and it being received.

I hear this every time the subject comes up.
But as far as I know I can do an interrupt transfer 8000 times a second, 64 bytes long on highspeed USB 2.0. And since USB is polling-driven, there is no reason why there would be extra delays or missed transfers when the EHCI controller is under RTkernel control.

Then there are only two issues left with USB:
- Most implementations on mainboards are not too reliable in the hostile environment called 'CNC machine' where VFD's, steppers and servo drives put out a lot of noise.
- As far as I know there is no realtime EHCI controller driver.

Especially #1 is enough for me to not want it. But is it technically impossible? I don't think so.

The problem with USB is it is designed for transmission RATE, not latency. USB controller chips
have their own clock, and all transmissions are scheduled by that clock. The old USB had
1000 frames/second, USB 2.0 has 8 microframes within each old frame. These are
scheduled by the driver according to available bandwidth and who has already scheduled
what percentage of the available. So, the clock in the CNC program has no control
over WHEN a packet will be sent. If nobody has reserved a microframe, you can have
the next one, but if it is reserved, you have to wait. if somebody plugs in a mouse
or memory stick, everything dies for up to a couple seconds until the new device
is enumerated and new scheduling slots are figured out.

Anyway, due to the built-in USB clock, there is a totally unavoidable jitter of at
least 125 us in the transmission of a packet. Now, if you used something like
the Cypress Ez-USB chip which has built-in FIFOs, and had a driver that
was shipping packets of step/dir signals out to it at a conservative rate, it
would almost certainly work, if you were careful to never touch the USB
ports while the machine was running. One problem is there is no RT
USB driver, so you'd have to toss buffers of step/dir info over from
the RT to the user side of LinuxCNC, and there could be gaps where
the user side is too busy to keep the packets flowing. This would all
be for open-loop operation only, but a lot of people are working in
that mode, anyway.

Jon

Hi,

I've never used this device, but it is shown as being able to run a modified "emc2" with USB:

www.ecklersoft.com/ers.html

Jeff

jmelson wrote:

So, the clock in the CNC program has no control
over WHEN a packet will be sent. If nobody has reserved a microframe, you can have
the next one, but if it is reserved, you have to wait. if somebody plugs in a mouse
or memory stick, everything dies for up to a couple seconds until the new device
is enumerated and new scheduling slots are figured out.

True for usermode USB, not so much for a RT module if it existed. Or at least no more than for example Ethernet, and that is being used sucessfully.

Anyway, due to the built-in USB clock, there is a totally unavoidable jitter of at
least 125 us in the transmission of a packet.

An RT driver which controls the EHCI controller also controls arbitration and to some extent timing. I am not too deep in the exact implementation of EHCI so it might be possible that the driver doesn't know exactly where in each 125usec window the transmission takes place. But it will be the approximately the same each servo period. and shift only slowly due to clock differences between the timer that generates the servo thread ticks and the USB clock which comes from a separate clock generator.

At most timing differs +/- 62,5usec, which doesn't introduce a very large extra phase jitter in the average servo control loop.
I also doubt Ethernet is much better in that area.

One problem is there is no RT
USB driver, so you'd have to toss buffers of step/dir info over from
the RT to the user side of LinuxCNC, and there could be gaps where
the user side is too busy to keep the packets flowing.

No RT EHCI driver is a problem of course . Passing packets through userspace zeroes out all the benefits of using a realtime kernel for machine control.
But 'USB is totally unuseable for FIFO-less realtime control the LinuxCNC way': I still don't think that is true.

xylotex wrote:

Hi,

I've never used this device, but it is shown as being able to run a modified "emc2" with USB:

That one uses a buffered approach and merely uses the NGC interpreter and the GUI from LinuxCNC.

andypugh wrote:

I don't know if it is possible to grab the USB ports for realtime control. When using Parallel port or PCI the transfer is done as direct memory reads/writes as they are memory-mapped (inb and outb instructions) and the pins update immediately. I believe that when you pass data to a USB port you are passing it to a second level of driver, rather than talking directly to the hardware.

The USB OHCI/EHCI controllers also have their registers mapped into a PCI base address, and it is possible to read/write to these registers from a RT module. From a helicopter view it is not that different from grabbing an Ethernet adapter for realtime control, and that is already done.

A RT driver would have to implement it's own USB stack for RT control purposes though.
(once again: just like RT Ethernet)

I confess I am no expert, I have been told enough times that it can't be made to work that I have accepted that. it would be great to find that it wasn't true.

I am no real expert either. I just have not read a convincing reason why USB would be unsuitable. A RT driver with it's own basic stack should be able to reliably put out packets at an 8kHz rate (USB 2.0).

From a theoretical point of view at least; there is no RT driver and electrically USB is not that robust either, especially not in an environment with high levels of EMI such as a CNC machine.