USB CNC (was Interface. Gauging interest.)

Hi Wayne,

First of all, nice design and impressive that you have published everything.
Very clever.

There's an even easier way than the method you describe. First some
history.

I've had to duplicate a 16 bit 1KHz A/D conversion of oilfield data in order
to test hardware and software upgrades. I take the logged data file which
has the 1mS samples and bundle them up into blocks. These blocks are sent
down to the USB device (FTDI 2232) and queued in a ping pong buffer by a
PIC. One is always being filled while the other is being used.

The PIC micro-controller drives a 16 bit D/A converter and isolated 4-20mA
driver to simulate the 10,000 PSI pressure transducer. This signal is fed
back into our test hardware. It's the PIC that has a 1mS interrupt that is
taking the 16 bit information and changing the D/A value. Looks just like I
have a drilling rig in my back yard with a 10,000 PSI transducer.

Since my E-Leadscrew ELS runs 25kHz (40uS per interrupt) to not only
calculate acceleration and velocity plus distance and limit switches/ESTOP
(and for that matter micro-step SPI to the LMD18245s) there's no reason that
you couldn't send a USB packet every 10mS with 250 bytes of data. Lots of
time on the PIC to do this.

Each byte would reflect what the output port of the PIC should be and each
byte is output on that 40uS interrupt. If the byte reflects the step/dir
line of each axis and then at the end of the 40uS interrupt the step lines
are cleared again then up to 25kHz stepping is possible.

1. Receive 250 bytes every 10mS.
2. every 40uS send out one of those bytes,
3. test inputs like ESTOP and limits.
4. if ESTOP/LIMIT switch set then flag that a status message back up the USB
should be sent along with the byte # of which 250 byte packet.
5. increment byte pointers, packet pointers, change ping pong buffers etc.
6. clear all step lines on the output port.
7. return from interrupt.

The mainline code just needs to accumulate 250+ byte packets into the
ping-pong buffers and return status information every 10mS or so. (probably
more like 9.5ms with handshaking.

That's easy for the USB and the PC. The PC does all the calculations as to
which step line should be set every 40uS. For very slow moves most of the
bytes won't have a step line asserted. Point is, the USB+PIC just ends up
being a synchronous serial to parallel converter with minimal smarts just
like my USB-D/A converter. It excels at responding quickly and precisely to
a 40 uS interrupt. The FTDI USB device queues up to 32K bytes so lots of
space for 10mS packets. Could even be 100mS and 2500 bytes.

The MACH software already does the co-ordinated move calculations so
theoretically, a driver to create 250+ byte packets with 4 axis
step/direction information out the USB port would be pretty simple. In fact
if Art made this a part of MACH4 and open so that the USB part could be
written by anyone then there'd be some competition in the driver end like
there is now with the parallel port side.

The difficulty is now in the user interface again. But instead of a package
like MACH driving the parallel port directly, it creates tables of 250 bytes
of what each axis should be doing every 40uS. It looks at the received USB
information from the PIC (or ATMEL or Rabbit or whatever) to determine if
the driver stopped for some reason and where it stopped (byte # and packet
#). So if can rewind and start again.

Take it one step further and make it 16 bits per 40uS to deal with more than
4 axis and some other high speed I/O. The rest of the output and command
information can be in the '+' part of the now 500 byte packets.

Simple right?

John Dammeyer

>
> What you describe is exactly the way I designed my Axis4
> controller board. The Axis4 board can drive up to 4 bipolar
> stepper motors in 1/8 step microstepping mode (2A per coil.)
> It also has a dedicated microcontroller and memory buffer
> for buffering up pulse timing information. Here's a URL
> for the Axis4:
>
> <http://gramlich.net/projects/cnc/axis4/rev_a/index.html>
>
> The software that does all of the step pulse timing is
> run on the PC. Again, here's the URL for the software:
>
> <http://gramlich.net/projects/steps/index.html>
>