ASCOM.SoftwareBisque Driver Error

[Edward Michaels]

A few nights ago, near the end of an all-night observing run, I found a “Hardware or Driver Error” had interrupted the run. I have an MX mount using TheSkyX for telescope control. What I find interesting is TheSkyX had actually closed (crashed?) which I’ve never seen before. One negative consequence was the telescope was still tracking which could have caused a pier crash if the event had occurred before meridian flip. A snippet from the log is shown below.

11:06:01 === Starting target repeat 315 of 999 ===
11:06:02 Selecting sR filter (6) for imaging
11:06:04 [flip check: Tn=60s HAc=15882s GW=T HAz=15943s DWz=T WF=no]
11:06:04 === Place in plan ===
11:06:04 Set 1 of 1
11:06:04 Target is "NSVS7330183" (1 of 1)
11:06:04 Repeat 315 of 999 for this target
11:06:04 Filter sR (1 of 1)
11:06:04 Image 1 of 1 for this filter
11:06:04 Imaging to NSVS7330183-sR-S001-R315-C001-B1-W
11:06:04 (taking 60 sec. exposure, sR filter, binning = 1)
11:06:04 (using Raw readout mode)
11:06:04 (starting [RBI] + exposure)
11:07:00 [**HARDWARE OR DRIVER ERROR**]
11:07:00 [Source: ASCOM.SoftwareBisque.Telescope]
11:07:00 [Slewing]
11:07:00 [This is not an ACP problem]
11:07:00 **Script Error**
11:07:02 Source: ACP Observatory Control Software
11:07:02 Message: The script was interrupted before completion.
11:07:02 Location: line 1879 column 25.

This event occurred again last night but this time I was awake and monitoring the run. The same thing happened, a script error was reported by ACP, the TheSkyX closed, and the telescope continued to track. A snippet from the log shown below gives some additional info compared to the first event. Since this was another all-night run (serial photometry) and the telescope had not yet crossed the meridian yet, I decided against a restart fearing another unattended event might cause a pier crash and damage hardware.

04:07:33 === Starting target repeat 12 of 999 ===
04:07:34 Selecting sI filter (7) for imaging
04:07:35 [flip check: Tn=60s HAc=-8585s GW=F HAz=-8525s DWz=F WF=no]
04:07:35 === Place in plan ===
04:07:35 Set 1 of 1
04:07:35 Target is "NSVS7330183" (1 of 1)
04:07:35 Repeat 12 of 999 for this target
04:07:35 Filter sI (1 of 1)
04:07:35 Image 1 of 1 for this filter
04:07:35 Imaging to NSVS7330183-sI-S001-R012-C001-B1-E
04:07:35 (taking 60 sec. exposure, sI filter, binning = 1)
04:07:35 (using Raw readout mode)
04:07:35 (starting [RBI] + exposure)
04:08:09 [**HARDWARE OR DRIVER ERROR**]
04:08:09 [Source: ASCOM.SoftwareBisque.Telescope]
04:08:09 [GetAndFixRaDec]
04:08:09 [This is not an ACP problem]
04:08:09 **Script Error**
04:08:10 Source: ACP Observatory Control Software
04:08:10 Message: The script was interrupted before completion.
04:08:10 Location: line 1879 column 25.

I’m unsure if this is an ACP or an ASCOM SoftwareBisque driver issue. The only software changes made before the occurrences was updating Maxim DL from version 6.27 to 6.28. I don't think this is a Windows update issue. The last Windows 10 quality update was on December 16 and a MS Defender Antivirius update on January 13. I have rebooted the computer many times since those updates including a couple of times yesterday afternoon (before last night’s event). Any help in resolving this issue would most appreciated. I’ve attached the logs from both nights.


Thanks!
Ed

[William Bristow]

Hi Ed.

As a user of the SkyX and a series 1 MX myself it is difficult to think of anything that ACP, the Bisque ASCOM driver or MaxIm could do that would cause TheSyX to crash, this has to be something specific to the Paramount, Windows or TheSkyX.

The logs show that the last instruction before the problem was to start an exposure, are you using the Paramount Versa Plate USB ports to connect to the camera?

If so, disconnect all USB devices that are using the Versa Plate USB ports and run USB cables direct.

I have had so many problems with the internal USB cables that run from the MKS5000 control board up to the Versa Plate outlets that I stopped using them.
It's conceivable that a problem with those internal USB cables and connections to the devices, or the devices themselves, can break the control link between the Paramount and TheSkyX, causing TheSkyX to quit while leaving the mount still tracking since they all use the same internal hub on the Paramount control board.

A further issue may occur when running additional through-the-mount cabling on the Paramount as there is just insufficient room in the RA axis of the MX and eventually the cables becoming tangled in the RA axis and pull the internal USB cables partially out of their sockets on the MKS5000 board, which also can cause the Paramount to TheSkyX USB link to fail and TheSkyX to crash.

If this applies to your mount then drop the front of the MKS5000 tray and check that both the through-the-mount Versa Plate internal USB cables are still firmly pressed into their respective sockets at the left-front of the MKS5000 board.
From memory I think the sockets used for the Versa Plate USB outlets on the MKS board are USB0 and USB1 while socket USB2 is left empty.

Besides the above you might be a little behind with the Windows updates, there were two major updates on my Windows 10 Pro system this week, .NET 3.5-4.8 as well as the usual Windows quality updates and several Windows Defender signature and engine updates (which I haven't bothered listing separately):

KB5009543 Quality update 2022-01 for Windows 10 platform 21H2.
KB5008876 .NET 3.5-4.8 update 2022-01 for Windows 10 platform 21H2.

My Windows 10 PRO platform 21H2 is now at build 19044.1466.

It's possible your computer was trying to install either of the above updates and that caused the issue, check for updates manually.

Recheck also that your dedicated Windows Power-Plan for the observatory computer has retained the correct settings for USB sleep.
Here is a link to a document I wrote a few years ago on the Diffraction Limited forum that details how to create a bespoke Power-Plan in Windows:

https://forum.diffractionlimited.com...ate-1909.6546/

Lastly, check in MaxIm's own logs to see if anything else was reported from the camera(s) before TheSkyX crashed that might help point down the exact sequence of events (such as loss of communication, USB errors etc).

That's all I can think of at the moment, if I have any other ideas I'll come back to the thread later.

William.

[Bob Denny]

11:07:00 [**HARDWARE OR DRIVER ERROR**]
11:07:00 [Source: ASCOM.SoftwareBisque.Telescope]
11:07:00 [Slewing]
11:07:00 [This is not an ACP problem]

To add a bit to William’s comprehensive reply, the Source is SoftwareBisque and the error message from TheSky “slewing” is not much help. The part about “this is not an ACP problem” is really true. It is happening in response to ACP polling the mount info from TheSky to keep the ACP console and web UI displays (RA, Dec, HA, etc) updated. It does this every 6 seconds. Why TheSky threw an error is unknown own to me. If this “just started happening” I would look for maybe changes in temperature causing a marginal USB controller to hiccup or ?? I just don’t know what specifically happened inside TheSky.

[Edward Michaels]

Hi William and Bob


I have also had issues with the USB cables in the MX and com errors when the camera’s (SBIG STXL) USB is plugged into the Versa Plate. I solved the camera issue by running a dedicated USB line from the camera directly to my office desktop (150’ distance) using a Icron USB Ranger extender. USB dropouts are now very rare. The only USB device connected to the Versa Plate is an Optec focuser which has had no issues. I also minimized the cables running through the RA axis. This seems to have eliminated the cables tangling which did occasionally pulled the USB cables from the sockets on the MKS5000 board.


I generally do monthly Windows 10 updates. In between updates I have the updater paused to prevent unexpected reboots and changes to the Windows operating system that sometimes cause issues with observatory software. My computer’s operating system has Windows 10 Home 21H2 at build 19044.1415. The two updates you listed had not been installed so I did that this morning.


Thanks for the power plan suggestions. I had already set the computer to never sleep but not the USB hubs. They are now set to never sleep as well.


I had not thought to check the MaxIm logs. I discovered something interesting at the moment the two failures occurred. These are the MaxIm log entries at the time of each of the two events.


11:07:02$5 Guider algorithm 'Single Star' ended
11:07:02$5 Guider Calibration Completed
11:07:02$4 Camera Exposure Aborted


I don’t understand the first two log entries since I don’t use autoguiding and auto guiding is disabled in ACP. The MX can take 3 -5 minute exposures with no apparent tracking issues. The exposures I use are 90 seconds or less so autoguiding is not necessary. I went backed and looked through several Maxim logs for nights that completed successfully at the time specified in the ACP plan. After the last image had downloaded those same two log entries also occur but not the third one (Camera Exposure Aborted). Could this have triggered the error seen in the ACP log? If so, why was the source of the error given as ASCOM.SoftwareBisque.Telescope?


I have turned on the Trace feature under telescope setup in ACP. The next time this occurs maybe that trace log will give some additional clues.


Thanks so much for helping with this issue!


Ed

[Bob Denny]

And thank you so much for coming back here and providing all of this info that may help others in the future. Most appreciated!