3.1.0.394 Beta (and 387) Crash in Frame and Focus

When I run Frame and Focus in continuous mode fo ra ZWO ASI 1600MM pro camera with 2x2 binning running exposures 3 seconds or less, SGP will unexpectedly crash with no errors or warnings (it vanishes). I notice that the CPU usage is about 38% when in this mode. Simultaneously, I have PD2 running (2 sec exposure time), Celestron’s CPWI ASCOM driver and application, StellariumScope and Stellarium. Total CPU time is < 80% (Stellarium uses about 15% CPU).

The other thing that happens is that when I have SGP F&F exposures at 1 or 2 seconds, CPWI will occasionally time out and disconnect from the mount (connected through hand controller via a USB hub port) All cameras, focuser, etc. also connect via the USB 2/3 hub.

If I connect the ASI 1600 camera to SharpCap Pro 3.2 instead of SGP, everything runs without any problems. SharpCap with exposure times of 1/2 or 1 second only take about 8 to 8.5% CPU time, and CPWI never times out.

So, Frame and Focus with short exposures is eating a significant amount of CPU resources and the busy traffic is causing some kind of fatal error. Note that I am not running a sequence or doing anything in SGP other than F&F. I am not saving images or doing an HFR. I have a locked stretch in the image. All gear is connected and the only things active are the mount/CPWI, the ASI1600 and ASI174 guide cam (in PHD2 - not guiding).

Mark W

Lenovo Thinkpad 11e with latest Windows 10
Celestron CPWI V2.2.3 (latest production)
Latest ZWO ASCOM and direct drivers
Pegasus Astro FocusCube2 with latest ASCOM driver

Please file support requests here SGPro Support

See here for information we need to help:

I doubt this is coming from SGPro. Every single camera uses the same Frame and Focus code and there aren’t really any other reports of this. This points to an issue specific to ASIs. So…

  • Are you using the ASI ASCOM drivers? If not, you should be.
  • Have you made sure that both the native ASI and ASCOM ASI drivers are up to date?
  • Hubs and cameras can be problematic. Please at least see if the issue occurs when connected directly to the computer.

Unfortunately, comparisons between SGPro and other software are not meaningful. SGPro does a lot of things to and with a connected camera. It is rough on drivers because it tests them in a complex multi-threaded environment… That said, SGPro does not do anything “illegal” or outside of standards and norms (for ASCOM)

Ken,

Thanks for the prompt reply.

I was using the native driver as it allows me to set the gain AND the offset. The ASCOM driver does not allow for the offset. I am trying a test with the ASCOM driver.

I updated all ZWO drivers yesterday.

In the field, I have no option but connect to the hub and also use the ZWO ASI1600 hub.

I do know that SGP does much more processing and other tasks. I was trying to determine if it was hardware, software or I/O and CPU loading.

Mark

Understood… was just indicating that you should attempt this as a means of understanding where the problem lies… wasn’t implying that you should move to this configuration.

I tested the ZWO ASI ASCOM driver. Same thing happened with 1 sec exposures in F&F: SGP vanished.

At this point, we would need to see logs.

Ken,

After Christmas, I will try frame and focus with the new version of SGP using 1 sec exposures and with all imaging and control software running. By then, I will have a new USB 3 hub with 7 ports for all gear to have its own connection (ZWO ASI 1600 on camera hub is problematic, and Celestron CPWI software using a WiFi connection can timeout when SGP is very busy ).

Mark

Mark,

Did you solve the issue? Im having similar problems when i run Frame and focus. CPWI looses connection with the mount. It seems to be a little bit more stable with longer exposures. But for me it looks like something happends during the download process.

I currently run on an old computer with usb 2 so im thinking that miggt be a part of the problem. I also have the same issue with ASIcap.

/Martin

I ran a simple test with Celestron CPWI running and SGP 3.1.0.432 in Frame and Focus Mode. When I set binning on the ZWO ASI 1600MM Pro camera to 1x1 with 1 or 2 second exposures, CPWI would loose its connection to the mount. The laptop running Windows 10 Pro is connected to a powered USB 3 hub where each device on my rig has a dedicated USB port. I have reported the conflict between CPWI and SGP to both MSS and Celestron. On the CPWI side, the real-time interface to the scope may not be as robust as it needs to be. On the SGP side, SGP should never crash (disappear without an error message). However, in F&F mode, I changed to 2x2 binning with 1 or 2 second exposures (see log). CPWI was fine, but SGP crashed without warning. The log shows nothing other than issues with analyzing the images which are looking at my ceiling through an Ha filter.

Mark W

Ok, i have not experienced a lot of crashes with SGP, a few occasions when it was not responding but it does not disappear as yours.

Have you tried to connect the camera directly to a usb 3 port on your computer instead of through a hub?

The next thing i will try is to run it on another computer with usb 3 to see f it works better.

I know this is a SGP forum, but posting the messages from PWI here, maybe you can confirm that you are getting simmilar messages when your PWI looses connection.

2020-01-03 22:49:40.614: ERROR Mount error No response from device, wait for packet Src:32 Dst:17 Cmd: 6

2020-01-03 23:20:47.667: ERROR Mount error No response from device, wait for packet Src:32 Dst:16 Cmd: 19

2020-01-03 23:54:05.014: ERROR Mount error No response from device, wait for packet Src:32 Dst:17 Cmd: 1

Martin

As it turns out, it was a bad USB 3 cable from the ASI 1600 camera to the USB 3 hub. The camera and its on-camera USB 2 started working again when I changed the cable. It was a cable that sometimes worked, and then would cause the SGP crashes.

The conflict with CPWI still exists, and Derik at Celestron has indicated in the Team Celestron forum that he is working on the timeout problem for the next version.

Mark