Issue 
A "dome didn't appear to move during telescope slew" alert issued by AstroMain even though dome did move and in a manner consistent with slaved behaviour.

Description
Red Alert issued at 01:56:14 as the dome seemed to not move during telescope slew to Target 10/13 (Mrk 506 w/AT2021agiv).  

For the  telescope moving from AzAlt 171.1 / 39.7  to AzAlt 145.4 / 60.6, the slaved dome should moved from its initial position at Az 170.7, but it appears not to have moved according to slew monitoring

Report file shows Dome at Az: 170.7° after the slew with the alert '(ALERT. 25.3° difference from Scope Az)'.  There is then a follow up message 'Last Slew Alert - Dome didn't appear to move during the last telescope slew' / 'Dome Driver/Dome Slaving might be stalled' .

Analysis
Logs record that telescope was commanded to slew at 01:55:45, with first physical movement of the scope being recorded at  01:55:49. 

ObsPics show
- telescope starting to slew in picture at 01:55:47 (dome slaved but still stationary),
- dome at Az 148 in picture at 01:56:17 (dome still slewing),
- dome at Az 148 at 01:56:45 (dome stationary). 

After the Last Slew Alert message the Report file records ' Dome Position  Dome Az. 151.1° (vs. Scope Az. 145.4°, Delta Az. 5.7°).

So it seems that the Dome has operated ok. But why was the  Dome Alert generated ?  

The Pulsar ASCOM log file shows
- 01:56:04, Dome at Az 170.7°  (Slewing=False)
- 01:56:05, SlewToAzimuth (147.8°) command
- 01:56:06, Dome at Az 169.2°  (Slewing=True)
- 01:56:17, Dome at Az 147.8° (Slewing=False)
  (Note:  log slewing boolean is reported opposite to actual state , this is a known logging issue) 

This confirms that there was no any physical issue with the Dome or Dome driver, and that slew time (12s) was normal

The DeviceHub Dome log shows
- 01:56:09, Dome at Az 170° 42'  (Slewing=False),
- 01:56:12, Dome as Az 157° 48'  (Slewing=True)
- 01:56:17, Dome at Az 148° 00'  (Slewing=True)
- 01:56:19, Dome at Az 147° 48'  (Slewing=False). 

So again the physical dome slew and its communication seems completely normal.

Conclusion

The above analysis implies that there is some bug or design flaw in AstroMain's Scope/Dome Slew Monitoring loop, but we also find an apparent issue with DeviceHub-Pulsar communication ?

AstroMain's og file indicates that the slew monitoring loop  finished at 01:56:08 when the scope had reached its target, and didn't wait to see the movement of the Dome, which was only recorded to have started by DeviceHub at 01:56:12  (this is 5 secs after the monitoring loop exited,  7s after SlewToAzmiuth command from DH was received by Pulsar Dome, 27s after scope slew was originally requested (ie 27s since TimeStart) ) .   

So in this case it seems there was an unexplained delay of 20s before DH seemed to issue the SlewToAzimuth command to the Dome.   May be raise with Rick Burke (author of DeviceHub) ?   Did DH on this occasion wait until dome has reached its target before issuing command (was this actually a follow-up Slave Check action and the original command never reached the Pulsar driver for some reason. 

Regardless need to review/rework the design logic in AstroMain 's Scope.SlewTheSkyScope() routine to wait longer if the dome hasn't moved before closing the monitoring loop (at least in cases where a dome movement is fully expected but can evidenty be delayed).

Actions

Following actions identified and raised as ticket items (see Operational Issues section above for details)

• Communicate observation of the apparent DeviceHub slaving anomaly to Rick Burke (author of DH).
• Review/rework Slew Monitoring Loop to wait longer in cases where Dome hasn't moved when movement is expected.

Observation - Slaving Anomaly

Expectation.  
When the DH.Dome is slaved , I am supposing (expecting) that at the same time that a telescope slew request is received by DeviceHub and the the slew request is forwarded to the Telescope, a DH routine kicks-in and calculates the appropriate Dome azimuth that is best suited for the Telescope’s Target Az/Alt , and it then immediately or shortly after sends a SlewToAzimuth request to the Dome, so that both Scope and Dome head off to the target at more or less the same time (at least that’s the physical behaviour that I observe)

The above it what I suppose happens, rather than DH waiting for the Telescope to have moved by some distance or for it to reach the Target before it sends a command to slew the Dome (clearly through this, more reactionary behaviour, would occur if the scope was moved using its handbox controls since DH may not know what the target coords are in this situation)

My expectation of near-immediate dome slewing is what I normally experience, but it seemingly didn’t in one particular case encountered during my session last night.

Anomaly (Mrk 506 slew at 01:56)
Following the request to slew Telescope at 01:55:45 and its initial movement (not later than 01:55:48) , there is no 'immediate' command to slew the dome (at least the Pulsar Log shows no such commands being received). Instead the command to slew the dome appears not to be made until 01:56:05 which is 20s after the telescope was commanded to slew.

DH doesn't see any movement of the dome until 01:56:12 which is 4s after the telescope has arrived at the target.

Timeline.
The following combined timeline has been compiled from Pulsar Dome Ascom Logs, DeviceHub Dome & Scope Logs, Client Logs

01:55:43 Client looking up existing Scope/Dome positions (Scope Az= 171.1° Scope Alt=39.7°, Dome Az= 170.7°)
01:55:44 Setting Target RA/Dec (these are equivalent to Target Az 145.4°, Target Alt=60.6°)

01:55:45 Telescope commanded to slew to Target RA/Dec using TheSky6.Telescope.SlewToRaDec
                 (this is my normal method, it uses TheSky6 for it's TPoint functionality and it uses TheSky6>TeleAPI>DH.Telescope)
01:55:48 DH.Telescope starts moving (coordinates start changing, Slewing=True)

01:56:04 Pulsar Dome still at Az 170.7° (Dome.Slewing=False)
01:56:05 Pulsar Dome receives SlewToAzimuth (147.8°) command
01:56:06 Pulsar Dome moving at Az 169.2° (Dome.Slewing=True)
01:56:08 DeviceHub.Telescope arrives at Target (Scope.Slewing = False)

01:56:09 DH.Dome still stationary at Az 170° 42' (Dome Slewing=False)
01:56:12 DH Dome moving at Az 157° 48' (Slewing=True)
01:56:17 Pulsar Dome arrives at Target, Az 147.8° (Slewing=False)

01:56:17 DH Dome moving at Az 148° 00' (Slewing=True)
01:56:19 DH.Dome arrives at Target (Az 147° 48' (Dome.Slewing=False)

Analysis & Conjecture
The Pulsar log doesn't show receipt of any SlewToAzimuth command between 01:55:45 and the command that was recieved at 01:56:05.

It is possible that DH prepared an immediate Slew Dome command but didn't send it for some reason (exception ?)
or sent it but it wasn't received by the Pulsar Dome driver (but no other indication of any comms issue).

The Slew Dome command that was received was either the ‘immediate’ command but became somehow delayed on route or (more likely?) it is was a SlewToAzimuth command that was one sent by DH’s regular slaving checks and wasn't in direct response to the Slew Telescope command.

It is not throught that the observed anomaly is anything more than a one-off glitch. In particular there were no issues with either the proceeding slews or the two target slews that were made after this one particular slew.

Effect
The unexpected delay in dome movement caught-out my existing Slew Monitoring Loop and it issued a (false) alert that the ‘Dome hadn't appeared to have moved in response to Telescope Slew , is the DH slaving stalled ?’ . It hadn't stalled and the alert / issue didn't cause my observatory control program any material problem.

AstroMain client was modified today (2022-05-12) to allow for a delay of up to 30s before concluding and reporting that dome wasn't moving for some reason, so I shouldn’t get a similar false alert in future, and it will also ensure that loop sees the Dome movement and sees it finishing its slew, before I start taking images.

Note : I don’t use DH’s ‘Report Composite Slewing When Dome Is Slaved’ as it offers me better monitoring, such that I can separately spot/differentiate any scope slew , dome slew anomalies/issues.
.

Code Review/Rework:    Slew Monitoring Loop
Log files show that the monitoring loop was entered at 01:55:45.21, and exited 23s later at 01:56:08.00.

 It can be inferred that loop exit occurred upon the following condition state : 
  bScopeCompleted=True And bDomeCompleted=True
 (Other exit scenarios : JobAbort,  JobAbortTarget or loop taken > 4 mins can be discounted))

The current code shows that the bDomeCompleted flag is set to True in the following 4 situations

a) SecondsSince(StartTime) > 8 And bDomeSlewStopped And bDomeCompleted = False
b) bDomeSlewStarted = False And Dome.Slewing = False And SecondsSince(StartTime) > 10
c) bDomeCompleted = False And SecondsSince(StartTime) > 60 and DomeSlewAngle = 0.0
d) bSlaveDome = False

In the particular case of the Slew to Mrk 506 target at 01:56, the bScopeCompleted flag evidently became set to True by situation b).

Modifying the required condition for situation b) by increasing the minimum time to 30s (instead of just 10s) and including an additional condition that bScopeCompleted = True will have prevented the Mak 60 slew at 01:56 issue from occuring and prevent other foreseeable scenarios where there is a delay in commanding the dome to SlewToAzimuth.

Update 2022-04-14.  Observations on the anomalous slaving behaviour during Mk 506 slew at 01:56 emailed to Rick Burke (2022-12-13 am).  Reply indicated that DH code couldn't have given rise to a 20s delay, so issue is put down to a one-off glitch.   DH code could give rise to a delay of around 3s however and this will be fixed in the next version of DH.