Issue:  AstroMain produced a 'Dome Failed to Park, Dome at Az 110 degs' alert whilst parking dome at end of session.
However it was a false alert as dome had actually moved to its Park position at 090 deg

Description : As with the last session there was a false alert message when parking the dome.   When dome was checked it was found to be at the correct park position (090 deg).  Investigating showed that the  Report file contained the error message 'Dome slew failed (Dome at Az 110.0degs)' )  and the slew table showed dome starting and ending at Az of 110 deg.  Extra tracing of dome parking operations that had been added to AstroMain program since the last session were of help in identifying the exact route taken by program execution. 

05:44:24.66  Starting SlewDomeToAzimuth(90.0)
05:44:25.48  Exiting loop as slewing has stopped
05:44:25.48  Dome Slew Time: 0.8s
05:44:26.00  PostSlew DomeAz Info | Az= 110.0
05:44:26.00  Dome Park aborted (0s, Az=110.0degs)
05:44:26.22  Exiting Post-Slew loop due to 3 minute timeout
05:44:28.45  Park Telescope
05:44:31.11  Dome Dome Movement Ok | Dome has moved 9.7 deg (Az 110.0 -> 100.3) following telescope slew.
05:44:33.71  Dome Dome Movement Ok | Dome has moved 8.8 deg (Az 100.3 -> 91.5)
05:44:36.24  Dome has moved 1.5 deg (Az 91.5 -> 90.0)

This shows that the 'wait for dome slew to finish' loop exited after just 0.8s (ie two cycles) when .Slewing=False was detected after an initial Slewing=True.
There were no exceptions from any calls to objDome.Slewing

Why was Slewing percieved to have stopped at 05:44:25 when it is clear that Dome Slewing didn't actually finish its slew until 11s later at 05:44:36 ?
(Does DH set slewing to True when it receives call to Slew, but this is briefly overwritten by a slewing = False from the dome (before its actually starts slewing) which then turns Slewing=True again ? )
In the post-slew loop why was it exited with 3 min timeout message when it was only in the loop for no more than 22s ?

Pulsar's ASCOM log shows

05:35:05.346 Slewing Get True     <-------- shows True when dome is not slewing  !
05:35:25.376 Slewing Get True      
05:35:25.376 SlewToAzimuth Start 91.4979728662159   <----- DH commanding dome to slewing back to Slave Position
05:35:26.297 Volatile 109.0  1  91.5  2   <---- 1 indicates dome slewing,  2 seems to show rotating anticlockwise
05:35:26.390 Slewing Get False      <-------- shows False when dome is slewing  !
05:35:35.251 Volatile 91.5  1   91.5 2
05:35:35.516 Slewing Get False
05:35:36.249 Volatile 91.5  0   91.5 0  <---- dome stationary
05:35:36.530 Slewing Get True           <-------- shows True when dome is not slewing  !
05:35:53.263 Slewing Get True
05:35:53.263 SlewToAzimuth Start 110     <---- User commanding dome to slew to 110 deg
05:35:53.419 Slewing Get True
05:35:53.481 Volatile 91.5  1  110.0 1   <----  1 indicates dome slewing,  2nd  1 seems to show rotating clockwise
05:35:58.426 Slewing Get False
05:36:02.670 Volatile 109.8  1  110.0 1 
05:36:03.496 Slewing Get False
05:36:03.637 Volatile 110.0   0  110.0  0   <---- dome stationary
05:36:04.510 Slewing Get True

05:44:20.231 Slewing Get True    <-------- shows True when dome is not slewing  !
05:44:24.521 Volatile 110.0  0  110.0 0    <---- 0  show dome stationary
05:44:24.661 SlewToAzimuth Start 90       <----  Dome commanded to slew to 090 deg
05:44:24.677 SlewToAzimuth Completed     <-- request acknowledged
05:44:25.238 Slewing Get True   <-------- shows True when dome is not slewing  !
05:44:25.550 Volatile 108.8  1  90.0 2   <---- 1 indicates dome slewing,  2 indicates rotating anticlockwise
05:44:29.793 Volatile 100.3  1  90.0 2   <---- 1 indicates dome slewing,  2 indicates rotating anticlockwise
05:44:30.246 Slewing Get False    <-------- shows False when dome is slewing  !   (~5.8s after original request )

It seems that the hypothesis   "DH set slewing to True when it receives a call to Slew to Azmith, but this is briefly overwritten by a slewing = False from the dome (before its actually starts slewing) which then turns Slewing=True again " is consistent with the observations.

05:44:15.223  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=False.  On 5s Normal Polling
05:44:20.231  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=False
05:44:24.66    Client asks DH.Dome to Slew to Az 090 deg.   Received by DH.Dome and sent on to Pulsar Dome Driver
05:44:24.66    DH.Dome changes its representation of Slewing state to True (inferred)
05:44:24.661  Pulsar Dome Driver receives request to slew to Az 090 deg
05:44:24.677  Pulsar Dome Driver acknowledges request
05:44:24.68    Client asks DH.Dome for Slewing State and receives Slewing=True  (inferred).
                         Client takes this as showing that slewing has started
05:44:25.08    Client asks DH.Dome for Slewing State and receives Slewing=True  (inferred)
05:44:25.238  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=False
05:44:25.48    Client asks DH.Dome for Slewing State and receives Slewing=False.  
                         Client takes this as showing that slewing has stopped !
05:44:25.550  Pulsar Dome Driver receives message from Dome Controller that it has started the slew.
05:44:28.45    Client is off to perform next phase of observatory shutdown (Parking Telescope)
05:44:30.246  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=True.   Still on 5s Normal Polling.
05:44:30.683  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=True    Start of 1s Fast Polling
05:44:31.697  DH.Dome asks Pulsar Dome Driver for slewing status and receives Slewing=True 
                         etc  
05:44:36.24    Dome reaches in destination (Az 090 deg)

Code needs to be modified to wait at least 8s before concluding that a slew has really stopped (or not taken place), since a Slewing=False state (after a Slewing=True) can not be used within first few seconds to conclude that slewing has stopped.

Improvement Plan for TS80/178MC (see notes from last session) necessitates a new review of the software used for capturing and processing of images.
Last review was held in late 2016 (see Planetary Image Capture / Processing Software (2016-12-30) ) .  New software that could be useful include :
 

• Siril
• FITS Liberator
• DeepSkyStacker Live
• AstroImageJ

Improvement Plan for TS80/178MC (see notes from last session) requires the building a dark library to be used for pre-processing light frames for Live Stacking.

 It is important that Light Frames and Dark Frames are taken with the same parameters (ie same Colour Space, Capture Area, Binning, Exposure, Gain etc)
Building a dark library for the CMOS Colour Camera like Zmy WO ASI 178MC 178MC camera is notionally more complicated than building a dark library for a CCD Camera like my ST-10, because a CMOS Colour Camera as additional variables such as camera 'gain' ,  'offset' ( or 'Brightness' as it referred to in SharpCap).and White Balance (White Bal (R) and White Bal (B) in SharpCap) , that are not relevant to for a monochrome CCD camera

For cooled cameras like my ST-10 it is easier enough to build master darks taken at the same specific temperature as the light frames. (-5, -10, -15, -20, -25 &  -30 degC are the specific temperatures that I use.).  For non-cooled camera it is much harder to ensure that darks are available that have been taken at the same temperature as the light frames, the initial approach to be used it to take darks at a range of temperatures and use a routine to select the dark which is closest in temperature to the temperature of the light frame.

One way of simplying things is reduce the almost infinite combination of  properties to just a few standard setups. The following set were collected today (2020-10-28)

Parameter		Value(s)
Colour Space		RAW16
Capture Area		3096 x 2080 (Full Frame)
Gain		0, 50, 150, 300
Exposure		1.5s,  10s, 20s, 30s, 60s
Offsets (gain)		25 (g0),  83 (g50),  200 (g150),  375 (g300)
White Bal (R)		0.50
White Bal (B)		0.50
No. of Frames		25
Temperature		17.0 to 19.3°C (see table below)

Offsets are generated from the equation Offset= 25 + gain/270 * (340-25),
(this is a linear interpolation between two standard points on ASCOM setup ZWO ASI178MC (gain 0 / offset 25   and gain 270/offset 340).

A series of checks were made to establish that offsets derived from this equation wouldn't crop the histograms on left hand (lower nunber) side. The equation is possibly too conservative and the slope in particular could be reduced, in order to give greater ADU range, but in the end it was decided to go with the 1st equation (above) as it tied in with a publically acknowleged data source.

Previously values of 0.54 (R) and 0.52 (B) were used for white balance,   but 0.50(R) & 0.50 (B) is a setting that others use and testing show that R G, B histograms from Darks are best aligned with these settings.

Dark Sets acquired (2020-10-28)

Dark Set	Temperature
1x1, 1.5s, g50	19.3°C
1x1, 1.5s, g150	19.3°C
1x1, 1.5s, g300	17.6°C
1x1, 1.5s, g450	17.7°C
1x1, 10s, g0	17.2°C
1x1, 10s, g50	19.7°C
1x1, 10s, g50	17.2°C
1x1, 10s, g150	19.1°C
1x1, 10s, g300	18.0°C
1x1, 10s, g450	18.0°C
1x1, 10s, g0	17.5°C
1x1, 20s, g50	19.3°C
1x1, 20s, g50	17°C
1x1, 20s, g150	19.1°C
1x1, 20s, g300	17.2°C
1x1, 30s, g0	17.3°C
1x1, 30s, g50	19.2°C
1x1, 30s, g50	16.6°C
1x1, 30s, g150	19.1°C
1x1, 30s, g300	17.6°C
-
2x2, 1.5s, g50	19.2°C
2x2, 10s, g50	19.2°C
2x2, 10s, g50	16.0°C
2x2, 10s, g100	15.6°C
2x2, 10s, g150	19.0°C
2x2, 10s, g300	18.2°C
2x2, 20s, g0	17.1°C
2x2, 20s, g50	19.1°C
2x2, 20s, g50	16.1°C
2x2, 20s, g100	15.3°C
2x2,, 20s, g150	18.7°C
2x2,, 20s, g300	18.1°C
2x2, 30s, g0	17.0°C
2x2, 30s, g50	19.0°C
2x2, 30s, g50	16.3°C
2x2, 30s, g150	18.3°C
2x2, 30s, g300	18.1°C
-
2x2, 60s, g0	16.7°C

60s Dark Frame showing AmpLight
 (g0, 2x2 binning, Reduced)

1) ASCOM Conform (6.4.46.0) was run on Device Hub.Dome with DH connected to the Pulsar Dome Driver.

  Driver had 1 error, 0 warnings and 0 issues

  - FindHome                 ERROR             Home command completed but AtHome is false
 

2) ASCOM Conform (6.4.46.0) was run directly on the Pulsar Dome Driver

The first attempt to run Conform directly against the Pulsar Dome failed when the following error was encountered whilst trying to select the Dome Driver:

 “Incompatible Driver (ASCOM.Pulsar_Observatories.Dome.Dome).
  This 64 bit capable driver is only registered as a 32bit COM driver.
  Please contact the driver author and request and updated installer”

The solution was to run Conform as a 32-bit application. This was done by Starting Conform and selecting  Options | General and clicking "Run as 32bit on 64bit OS"