Re: [CAD_CAM_EDM_DRO] RE: USB DLP2232M CNC, Was Re: Interface. Gauging interest.

Alan Marconett wrote:

> Hi Mike,
>
> Sorry I couldn't remember the source!
>
> That certainly sounds simple enough. Then can the USB keep stuffing the
> input of the FIFO fast enough so that the 6.5 uS output of the FIFO is NEVER
> interrupted?

Unfortunately, I don't have the equipment to measure this. I suspect
the answer is "yes", but I can't prove it. At some point, I may
beg/borrow/steal the equipment to find this out.

> What USB transfer mode do you use? I've read about the
> ISOCHRONOS mode that sounds like a likely candidate.

I don't know for sure. I don't think it uses the isochronous mode,
which as I recall is mainly for video. I would guess that it uses the
BULK mode. FTDI specs say it supports both, I just don't know which one
their subroutine library defaults to.

> HID or COM type?

I'm not a USB guru, but I think the correct answer is "neither".
HID is can be used for a lot of different devices, and Windows has
built-in support for this class of device. But, it's generally a
lower-speed protocol, for stuff like keyboards and mice and buttons.

COM (as in COM port??) views the USB device as a "port", e.g. a serial
port, or parallel port. I have the B side of the 2232 programmed this
way, because I use it to talk to an LCD display that expects 9600 baud
serial.

But, the high speed part of the design, the part that connects to STEP
and DIRECTION, is neither. It shows up in the Windows Device Manager as
"FT2232C Channel A".

> Do you already have a full CNC controller program written for Windoz, or are
> you testing move routines? What language?

I am writing my own CNC controller program. Right now, it's real
simple, and I use it for testing. The test program has the following
buttons right now:

Open Port A
Close Port A
Write 0x00
Write 0xFF
Interpolate

That last one I use to test my linear interpolation routine. I have 3
distance sliders right now (X, Y, and Z), and when I click on
"Interpolate", my test generates an incremental move using linear
interpolation (essentially, G91 G01 X.. Y.. Z.. in g-code).

The test program is written in Borland C++ Builder 5. At some point, I
may switch over to Visual Studio Express, which is now free from Microsoft.

> How hard is it to "talk" to the USB via your high level language? I've seen
> apps that relied on a "virtual comm. port" created by a USB driver. Do you
> use that (FTDI driver), or is there a way to talk "USB" to the USB device
> directly? (Boy, there is a LOT I've got to try to ketch up on!)

I don't pretend it's a serial port, or a parallel port. It's simpler
than that. FTDI provides a separate subroutine library and driver that
makes it super-simple to talk USB to their chip.

Here's what it looks like (somewhat simplified, but not much). This is
in C/C++:

1. ftStatus = FT_Open(0, &ftHandle);
2. ... code to calculate what to send out ...
3. ftStatus = FT_Write(ftHandle, buffer, numBytes, &bytesWritten);
4. FT_Close(ftHandle);

Line 1: Open the port (0 means port A), and give me back something to
refer to this port later with (the port's "handle").
If there's an error trying to open it (like, it wasn't
plugged in), ftStatus will contain an error code.


Line 2: This is where the hard work happens. Here is
where I figure out the bytes I want to send to the
Allegro chips. I stick all the bytes (1 at a time) into
a buffer (an array), and when I have enough of them...

Line 3: ...I call FT_Write to send them all down the wire.
Write <numBytes> bytes starting at <buffer> to the port
specified by <ftHandle>. When you're done, tell me
how many bytes you wrote (bytesWritten).

The FTDI library takes care of sending them in batches that
fit into the on-chip FIFO.

Note that all the clocking out at 9600*16 baud happens in
hardware on the FTDI chip itself. So, once the on-chip
buffer has data in it, it merrily clocks away every 6.5us,
while I'm working on the calculations for the
next batch o' bytes.

Line 4: Close the specified port, because I'm done with it.

> I didn't see a " DLP-2232PB has the FTDI chip, plus a PIC 16F277A " on the
> FTDI website:
>
> http://www.ftdichip.com/

The 2232 + PIC module isn't sold by FTDI itself. It's sold by another
company called DLPDesign. DLPDesign provides schematics for the thing,
too, so you can see exactly what you're getting.

I'm not at all associated with the DLPDesign company, other than being a
happy customer! DLPDesign sells their little modules through Mouser,
which is where I got mine.

> It sounds more like the USB PIC, and could be more useful.

Very similar, I think. I was going for minimal cost (with adequate
performance), so I decided to try doing without a microcontroller to
start with. (I like to think of myself as "fiscally conservative",
although my wife calls me "cheap". :-)

> Your project hardware also seems to fit into the "USB-CNC-PARALLEL" board
> description. Do you have to do much to program the 2232?

There's really no "programming" of the 2232 to do, per se. If you use
the FT_ routines I described above, the library does all that work for
you. Saves a ton of time!

> Certainly sounds interesting. I'm anxious to see your progress.

I'll let you know how it goes! Right now, I am focusing on the basics:
lines (with accel/decel) and circles (with accel/decel).

If I can get those working well, I will work on a minimal G-code
interpreter (G00/01, G02/03, G54/43/28, G90/91, M03/M05, M30).

> Alan KM6VV
>
>
>
>>Alan Marconett wrote:
>>
>>>WHO was doing something with the DLP2232M module? (please contact me)
>>
>>I'd
>>
>>>like to hear a little more about that. There IS buffering (FIFO). Is
>>
>>there
>>
>>>an interrupt to clock the data out of the FIFO? Another clock to de-
>>
>>couple
>>
>>>the output as smooth steps?
>>
>>That would be me!
>>
>>Yes, there's buffering, and it seems to work pretty well. I seem to be
>>getting a reliable rate of one byte sent out every 6.5us, and my PC is
>>not even breathing hard doing the calculations for the step pulses.
>>
>>Note: no separate clock is needed to output smooth steps -- what's so
>>nice about this FIFO mode is that the chip clocks data out every 6.5us
>>for you. If you don't send it anything, the last value you sent just
>>sits there. The clock rate I'm using right now is 9600 * 16 (153.6kHz).
>>
>>That makes for a maximum step rate of 76.8kHz, because you have to send
>>a zero, then a one, for every step. But, since data is clocked out
>>every 6.5us, that means that you can place the slower STEP signals with
>>an accuracy of 6.5us (the full resolutions you'd expect with a 153.6kHz
>>clock).
>>
>>If I remember right, that's almost as fast as the Allegro chip in the
>>HobbyCNC board can take it.
>>
>>There is a line available to clock data out of the thing, but I don't
>>use it -- the FTDI chip just holds on to the last value, until the next
>>one is ready to be clocked out. If you wanted to clock the data stream
>>into an external latch, or use that line to interrupt a PIC, you
>>certainly could.
>>
>>In fact, DLPDesign makes such a FTDI+PIC thing, that works exactly like
>>that. DLP-2232PB has the FTDI chip, plus a PIC 16F277A. Because of the
>>PIC, it costs a bit more ($50 vs $35).
>>
>>If I get stuck with the 2232 alone, and the pulse train has problems
>>coming raw from the 2232 chip, I'll move up to this more expensive
>>version, and program the PIC to do the pulses for me.
>>
>>Info is here:
>>http://www.dlpdesign.com/usb/2232m.shtml
>>
>>Right now, I run the FTDI chip's output lines directly to a female DB-25
>>connector, that plugs into a HobbyCNC board, just like a parallel port
>>cable would. Something like this:
>>
>>2232's
>>PortA
>>0 XStep
>>1 XDir
>>2 YStep
>>3 YDir
>>4 ZStep
>>5 ZDir
>>6 AStep
>>7 ADir
>>
>>The FTDI chip also can do simultaneous reads at that same rate (so, as
>>you're writing bytes, the chip is also reading bytes in at the same time
>>and sending them back to you), but I'm not doing that sort of thing yet.
>>
>>Mike