RE: [CAD_CAM_EDM_DRO] USB CNC (was Interface. Gauging interest.)

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