Re: black box specs

Jeff,

(snips, inserts below)

>Being a "microcontroller in a box" kind of guy, I keep wondering if
>this isn't a good way to go. Keep the interp algorithms and
>trajectory planning on the pc, put just the real time stuff in a
>micro. If partitioned correctly this type of thing can work.

Sure. Drafting plotters, commercial engraving machines, Shopbot and
Flashcut all use the serial port connected to a microcontroller
approach.

Nagging thought is "just WHERE do you partition? CAN the interp be
separate from the pulse gen? I have my doubts...

If you follow the same path as those above listed (putting
an 'embedded motion control system' in the black box with either
dedicated motion chips or the uP equivalent), you will probably cost
what they cost (i.e. lots, relatively speaking, especially if
development costs are included)

And if you don't put the 'motion control' chipset (or its' micro
replacement) in the black box, then just what do you put there?
(which is what we're trying to decide)

>>Which protocol?
>Ethernet, anyone? Don't laugh, it works, it's fast, cheap, and not
>going away any time soon. Yeah, I know it has a few problems of it's
>own, but so do all the others.

Okay. So one of the first things we need to decide is: Does whatever
is "out there" waiting for control from us, require a deterministic
connection (which I am taking to mean, either 'real-time' or
determine-able and/or consistent delay)? And if it does, what,
besides the p-port, can get us there?

Again, this leads back to the 'standard' black box approach. (a
fairly sophisticated box which only needs coordinate information/
type of motion to do, and rates) A non-deterministic connection.

>>Yes. Again agreed. And let's keep Jeff Bs' advice in mind. Figure
>>out the LEAST BIT that NEEDS hardware! This is a product/ project/
>>situation which will scream for feature-itis, IMO! Let's keep the
>>box really simple.

>Many times the simplest, cheapest hardware turns out to be a
>microcontroller. I was talking about chip count, cost, etc. not
>conceptual complexity.
>Jeff

But if all we end up doing is put a "baby pc" in the black box, then
I'd say we're better off just using the PC. Unless the "baby pc" is
designed for motion control, at which point we're just re-inventing
the wheel... Where the costs, and the path, are WELL-established!

I'm still looking at that 'partitioning' question!

Hope this helps.

Ballendo

P.S. I know Ron G has said "Give me an 'open' Flashcut box...
at $2-300, he'd be happy. Except for price, these are ALL over the
place. Try OMS, Galil, PMD, etc.

So we really seem to have 2 different paths:

1) duplicate the 'motion control black box' in a cheaper, 'open' way.
2) Innovate a minimum hardware 'plugin' to offset the PC architecture
weakness's where motion control is concerned.