| Comments |
| 6/15/2015 8:01:23 AM |
Bob Denny |
After last problem, this is looking good. Closing. |
| 5/4/2015 7:26:23 PM |
Bob Denny |
|
| 5/4/2015 5:17:47 PM |
Bob Denny |
See this Comm Center thread by Mark Williams. Genuine bug! |
| 4/3/2015 2:51:03 PM |
Bob Denny |
|
| 4/3/2015 10:15:39 AM |
Bob Denny |
|
| 4/2/2015 8:48:32 PM |
Bob Denny |
|
| 4/2/2015 6:37:18 PM |
Bob Denny |
|
| 4/1/2015 5:16:57 PM |
Bob Denny |
|
| 3/30/2015 3:09:17 PM |
Bob Denny |
There were several problems with the startup sequencing. I think I have them fixed now and it will start with the dome closed. Tough crap if the customer's startup script causes the scope to hit the roof. NEED WARNING ABOUT THIS!!! This has been the case all along anyway. |
| 3/30/2015 1:55:24 PM |
Bob Denny |
OK, Mark Williams wants to be able to start up with unsafe weather, then open when the weather is safe, which makes sense. CAUTION FOR DANGEROUS ROOFS!
I see a flaw in the evening tasks still so I need to work on this some more!
Back to In Progress |
| 2/23/2015 12:52:16 PM |
Bob Denny |
|
| 2/23/2015 11:57:06 AM |
Bob Denny |
Ugh, this is really horrible. My whole architecture for keeping stats is now compromised ... we're starting the observatory during dispatching. DAMN IT!!! I can't do this, somehow I need to dispatch without a running observatory. At the moment I need to know how long the scope takes to get on target. What if I return 0? The damn observatory is going to have to start up which will throw everything off anyway. Punt! |
| 2/19/2015 10:47:49 AM |
Bob Denny |
Two problems with Pre-#6.
|
| 2/13/2015 11:27:05 AM |
Bob Denny |
|
| 2/13/2015 11:02:42 AM |
Bob Denny |
|
| 2/13/2015 10:53:28 AM |
Bob Denny |
|
| 2/13/2015 9:01:20 AM |
Bob Denny |
|
| 2/12/2015 1:49:47 PM |
Bob Denny |
|
| 2/12/2015 10:42:08 AM |
Bob Denny |
Decided to refactor weather polling into a common function. This was a mess with the separate poll function and the n the static bool. |
| 2/11/2015 6:50:47 PM |
Bob Denny |
|
| 2/11/2015 11:50:05 AM |
Bob Denny |
|
| 2/11/2015 11:28:37 AM |
Bob Denny |
Damn, found a bunch of Observations with Observation.AcquireNow set. Don't know how it's possible. Prevent this proactively in the future. |
| 2/10/2015 10:51:38 AM |
Bob Denny |
See this Comm Center thread. Need to document the limitations of this feature. The log from Rob is also attached to this ticket. |
| 2/10/2015 10:42:55 AM |
Bob Denny |
|
| 2/9/2015 2:30:05 PM |
Bob Denny |
|
| 2/4/2015 9:44:45 AM |
Bob Denny |
|
| 2/2/2015 4:38:30 PM |
Bob Denny |
|
| 2/2/2015 3:51:20 PM |
Bob Denny |
OK, i think I have it (mostly or all of it maybe) for Pre-Release 5. |
| 1/31/2015 8:38:13 PM |
Bob Denny |
|
| 1/31/2015 8:37:29 PM |
Bob Denny |
Getting there. Major refactoring of the schedule pass and open/close logic (scary). Needs extensive testing. Right now it doesn't look like it closes the dome after a late target after successfully closing it for an early target with > n hours of dead time. There is >n hours dead time after the late target.
Needs testing for periodic AF also. As it is now, the periodic AFs will NOT happen by themselves any more, they will only be done just before an Observation if the AF interval has expired. The idea is to prevent periodic AFs from causing a re-open. Need tests with a full plate as well. Also a test with the late target just before sunrise to make sure it won't close if sunrise is closer than n hours. |
| 11/4/2014 10:23:09 AM |
Bob Denny |
He repeated this in Nov 2014 in this Comm Center thread.
This is related to SCHEDULER-1234 which would allow panel flats and cal frames to be done during this dead time before closing up.
Make this an option so the obs can be kept on standby for targets of opportunity (GRB). |