CapCOMM Design Ideas.

1) Basic RS232-control (DCOM InProc server, interface exposed to Perl, Python, etc.)
2) Packetizer (can be constucted with other protocols)
3) CapCOMM, which exposes a minimal interface for string-based (ie dumb) exchange

That is the basis. Here is the functionality I want to eventually add--

4) Capstone-specific command interface (self-documenting), which includes sequences and sanity-checks, allows polling as well as UDP-based IP broadcasts of turbine instumentation (whatever is available, as it comes into the serial port). This server will have a CPL, and will probably run as a service. It will have a query and control interface which can be attached to by multiple guys. It will have a state machine that keeps track of the turbine and does the sanity checking.

States:
Connected and communicating
Unconnected
Local Logging (on or off/history available on request)
Status-request pass-through (for any stat or instumentation that is not being polled already)
Control-request (token-passing amongst clients). Exclusive access to token holder.

CFA--

A) Upon startup, attempt to establish comm with last known RS232 parameters. Auto-connect NV attribute, can change the default behavior. With success, provides a UDP announcement, regular status updates (SYSSTA), and depending upon the status of the turbine (if it is running, for instance), a set of basic instrumentation (ie something beyond SYSSTA, which provides a reading of current power, voltage/amps, etc.). With unsuccessful connection, sends that status via UDP, while also doing a timed connect-attempt, eg sending a SYSSTA request continuously, regularly, until told to stop.

UDP will be used to provide status and instumentation to anyone on the network.

Normal socket TCP will be used to command and control the Capstone (via the ICapComm interface, in the service, which has local connection). Normally, a GUI front-end will reside on the local PC (the 640x480 Intermec, which also controls the bus' alarm system & provides my main unswitched interface to the bus systems). When the Capstone is on/started and providing power, a second Intermec at the Driver's station will assert control. The CapCOMM service will run on all of the Intermecs, and be available to run on any W2K like the laptops, and they will each provide in and out TCP connections, so any could serve as the master controller and any could serve as a gateway to other networks (i.e. allow me to remote control and receive intrumentation over a wireless link). 

So, thus far, we have a service which starts with the machine (Autorun), and has a CPL for access to some parameters. Attributes such as AutoConnect, Connection Settings, and other registry variables control any local serial port access to the Capstone, while other settable attributes control whether polling and broadcasting is enabled.