---

Fig 1.   Telescope Slewing Chart showing 2 slews cutting across Azimuth 0 line
Slews appear to enter/cross the telescope's 'no slew / az limit region'


 
 
Fig 2.   ObsCamera showing telescope's main cable bundle wrapped around scope base

 

Fig 3. Interlaced Report Messages problem when restarting Dome (23:05)


  Restart DeviceHub                    2024-08-25 23:05 (Local, BST)
  Stopping Process ** (Continued below)
  Dome Connection             Error     Dome Connection has been lost. Attempting reconnection
  DeviceHub:

**DeviceHub: Ok Started (23:05) (ASCOM.DeviceHub 6.6.1.1)
Ok Stopped (ASCOM.DeviceHub)

  Restart Dome (incl Power Reset)       2024-08-25 23:05 (Local, BST)

  Restart Dome Controller               2024-08-25 23:05  (Local, BST)

  Switch Off Pulsar Dome      Ok        Switching off Pulsar Dome
> Dome Power                  Info      Dome Power has switched off       (23:05:37, on time > 116 h)
  Wait on Pulsar Dome..       
  Dome:             (COM3)    Ok        Started (23:05)   (ASCOM.Pulsar_Observatories_Dome.Dome, 6.4.0.0)
Ok        Waited 15s for power to fully drain

  Switch On Pulsar Dome       Ok        Switching on Pulsar Dome
> Dome Power                  Info      Dome Power has switched on        (23:05:52, off time 15 sec)
  Wait on Pulsar Dome..       **                          (Continued below)
> Observatory Manager         Info      DomeRecords have stopped updating (23:05)

**Wait on Pulsar Dome..       Ok        Waited 20s for controller to initialise

  Restart Dome Service                  2024-08-25 23:06  (Local, BST)
  DeviceHub:                  Ok        Started already   (ASCOM.DeviceHub, 6.6.1.1)
  Dome:             (COM3)    Ok        Started already   (ASCOM.Pulsar_Observatories_Dome.Dome, 6.4.0.0)

  Dome                                  2024-08-25 23:06  (Local, BST)
  Azimuth                     Ok        Az: 61.3°
  Shutter                     Ok        Closed            (Zigbee: Closed)
  Pulsar Log File             Ok        2024-08-25\ASCOM.Pulsar_Observatories_Dome.2305.382490.txt
  Dome Connection             **                          (Continued below)
  Dome Connection             Ok        Dome Connection has been recovered
> Observatory Manager         Alert     DomeRecords have resumed updating (23:06)

Issue

1a) Telescope Slewing Chart show telescope slewing beyond Az 360 on two occasions during session (S1122 2024-08-03 23:17)
1b) Telescope's SBIG Power / ZWO USB3 cable bundle became caught on the equatorial wedge's altitude knob.

Description
Telescope slewing section on the right hand side of the session's 'DomeChart' picture shows the observatory's  LX200 telescope slewing through Az 0/Az 360 line and entering the telescope's 'no-slew / az limit' area on two slews. . Such slews pose potential serious risk of damage to cables/equipment as the cables could become wrapped/strained around the pier / wedge. No particular adverse effect or long lasting problem was noted on this occasion. Targets were imaged ok and telescope was returned to park position ok at end of session. 
 


To issue is ranked as 'Major' due to the potential damage caused by slewing beyond Az 360 (or beyond Az 0) .

An ObsCam 'session-suspended' picture (whilst on Target 17/17, NGC 3729)  at 03:57 with telescope at Az 15.2° shows main cable bundle wrapped around the telescope base indicating that the telescope has indeed slewed across the designed 'No Go' region (Az 345-360°) and beyond Az 360° line during some prior slew. This is a serious event/situation and one that shouldn't have occurred.

ObsCam pictures of telescope at start and end of session show that the SBIG Power / ZWO USB3 cable bundle ended the session on the wrong side of the pier, indicating that it was potentially wrapped around the pier or otherwise caught/held-up (which presents an issue for the next time the telescope is powered up).

ObsCam Image : Start of Session - Telescope On (22:15).  SBIG Power & /ZWO USB3 cable bundle to right of Pier (normal state).

ObsCam Image:  End of Session - Telescope Parked  (04:31). SBIG Power & /ZWO USB3 cable bundle to left of Pier (anomalous state).

 

A daylight check revealed that the SBIG Power / ZWO USB3 cable bundle from the telescope was not wrapped around the pier but it was caught/strained on the equatorial wedge's altitude control knob.

Analysis

Why did the LX200 perform this action ?.
Why was this allowed to happen with the telescope monitoring active within the AstroMain program ?

A tabulated summary of the telescope slews made during session are shown below.


An ObsCam picture at 03:15 (start of slew to Target 15/17, UGC 4730) clearly shows the telescope cables in their expected positions, and seemingly still normally arranged at the end of slew, centering & start of UGC 4730 imaging. 

The slew to Target 16/17 (NGC 3690) involved a slew from Az 30.6° / Alt=34.5°  to Az 11.2° / Alt:  26.1°. This should be an anti-clockwise rotation.
An ObsCam picture at 03:33 however shows the telescope at Az 75.6, seemingly slewing clockwise towards the Target 16/17 (NGC 3690)

AstroMain's log file records the telescope path moving clockwise from Az 30.6° to Az  358.6°, crossing Az 360° and continuing to Az 11.2°.

  03:33:18.50 | Time:  0.0, Az:  30.62, Alt: 34.49
  03:33:22.40 | Time:  3.9, Az:  30.62, Alt: 34.49
  03:33:23.25 | Time:  4.8, Az:  32.32, Alt: 34.55
   ...
  03:34:19.84 | Time: 61.4, Az: 349.67, Alt: 25.94
  03:34:21.76 | Time: 63.3, Az: 355.68, Alt: 25.24
  03:34:22.59 | Time: 64.1, Az: 358.63, Alt: 25.10
  03:34:23.44 | Time: 65.0, Az:   1.55, Alt: 25.11
  03:34:24.49 | Time: 66.0, Az:   4.51, Alt: 25.25
  03:34:25.54 | Time: 67.1, Az:   7.44, Alt: 25.53
   ...
  03:34:38.11 | Time: 79.6, Az:  11.18, Alt: 26.09
  03:34:40.03 | Time: 81.5, Az:  11.18, Alt: 26.09
  03:34:41.92 | Time: 83.4, Az:  11.18, Alt: 26.09

The session's report file implies a Telescope Safety irregularity at 03:34, but shows 'Check Telescope Safety' as "Ok" with the message  Telescope has moved back to a safe position (Az 11.2°)". 

  > Telescope Safety            Ok        2024-08-26 03:34  (Local, BST)
  > Telescope Safety            Ok        Telescope has moved back to a safe position (Az 11.2°)

The short slew from Targe 16/17 to Target 17/17 is relatively normal accept that it occurs with the cables still 'wrapped' .

During the later  Slew to Pre-Park position, the log file records telescope moving anti-clockwise from Az 20.0° to Az 2.3°, crossing Az 0° to Az 357.5° and then continuing to Az 180.7 / Alt 5.0.  

A Telescope Safety irregularity is later recorded in report file at 04:29 with the Warning "Telescope has moved beyond Az 345°" but a 'Telescope Safety' check at 03:34  is reported as "OK" with the message "Telescope has moved back to a safe position (Az 180.7°)".  

  > Telescope Safety     Warning   2024-08-26 04:29 (Local, BST)
  > Telescope Safety     Warning   Telescope has moved beyond Az 345°
 
    Slewing (Az/Alt)...  Ok        Slew Finished (61s overall)
    - Scope Speed:       Info      3.7°/s (229.4° scope slew in 61s)
 
  > Telescope Safety     Ok        2024-08-26 04:30 (Local, BST)
  > Telescope Safety     Ok        Telescope has moved back to a safe position (Az 180.7°)

A check was made in person the following day and it was confirmed that the SBIG Power & /ZWO USB3 cable bundle wasn't wrapped around the pier and was sitting on the left hand side of the pier as the cable bundle had caught on the altitude control knob on the equatorial wedge (presumably due to the unexpected slew past Az 360° on the previous night.   The cable bundle was released allowing to return to it normal position when at park.  The telescope was switched on and checks made that it was slewing normally and wasn't moving across the northern Az 0/Az 360 line.  The issue is put down to a random glitch in the LX200.  Issue closed after review 2024-08-06.  A separate Continuous Improvement ticket has been raised to examine if ObsManager/ObsOverseer need to do more to prevent the scope from entering the 'Az Limit area.

Conclusion

• The LX200 appears to have had a glitch whereby it didn't slew the scope in the correct direction but caused the slew to be in the wrong direction which resulted in the scope moving beyond Az 360°  which resulted in the main cable bundle wrapping around the scope's base (probably straining it in the process).
   
• The SBIG Power / ZWO USB3 cable bundle caught on the altitude control knob on the equatorial wedge and this strongly presumed to be due to the unexpected slew past Az 360°
   
• The damage to scope & cables could have been much worse if the coords of the target had caused an even longer slew beyond Az 360°
   
  
• The telescope may be in an endangered state at the start of the next automated session without prior visual checks & telescope tests by the user

Actions:

• Cables. Check Telescope cables before next live session.
  Done 2024-08-26  
  
  Checks showed that SBIG Power & /ZWO USB3 cable bundle wasn't wrapped around the pier and was sitting on the left hand side of the pier as the cable bundle was caught on the altitude control knob of the mount's equatorial wedge.
  
• Telescope. Check telescope positioning/slewing before next live session
  Done 2024-08-26  
  
  The observatory telescope was switched on and checks made that showed that it was slewing normally and wasn't moving across the Az 0/Az 360 line.
  
• AstroMain.  Review if AstroMains' telescope monitoring is doing enough to prevent or limit the scope moving past Az 360.
  To be done 2024-08-26+ 
  
  Continuous Improvement ticket has been raised to make this review.

Update 2024-08-25:

Is there any possibility that this was caused by a UT - BST time difference issue in some way ?

The slew to Target 16/17 (NGC 3690) that involved a slew from Az 30.6° / Alt=34.5°  to Az 11.2° / Alt:  26.1° was made at 2024-08-26 03:33 BST. This corresponds with a UTC Time of 02:33 UT, a 1 hour difference.

Just working for a moment with NGC 3690 at time 02:33 BST (ie one hour before the slew was actually made), a proposed theory is that at this time the target might have lain at Az 358-359° which could have possibly explained the clockwise slew if the scope was trying to avoid slewing across the Az 360° line, however at 02:33 BST the target NGC 3690 would have being lying at Az 2.0° /Alt 25.8°. This would still involve a anti-clockwise slew and it can't explain the clockwise slew that was actually made by the scope.

The reason why the scope made its clockwise slew to NGC 3690 at 03:33 BST taking it beyond the Az 360° line, wrapping cables in the process,  is still a mystery.

Is there a possibility that scope suddenly lost time information and suddenly thought it was at 2024-08-26 00:00 UTC (ie 2h 33m before the actual time).
At this time (01:00 BST) NGC 3690 would have lain at 348.5° / Alt 26.8°. This might explain why the scope thought it needed to slew clockwise, but how did the scope come to slew to correct sky position nevertheless (at Az 11.2).

Update 2024-09-18:

There was a further incident with this issue during Session S1246 (2024-09-17)  (see Major Issue, S1246 for full details),   telescope slew chart shows telescope slewing through Az 0°/Az 360° line and entering the telescope's 'no-slew / az limit' area on two slews.  This involved a slew from Az 292.2° to Az 13.0° (NGC 3206) at 01:06 and after an intervening session suspension from Az 18.6° to Az 173.0° (UGC 2028).

The following post on cloudynights forum may be worth keeping in mind https://www.cloudynights.com/topic/782282-meade-lx200gps-slewing-problem/

Update 2024-09-20:

Examination of past sessions involving slews to Azimuths < 15°, didn't encountered the issue:

 S1188 Az 10.3° (2024-02-21)
 S1175 Az 11.3° (2023-12-18)
 S1166 Az 11.3° (2023-11-12)
 S1164 Az 14.5° (2023-11-09)
 S1163 Az  9.5° (2023-11-08)
 S1160 Az  9.8° (2023-11-05)
 S1156 Az  9.4° (2023-10-11)
 S1141 Az 14.0° (2023-09-08)
 S1137 Az 12.5° (2023-09-01)
 S1132 Az  14.6° (2023-08-20)