David's Astronomy - Notes 2019-09-26 (S00700)

Session 700 used a new version of AstroMain which contains a number of new processes/routine, and it useful to document the changes.

The overall aim is increase the independance of different parts of the program and reduce chnaces that a problem in one part of the program causes another part to freeze.

Obs. Overseer is a new Threaded Process loop under the umbrella of the Manager Object that is initiated and stopped at the same time as the Obs.Manager. It's purpose is to provide high level monitoring of Obs.Manager and Job Queue. and specifically to recognise and log when the Observatory Manager freezes. The process also used to action specific tasks (some formerly actioned within the Observatory Manager loop, others are new) either calling routines directly to perform the tasks or via the setting of flags to trigger tasks managed by a further threaded process loop called Obs.Worker.

At the moment it actions the following
- WriteLiveHeaderJs. This outputs of 'System.Header.js' file that describes the Session to Javascipt running in the Current Session Webpage
- bCaptureObsManagerTab & . This flag triggers the collection of screen-captures of the Obs.Manager tab and the
- bCaptureSkyConditionsTab. This flag trggers the collection of a screen capture of the Sky Condition tabs
- bUpdateSynopsisFields. This flag triggers the writing of various Observatory,Weather and Envirnonment data
- WriteLatestLiveLogs. This generates Session.latest (run).log & Session.latest (report).htm containing the more recent log/report messages
- SendObsStatusToFile() . This generate a small file to pass key information to AstroGuard
- CreateObsManagerChart. Placeholder for code to draw a suitably designed chart with Obs.Manager and other data,

- Checks status of Job Queue by looking a IamALive Queue / messages for potential overruns during Job Queue execution.
- Checks status of Observatory Manager
- Check status of UI

Obs.Worker is a new threaded Process loop under the umbrella of the Manager Object and like the Obs.Overseer thread is initiated and stopped at the same time as the Obs.Manager. It's purpose is to perform listen to flag settings ad perofrm specific tasks (some formerly actioned within the Observatory Manager loop, others are new) either calling routines directly to perform the tasks or via the setting of flags to trigger tasks managed by a further threaded process loop called Obs.Worker.

- bCaptureObsManagerTab & . Calls objConsole.RunCaptureObsMangerTab() & objConsole.RunCaptureServicesPanel()
to capture specific tabs/panels in AstroMain for uploading to website
- bCaptureSkyConditionsTab. Calls objConsole.RunCaptureSkyConditionsTab to capture views of the Sky Condition tabs
- bUpdateSynopsisFields. Calls objConsole.UpdateSynopsisFields

ReportQueueManager is a new thread Process loop that continuously looks for new items in the qReport queue and write them to the txtLogBox console.
Items are added to the queue in ReportComment, AddComment routines etc by the command qReport.Enqueue('string to be written')
and then in the queue manager if qReport.Count > 0 then AppendTextBox(qReport.Dequeue)

Observations
a) The Obs.Manager freezes during the following operations
- Connecting Scope / Telescope (5s)
- Set Tracking Off (5s)
- Parking Dome (36s +)
- Parking Telescope (39s +)
- Closing Down Cameta (30s +)
b) The UI stops responding for around 5s -10s at a time on 3 occasions during 'Start Services')

After creating a new session, setting the Observatory to Fully Automated Mode, and seeing an Observing Plan created and loaded the Observatory Manager proceeded to close down the observatory and finish the session, 5 secs after starting to open the Shutter.

After entering the Equilibrating State at 22:21 and commanding the shutter to open, the Observatory Manague issued a "Critical Light " and 'Critical Sun Alt Alerts. SunAlt was reported to be of -0.8. and this would have automatically triggered the Critcial Light Alert regardlesss of the light meter reading since a sun alt value of -0.8 might indicate approaching Dawn). The actual sun altitude at the time was -26 deg. After restarting the Software and unparking the telescope (by power-cycling the scope using the UPB PowerBox Program), the session was successfully re-started.

During the original session creation , the plan generation happened pretty fast (just 27s, due to code/target improvements) .

The Observatory Manager was started at 20:18. During initialisation of the main Observatory Loop the Sun Alt is obtained from TheSky6 (This should have been the correct number of -25.7 deg if TheSky6 was using the Computer Clock which it nornally does when it starts up) and LastSunAlt is set to vcNull. Within the Main Loop, a new Sun Alt value is fetched every 30s. For first minute or so whilst the Observatory was in Manual mode, the Sun Alt is obtained from Synopsis.SunAlt provided that the published Synopsis time is < 2 minutes old. After moving to Fully-Automated Mode, at 20:20 Sun Alt is obtained from TheSky6 (unless Observatory State is 'Running') . LastSunAlt is set to SunAlt at the end of code section, ready for the next cycle of the loop. It would seem SunAlt was read as ~ -25.7 at some stage (and copied to LastSunAlt) before taking on the value of -0.8 before the next cycle, since at 22:21 the Obs Manager produced the message. "Sun has reached SunAlt of -2 degs" which is produced by the condition 'If LastSunAlt < -2 And SunAlt >= -2 Then'.

So why did SunAlt take on the value -0.8 ? The most probable explanation is that Sun Alt was read from TheSky during a moment that AstroPlan Schedule Builder had set TheSky6 time to either near sunset or near sunrise in order to collect Sun/Moon data for the night. Because the Schedule Building was very quick there was no time for Obs. Manager to get a 'new' correct Sun Lat before the Shutter was opened at which point the SunAlt Alert was triggered lead to closin the shutter and shutting down the Observatory.

When the AstroMain program was restarted the original V1 plan was loaded directly without the steps manipulating the time/date in TheSky6, and hence the issue wasn't seen the second time around.

Issue was fixed 2019-09-27 (AstroMain 3.12.3) by modifying code to get a fresh SunAlt value from TheSky6 after loading the Observing Plan and before moving to 'Starting' State.


	Session Aims & Highlights
	- Observing Result - Night Summary Plot - Session Event Log

	Operational Issues
	- Critical Issues (0), Major Issues (0), Minor Issues (7), Continuous Improvement (7)

	ObsOverseer, ObsWorker and other new Processes (AstroMain)
	Investigation - Invalid Sun Altitude at session start

	Images from 2019-09-26 >>

This Web Page:	Notes - Session 700 (2019-09-26)
Last Updated :	2024-10-09
Site Owner :	David Richards
Home Page :	David's Astronomy Web Site

David's Astronomy Pages
Notes - Session 700 (2019-09-26)

Session Aims & Highlights (2019-09-26)

Operational Issues (2019-09-26, S700)

Obs.Overseer, Obs.Worker and other new Processes (AstroMain)

Investigation - Invalid Sun Altitude at session start

David's Astronomy Pages Notes - Session 700 (2019-09-26)

Session Aims & Highlights (2019-09-26)

Operational Issues (2019-09-26, S700)

Obs.Overseer, Obs.Worker and other new Processes (AstroMain)

Investigation - Invalid Sun Altitude at session start

David's Astronomy Pages
Notes - Session 700 (2019-09-26)