Re: Interface. Gauging interest.

Hello,

That it CAN be done is already proven.

(It being precise motion control over a USB connection)

Fred recently "announced" a new usb 6 axis "pod".

I'll bet it's based on the original version of the g100. (the G2002,
also known as the cube and slab)

The hardware portion--rate generators--of Mariss's solution is
simple, it just costs a lot if you use discrete TTL/CMOS chips.
So you put it on a CPLD/FPGA, and it becomes inexpensive again.

Now you feed those rate generators with a ring buffer that is fed
from the USB stream. You can use the Ft245bn as the initial buffer,
but it's not large enough.
When Art was writing Firmware for the cube and slab, we were in
daily conversations about it, as I was working on a "clone" I called
the beehive. In those conversations he told me that the worst USB
latency he saw was 18ms. So your ring buffer has to queue at least
that much data for the rate gens, or they die of data starvation.
(and that 18ms needs to be addressed the "other" direction; more on
that below...)

So far this is pretty easy. That's why we'll continue to see
developments like the CNCdudez, and Mikes project, IMO.

The fly in the ointment is dealing with things like feedrate
changes, Estops, and inputs which can arrive at any arbitrary time.
You have to deal with this info, ACT upon it, and NOT screw up your
kinematics...

You have a buffered set of commands (velocities, if you're using
Mariss's technique)which represent the rates needed at a given
feedrate and based upon a known stopping point. BUT...

Either of those assumptions can be made irrelevent at any point in
time by the parsing of a single inbit...
How do you flush the current queue, recalc the modifed queue, and
continue sending veldir's at the rate of 1024 hz.?!?

(I call them veldirs because for each axis you need a velocity and
direction. The 1024 hz is based on Mariss's original hardware
algorithm, which updated the veldirs at this rate. Since the
hardware rate gens were flying along at 4mhz, we'd get the increase
in spectral purity by the factor of the different rates of the two
operations. (Divide and conquer, so to speak!<G>)

Anyways, the hard part is NOT getting outbits across the USB to the
drivers. Nor is it getting the inbits back across the wire to the
operator. The HARD part is integrating the needs those inputs
represent into the generated output in real-enough time to keep the
motors first, and the operator second; happy.

The solution taken by Mariss is to use a high powered--relatively
speaking--micro(the rabbit 3700) to put enough brains into the loop
to deal with the hard stuff. And also use some cool math--moving
average--to distill and present a reduced and informative data set.

Art stopped development of the slab code just before it
was "complete"; pretty much lacking only homing and probing. FWIW,
That firmware and hardware is open source, and still available...

So now I'll finish by repeating what a few others and myself have
already said. Doing the "dongle", or black box, or whatever is not
really enough. It HAS TO integrate into a usable, hopefully popular
cnc controller applicationm, or at least a decent API.

(In that latter case we'd be able to spur NEW developers to create
some new "competing" apps to DeskCNC and Mach3/4; since it doesn't
appear at this point that either of those two are going to open up
to this idea.)

A lot of the work is already done and "out there". But unless you
just want to spit pulses in a non-CVV mode, ignoring feedrate
overrides and path-preserving decels, there's still quite a bit to
be done...

And if you DO ignore these items, consider that your market just got
a LOT smaller, whilst your exposure to legal action arising from
safety breaches just got a LOT bigger...

Hope this inspires,

Ballendo

P.S. Like I said before, someone give me one with 4 axes and 8+4, or
perhaps 8+8 bits of IO at 50-75 bucks (that will work with Mach-- or
something similar) and I'll guarantee purchase in excess of 1000
units per year. But probably a LOT higher volume than that.

P.P.S. It became obvious to me pretty early in the G2002 development
that Mariss was heading for the motion control marketplace, not just
CNC. (a Good idea for him because that market is HUGE, compared to
CNC.)
Anyways, I also saw that this was going to result in some needed--
for THAT market--feature creep which was gonna drive up eventual
costs well beyond "the price of a g201" that was initally targeted
and put us where we are today.
(Which is having the Grex be a GREAT product, fairly priced for what
it is and can do... But also FAR more than what is needed by a
large majority of home and small shop CNC-ers.)

Doing the hardware is ultimately "easy"; not having it integrate to
a decent controller app is the sword-in-the-stone. (A great tool
made useless.)

Arthur? Arthur? Where are you?<G>

>In CCED, "Alan Marconett" <KM6VV@...> wrote:
>There are drivers to make USB look like serial, but I haven't heard
>of one for making them look like a parallel. Are they out there?

At any rate, the timing of the signals we want to put on the
parallel pins

> would no doubt be considerably distorted, and probably make the

driver

> unsuitable for our use. I'd like to be proven wrong!
>
> I suggest that the USB "dongle" needs to be a little smarter. I'd

like to

> see something like the DeskCNC module with an FTDI USB chip, or

implemented

> in an 18F4550 PIC. And the protocol specs for the DeskCNC module

made

> public so that it could be standardized on (or is it already?).
>
> No, we'd be away from the simplistic LPT interface we've been

using, but

> it's probably necessary if we want USB.
>
> Alan KM6VV
>
>
> >
> > OK, does anyone offer a converter that plugs into the USB port,

but has a

> > "parallel port" LPT-1 type connector for use by us OLD

folks? I could

> > use
> > such! But wouldn't that obviously require a "machine-code

patch" to

> > produce
> > code that would come through such an adapter as that code would

come out

> > of an
> > "old" LPT-1? How? COMPLICATED! Makes me tired just to PONDER!
> > Jan Rowland
> >
>