Why not USB? (again)
- grawp
-
Topic Author
- Visitor
-
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
John
Please Log in or Create an account to join the conversation.
(it would be almost impossible to share the USB system with non real time tasks)
Please Log in or Create an account to join the conversation.
- grawp
-
Topic Author
- Visitor
-
Do you have a link to this info?
John
www.embeddedsys.com/subpages/resources/i...InterruptsAndUSB.pdf
Please Log in or Create an account to join the conversation.
Depending on many factors the host processor may not be able to transfer the interrupt data at
the requested interval. OS design, driver design, application software, CPU speed, and bus
bandwidth may all limit the host’s ability to meet the obligation to poll for interrupt transfer data
within the required interval.
John
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
- grawp
-
Topic Author
- Visitor
-
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 .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 think I will go for RTnet. These USB issues are causing me a headache.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.