Issue 
Problem with Dome Slew to Target 1/6 (SS Cyg) - either an actual problem with the slew or a slew monitoring/reporting problem.

Description
A 'Dome Discrepency' alert was issued at 01:09:27 "Difference between Telescope Az and Dome Az is > 8 deg (GCVS SS Cyg)" and the ObsPic on Current Session page showed the dome apparently not aligned with the telescope and apparently still 'slewing'. The Report file showed the message "Az: 171.8° (Dome)   ALERT. 99.7° difference from Scope Az" , followed a few moments later by "Dome Az. 157.5° (vs. Scope Az. 72.1°, Delta Az. 85.4°)"

The session's slew table reports that the dome slew to SS Cyg at 01:08 took 12s to slew from Az 203.1° to Az 171.8°  (an angle of 31.3°) at an anomously high speed of 2.57°, whilst the scope slew took 32s to slew from Az 208.6°  to Az 72.1°.  (overall slew time 32s).  The following dome slew to BL Lac at 01:18 was reported to have started from Az. 76.0°.

Analysis
The changing Dome Az (from 203.1° to Az 171.8°, then to 157.5° and then to destination Az of ~ 76° suggests that scope was still slewing after the Scope/Dome Slew monitor had assessed that the slew had been completed, and was physically normal.

Centering operations, and in particular Locate Frame 1 that followed directly after the slew operations, were normal (dome had evidently arrived at the required slaved location for SS Cyg target).  This confirms that the dome slew was physically normal.   

It would seem that the problem lies in the slew monitoring routine which has somehow failed to identify the correct end of dome slew.  This would be due to a flaw in the routine's logic or a glitch in the data being sent to the client from the Pulsar Dome driver.

Example Time Line associated with a normal slew

This timeline is consistent with that expected from a ‘Best Way’ configuration. 
The scope and dome are sent slew commands at the same time.  The Dome Slew is clearly given the destination Az. 289.7°,  and this occurs even before the scope is perceived to have actually started to move.

Time Line associated with anomalous slew (SS Cyg, 01:08)

The Dome-Scope Configuration used in the Observatory is shown in the following diagram, along with the data flow paths associated with a slew to target

This a "Best Way" configuration and would normaly see both the telescope and the slaved dome being sent a slew command froom DeviceHub at the same time when a slew is initiated by DH or by an Ascom client connected to DH.Telescope (and Dome.Slaved = True).  This should mean that both devices should begin to slew directly to their new target position within a few 10ths of a second of each other. Both devices should move directly to their new destination in a single move.

Whilst most of slews requests (initiated from AstroMain via TheSky6/TeleApI/DH.Telescope show this expected behaviour, in at least the one anomalous slew case documented above this behaviour obviously didn't occur. Instead the dome 'followed' the scope movement, didn't occur in a single move and caused the dome azimuth to not arrive at the appropriate destination azimuth until some time after the scope has finished its slew.

Conclusion

 It would seem that Scope-Dome system works as intended for most of the time, but at least in one case documented it didn't. The hypothesis to explain this anomaly is as follows :-

• around the time that DH commanded telescope with SlewToCoordinatesAsync (in response to Slew request from Client), the DH.Dome ‘thread’ just happened to still be busy doing a periodic slaving calculation based on current scope position and missed picking up the request from DH.Telescope to perform a Dome Slaving calculation for the scope’s destination coordinates, or produced an exception.
• a SlewToAzimuth (destination Az) was consequently never sent to the dome.
• on a following periodic slaving calculation performed after scope had started moving a new Slaved Dome Azimuth was calculated and a SlewToAzimuth (192.5°) was issued to the dome.  (with the scope slewing, this was a command to slew to a position that was essentially out of date the moment it was sent)
• there may have been further requests to move to new Slaved Dome Azimuth position as the scope proceeded through its slew , but as the Dome was already slewing these requests were ignored, until the Dome reached the interim azimuth (192.5°) and it was then receptive to a final SlewToAzimuth request resulting from a later periodic slaving check which eventually got the dome to Az 75°.

Actions

Document Slew Anomaly (SS Cyg) and forward description of the problem and hypothesis to the author of the DeviceHub program for review/comment.
Modify AstroMain to handle the slew behaviour that occured for the slew to SS Cyg.

Update 2022-06-03
Whilst reviewing the Dome Slew Monitoring code in the SlewTheSkyScope() routine it was found that a 20s cutoff had been added 2022-05-10 (in response to MI, S995 2022-03-25) in the code for reset SlewStopped Flag if dome is slewing again.   Because the resumed dome slew to Az 75° only happened after 23s the opportunity to lower the SlewStoppedFlag and bDomeCompleted flags was lost, with the consequence that slew monitoring was exited before dome was in the correct position for the target. This is fixed in AstroMain 3.51.13.

Update 2022-06-04
For further diagnosis of this issue it is critical that DeviceHub ActivityLog is running and captures Dome & Scope Commands at the time of a similar event.  DH will be setup at start and end of each new session to capture ActivityLog message from each session in order to have information on the commands & any exceptions relevant to a future instance of this issue.

Session S1016 and S1017 both had one instance of an anomalous dome slew where the dome slew stopped part way from the slew to Target., but didn't effect the follow-on operation as Scope/Dome slew monitoring ended at appropriate point.  In both cases the Anomalous Slew was associated with slew to Focus Field target as the beginning of the session. After turning-on Slaving the dome began still slewing towards the telescope which was sitting close to its startup position (Az ~180°).  This slew was still underway when Scope was commanded to slew to the Focus Field target.  In S017 an attempt was made to abort this already active dome slew before commanding the slew to Focus Field, but process didn't wait longer enough for the dome to be confirmed as no longer slewing.

Update 2022-06-05
AstroMain 3.51.15 version built with updated fixes for this issue.

Update 2022-06-09
New version of DeviceHub installed (DeviceHub 6.6.0.11) which contains a fix for an issue with DH's dome slewing interruption that may have caused the anomalous dome slew seen during slew to SS Cyg (01:08).