| Comments |
| 11/20/2009 9:23:25 PM |
Bob Denny |
Confirmed OK now by Farrell and tests by me on BigDome. |
| 11/19/2009 4:20:08 PM |
Bob Denny |
|
| 11/19/2009 4:14:06 PM |
Bob Denny |
I did a cleanup edit of AcquireScheduler::StartSlewToTarget() as part of this. It was needlessly returning a Boolean, and the comments about it were wrong. Change it to a Sub and removed all returns and comments relating to same.
I also removed the issue link to the Dither=1 -> 999 issue, which after all is not related! |
| 11/19/2009 4:09:49 PM |
Bob Denny |
|
| 11/19/2009 3:22:38 PM |
Bob Denny |
This uncovered a general problem with Observations with Repeat Count > 1. The logic attempts to leave tracking turned on for the second and subsequent Observations in the group. The dither slew relies on internal RA/Dec which are the J2000 targets of the last slew. But if, on the second and later Observation, it doesn't slew, then those variables don't get set. See the logic in SUP.TakePicture for unguided dithering, where it uses c_SlewTargetRA/Dec. These variables aren't set if no slew takes place.
I linked an ACP issue to this for fixing in AcquireSupport. The unguided dither will use the current J2000 scope coordinates as a base, eliminating dependence on a previous slew, etc. |
| 11/19/2009 11:39:49 AM |
Bob Denny |
Reopened again! Farrell reports that it is still happening. He is sending an RTML repro scenario. |
| 11/17/2009 11:30:23 AM |
Bob Denny |
|
| 11/17/2009 11:27:25 AM |
Bob Denny |
The Overflow message comes from the Scope Simulator when told to slew for the dither "tiiny slew" after the Scope Sim gets one of those "Wrong Tracking State" errors (from the previous attempt to slew with tracking off). At this point the ScopeSIm is wedged and needs a restart. Separate problem.
The AcquireScheduler problem is solved. |
| 11/17/2009 9:46:09 AM |
Bob Denny |
It wasn't turning tracking on at the start of a run! Rather it was relying on the run-start slew to do that. If the second Observation's target coordinates are identical to those of the first Observation, no slew is done and the run starts with the tracking off. Fixed that... continuing... |
| 11/17/2009 8:47:39 AM |
Bob Denny |
So why is it updating pointing when it's already right on target??? There are multiple problems with this. It's the second Observation, with the identical target coordinates of the previous Observation. Starting observation 2 for plan Dithered Plan
(Obs #2 within tolerance, no slew needed)
Updating pointing...
Switching from Red to Clear filter for pointing exposure
Focus change of 10 steps required
(taking 10 sec. exposure, Clear filter, binning = 2)
Image finished
Plate-solve pointing image.
94 image stars found
505 catalog stars found
Solved! 94 stars matched.
Average residual is 1.23 arcsec.
Pointing error is 0.046 arcmin @ angle 219.02
Image FWHM is 4.9 arcsec (1.51 pixels)
True focal length is 126.0 cm.
True image center (J2000): 12h 59m 59.8s 44° 59' 57.87"
Imager sky position angle is 359.9 deg.
Image FWHM is 4.9 arcsec (1.51 pixels)
(avg FWHM = 4.93 arcsec)
**Pointing update error from ASCOM Scope Simulator:
Wrong tracking state
Imaging to Obs #2-S001-Images #3-R001-Clear
(taking 180 sec. exposure, Clear filter, binning = 1)
(unguided dither, doing small slew)
Start slew to dither...
Overflow
|
| 11/16/2009 9:37:48 PM |
Bob Denny |
John reports that it only happens with dithered images where there are multiple images in an image set and there are multiple Observations, each with image sets having multiple images. |
| 11/6/2009 10:30:55 AM |
Bob Denny |
John reports that it has been fixed in the 3.1 beta. It must have been the RTML 999 error (issue 221) |
