Re: new Mark IV control program

[Chris Albertson <chrisalbertson90278@yahoo.com>]

Michael,

I've got your software built and I've been reading
the code.  Good work.  You've done the part I had
yet to complete.  For example I have a way to use
TCL as a high level scripting language and I do
track the RA and DEC of the camera aim point and
accept "Go To RA,DEC" commands but I don't yet send
commands to the motors. 

I may want to either "borrow" some of your code or
(better) possibly think of a way I could use your
program as a low level driver and mine as a higher level
driver.  We could have a layered architecture that way
and avoid duplicated effort.

One small problem.  When I send a command to the STAMP
I _don't_ wait for a response.  I maintain a queue
of outbound STAMP commands and when a response happens I
de-queue and send the next command.  That way the software
never has to wait and is free to accept new commands from
the user even if the STAMP is busy.  I needed this because
one high level command (GoTo ra,dec) typically decomposes
into many level level commands that all get queued at the
same time.  Also logically while doing a long command like
"move to limit" you may want to do other things like
clear charge off the CCD. or readout engineering data.

I would send commands to your program if we (any of us on
this list) can think of how to do two things:

  1) Have Michael's program accept commands via some
  inter process communication interface. (I'd prefer sockets
  but a FIFO Pipe would be easier.)

  2) Return the response back via the same interface.

I need to be able the send a command down the FIFO and
not have to wait.  I let the STAMP drive the command rate
by always sending a command when the previous response
comes back.  Yes, there is always a command I can send
like "read out a temperature".

On another front I've got RH7.1 with it's 2.4 Kernel installed.
and I'm working on converting my RAM card driver.  I intend to
write a loadable kernel level driver for the Mark IV's ECP port
interface too.  I'll copy the Zip drive driver or some other
parallel port device's driver.  There are plenty of examples
in the kernel sources.

I may send you some code that you could put in you control
program.  Possibly a new make file with a few more targets
Like a "make dist" that will build a time stamped tar file.

Stupendous Man wrote:
> 
>   I've written my own control program for the Mark IV
> (as you all should know by now, I have a compulsion to
> re-write any and all software I use on a regular basis).
> This version is written in C and *nix.  It allows both
> interactive and file-driven input.
> 
>   Please read the manual to get an idea for the way it
> works -- a simple command-line reader.  I welcome comments
> on improving it.  The program hasn't been field-tested yet,
> but will be soon!
> 
>   You can find the manual and full source code at
> 
>         http://spiff.rit.edu/tass/tait/
> 
>   Beware -- this is alpha quality.
> 
>                                             Michael Richmond

-- 

--
   Chris Albertson             
   chrisalbertson90278@yahoo.com
   Redondo Beach, California
   home: 310-376-1029
   cell: 310-990-7550