Re: [CAD_CAM_EDM_DRO] Re: Interface. Gauging interest.

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.