p12mXfThr.c: radec->az,el and 12m control.

    xfThr is the thread that controls the 12meter telescope via ethernet. Once a second it computes ra,dec to az,el and then sends the info to the 12meter. It  takes it's input from an aoQueue. Once a second status info is sent to the logging thread.

    xfThr program flow is:

• started by p12mMain.
  
• xfInitialState(): make sure the telescope is in a known state on startup:
• see if this is the first time through, or a reconnect to 12meter request
• If 1st time. make sure telescope is at least in stop mode.
• initialize some counters
• if not the first time, then reread the status info from 12meter.
• set the following state in the 12meter
• turn off set point offsets
• turn off tracking offset mode
• set coordinate mode to horizon (we send az,el not ra,dec)
• Turn off model corrections (we compute model  offsets in pntmXfThr)
• load 0's into 12meter model correction params (just in case).
• Force dut1 correction to be 0.. (we do the dut1 correction in pntmXfThr, and the send utc times to controller.
  
• on successful exit, set flag saying that we completed startup.
• Loop forever (or until signal)
• If we got a signal, exit loop..return from p12mXfThr
  
• xfTickChk() - see if we should wait for the arrival of 1 sec tick.
• xfSecsTillNextWait().. return true if we are within .1 secs of the next tick (define:(SEC_BEFORE_TICK_TO_WAIT)
• if need to sleep: sleeptilltm() wakeup at next tick
• xfCmpTimes(): load XF_TIME struct with time info for this sec: ast,utc,jd,last..etc
  
• return xfTickChk() true..
• If xtTickChk() returned true
• xfTickProc() do 1 second tick processing.
  
• Compute seconds till next tick
• If close to next tick, go back to top of loop.
• wait for commands on input queue
• getNodeQ(): use timeout that will wake us at .9 secs of this second
• If we got a command on input queue, process it:
• xfProcCmd()
• If command requires a reply, build the reply packet and send it:
• putNodeQ()
• end xfThr infinite loop

• statWd.trValidPnt is set to 0 when p12mProg initializes
  
• If we have a pending coordinate point
• user request tracking points via the command pnt tr c1 c2 -t -cC ....
• these are sent to ioThr and then to xfThr via it's input queue
  
• see if the point becomes active on this sec. If so copy it to the current tracking point struct.
  
• coord points can have a timestamp when they should activate. If no timestamp, they become active when received.
• Set statWd.trValidPnt to true.
  
• This keeps us from tracking a position before we have received any requests.
  
• There is only 1 pending point. If the user sends a 2nd point before the 1st is activated, the 1st is discarded and the 2nd point becomes the pending point (you can't queue more than 1 coord request).
• If statWd.trValidPnt is true: we've received at least 1 tracking request, and it has been activated.
• We convert the coord request to az, el
  
• we do this twice: once for this 2nd and once for the next second
• we need a velocity for ramp mode.
• xfCmpTimes(): compute times for the timestamp sent in. Load xf_time struct
• jd, asttime, utc time, dut1frac, lmst,last (local mean/apparent siderial time)
• xfConvert(): converts astronomical pos,times,offsets, rates to az,el, timestamp
• xfDoOffsets(): add on model and any great circle offsets (pnt dbg gc azOff elOff).
• Keep track of cumulative offsets (if -r rate was included)
• Compute the az,el velocities for the 1 second step (needed for ramp mode)
  
• store the requested az,el,tm,in the azelBuf[20]. This holds the requested points. Will be used later to compute the pointing error.
• p12mdTrLdRamp(): load ramp data into controller.
• The ramp will take affect when it is received, so we don't want to be too far after the tick..
• If we are a little late (millisec) it will just use be using the velocity from the previous sec.. So the error in the acceleration  over 1 sec.
• Note that we do this conversion as long as we have an active tracking point.. whether or not we are in tracking mode.
• xfReadP12mStat(): Read the status blocks from the 12m controller using group read.
• The status will be time stamped by the 12m controller for when the data was grabbed (4ms cycle).
• Typically this take 20 ms for the read.
  
• Compute the current telescope state from the status block (off, standby, stop,track mode).
• Below here is the non time critical portion of the 1sec tick routine.
• if statWd.trValidPnt is true (we have a valid tracking point)
• back convert ra,dec J2000 from the az,el read back from the controller
• Compute the tracking error:
• Interpolate the requested position to the timestamp of the data read back by xfReadP12mStat()
• We store a history of the requested positions i azelBuf[]. this is searched to get the current req.
• This was needed for trackArray mode. Ramp mode probably doesn't need azelBuf...
  
• We store the last used in pxfI-azelLast
• See if we are in the process of changing states:
• statWd.stChangeReq  keeps track of state req changes
• This routine sometimes needs to change state (stop telescope when re initializing..etc).
• This can take many seconds for the controller to change state (stop telescope,etc). stChangeReq keeps track of this.
• When changing states, you need to transition to the next closest state:
• eg: moving, not moving, breaks on, power of...
• Send info for this second to the logThr
• return from xfTickProc()

xfProcCmd: Process a command request from IoThr

p12mLogThr.c: logging thread

p12mIoThr.c: handle I/O for external requests

<- page up
 home_~phil