Hello Till,
I would love to have a USB interface to EMC as well. I only have a laptop
and it only has USB ports.
I've spent some time learning about USB/EMC/RTAI and have thought of 3
possible ways of making EMC work with a USB device. I'm still relatively
new to this (especially EMC & RTAI) so if anyone thinks I'm way off base
please tell me so :)
1) run the non-realtime EMC version and send the task controller commands to
the USB device. Have all realtime calculations done on the device
(trajectory planner).
2) write a HAL driver that uses an RTAI FIFO to communicate to a user space
application that in turn writes to the USB device.
3) modify the existing Linux USB host/core drivers to allow realtime
communications.
my thoughts on each of these are:
1) the advantage is you could get away without having to patch the kernel.
To me the disadvantages are that all the realtime stuff would have to be
done in firmware on your device. I think that would actually be a lot of
work, and we would not be able to take advantage of all the work the EMC
folks did on the motion controller/trajectory planner. I think it would be
much harder to debug (without the benifit of the HAL meter / HAL scope), and
finally if the task controller changes, we would have to change our driver.
2) the advantage is the existing Linux USB host/core driver could be used.
The disadvantage is you need to patch your kernel, and write 3 seperate
pieces of software. The EMC HAL driver, the user space part, and the Linux
USB device driver.
This solution would not be completly realtime from the perspective of EMC,
but with proper buffering it would be from the perspective of the device.
3) the advantage is this is a complete realtime solution, and once the
modified USB host/core driver is written, all you would need to write is a
EMC HAL driver. The disadvantages are that you need to patch your kernel
(same as #2), and the Linux USB host/core drivers are pretty complex (for me
at least :) ).
I have mostly been looking at #3, but perhaps #2 would work as well. I have
a little bit of information on how you would do #3. Basically you replace
all standard Linux spinlocks and interrupts with RTAI variants. There is a
library (RTDM) in the RTAI distribution that is supposed to help a
lot......I'm still reading.
Are you really super against compiling a realtime kernel? It took me a few
days to get mine working, but it was worth it and I learned a lot. You
could compile a new kernel, and use GRUB or LILO to dual boot so that you
have your normal Linux and realtime as well.
If you would like some help with a realtime kernel, I could give you a few
tips.....especially if you would like to collaborate on a USB driver :)
Take care,
Garrett.
Hi,
please excuse me for just starting a topic while being new on the list.
I have recently got some use for a cnc milling machine to make some toys
for my new-born daughter (always a good reason :-)
I have thus taken a look at existing solutions and obviously found the emc
project which perfectly fits that fact that i run linux on all my
machines.
But there's something that's "uncomformatable": emc requires a real time
kernel and doesn't just run on my standard desktops. I do understand that
this is due to the fact that generating proper motor timing requires the
response times only a real time kernel can give, But for me a different
solution exists: As you can see from some of my projects
(http://www.harbaum.org/till/lcd2usb
http://www.harbaum.org/till/i2c_tiny_usb
http://www.harbaum.org/till/xu1541) you can see that i am quite successful
in
converting existing printer port solutions into usb ones. The projects
above
all have formerly used the printer ports just like most of the home cnc
machines seem to do.
What i'd now like to do is: Build a simple yet powerful USB to something
converter that removes the need to use the printer port and more important
avoid the need for a real time kernel. What i have in mind is a very
simple
device:
Let's for simplicity reasons assume that we can run the machines in
question
at a constant signal rate. This means that the clock signals like e.g.
required for the sc800 are updated at a maximum fixed rate. Lets assume
this
max rate is e.g. 50khz and we want to drive four motors with a direction
and
clock signal each resulting in 8 bits to be sent at once. We thus have to
generate and forward 50kbytes per second. This is roughly 500kbit/s incl.
control bits which are to be fed into the controller pcb at a constant
rate. I
can easily build a simple use device that inputs data via high speed usb
(480
MBit/s), buffers it and forwards it byte per byte into the controller. If
the
interface has e.g. 8 kbytes buffer the PC has thus only to make sure it
refills the interfaces buffer at least every 125ms. More buffer means even
lower timing requirements. From the PCs point of view it would just try to
write the data via usb as fast as possible. Once the device internal
buffers
are full the transfers are automaticall throttled and e.g. usb_write
commands
will block.
As i said: I can build something like this, but i am not sure if emc can
be
converted to support this without requiring a real time kernel. Is this
possible and are you interested?
I would of course still need "example hardware" myself. I am thinking
about
e.g. a modified proxxon mf70 with the sc800 controller board.
What do you think?
Till
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
