Re: Re: EHP External Hardware Proposal

Hello,
I am new to this group, and so please forgive me if I rehash ideas from
before. Looking at the past few days' posts, it looks like there is a
desire to get:

1. A 'black box' back end to take care of 'details' from code
decomposition down through actual controller driver functions [and
personally, I think this 'box' should handle DRO 'feedback' so that
steppers can be run in closed loop if desired]. Obviously this box
should also handle 'panic' conditions as well (limit and other
conditions) [probably this would usually mean stopping the drive motion
until receiving further instructions].
2. A standardized hardware/software interface to allow for a
(relatively) arbitrary front end (gui or command line), not necessarily
in the 'same box' as the back end. This front end would need to supply a
G-code stream (or whole program up front), initialization parameters,
and be able to receive exceptions and handle them (obviously NOT in hard
real time).

Hopefully everyone would agree that the back end should use a true RTOS,
so that worst case response time can be known. Neither NT or W9x (nor,
for that matter, vanilla Linux) can guarantee a specific worst case
response time, rather the goal is to optimize average response. The
choice of RTOS is influenced by cost and the level of 'high end'
functionality required. I'm assuming here that we all want to minimize
costs, including hardware, software, and development. Given this, it
seems that the most cost effective solution would be a stripped down pc
running RTLinux and EMC. A serial port can be used for console (no
keyboard/video card), although in general use no console should be
needed. There should be at least 2 (?3) parallel ports to provide enough
i/o lines. TCP/IP via ether net is the fastest/best means of
communicating with the front end. Cheap ne2000 pci cards are <$20 each,
and for interface with a single front end host, a simple cross patch
cable suffices (no hub needed). Most importantly, it makes it simple to
set up server/client relationships with the front end using standard
socket programming. As a 'hardening' measure, the software should be
stored on a read-only medium, with the system utilizing a ram disk for
root (/usr can be on the storage medium). The easiest/cheapest way to do
this is to boot off of CD-ROM (LS-120 also good, but more $).
Optionally, a floppy disc drive could be used to store any site specific
configuration data. NO hard drive would be needed, improving reliability
and cost. At <$1.00 each, CD-ROM's are great distribution media.
WRT front end interface, this would be done in userland only (hard real
time not a concern). The choice here is whether to use a daemon
listening on one or more ports (classic server/client design), or set up
a simple web server listening on a specified port (web based interface).
I guess both systems have pros/cons. The biggest disadvantage of the
client/server design is that there has to be a client program written
for each client OS. How hard is socket programming with VB??
Although the web interface (in principle!) works with any client with a
suitable browser, I think the stateless protocol makes what we want to
do here harder. For-real web programmers are welcome to correct me
here!! Actually, perhaps the best compromise is to write the client
software in (100% compliant) JAVA. That way any client with compliant
jre could serve as a front end. Technically, socket programming is VERY
slick under java, and the graphical capabilities are 'good enough'. This
application could either be a stand-alone application or an applet
downloaded from the back end.

Finally, I guess what I'm envisioning here would be a software
distribution that would be ready to 'burn' onto CD-ROM, so that
non-geeks wouldn't have to get into the guts of the software. By
including a (simple but functional) JAVA client, someone could use the
system with no additional programming.

Sorry for the length of this post, and if its redundant with any earlier
porposals. (Constructive) comments/suggestions/discussion are requested.
Thanks.

Carlos Guillermo wrote:

>
> From: "Carlos Guillermo" <cnk@...>
>
> Reply from Carlos Guillermo between text:
>
> > ...................
>
> Ron - I, for one, would GLADLY pay $300 for the beautifully choreographed
> signals that IndexerLPT sends out the parallel port, but ONLY if I could
> also find a nice windows CNC interpreter/frontend for it, for which I would
> also GLADLY pay an additional up to $300. This combo could provide much
> better performance than the equivalent external box such as Flashcut, and
> they are charging over $1000 for their "no-upgrade" solution. To perform
> the same lookahead and ramping that IndexerLPT handles in an external box
> seems impractical and very difficult to me, especially for the price. Plus,
> Flashcut's steprate is limited to 7300 steps/sec (in good weather) compared
> to Indexer's 100,000+.
>
> > .....................

> Isn't the Tiny Tiger a pricey module??
>
> > ............................

>
> Please, please, use IndexerLPT commands in your VB frontend?! Then we could
> have the choice whether we send them out to the serial port or write them
> out to IndexerLPT.
>
> > ................................
>
> There we are... let's copy Indexer's command set! They've got it all worked
> out, and they couldn't complain if it meant more sales of IndexerLPT.
>
> > --
> > Ron Ginger

--

-------------------------------

George Fouse

-------------------------------