RE: Observational session control

[Tom Droege <tdroege2@earthlink.net>]

Rob,

Don't try to do too much.  Just design a framework that will allow doing 
anything.  The goal is to just take a couple of images from Linux using 
your program before you come and get ROB.  If you do it in perl, I will now 
be able to follow your code.

I think the big part will be getting the code you have already written for 
me to run under Linux.  Then just enough control to take a couple of 
images.  Then you can have ROB and start adding things to your control 
program as you see that you want to use them.

Tom

At 10:12 PM 3/22/02 -0700, you wrote:

> >
> > A few comments
> >
> > 1) XML is a program to program interface.  Human's should never
> > have to read/write it.  Use XML is you like but you don't need
> > to tell us that you are
>
>Good point.  I'll distil what RTML provides into a human form and post 
>that.  Then, if
>anyone wants to provide remote observation capabilities, they can use RTML 
>without
>modifying the compiler/scheduler.  The XML would be converted into code 
>for the
>compiler.
>
> >
> > 2) The one example of an active Mk IV user we have to go by (Tom)
> > does not use the "target list model" to control his system.  He
> > uses a simple algorithum that defines a scan sequence.  This
> > is actually the best use of the system in terms of photons
> > per hour
>
>Tom gave me his requirements of:
>1) take dark
>2) take bias
>3) scan the sky.   This is a mode where the maximum amount of sky is
>covered as long as it runs.
>4) follow.  Follow a field as long as possible.  Next available field, or
>wait for some RA to be available, meanwhile do "scan the sky"
>5) scan the sky preferring these fields if available f f f
>6) get fields from this table if possible.  Meanwhile "scan the sky"
>7) unpark at delay after dusk (program should compute dawn and dusk from
>data and latitude
>8) park at delay before dawn
>
> >
> > Whatever the input to the scheduler looks like it had better allow
> > a user to specify a loop and relative movement.
>
>Hmmm.  I see what you are getting at, but I don't see the need just 
>yet.  I have not
>thought about this enough, but it seems like this can be handled without 
>getting that
>complex.  Regardless, if folks don't mind using Perl, they use whatever Perl
>language features they like in specifying the target.  I don't know TCL, 
>which is why I
>say Perl...  I would imagine that TCL is doing something like Perl's <eval>.
>
> >
> > You could make the "targt" a very large patch of sky and have the
> > program design the best scan pattern.
>
>Very good idea.
>
> >
> > It might be good to first compile a list of requirements:
>
>I'm trying, but Tom is the only one talking.  Maybe everyone else is just 
>waiting to see
>what happens?
>
> >
> > Some people are wanting to do a scan pattern but jump over the
> > specif fields as they get near.
>
>Why?  Because of crowing?  Something else?
>
> >
> > What about overlapping operations?  For example doing a dark
> > frame while the mount moves?
>
>Well, if there was a means of specifying how many dark's and bias's were 
>desired for
>the night, then these could be scheduled during moves, or at other times,
>automatically.  At 32x sidereal rate, we have 7.5 seconds per degree 
>(right?), which
>doesn't allow long dark/bias exposures just during moves.  But more 
>observing time
>will be gained if some of the dark/bias time is during the moves, rather 
>than not using
>the moves.
>
> >
> > How many people would really use the target list model?  I don't
> > think most will use that as the primary method
> > That's what drove me to think a programing language was required.
>
>Dunno.  But relatively easy to do.