David's Astronomy Pages Notes - Session 1019 (2022-06-12)

Notes (S1018)

Notes Main

Home Page

Notes (S1020A)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (1),  Major Issues (0),  Minor Issues (4),  Small Defects (7),  Continuous Improvement (9),  Issues - Daytime testing (13)
	Images from 2022-06-12 >>         [ Local Files >> ]
	2022-06-16
	Observatory Computer - Inaccssible Boot Device
	2022-06-21
	Observatory Computer - Windows 10 Reinstall & Rebuild
	2022-06-23
	Observatory Computer - Device Setup / Daytime Testing
	Issues - Daytime testing of rebuilt Observatory Computer (13)

Session Aims & Highlights (2022-06-12)

Main aims

1. DeviceHub. Check out new 6.6.0.11 version of Device Hub.  Ensure that new version is operating without any new issues. Check for the absence of any anomalous dome slews (of the type that impact slew to SS Cyg in S1014 (2022-05-31)
2. AstroMain. Check out new 3.51.16 version of AstroMain. Ensure that new version hasn't introduced any new issues and that fixes and improvements are working as per design.  In particular check slaved dome slewing behaviour and Obs.Monitor behaviour where code has made significant chnages.
3. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by time & twilight conditions.

 Equipment & Software

• 12" LX200 and ST-10XME
• 80mm APO and ZWO ASI 178MC
• CCDApp2, TheSky6, CCDSoft5, DeviceHub 6.6.0.11,  MeadeGeneric 1.3.5.414, UPB 1.5, ASCOM 6.6
• Pegasus UPB & Motor Focus, TCF-S
• SharpCap 3.2, PHD2  2.6.10
   
• AstroMain 3.51.16,  AstroPlan 1.30.8,   AstroShCap 1.3.12, AstroGuard 1.8.1
  AstroVOE 1.10  AstroSN 1.8.2,  AstroProtect 1.7,  AstroMove 1.9.1
  (AstroWeather 1.17, AstroAllSky 3.16,  AstroObsCam 1.9, AstroLaunch 1.9.1)

Highlights

•  DeviceHub.  Device Hub 6.6.0.11 operated without any issues or problems
•  AstroMain. AstroMain 3.51.16 operated without any new issues or problems
•  Targets. 7 targets were successfully acquired.
•  Start Time.  First target started 13 minutes later than expected. 

Notes:

• Summer Twilight . Twilight conditions for session (Sun Alt -9.5° at local midnight)
  

  Summary Plots & Logs

Observing Plan

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance

Guiding Performance Black Point (7) : Guiding badly affected by cloud

Sky Conditions (Locate Frames)

Night Sky Summary Plot Top axis: Sky Brightness at Zenith (in ADU/s) Lefthand axis: Local Time (hh LT). Righthand axis: Sun Altitude (degs)

Actual Weather vs Pre-Session Weather Forecast

Session Event Log

Time     Event Detail 20:01:29 Session Monitoring AutoStart monitoring for Live Session opportunity between 23:37 & 01:27 20:01:33   AutoStart Waiting AutoStart waiting till earliest start time at 23:37 23:41:50 Session AutoStarting Session autostarting (23:41) 23:42:31   Camera1 Connected SBIG Camera Connected (set point -15°C) 23:42:33 Session Created Live Session Created (2022-06-12 S01019, ImageSaveNum: 1019001) 23:42:35   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 23:44:15   Services Started Observatory Services started 23:44:22 Observatory (Auto) Observatory placed in Fully-Automated Mode 23:44:25 Session Pending Session pending (2022-06-12) 23:44:27 Session Initiating Session initiating (2022-06-12) 23:44:29   Plan Requested Observing Plan requested from AstroPlan (1.30.8) 23:45:12   Plan Loaded Observing Plan loaded to queue (Plan ID: 779) 23:45:27   Camera1 Connected SBIG Camera Connected (set point -15°C) 23:45:32   Telescope Connected Telescope Connected (TheSky6) 23:45:56 Session Equilibration Session ready for dome & camera equilibration 00:01:58   Dome Opened Dome opened (opening time 45s) 00:02:14   Equilibration Started Dome Equilibration started 00:07:14   Equilibration Ended Dome Equilibration ended (5.0 mins total) 00:07:16 Session Running Session running 00:07:18   Queue Started Observing Queue started (8 targets selected) 00:07:20     Target Started (NrZen) Target started (Focus Field 16, HIP 78946) 00:09:38       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:12:35       Focusing Completed Foc1 AutoFocus Completed (Profile No 1, wide) 00:14:33       Focusing Completed Foc1 AutoFocus Completed (Profile No 1) 00:14:35       Focusing Started-Foc2 Foc2 Focusing Started (Secondary Scope, using ShCap) 00:16:47       Focusing Completed Foc2 AutoFocus Completed (Profile No 2, wide) 00:18:34       Focusing Completed Foc2 AutoFocus Completed (Profile No 2) 00:18:51     Target Completed Target completed (Focus Field 16, HIP 78946) 00:20:38     Target Started (1/8) Target started (1/8, GCVS U Her) 00:23:28       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:25:29       Focusing Completed Foc1 AutoFocus Completed (Profile No 3) 00:33:50     Target Completed Target completed (1/8, GCVS U Her) 00:33:54     Target Started (2/8) Target started (2/8, HIP 87937) 00:36:50       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:39:01       Focusing Completed Foc1 AutoFocus Completed (Profile No 4) 00:41:44     Target Completed Target completed (2/8, HIP 87937) 00:41:48     Target Started (3/8) Target started (3/8, 61 Cyg) 00:44:40       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:46:41       Focusing Completed Foc1 AutoFocus Completed (Profile No 5) 00:48:39     Target Completed Target completed (3/8, 61 Cyg) 00:48:43     Target Started (4/8) Target started (4/8, GCVS SS Cyg) 00:51:29       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:53:41       Focusing Completed Foc1 AutoFocus Completed (Profile No 6) 00:59:03     Target Completed Target completed (4/8, GCVS SS Cyg) 01:04:13     Target Started (5/8) Target started (5/8, GCVS R CrB) 01:07:48       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:09:44       Focusing Completed Foc1 AutoFocus Completed (Profile No 7) 01:13:03     Target Completed Target completed (5/8, GCVS R CrB) 01:13:30     Target Started (6/8) Target started (6/8, GCVS AM Her) 01:16:39       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:18:51       Focusing Completed Foc1 AutoFocus Completed (Profile No 8) 01:24:10     Target Completed Target completed (6/8, GCVS AM Her) 01:24:47     Target Started (7/8) Target started (7/8, Vega) 01:27:39     Target Completed Target completed (7/8, Vega) 01:31:38     Target Started (8/8) Target started (8/8, GCVS CY Lyr) 01:34:33       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:37:04       Focusing Completed Foc1 AutoFocus Completed (Profile No 9) 01:39:59   SoftSuspend Called Soft Suspend is called due to Deteriorating Conditions (reducing clarity) 01:40:01 Critical Cloud Alert Critical Cloud Alert (Obs.Manager will close the Dome) 01:40:03   HardSuspend Called Hard Suspend is called due to Critical Conditions (cloud) 01:40:05     Target Aborted (8/8) Target aborted (8/8, GCVS CY Lyr) due to cloud 01:40:07   Queue Paused Queue paused for Session Suspension 01:40:09 Session Suspended Session suspended 01:40:54   Dome Closed Dome closed (closing time 50s) 01:50:40     Target Cancelled Target cancelled (8/8, GCVS CY Lyr) due to cloud 01:50:45   Queue Completed Job Queue completed 01:50:51 Session Closing Session closing 01:50:56   Dome Closed Dome already closed (closed at 01:40, closing time 50s) 01:51:41   Dome Parked Dome parked (parking time 37s), Az: 90.0 deg 01:52:58   Telescope Parked Telescope parked (parking time 71s) 01:53:13   Telescope State Scope parked Turn scope off. (Handbox) 01:53:35   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 01:54:28   Services Stopped Night Services stopped 01:54:30 Session Housekeeping Housekeeping Started (Cleanup FITS, Create Fits Summary, Transfer Files) 01:54:36 Session Finished Session Finished

Session Alerts

Time     Alert Detail -- No Alerts                --

Back to Top

Operational Issues (2022-06-12, S1019)

• Critical Issues (1)
• Major Issues (0)
• Minor Issues (4)
• Small Defects (7)
• Continuous Improvement (9)
   
  
• Issues - Daytime testing of rebuilt Observatory Computer (13)

[ Prev | Next ]

Critical Issues

• Observatory Computer, won't boot up,  BSOD screen appears with message "Boot Device Inaccessible" (post-session). On 2022-06-16 following installation of windows update (some time after 22:14) the observatory computer failed to boot to windows and produce a BSOD with error 'boot device inaccessible. All attempting to resolve/fix the issue in Windows Recovery Environment failed, and computer/sobservatory were still down as at 2022-06-19 (See Observatory Computer - Boot Device Inaccessible).  Issue eventually resolved by a complete reinstall of Windows 10 on 2022-06-21 following by two days of setup and testing.
  Resolved 2022-06-21 (Observatory Computer)

Major Issues

• None

Minor Issues

• Targets commenced 13 minutes later than expected (00:20 instead of 00:07).  When inititating Autostart at 20:00 (with start of AutoStart Window specified as SunAlt -8.5° minus 30 mins) the AutoStart Reference was reported as being 2022-06-13 00:07 (Local, Sun Altitude -8.5°) with an earliest window start at 23:37 (30 minutes beforehand).  The calculated reference time (00:07) is confirmed as being correct based on a -8.5 deg sun altitude in TheSky6's Virtual Sky at the time, and based on 5 minutes of initial initiation & starting (create New Session  (2 min), start Night Time Services (2 min), create/load Observing Plan (1 min) ) and 23.4 minutes of pre-queue activity  the 'minus 30 mins' adjustment seems adequate.  In the event Autostart Monitoring reported at 23:37 that it was 'waiting for fresh shutter communications' and autostart became delayed 4 minutes until fresh shutter data was received at 23:41.  The creation of Observing Plan was begun at 23:44:27, with a specified pre-queue activity of 23.4 mins.  This should have produced a plan starting at 00:07:53, however the plan was created with a start time of 00:25 (corresponding to SunAlt -9.0°).  Session Equilibration was entered at 23:45:54 at which point the Expected Dome Opening was stated to be 00:04, with Expected Run Start at 00:07,   Expected Queue Start at 00:23, referenced to Planned Queue Start at 00:25.  In the event operations  waited for 15 minutes until 00:01 when the dome was opened and after 5 minutes of (discretionary) equilibration time the session began running at 00:07 (on-time vs Plan), with queue start (1st target) beginning at 00:20 (5 minutes early vs Plan, but 13 minutes later than the original anticipated start of 00:07). It would seem that the problem is due to AstroPlan not setting the expected start time.    'StartingMins' and 'Plan Time' (Best Plan) are supplied to AstroPlan via the 'CreatePlanFlag.dat' file.  'Starting SunAlt' is not currently supplied and is instead supplied by AutoSelectStartAlt() routine in AstroPlan.   For the night in question (2022-06-12) where the minimum sun altitude was -9.5°, this gives Valid12 (boolean) = False leading to StartAlt of -9.0.   In the shorterm problem resolved by adding a setting condition in AutoSelectStartAlt() routine such that where Valid10 (boolean) = False it leads to StartAlt of -8.5.   [Note : A later fix could look into sending StartSunAlt from AstroMain to AstroPlan ].
  Fixed 2022-06-13 (AstroPlan 1.30.9)
   
  Post Session (3)
   
• Unable to run AutoBuild or Build button function for an imageset from 2017 Session (Analysis/ImageSets).  Whilst trying to create a log scaled image picture for NGC 6886 (Ast.Now Deep Sky Challenge Object , Jul 2022) it was found that neither AutoBuild or Build functions could be used to create a base picture or open it in the ImageBuilder tool  (ImageSets/Images tab).  'Base Name', 'ID' & 'Store' fields noticed to be all blank. as were the Target fields on ImageSets/Targets tab (this is due to FIT having being captured before Target ID's were introduced).  Image couldn't be created because the Image set because 'Store' and 'Base Name' were blank.   Base name was blank as 'NGC_6886 3x3 30s C' image set had just 1 FIT image , and the 'Aligned' folder wasn't used for creating a main FIT file.   Copying the FIT file from Reduced folder to the Aligned folder, allowed the Base Name to show the appropriate name 'NGC_6886.20171102.im603085.30s.C'.   Copying target name 'NGC 6886' to the 'Store' field then allowed AutoBuild function to work ok, creating 'NGC_6886.20171102.im603085.30s.C.logscale.png' and allow ImageBuilder to be opened.
  Resolved with manual workaround 2022-06-18 (AstroMain)
   
• Store Field isn't automatically filled in for an imageset from 2017 Session (Analysis/ImageSets).  Whilst trying to create a log scaled image picture for NGC 6886 (Ast.Now Deep Sky Challenge Object , Jul 2022) it was found that 'Store' field was blank, whilst it should be automatically completed when selecting the imageset.  FIT Image was captured before Target ID's were introduced, but unclear if this is relevent to Store Field.  Issue fixed by modification to GetObjectTargetDetails() so that exception to Image.FitsKeyword("TARGETID") is immediately caught allowing the code to execute a call to the SetStoreFolderName() routine (previously the exception was going to an outer try-catch-end try block, which skipped over the setting of Store Folder Name
  Fixed  2022-06-18 (AstroMain 3.51.17)
   
• Crosshairs XY & Center XY field values are not filled with valid/correct values when ImageLinking an image from 2017 Session (Analysis/ImageSets) .  Whilst trying to link image for NGC 6886 (Ast.Now Deep Sky Challenge Object , Jul 2022) it was found Crosshairs X/Y & Center X/Y are filled with -252702.8/55483.7.  The FIT Image is one that was captured before Target ID's were introduced. It is hypothesized that without a Target ID,  .Ra2000 & .Dec2000 still has initialised values of 0.0 and X/Y field show X/Y distance from Ra 0, Dec 0. In the absence of a TargetID (or without a valid TargetID), Ra/Dec should be obtained by looking up Object Name in TheSky6.  LocateInfo.ObjectX/Y and LocateInfo.nX/nY have to be set as UpdateLocateInfo_Test(ObjTargetT)  isn't called and are needed by InsertObjCrossHairsData() routine.
  Fixed  2022-06-18  (AstroMain 3.51.17)

Small Defects

• Dome slewing hold-up falsely reported for slew to CY Lyr (01:31).  A dome slewing hold up of 29s (Az 154.3) was written to the Report file and  SlewTable for the slew to Target 8/8 (GCVS CY Lyr).  However this was a short telescope slew and in the event didn't require a movement in the dome, (ie dome slew was 0.0 deg).  The slew angle (0.0) and dome slew time (0s) were handled and reported appropriately, but because of 30s time out waiting in case the dome did move, the new code for detecting dome slew hold-ups falsely identified a hold-up of 29s.
  Fixed 2022-06-13 (AstroMain 3.51.17)
   
• Overall slew time for slew to CY Lyr was incorrect (01:31).  An Overall Slew Time of 30s was written to the Report file and SlewTable for the slew to Target 8/8 (GCVS CY Lyr).  However this was a short telescope slew (21s) and in the event didn't require a movement in the dome, (ie dome slew was 0.0 deg).  Whilst the dome slew time (0s) is reported appropriately, but because of 30s time out waiting in case the dome did move,  code for determining overall slew time determined a time of 30s (max ( 21,30) ) rather than 21s (max (21,0).
  Fixed 2022-06-13 (AstroMain 3.51.17)
   
• Numbers reported for Sky Photometrics sometimes contains commas  (',') . Commas should be removed from double type numbers so that
  "Av Variation 2,007(Peak 105, C 1,088.8, RMS 20.1)" should be written like "Av Variation 2007 (Peak 105, C 1088.8, RMS 20.1)" .
  Fixed 2022-06-13  2022-06-13 (AstroMain 3.51.17)
   
• Use TAG-RA, TAG-DEC coordinates when performing post-session Image Linking & Image Analysis of Comets. Whilst performing a backlog analysis of images from session S882 (taken 2021-04-11 but analysed 14 months later on 2022-06-14) the position of comet C/2020 T2 (Palomar) calculated in TheSky6 & drawn in ImageBuilder tool was noted to be around 4' away from the comet's actual position in the stacked image.  Investigations (see details) determined that the currently loaded Comet.cmt file (downloaded 2022-06-09) being incorrectly backpredicting the 2021-04-11 position of the comet due to a small change in the orbit of the comet as it passed through the inner solar system.  Although the original Comets.cmt used in Apr 2021 is no longer accessible (so future TheSky6 image links will still always show the comet in incorrect position for the original date/time) , the J2000 coordinates originally predicted for the comet in Apr 2021 are nevertheless still available in the FITS Image file header under the keywords TAG-RA and TAG-DEC.   Post-session Image Analysis should be changed to utilise the TAG-RA & TAG-DEC (where available).  Whilst trying to implement this improvement it was found that code already makes use of TAG-RA & TAG-DEC coordinates, but a following call to UpdateLocateInfo_Test(T As classT)  routine (which was added 2022-02-07) overwrites the LocateInfo coords with object coordinates from T.Ra2000, T.Dec2000 which have been extracted from TheSky6.  GetObjectTargetDetails(),  which is called first, has been modified to assign T.Ra2000 & T.Dec2000 from TAG-RA & TAG-DEC for non-sidereal objects (like comets) in preference to used coordinates derived from TheSky6.
  Fixed 2022-06-14 (AstroMain 3.51.17) 
   
• 'Last Session' value shown on AstroMain/Analysis/ImageSets is incorrect when the Target has images held in the Store Folder from session S10 to S99 (post session analysis). Whilst performing a backlog analysis of NGC 4281 images from session S883 the last session from reported to be S861 but no images of NGC 4281 were located on the S861 Session Images page.  Opening the 'NGC 4281' Store Folder revealed that there images from two  previous sessions:  S771 (im771044-48) &  S86 (im86162).   Code for extracting the last session folder in 'FindLastStoreSession()' routine has failed to correctly identify the session number from the image file "NGC_4281.20050513.im86162.120s.Clear.gif' extracting 861 instead of 86.  Because 861 is more recent than 771 the routine returned S861 as being the last session instead of S771.
  Fixed 2022-06-15 (AstroMain 3.51.17) 
   
• Cloud Sensor alert being issued with an exceptionally large outage time (2022-06-24). A red alert at 2022-06-24 21:12:16 reporting "Cloud Sensor data has been inactive for more than 5 mins"  was followed 4s later by a green alert reporting "Cloud sensor data is active again (outage 1,063,195,032.3 mins)" suggests that this is a start-up monitoring artefact in some way as CloudSensor service/listening loop only began at 21:12:08.59 . The large outage value  comes from comparing current date/ time against a vcNullDate value, rather than a date of actual last data.  LastDataTime should probably be assigned as the start monitoring time and not left as vcNullDate in order to get an accurate outage time.  Should LastDataTime get through with a value of vcNullDate the outage time should probably be reported as unknown, rather than a very large number of minutes since an arbitary 'null' value date.   CloudSensorData.DateX is currently set to vcNullDate by GetNullCloudSensorRecord() routine which is called only when ParseCloudSensorRecord() routine encounters an exception.  Alerting code changed in AstroMain 3.52 to use CloudSensorData.LastCloudSensorTime instead of CloudSensorData.DateX (with .LastCloudSensorTime set to Now() when CloudSensor monitor begins to run. A similar issue might affect Synopsis/Scorcard and Weather Station data). Note the solution employed here may not work across Daylight Savings Time (DST) changes. 
  Fixed 2022-06-26 (AstroMain 3.52) 
   
• Left hand (wide view) RainViewer Radar map on Current Weather webpage is not correctly centered on the observatory region. Lat/Long values in API call have been fixed
  Fixed 2022-06-26 (Website)

• Add the user requested URL to the messages for '404 Error - File Not Found'.  Come up with a way of extracting the requested URL for a '404 Error' and add the URL path to the message written by the 404.html file.  (Note: this is a '404.html' and not '404.shtml').  Implemented using
     <script type="text/javascript">document.write(window.location.href)</script>
  Done 2022-06-13 (Website)
   
• Add Current Temperature/Current Wind to top section of Current Weather web page.  Data boxes added with <a hef=> links to bookmark with relevant 8hr graph.
  Done 2022-06-13 (Website)
   
• Change background colour,  text size and text position of Graph data boxes created by AstroWeather so they match those produced by Virtual Weather Station (VMS). Graphs of .ChartType=2 to use background colour of Color.Silver,  Font10 (title), Font15 (data), y=3 (title), y=27 (data)
  Done 2022-06-13 (AstroWeather 1.17.1)
   
• Write 'Graph Completed' to  Message field when Test Graphs are completed. It will be helpful to definitively know that the test charts routine has completed, when testing. 
  Done 2022-06-13 (AstroWeather 1.17.1)
   
• Relocate Slow Dome indicator (D*) on AstroMain's slewtable.  The recent addition of Dome Holdup columns to the slew table has caused it to become widened by 20 characters.  Relocating the D* indicator will have the benefit of reduceing the width of the table by 5 characters to compensate in part.
  Done 2022-06-13 (AstroMain 3.51.17)
   
• Sun Altitude should be written to Job Queue's "Conditions" Section.  SunAlt is calculated via the GetSunAltNow() function without reference to TheSky6. 
  Done 2022-06-13  (AstroMain 3.51.17)
   
• Adjust position of AstroMain's ObsConsole window so that it doesn't overlap with the ObsViewer window when operating in Observatory Mode. Position set using objConsole.Location = New Point(723, 149) .
  Done 2022-06-13  (AstroMain 3.51.17)
   
• Display an Error Dialog if Store or Base Name fields are blank when AutoBuild or Build functions are attempted (Analysis/ImageSets). These functions can't work when Store and/or Base Name fields are blank so it would be helpful to explain to user what prevents the operation from proceeding.
  Done 2022-06-18  (AstroMain 3.51.17)
   
• Query.  What does the 'Max Pulse Guide' field on the Observatory/More/Cam1 tab do ?  The 'Max Pulse Guide' field (txtMaxPulseGuideJog) has a current value of 5 (arc mins) on the Observatory Computer. Does this limit centering jogs at all ? .  txtMaxPulseGuideJog.text value is currently set to 5 in the form design, but can be manually changed for a session, but the setting is not saved to a future session. The Max Pulse Guide value is assigned to local variable 'MaxPulseGuideJog' in Scope.Jog() routine (which is called from PlateSolver.ApplyJogs() / PlateSolver.MakeCorrectiveJog routines  ), where it is used as a threshold for setting JogMode (either 'Slew' or 'Pulse')  which determines whether Telescope.Jog(dAmount, szDirection) is used (dAmount > MaxPulseGuideJog (norminally 5) ))  or by JogUsingPulseGuide(GetGuideDirection(szDirection), dAmount). Using Jog vs PulseGuide is a trade off (jog is faster, but lis ess accurate). With the removal of PulseGuide limit in MeadeGeneric 1.3.4.410 (installed 15 May 2022), it is appropriate to raise the design value from 5 arc mins to a new value of 10 arc mins. (at x0.90 guide speed this would be a 45s pulse guide).  This change has been implemented in AstroMain 3.52.
  Done  2022-06-24  (AstroMain 3.52)

Issues - Daytime testing of rebuilt Observatory Computer (2022-06-22 & 2022-06-23)

• TheSky6 produces 'Windows Theme Settings' error message when Connecting to Telescope.  When 'Connect Telescope' button is clicked Windows 10's Personalise Settings window is opened and TheSky6 puts up a modal dialog with the error message "The Windows Theme Settings (Vista) or Display Properties (XP) dialog is open and has been closed. Click View > Night Vision Mode again to successfully enter Night Vision Mode.   Error Code = 250 ".  User has to dismiss the dialog before TheSky6's GUI can be manipulated.   The same problem occurs when the 'Night Vision Mode' button is clicked.  Fixed by disabling the 'Switch to Night Vision Mode upon link' option in Telescope Setup.
  Fixed 2022-06-22 (TheSky6 Telescope Setup)
   
• Pegasus Astro ASCOM Powerbox Switch puts up a "Lost connection to powerbox'  after selecting an Observatory Session in AstroMain.   When 'Create Test Session' or 'Continue' test session is clicked a ASCOM Powerbox Switch puts up a modal dialog with the error message "Lost connection to powerbox " and a red flag appears against 'Powerbox' on the Observatory tab.  When Observatory Session is started/resumed ASCOM Switch object is created and connected (by default this is to a Simulator.Switch on Development Computer (Laptop10), but to UPB.Switch on Observatory Computer (Laptop9).  Problem occurs on Observatory Computer whilst testing AstroMain before the computer has been moved to the Observatory and connected to the physical Powerbox. Issue is understood and can be worked around.  Powerbox.Connect code changed so that connection is only attempted if Powerbox software (UPB.exe) is running, otherwise it automatically sets IsConnected to false, and shows a Red Flag against the Powerbox Service.
  Fixed 2022-06-23 (AstroMain 3.52)
   
• Logfile contains multiple messages describing exceptions caught in MonitorPowerBox & in DomePicture    Logfile contains multiple messages "Exception whilst monitoring PowerBox in RunObservatoryMonitoring - Object reference not set to an instance of an object" and "Exception in ObsViewer.DrawDome - Object reference not set to an instance of an object" . Messages are written to log file every 2.5s.  This is due to an creation of ASCOM.UPB.Switch and other ASCOM.UPB objects without being physically connected to the UPB Powerbox.   Problem resolved by the same fix to the above issue where Pegasus Astro ASCOM Powerbox Switch puts up a "Lost connection to powerbox' immediately after starting Observatory Services.
  Fixed 2022-06-23 (AstroMain 3.52)
   
• 'AstroMain producing an Info message 'Dome Port () resumed at ...' every 5s.  After connecting Dome Simulator (Observatory tab) a Obs.Manager message is written to the console and to the report file every 5s with messages like   "Obs.Manager, Dome Port:   Info   Dome Port () resumed at 2022-06-22 22:33:13".  The message is not appropriate when using a Dome simulator.   Message is related to Dome Port monitoring and whilst it is currently coded to not be executed when 'SU.SimDome = False',  this should be when VM.UseSimDome = False.
  Fixed 2022-06-22  (AstroMain 3.52)
   
• '(Sim)' text isn't included in Console/Report Message when starting or stopping Dome Service (when using Dome Simulator).  AstroMain currently reports  "Dome:  () Ok  Started"  or "Dome:   Ok  Stopped' .  (Sim) should be added to Dome Service report messages as happens for the Telescope and other services when using a simulator.   Problem occurs because Connect / Disconnect routines current consider SU.SimDome in  reporting instead of considering VM.UseSimDome.
  Fixed 2022-06-22  (AstroMain 3.52)
   
• 'JIT debugging' isn't working correctly. text isn't included in Console/Report Message when starting or stopping Dome Service (when using Dome Simulator).  AstroMain currently reports  "Dome:  () Ok  Started"  or "Dome:   Ok  Stopped' .  (Sim) should be added to Dome Service report messages as happens for the Telescope and other services when using a simulator.   Problem occurs because Connect / Disconnect routines current consider SU.SimDome in  reporting instead of considering VM.UseSimDome.
  Fixed 2022-06-22 (AstroMain 3.52)
   
• Unable to connect the SBIG Camera (daytime testing).  Attempt to connect to SBIG ST-10XME Camera from CCDSoft failed with 'Error code 1027. Camera Driver/Device not found.'   After looking at previous problems with this issue in the past, the solution was found and reemployed.  The issue was resolved by removing the USB cable to the SBIG Camera, removing SBIG Drivers in 'SbigDriverChecker64',  then locating all SBIGuDrv.dll files on the computer & rename them as  SBIGuDrv.dll_old, and finally update/install drivers again from SbigDriverChecker64. After reconnecting the USB cable the camera was able to be connected to from CCDSoft5. Problem is due to 'DLL hell' and is a typical issue seen when setting the SBIG Camera/ CCDSoft on a new computer or on a new installation.
  Fixed 2022-06-23  (SBIG drivers / DLL Hell / CCDSoft5)
   
• 'Unable to remote VNC connection to Observatory Computer as it had unexpectedly hibernated. After installing Observatory Computer in the Observatory and leaving it running with power plugged-in, a later attempt to make a VNC connection to the computer (over 3 hours later) failed. Visiting the observatory and checking the computer showed it to be off, but pressing the power button allowed it to resume from hibernation.  Examiming the computer's Power Options showed that  "Put computer to sleep (plugged in)" was set to 'Never', but buried in the Sleep section of the 'Advanced Power Settings' was a setting "Hibernate after (plugged-in)" which was set to 180 mins.  Computer needs to be on 24x7 so having it hibernate after 3 hours is totally unacceptable.  Issue was fixed by setting  "Hibernate after (plugged-in)" to Never.
  Fixed 2022-06-23  (Observatory Computer)
   
• ObsPic showing 'Dome Control' at start of session with an orange flag and the description  "97% (+11,861.6d)"  What does +11.861.6d refer to ? (the 'comma' separator should be fixed). Later on the field had a green flag and the description "97% 15.0V".  The value shows the TimeSince(DomeRecord.LastDateTime) in days (since it the duration is >24 hours).   Code change to show this as "97% (+11861d) with trace messages sent to logfile to show the LastDateTime in format yyyy-MM-dd HH:mm:ss)
  Closed but monitor future behaviour 2022-06-24  (AstroMain 3.52)
   
• When Parking Dome, the dome slew monitor reported that the slew held up at Az 94.5 for 5s. From a starting position at Az 95 the 'Park Dome' button was clicked to begin a slew from Az 95.0 to Az park  (90.0) at end of daytime testing. No interruptions or hold-ups were noticed during the slew (no sounds suggesting it was spinning at one spot). Examining log file shows that SlewDomeToAzimuth() had exited with the message "A Slewing=True state wasn't seen, but the dome has reached the target Az".  The DomePath table showed two rows:
  Time: 0.5, Slewing: 0, Slew: 0.0, Az: 95.0, Speed: 0.00, Time: 13:12:39.31
Time: 5.6, Slewing: 0, Slew: 5.0, Az: 90.0, Speed: 0.89, Time: 13:12:44.41
  Repeating the slew later on with the DH Activity Log on shows that the problem is caused by DH dropping back to normal polling (every 5000ms), just 2ms after it begin fast polling (every 1000ms). This means that DH doesn't see Slewing=True from the dome for at least 5s or so after it began moving or not all if the slew is a short one and completes within 5s.  Issue has been passed to author of DeviceHub for review/consideration, which may result in a fix in a future release update of DeviceHub. In the meantime a fix has been added to ignore and not report 5s holdups during the first 5-6s of a dome slew, as they are always certainly an artefact caused by delay in Dome Driver returning Slewing=True and DH jumping to a 5000ms polling when it sees an initial Slewing=False from the dome.
  Workaround employed  2022-06-24  (AstroMain 3.52). (Waiting on a final solution from Pulsar Dome, DeviceHub)
   
• Slew Monitor is incorrectly reporting that certain dome slews are being held up for 5s. Due to an issue with DH's Dome Polling Rate during the first few seconds after commanding a SlewToAzimuth, the dome can appear to be stationary and not slewing for at least 5s after starting a slew, and this can be counted as a 5s hold-up even though the dome is actually moving ok.  Apparent hold-ups of around 5-6s at the start of a slew are almost certainly false alerts and shouldn't be counted as a holdup in either reporting or in slew statistics. Fix made to DumpSlewPointsToLogFile() to ignore these false hold-ups (recognised as a 'holdup' that finishes within 7s of the start of a slew).
  Fixed  2022-06-24 (AstroMain 3.52)
   
• Unable to bring up JIT Debugging.  AstroMain met a fatal exception (when testing an attempted fix for s separate Powerbox connection issue). Whilst the exception details were displayed in a dialog box there was no option to open the code in Visual Studio in order to see and understand what the problem was. Attempts to set JIT Debugging in Visual Studio's Options and  set <system.windows.forms jitDebugging="true" />  in AstroMain.exe.config file failed to resolve the issue. Checked VS2022 Options and ensured that JIT debugging is enabled (as Admin).  Resolved in part by using a fix to a known Windows issue which can cause the Just-In-Time debugger to fail.  Using Regedit a DWORD Value of Auto, with Value data of 1, added to two registry keys i) HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug and ii) HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug.  (Note that it is neccessary to add 'Auto' = 1 to both these keys).  Without this fix to both registry keys the running AstroMain program simply disappears when an untrapped exception occurs, without showing any dialogue and without opening the Visual Studio 2022 debugger. With this fix a "Choose Just-In-Time debugger" dialog pops up" if AstroMain encounters an untrapped exception, and after selecting 'New instance of Visual Studio Community 2022'  the Visual Studio application then opens up with details on the exception.  The primary issue is deemed to be fixed, however a separate critical issue is then exposed whereby the source code (with the position of the exception enountered) is not opened/displayed.
  Closed but with a continuing follow-up issue (JIT / Visual Studio 2022)
   
• JIT Debugging fails to show source code with the position where exception has occurred. After resolving a prior issue in which JIT debugging wouldn't start, it was found that whilst VS2022 debgger would open up and have details on the type of exception encountered etc it didn't open the source code associated with the exception and would thus not be able to show the code line where the exception had occurred, meaning that JIT debugging was less helpful that having JIT debugging turned off (since that gave a clear description of the exception,  and the source file/line number than exception has occurred).  Issue occurs on both Development and Observatory Computer.  Initially the VS 2022 debugger opens up with the application in break mode with no code to show because 'all threads were executing external code (typically system or framework code).'   This message can be overcome by turning off the ''Enable Just My Code' option (Options/Debugging/General), however VS 2022 debugger opens up with the message "Microsoft.VisualBasic.pdb not loaded" (Microsoft.VisualBasic.pdb is supposedly needed as it contains the debug information required to find the source for the module Microsoft.VisualBasic.dll).   Setting Debug / Symbols to use 'Microsoft Symbol Servers' and to cache symbols in  "file:///C:/Users/David/AppData/Local/Temp/SymbolCache" leds to long delay whilst symbols are downloaded after the VS2020 debuger opens up before a "Find source - WindowsFormsApplicationBase.vb" dialog to appear and if not chosen (as file doesn't exist) it puts up the message "WindowsFormsApplicationBase.vb not found". Again the problem occurs on both the Development and the Observatory Computer. 
  Creating and selecting an empty 'WindowsFormsApplicationBase.vb' file results in an empty file opening with the detail on the exception,  but again no source code.  AstroMain.exe is compliled with Debug option and an AstroMain.pdb file is created and held in same folder as AstroMain.exe so it is really unclear why the debugger can't open the source code with the offending exception highlighted. See  https://docs.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2022 . Problem appears to have resolved itself on 2022-07-18 or so.  Closed after review 2022-07-19.   Residual issue is there is a long delay whilst VS 2022 loads multiple sets of symbols from Microsoft Symbol Servers.
  Appears resolved 2022-07-19 (Observatory Computer, JIT / Visual Studio 2022)

[ Prev | Next ]

Back to Top

2022-06-16

Observatory Computer - Inaccessible Boot Device

Back to Top

2022-06-21

Observatory Computer - Windows 10 Reinstall & Rebuild

Back to Top

2022-06-23

Observatory Computer - Device Setup / Daytime Testing

Back to Top