Needed for Scheduler's slew-ahead feature. A slew in progress needs to be allowed to complete across scripts.

 

  
SVN Comment
 
 

  
Author
  
rbdenny
 
 

  
Repository
  
svn+ssh://rbdenny@a2_svn_dc3/home/rbdenny/svn/astro/acp
 
 

  
SVN Revision
  
817
 
 

  
Affected files
  
/trunk/ACP Help/relnotes.htm (Modified)
/trunk/Main.bas (Modified)

 
 

  
Check-in comment
  
Oops forgot to (a) restore the track-off safety timeout to 10 min after testing, and (b) note that slews in progress at script end will now be allowed to continue.
GEM:1325

 

 

  
SVN Comment
 
 

  
Author
  
rbdenny
 
 

  
Repository
  
svn+ssh://rbdenny@a2_svn_dc3/home/rbdenny/svn/astro/acp
 
 

  
SVN Revision
  
816
 
 

  
Affected files
  
/trunk/ACP Help/relnotes.htm (Modified)
/trunk/AcquireSupport.wsc (Modified)
/trunk/CorrectedTelescope.cls (Modified)
/trunk/Main.bas (Modified)
/trunk/Script Components Master/AcquireSupport.wsc (Modified)
/trunk/main.frm (Modified)

 
 

  
Check-in comment
  
Handling of telescope tracking at the end of a script has been completely changed. Tracking is left under manual control at all times unless a script is run in the console. At the end of the script (successful or error) a timer is set for 10 minutes, after which, if nothing else happens, the tracking is shut off. The TRACK light flashes and may be clicked to disable the timer so that tracking will remain on. AcquireSupport already cancels tracking rate offsets on startup. All of the old track rate hacks for quirky telescope driver behavior have been removed. The flashing TRACK light no longer indicates offset tracking in effect.

GEM:1325

 

Yeah! This is a big improvement on several levels.

See ACP-841 - Offset Tracking Fails Due to Test With Tracking Off for the crazy issues that led up to all of this, and how I tried to solve the problem(s). This is one of my few "device dependent" fixes in ACP, and man what a mess. 



This is going to expand into an overhaul of how tracking and rate offsets are managed overall. As a result of variations and quirks in how different mounts deal with rate offsets, there is some partly-sleazy logic in ACP's script cleanup code to kill a slew in progress, reset rate offsets, and leave tracking in the state is was in at script completion (or err0r). Then add to that that there is  logic to kill tracking unconditionally at the end of a script is the script was "run from web". Leaving tracking on is useful when doing engineering work locally from the console.



The logic for killing the track offsets results in TheSky going through some machinations that are nerve wracking, but the AP requires tracking to be unconditionally on to change the offsets (why?? but I gave up on arguing with Bulldog Gralak) so I have to turn on tracking if needed, change the offset(s) then if it wasn't on at script exit, turn it back off. There are time delays in all of this what a mess.



I'm going to let slews in progress continue across script executions. I don't see a risk in this since the slew has been limit checked before started. Since you can't fiddle with tracking and rate offsets while a slew is in progress, I'm going to remove all that shit from the script rundown too. 



The safety catch is going to be on the timer. At the end of any script, a timeout will be started, something like 10 minutes. If the script engine has been idle for that long, tracking will be stopped. Shortly before this, the tracking light will start flashing. If you click the light, it will add another 10 minutes to the lifetime of the safety timer. Each click will add another 10 minutes, and the tooltip will show how much time is remaining. 



It will be up to scripts to cancel any remaining rate offsets when they run, if needed. I am not going to mess with this in ACP itself any more. I will cancel the rate offsets in AcquireSupport.Initialize() when the tracking is turned on. 



Time estimate -> 8 hours