Re: Tcl/Tk GUI

[Chris Albertson <chrisja@jps.net>]

(I was going to send this to Aaron but I think maybe others may
want to see this too.  Let's keep the software design on-list
so we all know what's gong on and don't duplicate effort.)


Aaron,

I'm still not clear about what you are trying to do.  Maybe you can
answer some questions.  

If you are writing a GUI front end to my controller then you
don't need to be writing out FITS format files or controlling
a shutter. 

All you do is (from within your tcl program is
  
    load /usr/local/lib/tass_tcl/libTmkivd.so.0.8.0  Tmkivd 

After you do that then you have a few tcl functions you can call
really you only need two

1) Tmk4_connect -- connects you to my controller.  You don't need
   to know anything about sockets or networking.  Just the name or IP
   address of the real-time control computer.

2) Tmk4_SendCommand -- sends a command to the computer you are connected
   with.  You can see an example of a minimal program if you look at
   Tmkivd_test.tcl   This program connects to the server and sends just
   one command to it: "help".  The server will in response to the help
   command send back a list of all valid commands.  The list is formatted
   for printing

To write a GUI front end first get Tmkivd_test.tcl to work on your
computer.  Now you have a working tcl program you can modify.  Keep
modifying it until you have a GUI from end.  I'd add one new feature,
test it, add one more then test and so on.

What you need to know is what commands the server will accept.  Of course
typing "help" will tell you but if you need more detail look at
commands.c  It is mostly a dispatcher that calls functions to do the
command.  But also please not the comments at the top of commands.c that
explain how to add new commands to the server.

I have designed the real-time controller so that someone who does not
want to fully understand the whole controller can still add a new
command.  You just write a function in C and add a new entry in a table.
The command parser reads the table as does the "help" command.  The table
contains a min/max limits for you new command's parameters.  So, command
parsing, error handling and help are all taken care of by adding a line
in the table.  See comments in commands.c for details.

The server already has commands for the "normal" stuff I could think of
like taking an exposure, pointing the telescope and saving the image
to a FITS file.  It also has commands to send the image to a display.
Either a local or a remote display. (I use ximtool or SAOimage as the
display device.)  You can also save the image as a jpg, gif, tiff or
whatever.  Now suppose you want to rotate your dome.  I have no function
for this.  You can add one in about 30 minutes (assuming you've already
debugged a dome/computer interface.)

One of the columns in the command table is "login required"  This can be
yes or no.  If yes the command will not be run for a user who has not
yet executed a "login" command without error.  I use a convention that
any potentially destructive command required a logged in user.  Reading
out the voltage on the 5V supply can be done with out a login.

You ask about connections by multiple clients.  Yes, the server
supports this but no, your GUI front end need not know or care about this.
The purpose of supporting multiple clients is to make writing clients
easier.  Now you can write a client that does just one thing

For example I could write a Tcl (or C) program that reads the 5V supply
voltage every 10 seconds and updates a bar graph display.  I have another
client that points the telescope and takes images.  I can run this all
night.  But, I can also run any number of these bar graph programs.  Maybe
they will ring an alarm if something goes out of bounds.  Anyway the
point is I don't have to write on big monolithic client program.
I can run a set of them.  Also notice that I don't have to run all the
clients on the same computer.  




Aaron Littich wrote:
> 
<snip>
> 
> Anyways, here is what I plan on doing:
> Continuing work on GUI.  I have found a FITS interface package for Tcl/tk that will allow you to read the data in a Fits image without much fuss. Still need to try though.  I found it on NASA's High Energy Physics website, here is a link:
> 
> http://heasarc.gsfc.nasa.gov/docs/software/ftools/fv/fitsTcl_home.html
> 
> The GUI will be mostly menu-driven, but I will have three different modes: schedule (if Peter gets that working), graphical, and command line (where simple ASCII text commands are sent to MKIV Server Daemon.

I think you will find the latter is triveal to impliment in tcl.
Just read lines of user input and send them off "as is".  I have a
client program that does this now.  I have another only slightly more
complex client that will read these same commands out of a file and
pass them on.  What makes it "slightly more complex" is that the commands
in the file are preceaded by a "time tag" and the command is not
passed on to the server until it is time to do so.  The time tags
can be relative or absolute.
> 
> It will have interfaces for Mkiv control, image editing, and database access.
> 
> I see that you are making a interface for Tcl users (Tmk4.c), see if i have this right-
> 1. Server socket setup on Mkiv end, starts listening on some port id
> 2. Client socket hooks up on listening server socket on default port id
> 3. Server sends login info such as what new port to connect on to client
> 4. Client receives info, connects on again on new assigned port and with login/pass.
> 5. Server/Client are totally online now.

That's about it.  Close enough.  But you should not have to work at
this low level if you are writting a GUI client in tcl.  You just
say "Tmk4_connect" and thats it.  Don'r worry about sockets.

> 6. Client sends configuration file (Mk4d.conf??) to server

The server will read it's config file with no help from a client.
> 7. Server receives, sets up according to file, and sends ack signal to client
> 8. Client is then ready to send commands, schedule, etc.

Commands, yes, but the server is not so smart as to accept a scedule.
That job is to be done on the client side.
> 
> Notice that in #3 that server sends info such as new port to client.  This is to enable multiple clients. (If we want this? could use when one user wants to control camera, and another wants to get data from server and push to local dataset??)

See above.  But that's the idea.  One client would control the camera
an other one would pull, say, engineering data and log it and send
an alarm or e-mail if something is wrong.
> 
> Is this right?
> 
> Aaron Littich
> 
> HotBot - Search smarter.
> http://www.hotbot.com

-- 
   --Chris Albertson             home: chrisja@jps.net        
     Redondo Beach, California   work: calbertson@logicon.com