Re: Interface. Gauging interest.

Mariss,

This reply surprises me<G>

You CAN lose many of the items you've mentioned IF you are willing
to do only what the bottom of your reply states is the truly needed
portion; accurate step rate generation...

A paradigm shift from what the Grex has become; but certainly a
useful tool. Remember your original post about a means to generate
evenly divided steprates?

What if that was all you supplied? (okay, amybe a couple more things)

Look at the DeskCNC controller as a model and it's pretty obvious
that while it in NO way competes with a Grex, it does offload "the
onerous task" of steprate generation from the pc to reduce its
burden.

And when yo look at that, you see that all that's really needed from
your list is: the xilinx, Vreg, PCB, xtal, cheap .1 headers, a FEW
leds, and perhaps a few of those 10 cent parts for IO support...

No enclosure is required. It could be optional just like the G101
vs. g100. I'm pretty sure Steve could fit the ft245bm into the
xilinx if it weren't already trying to do so much. Perhaps even a
simple MCU core would fit?

Point is, you are right; as long as you keep all the Grex features
in place. But pare down the list to what is REQUIRED (of a SIMPLE
cnc setup), and the hardware requirements are pared down too...

As for your point #3; is gcode really only 2-1/2 axis?
Wire EDM would say otherwise (4 axis). 5 axis machines are
programmed in gcode every day... And you can write efficient gcode
for any of these, and for hexapods too.
Using CAM. (Consider it--CAM--the software equivalent of your rabbit
in the Grex.)

IOW, you can generate step pulses from a Grex without the rabbit. As
you say in the literature, we need an 8 bit MCU with 4
address/handshake lines, and a hardware int. A lot of processors out
there fit that description that don't equal rabbit 3700 capability
or cost. In the same way the rabbit makes things easier for the Grex
overall; so does CAM make it easier to program Gcode. In far more
axes than 2.5

Just today I revisited a place I had worked with last winter. They
have 8 axis CNC grinders that they program in gcode...

So while I agree with #2, I think #1 is only true within the pre-
conceived stage it's set upon, and #3 is just not true.

Don't get me wrong; I love what you've done with the Grex. It's a
wonderful product. IMO there's room for another wonderful product
using similar METHODS to achieve the lower feature set that many
would be happy with. As you once said (paraphrased, from memory), no
one NEEDS a Ferrari, but they're sure nice to have when you WANT to
go in style.

Ballendo

P.S. the thing that is REALLY cracking me up here is that it was a
conversation/thread JUST LIKE THIS, ON THIS LIST, where I said that
I was SURE you could create decent pulses using Windows software only
(using the Pentium's then-undocumented RDTSC instruction); and that
I'd be happy if I could get 1hz rez up to 8khz speed... that started
Art F on the path that is now Mach4.

And now here I am pushing for a cheaper/simpler black box. Well
actually, those already exist. I'm pushing for one that can
integrate to MachX to relieve its "onerous" workload!<G>


--- In CAD_CAM_EDM_DRO@yahoogroups.com, "Mariss Freimanis"
<mariss92705@...> wrote:

>
> Couple of additional points:
>
> 1) I wish the G-Rex was a pizza you cut into 6 slices and take as
> many as you need, 1 slice or all 6.:-)
>
> It doesn't work that way; a single axis still needs the Rabbit
> RCM3720, the Xilinx FPGA, the FT245BM USB controller, the

regulators,

> connector blocks, xtal oscillators, pcb, enclosure, LEDs, etc,

etc.

> All you would save for a "single slice" would be a few 74HCT 10-

penny

> parts.
>
> 2) Step pulse generation is donkey-work a PC shouldn't have to do.

It

> is singularly ill-equipped for that task. This properly belongs in
> dedicated hardware like an FPGA; it was born to do that.
>
> Off-loading this onerous task from the PC relieves its burden. Art

of

> Mach fame reported he could watch a DVD and surf the web while

Mach4

> was running a complex contouring program. This on a slow PC

without a

> burp.
>
> PCs are meant to compute, not to do bean-counter accounting

parsing

> out microsecond step pulse timing and counting. It is the latter

task

> that makes PCs difficult to run easily no matter the OS.
>
> 3) G-code is at best a 2-1/2 axis control code. It is unimaginably
> unweildly for higher axis counts. How would you efficiently write
> application code for 6-axis of coordinated motion like a hexapod
> using g-code?
>
> Mariss
>
>
>
>
> --- In CAD_CAM_EDM_DRO@yahoogroups.com, "ballendo" <ballendo@>
> wrote:
> >
> > Hello,
> >
> > I disagree. Simply compare the output of KCAM running on windows

to

> > an older version of TurboCNC, or CNCpro.
> >
> > Then look at master5 vs mach1 versus mach3
> >
> > You will not doubt discover that the demands of RELIABLY running
> > multi axis vectored CNC moves requires far better pulse trains

than

> > you think.
> >
> > There is a HUGE difference between the programs listed above

when

> > run on the same computer, running the SAME hardware. And I'm not
> > talking about look and feel here, ONLY pulse train purity and

even-

> > ness.
> >
> > Ballendo
> >
> > P.S. the saddest thing IMO is that it's not the computer
> > architecture that's killing us; rather the OS

induced "protections"

> > aimed at the office products marketplace.
> > These products do not have the same demands as multi-axis CNC.

Even

> > a color printer, which includes a fairly sophisticated motion
> > control system, is nowhere near the requirements of CNC.
> >
> > From the outside, it looks "easy". Those who have tried find

rather

> > quickly the true meaning of the phrase, the devil IS in the

details!

> >
> > Since 1989 I've been watching--and helping--person after person

go

> > after the goal of a pc-based cnc control program. nearly all
> serious
> > efforts are successful to some degree. But that degree varies
> > widely, and many stop(give up) IMO FAR short of true cnc
> capability.
> > (G0,G1,G2,G3,G4) can theoretically do anything you need to do.

But

> > there's FAR more to "real" cnc)
> >
> >
> > --- In CAD_CAM_EDM_DRO@yahoogroups.com, Codesuidae <codesuidae@>
> > wrote:
> > >
> > > Mariss Freimanis wrote:
> > > >> ballendo wrote:
> > > >>
> > > >> What we truly need is a usb EQUIVALENT of the parallel port.
> > > >>
> > > >
> > > > That's just not possible for CNC programs that output step

and

> > > > direction signals from a parallel port. Step pulses have

timing

> > in
> > > > the microsecond range.
> > >
> > > You are of course presuming that microsecond precision is
> > required.
> > > There are plenty of motion control tasks that could be

performed

> > using
> > > less precise pulse timing. The availability of a cheap, bit-
> > bangable
> > > USB parallel port would enable control of such tasks from a

wider

> > range
> > > of hardware. It doesn't take much imagination to see a

variety

> of
> > > possible configurations and applications for such a device. I
> > suspect
> > > that it's probably more 'neat' than 'useful' though.
> > >
> > > Applications that require higher performance (of the sort for
> > which one
> > > might be inclined to use a Geckodrive) probably wouldn't be
> driven
> > from
> > > such a device and likely would justify spending a bit more to

get

> > better
> > > hardware.
> > >
> > > Dave K
> > >
> >
>