Re: USB CNC (was Interface. Gauging interest.)

--- In CAD_CAM_EDM_DRO@yahoogroups.com, John Dammeyer <johnd@...> wrote:

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

I've had some help from other people on the list --
I figured that publishing everything was one way
giving back to the community that has helped me out.

> 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.

What you describe below is largely what I have already
implemented. The primary difference is that I have
slower UART running at 115200 baud, and thus need a
larger buffer to get everything done. In addition,
I do some compression on the data stream the the PIC
uncompresses.

However, the back end process that I implement in the
PIC is a simple circular buffer where I dump the
step/dir line states and they are cleared out every
20uS. This is exactly what you describe.

> 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.

I've always liked the FTDI chips, but disliked their
surface mount only packaging. For a hobbyist like
myself, I like to design projects with DIP packages
that easily mounted in sockets.

> 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.

I don't know much about MACH, since I think that it
closes source. However, my software does all of the
coordinated move calcuations for linear and helical
moves.

> 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?

No real disagreement from me. The devil is always
in the details, some what is simple to you might be
a little more complicated for me. I have 100's of
hours tied up in board design and firmware debug.
It has been a lot of fun though and extremely
educational.

-Wayne

[snip]