I ran through a test sequence today and the Digital Loggers shutdown sequence ran successfully after the camera warm-up time elapsed. The equipment disconnects and switch shutdowns went gracefully.
Thanks!
Mike
Tonight I noticed something not seen before with the new beta version. During and after an auto focus session, the focus images all display the stars HFR values. If I toggle the star icon on the image panel twice, the values disappear. I usually leave that selection disabled. When a captured image is displayed, the HFR values aren’t displayed, it’s only with focus. It’s no big deal, but I wanted to let you know it was happening.
Mike
Hi SGP Team.
I have not had a chance to test with Beta version 4.0.0.636. However, last night I was using version 4.0.0.617 and when the sequence ended this morning SGP Crashed. Below is the end of the log file from the run. It looks like it was still having issues with the ASCOM Switches as the event occurred right after it sent notification to switch off my Dew Heater on my Digital Logger Switch. I will install 4.0.0.636 today and run again tonight and see if the issue is resolved.
> [11/03/20 05:24:46.986][DEBUG][Sequence Thread][SQ;] Sequence complete.
> [11/03/20 05:24:46.986][DEBUG][Sequence Thread][SQ;] No valid targets remain, aborting...
> [11/03/20 05:24:46.987][DEBUG][Sequence Thread][SQ;] ********* Run post sequence *********
> [11/03/20 05:24:46.987][DEBUG][Sequence Thread][SQ;] SGPro capture cal frame mode is OFF...
> [11/03/20 05:24:46.987][DEBUG][Sequence Thread][SQ;] Clearing timed monitoring events...
> [11/03/20 05:24:46.987][DEBUG][Sequence Thread][SQ;] Checking RunEndOfSequenceEquipmentOptions, force = True
> [11/03/20 05:24:46.987][DEBUG][Sequence Thread][SQ;] In RunEndOfSequenceEquipmentOptions
> [11/03/20 05:24:48.257][DEBUG][Image History Worker][SQ;] Star detection using min star size of 3px...
> [11/03/20 05:24:48.257][DEBUG][Image History Worker][SQ;] Star detection using max star size of 60px...
> [11/03/20 05:24:48.297][DEBUG][Image History Worker][SQ;] Find stars took: 1660 ms...
> [11/03/20 05:24:48.297][DEBUG][Image History Worker][SQ;] Star list contains 370 stars...
> [11/03/20 05:24:48.297][DEBUG][Image History Worker][SQ;] Calculating HFR with sample size: 6
> [11/03/20 05:24:48.403][DEBUG][Image History Worker][SQ;] Image analysis (async) END
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Observatory: Calculating new position using:
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Azimuth: 230.495833333333
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Altitude: 44.7122222222222
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Hour Angle: 33.2800916666667
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Pier Side: East
> [11/03/20 05:24:55.234][DEBUG][Dome Thread][SQ;] Observatory: No adjustment needed.
> [11/03/20 05:24:55.587][DEBUG][Dome Thread][SQ;] Dome thread is IDLE...
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Observatory: Calculating new position using:
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Azimuth: 230.538333333333
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Altitude: 44.6822222222222
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Hour Angle: 33.3240375
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Pier Side: East
> [11/03/20 05:25:05.399][DEBUG][Dome Thread][SQ;] Observatory: No adjustment needed.
> [11/03/20 05:25:05.753][DEBUG][Dome Thread][SQ;] Dome thread is IDLE...
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Observatory: Calculating new position using:
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Azimuth: 230.5825
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Altitude: 44.6536111111111
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Hour Angle: 33.3657666666667
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Pier Side: East
> [11/03/20 05:25:15.551][DEBUG][Dome Thread][SQ;] Observatory: No adjustment needed.
> [11/03/20 05:25:15.904][DEBUG][Dome Thread][SQ;] Dome thread is IDLE...
> [11/03/20 05:25:16.945][DEBUG][Main Thread][SQ;] PopulateDataModel: Transferring view to the data model...
> [11/03/20 05:25:16.981][DEBUG][MF Update Thread][SQ;] Performing serialize...
> [11/03/20 05:25:18.219][DEBUG][Main Thread][SQ;] Adding sequence level notification: Warming the CCD...
> [11/03/20 05:25:18.224][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Warming the CCD...
> [11/03/20 05:25:18.225][DEBUG][Sequence Thread][SQ;] Stopping auto guiding...
> [11/03/20 05:25:18.225][DEBUG][Sequence Thread][SQ;] Attempting to stop PHD2 guiding...
> [11/03/20 05:25:18.225][DEBUG][Sequence Thread][SQ;] Checking PHD2 state...
> [11/03/20 05:25:18.225][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Pre-Wait : Guiding
> [11/03/20 05:25:18.225][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method": "get_app_state", "id": 1001}
>
> [11/03/20 05:25:18.226][DEBUG][TEC Thread][SQ;] SGM_CHANGE_COOLER_TEMP message received...
> [11/03/20 05:25:18.226][DEBUG][TEC Thread][SQ;] TEC Change: Starting...
> [11/03/20 05:25:18.233][DEBUG][TEC Thread][SQ;] TEC Change: Changing temp from -20.03 to 20.00 in 900 seconds...
> [11/03/20 05:25:18.325][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Post-Wait: Guiding
> [11/03/20 05:25:18.325][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method": "stop_capture", "id": 1004}
>
> [11/03/20 05:25:18.325][DEBUG][Sequence Thread][SQ;] Checking PHD2 state...
> [11/03/20 05:25:18.325][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Pre-Wait : Guiding
> [11/03/20 05:25:18.325][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method": "get_app_state", "id": 1001}
>
> [11/03/20 05:25:18.425][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Post-Wait: Guiding
> [11/03/20 05:25:19.425][DEBUG][Sequence Thread][SQ;] Checking PHD2 state...
> [11/03/20 05:25:19.425][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Pre-Wait : Stopped
> [11/03/20 05:25:19.425][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method": "get_app_state", "id": 1001}
>
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Post-Wait: Stopped
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] PHD2: Successfully stopped PHD2...
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] Autoguider (PHD2) stopped Successfully
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] Waiting for Autoguider to stop...
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] Checking PHD2 state...
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Pre-Wait : Stopped
> [11/03/20 05:25:19.728][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method": "get_app_state", "id": 1001}
>
> [11/03/20 05:25:19.830][DEBUG][Sequence Thread][SQ;] PHD2 GetPhdStatus - Post-Wait: Stopped
> [11/03/20 05:25:19.830][DEBUG][Main Thread][SQ;] Adding sequence level notification: Auto guider has been stopped successfully.
> [11/03/20 05:25:19.835][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Auto guider has been stopped successfully.
> [11/03/20 05:25:19.837][DEBUG][Main Thread][SQ;] Adding sequence level notification: Disconnecting auto guider equipment...
> [11/03/20 05:25:19.842][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Disconnecting auto guider equipment...
> [11/03/20 05:25:19.842][DEBUG][Sequence Thread][SQ;] Disconnecting auto guider equipment...
> [11/03/20 05:25:19.843][DEBUG][Sequence Thread][SQ;] Sending to PHD2:
> {"method":"set_connected","params":[false],"id":1007}
>
> [11/03/20 05:25:19.848][DEBUG][Sequence Thread][SQ;] Parking telescope...
> [11/03/20 05:25:19.856][DEBUG][Main Thread][SQ;] Adding sequence level notification: Parking the mount...
> [11/03/20 05:25:19.864][DEBUG][Sequence Thread][SQ;] Sending Notification: Status - Parking the mount...
> [11/03/20 05:25:19.867][DEBUG][Telescope Thread][SQ;] SGM_TELESCOPE_PARK message received...
> [11/03/20 05:25:19.867][DEBUG][Telescope Thread][SQ;PK;] ASCOM Telescope: Park message received.
> [11/03/20 05:25:19.867][DEBUG][Telescope Thread][SQ;PK;] ASCOM Telescope: Dome slave set to park mount first, parking mount.
> [11/03/20 05:25:19.870][DEBUG][Main Thread][SQ;PK;] Adding sequence level notification: Mount is parking.
> [11/03/20 05:25:19.879][DEBUG][Sequence Thread][SQ;PK;] Sending Notification: StatusParkScope - Mount is parking.
> [11/03/20 05:25:19.881][DEBUG][Sequence Thread][SQ;PK;] Switches: Set state for sequence end...
> [11/03/20 05:25:19.883][DEBUG][Main Thread][SQ;PK;] Adding sequence level notification: Set switch "6 Dew Heaters - 6 Dew Heaters" to "0.00"!
> [11/03/20 05:25:19.888][DEBUG][Sequence Thread][SQ;PK;] Sending Notification: Status - Set switch "6 Dew Heaters - 6 Dew Heaters" to "0.00"!
> [11/03/20 05:25:19.904][DEBUG][Telescope Thread][SQ;PK;] ASCOM Telescope: Sending park...
> [11/03/20 05:25:23.394][DEBUG][Main Thread][SQ;PK;] Adding sequence level notification: Set switch "Temperature - Ambient Temperature" to "Not Available"!
> [11/03/20 05:25:23.401][DEBUG][Sequence Thread][SQ;PK;] Sending Notification: Status - Set switch "Temperature - Ambient Temperature" to "Not Available"!
> [11/03/20 05:25:23.401][DEBUG][Sequence Thread][SQ;PK;] GlobalExceptionHandler caught: ASCOM Switch does not understand Not Available!
> [11/03/20 05:25:23.401][DEBUG][Sequence Thread][SQ;PK;] InnerException: Empty
> [11/03/20 05:25:23.402][DEBUG][Sequence Thread][SQ;PK;] Call stack: at SequenceGenerator.AscomSwitch.cy(String A_0)
> at s7.pn(Dictionary`2 A_0, Boolean A_1)
> at s7.pn(ad A_0)
> at tv.rv(Boolean A_0, Boolean A_1)
> at tv.r4(Boolean A_0)
> at tv.afo()
> at tv.agn()
> at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
> at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
> at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
> at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
> at System.Threading.ThreadHelper.ThreadStart()I just installed Beta 4.0.0.636 and when I launch SGP it is still throwing an error related to the Pegasus Astro Ultimate Power Box V2. Not sure if this is an issue with SGP or the Power Box ASCOM Driver. I did check to make sure I am running the latest version of their driver which was released in Jun/20 per their website.
I get the same result - LOST CONNECTION TO POWERBOX. After loading - when I try access equipment profiles (from previous version), cannot do so. I get another error related to the PEGASUS issue.
Beta 4.0.0.636 “Open Image” doesn’t work for me - tried laptop and desktop. Allows file to be selected and then hangs with SGP being unresponsive. File is 120mb FITS.
The desktop shows “Ready” bottom left hand corner.
The laptop says Loading Target xyz in the background.
UPDATE This now seems to be working after rebooting SGP on both devices. This is odd because I had tried rebooting the devices before logging the defect and at that time it didn’t cure it. I cant currently recreate the issue - must be down to a specific scenario(s)
Hi, I am also seeing SGP 4.0.0.636 hang following an ‘Open Image’ request.
The problem arises both if the Open is requested while targets are being loaded and also when all are loaded.
I have to go to Task Manager in order to exit SGP.
Thanks, this issue was resolved in 636.
It seems unique to Pegasus, see post below…
What version of SGPro are you using?
I will take a look
I take it back, this does not seem to be an SGPro issue. In this case, the Pegasus driver is presenting that message box. In general, drivers should never attempt to control or alter the user interface unless it is expected as part of a contract (e.g. settings dialogs, etc)… especially if it blocks further execution of the consuming application (this type of message box does block). It seems like the root of the problem is that the driver does not tell SGPro that there was a problem connecting, but rather indicates the connection went fine and then, afterward, not as part of the communication to establish the connection, pops this error up, despite never actually being connected. Instead of “polling” for a lost connection or other error state, ASCOM drivers should just alter internal state to reflect the issue and then, when an action is requested that, due to the error state, cannot be fulfilled, an exception should be raised and place the burden of communication on the client application (SGPro) (i.e. drivers should behave in a transactional way). SGPro asks for something and the driver either handles it or says why it can’t, but does not attempt to communicate in an unsolicited manner.
Did anyone follow up on this with Pegasus? I just got a PPBA and installed SGP 4.0.0.637 and this error message keeps popping up. I’ll reach out to them if no one else has. In the meantime I’ll have to go back to the stable release.
I am running SGP 4 Beta 636 and have noticed a few issues with the ZWO native driver. I understand that the native driver is no longer supported in SGP but these issues were not present in SGP 3.2. If this is part of the evolution of the software, so be it.
I am using a ZWO ASI1600 camera with the native driver and these are the issues I have encountered:
-
Offset is no longer set in the native driver even if a value is selected in Event Offset. Can gain and offset still be assigned on a per event basis? I understand that ASCOM 6.5 exposes offset and sooner or later I’ll switch to that approach.
-
Autofocus does not work if ASTAP focus metric is selected. Autofocus fails to download frames and SGP locks up. Things still work fine with HFR focus metric.
Should I assume that ZWO native driver should no longer be used with SGP 4? Have other people noticed this behavior?
thanks,
Luca
Correction: it appears that offset in the ZWO driver is still set correctly. However, the %co tag in the filename does not report the set offset and the filename shows the tag “Not Set”. This was not the case in SGP 3.2.
The FITS header for camera offset contains the correct value that was set in the Event settings window.
I reported another issue in the Premium Support forum where when I switched to the ZWO ASCOM driver, I cannot edit gain or offset at all in the Event settings window.
I’m not sure if this has been posted elsewhere, but as long as the Pegasus Powerbox is connected and the software running then this error will not pop up.
I reached out to Pegasus about this and after a little back and forth the reply I got was “For some reason the ASCOM driver is clicked by SGP on startup. As you do not have the powerbox connected to your PC the driver reports this error.”
Technically I do have the powerbox connected to the PC via USB and even powered on, but I did not have the software running and devices powered on.
In any event, it is a slight annoyance that I have to start the Pegasus software before I start SGP otherwise that pop up error message will just keep popping up over and over again, but I can deal with it.
Thx Joel, I meant to send this over to Pegasus, but got distracted with other beta things. Please be aware that this issue could mean that, if your power box disconnects or if the driver thinks it disconnects, depending on what the sequence is doing at the point of disconnect, it has a high likelihood of hanging the sequence (because the type of dialog they display is “modal” and does not allow an application to continue functioning normally until it is acknowledged)
No problem Ken, that’s why we test beta software.
Hi All.
I have had a couple clear nights where I have been able to do some additional testing using the latest Beta version 4.0.0.636. I thought I would share what I have found in case it might be useful for further debugging.
The issue with the Pegasus Astro UPBV2 is still there, but as others have mentioned the current work around is to just make sure the UPBV2 is running before starting SGP. Hopefully eventually this will be fixed as I don’t always have the PC connected to equipment when I am planning a nights imaging session. That said, I can live with it for now.
My bigger concern is there are still some issues with the ASCOM Switches turning equipment off at the wrong time and that it appears that in some cases the mount continues to track during a recovery event even when close to a Pier Flip. Last night I was alerted by GNS around 2:15AM that there was an issue with my imaging session. When I checked I found that the mount had hit the safety stop and parked in place, the dome was still open and the UPBV2 power had been turned off.
Looking through the log, it appears that around 01:26:24 on my second target of the night the sequence encountered an unsafe condition started warming the camera, parked the mount and close the Dome around 3 mins later. The good news is that it did wait for the camera to warm up before at 01:42 :30 it switched off the UPBV2 power for my Camera, FW, and Focuser.
The sequence then went into Recovery Mode and attempted to restart the sequence starting at 01:47:29 even though it could no longer access the Camera, FW or Focuser because power had been switched off after the unsafe condition. What is not good is that even though it could not connect to all equipment it unparked the mount and reopen the shutter at 01:48:11 and then proceed to attempt at 2 recovery sequences for the next 30 minutes or so without the Camera. Of course, these recovery events failed because it had no way of performing the centering action without the Camera. The biggest problem was that the mount continued to track during these recovery events even though at 02:05:15 the log shows that the mount was 479.3 seconds from a Pier Flip. It did not stop the sequence until 10 mins later. Which means that if I didn’t have safety stops in place it could have tracked into the Pier. I received an audible alert in GNS at around 02:15 that something was wrong. By that time, the mount had tracked into the safety stop and parked in place. The sequence aborted without closing the dome. I am not sure if I had given SGP a few more minutes before manually intervening if it would have eventually closed the dome.
Some observations:
- I don’t think that the power switches should be turned off until all recovery events have been exhausted or after the very last event for the night. It looks like with 636 you fixed the issue with the Switches turning off before the Camera warmed up, but you may need to look into what happens with the Switches during a Recovery attempt.
- If recovery cannot find equipment like a camera which is required for centering, focusing, etc. that it should abort the Recovery attempt before unparking the mount or opening the dome.
- When close to a Pier flip, it would be nice if SGP took note of how far away from a the Pier the mount is so that it knows to check back and abort the sequence during the recovery if the Pier flip has not occurred within the expected time frame.
I am not able to include the log here because it hit the max line limit, but it can be downloaded from OneDrive here. The portion of the log that you likely find the most useful is between 01:00 - 02:15. At 02:15 I intervened and restated the sequence manually.
Hope this helps.
Andrew J
Hello,
I cannot connect my ASI2600 with this version. I get the message: "Error connecting to ASI Camera (1)! Method not found: ‘Int32 ASCOM Driver Access. Camera.get_Offset0’.
The camera worked fine using 4.0.0.617. Anyone know what’s wrong?
Thank you
This true. It is not supposed to do this and was seemingly broken by the new code to defer switch state until after camera warmup. SGPro makes inclusion of logs easy:
More information here How to Submit Logs in SGPro - SGPro Support - Main Sequence Software
The beta is currenty only compatible with ASCOM 6.5 and higher (this will change before release though).
Oh ok. Thank you