Re: Interface. Gauging interest.

Have you installed an run Mach3? www.machsupport.com

As I said, some nearly complete firmware and a working hardware
design for a smart dumb box--as opposed to a dumb smart, or either
singly--are in the public domain (though a bit harder to find right
now). You don't have to reinvent the wheel here...

Ballendo


--- In CAD_CAM_EDM_DRO@yahoogroups.com, "Dennis Schmitz"
<denschmitz@...> wrote:

>
> Apparently so, except the GRex 100 is way bigger (physically) than

I'm thinking.. I gotta say, finding out exactly what was in those
things wasn't exactly straightforward. Like looking at the product
page on the website would have been. That sure would have been nice.
(I kept looking at the PDF there and seeing installation
instructions for a CD thinking it was the wrong file when it
eventually did get to the point. Kinda.)

>
> Seriously, if they expect people to buy them for any other reason

than their friend told them it was the stuff to get, they need
better descriptions.

>
> Well, bottom line is that I'm doing this design for another

project, which is motion control but not CNC. The question is what
to do with it afterward.

>
> I'm considering two options: 1) try to sell it, like I don't have

enough to do and 2) give it away for free in the form of an
electrical cad package. I'm considering a free license to
individuals, but would charge a fee if a company wanted to build and
sell the design.

>
> Apparently, this simple email I sent caused a debate large enough

that I can pretty much glean everyone's input from what's already
written. Thanks!

>
> That said, my two cents regarding the smart/dumb box debate:
>
> As it happens, I was in the telecom industry during the great

smart/stupid network debate (the stupid network won btw), so I have
some perspective. My perspective is, if you use rule-of-thumb design
practice you'll get screwed every time. The system must be analyzed
from scratch during the system design.

>
> The first and absolute biggest problem is that Windows (XP or

otherwise) is not a real-time operating system. It never was a RTOS,
isn't an RTOS and can not be made into an RTOS regardless what Gates
has been smoking^H^H^H^H^H^H^H pitching to the developers. Running
control loops from Windows is asking for trouble. Hell, I even had
misgivings about the real-time extensions that EMC was using for
Linux, because Linux isn't an RTOS either. It is, however close
enough to fake being an RTOS if you run it really fast and hope you
don't get nailed by a cache flush at the wrong time.

>
> In any case, it's WAY easier to make the USB interrupt respond

deterministically in Windows (or Linux for that matter). I suspect
that the people working on the Windows code hitchhike on the audio
or video subsystems because Microsoft cheats to make them appear
snappy to the user. But that's fake. You can't make it
deterministic, and the message time jitter is awful. To do this
right, you need Quality of Service controls in the protocol and the
only thing really up to the job is Firewire.

>
> Seeing how I'm a guy who doesn't like beating his head against the

wall or trying to trick Windows into behaving civilized, I shall put
the control loops in the box, but not any of the other high-end
processing like G-Code interpretation, display and calculation of
long swoopy curves. For that a PC is just fine (even Windows).

>
> The question is what exactly the control loop should do and how to

configure/use it over the USB. So it's a protocol design.

>
> My thinking is that the box will be a true black box with a list

of general purpose resources, timers, digital I/O, ADCs, DACs, etc.
The host computer would send commands to the box at a high level
that tell the box to for example, "associate such-and-such I/O
channels and establish a position (or rate) control".

>
> Another command might be, "drive a step into the system and

analyze the response against the standard backlash model".

>
> Conversely, the controller could send the host a message

saying, "You're using 50 amps driving the X-axis into the broken
cutting tool, so I'm going to turn it off now and you should too."

>
> The command interface should be an open standard so anyone could

write software for it (or clone the hardware for that matter.)
Assuming the protocol was robust enough for every manufacturer to
make use of without hacking it to death, this would very quickly
evolve into a plug-and-play physical motion control where nobody
except the driver writers and code jocks would know about or even
care about the data interface.

>
> Anyway, the processor is going to be one of the automotive series

PPC, depending on how many channels of I/O I need. I'm also going to
run one of the SPI busses out of the board to control temperature
sensors and whatnot.

>
> On 5/12/06, John Stevenson <john@...> wrote:
>
> >Are you not describing a Gecko g100 GRex module ?
>
> John S.
>