See this Comm Center thread. Another TRAPPIST request. This will have to be handled in AcquireSupport somehow. The idea is to look to see if the Observation is a follow-up with "immediately after", then check the slew distance needed for the follow-up, and if it is less than the "min distance between pointing updates" to skip the pointing update.

 

  
SVN Comment
 
 

  
Author
  
rbdenny
 
 

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

  
SVN Revision
  
119
 
 

  
Affected files
  
/trunk/AcquireScheduler.vbs (Modified)
/trunk/Help/RelNotes.htm (Modified)

 
 

  
Check-in comment
  
Optimize pointing updated, also honor new ACP 6 "disable aggregation" setting GEM:518
GEM:452

 

Yes, that's it. I've implemented it all in AcquireScheduler, and it is actually pretty simple. Testing is taking a while though.

Ridiculous. The distance to slew is the key, so just measure from the telescope's current coordinates to the destination. No need for all the complexity.

Yes, remember the coordinates of the last pointing update for this plan, compare with the current target coordinates, do the pointing update if it's "too far away" (Prefs.PointingUpdates.MaximumSlew).



The reason for limiting it to this plan is to prevent old stale coordinates from being used. The idea is that this optimization is effective within a plan. But wait! A Plan can have widely spaced Observations (in time) with other Plans' Observations in between. If other plans' observations run, then they will do pointing updates and write out to the cache file, so that's OK. Later Observations for the original plan will not find cache info. But what if you have only one Plan with two Observations spaces 4 hours apart? Even if the equ. coordinates are the same, there's a huge slew to the new horiz. coordinates. Needs more thought -- tomorrow!

Couldn't you just look at the current scope coordinates?