Re: Re: EHP External Hardware Proposal

> From: George Fouse <gfouse@...>
>
> 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.

<...>

> 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.

The EMC software already supports exactly the setup you are talking about.
There is a program called emcserver that you can run on the RT box that
implements (I think) a socket type interface, and there is also a Java UI
that works with it. All of this is in the regular distribution. The only
problems I had with Java were:

1. The UI was very sluggish (poor drivability at the keyboard). This could be
due to some problem with the network interface code, but I suspect it's just
that the JVM is really slow.

2. The AWT (Abysmal Windowing Toolkit) comes with a small set of limited
functionality widgets. As an example, the button widget has only a "button
pressed" event, there's no "mouse up" event. You can't just glue more methods
on existing classes so I had to create a whole new button class by extending
canvas just to make an axis jog button! I forget the reason why I couldn't
extend Button...

A very early version of the EMC used two computers, one ran VxWorks (I think)
to do the real-time stuff, and another PC ran a VB GUI under NT (this is
around '93-'94). They were connected via Ethernet, and also remote control
experiments were done over the Internet with a mill at NIST in MD, and the
GUI at Sandia Labs out west. This rig also had a live video feed for the
operator, so they could see the workpiece.

You need to talk with Will Shackelford, his web page is:

http://www.isd.cme.nist.gov/personnel/shackleford/

He wrote emcserver and the Java UI and could explain all this stuff and how
it works in detail. I wrote a prototype Java UI as an illustration of what I
thought the GUI should look like. Will started linking it to the emcserver,
but I could never get past the sluggishness issue and the whole idea sort of
stalled (on my end I'm afraid). You can see this (my first and only Java
program) at:

http://users.erols.com/mshaver/emcgui.htm

Once it comes up in your browser, click on Power, then Reset, then press Home
and the X axis should read 0. Highlight the remaining axes along the left
side of the display and press Home for each one. You can jog (incremental
Only), and check out the tabbed displays. This is a couple of years old, but
I still like it, I'm hoping to redo this in tcl/tk some day...

Regarding boot to CDROM, it's a great idea if the PC's BIOS supports it.
Another OS that might do for an embedded RT-PC is DOS, but it's single
threaded (translation: you do all the work). I enjoyed your post and hope
you'll keep it up!

Matt