End of sequence does not park scope


#1

I have an AP 1200GTO mount with Lodestar OAG and Home Dome DDW. I am running 2.5.0.11. At the end of a sequence last night, the dome closed but the telescope remained unparked. “Park when sequence completes” and “Stop tracking when sequence completes” were ticked in the sequence. The scope did stop tracking as shown in the logs and the AP V2 driver UI. I was able to use the driver UI to manually park.

From the logs, it looks like a .net exception from DDW but the dome parked ok while the scope did not. I also see a lot of PHD2 communication even though guiding has stopped. Any ideas? Here’s a snippet from the log:

2/15/2016 12:49:26 AM] [DEBUG] [Sequence Thread] Checking RunEndOfSequenceEquipmentOptions, force = True
[2/15/2016 12:49:26 AM] [DEBUG] [Sequence Thread] In RunEndOfSequenceEquipmentOptions
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Stopping auto guiding…
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Attempting to stop PHD2 guiding…
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[2/15/2016 12:49:58 AM] [DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP message received…
[2/15/2016 12:49:58 AM] [DEBUG] [TEC Thread] TEC Change: Starting…
[2/15/2016 12:49:58 AM] [DEBUG] [TEC Thread] TEC Change: Time change is 0, setting to 0.00…
[2/15/2016 12:49:58 AM] [DEBUG] [TEC Thread] SGM_CHANGE_COOLER_TEMP complete…
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “stop_capture”, “id”: 1004}

[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[2/15/2016 12:49:58 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Checking PHD2 state…
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] PHD2: Successfully stopeed PHD2…
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Autoguider (PHDv2) stopped Successfully
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Disconnecting auto guider equipment…
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Sending to PHD2:
{“method”:“set_connected”,“params”:[false],“id”:1007}

[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] Stop telescope tracking…
[2/15/2016 12:49:59 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: Setting tracking state to False
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] Parking telescope…
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: Park message received.
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: closing observatory shutter…
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] Dome: Closing Shutter
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: parking observatory…
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: Error in Park : CheckDotNetExceptions ASCOM.DigitalDomeWorks.Dome Park System.InvalidOperationException: Remote operation refused (atomic remote operation already in progress) (See Inner Exception for details) (System.InvalidOperationException: Remote operation refused (atomic remote operation already in progress))
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 630
at ASCOM.DriverAccess.MemberFactory.MethodTargetInvocationExceptionHandler(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 678
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 487
at ASCOM.DriverAccess.Dome.Park() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Dome.cs:line 237
at ih.i5()
at fh.gh()
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Aborting sequence timer thread…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Sending sequence end notification…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Resetting UI elements…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Checking if sequence has work left…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] No work left…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Updating big status…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Enabling menu items…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Set target icons…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Removing camera protection…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] Monitoring system shutdown…
[2/15/2016 12:50:00 AM] [DEBUG] [Main Thread] SequenceEnds complete…
[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] Restoring system standby state…
[2/15/2016 12:50:59 AM] [DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[2/15/2016 12:50:59 AM] [DEBUG] [PHD2 Listener Thread] Checking PHD2 state…


#2

Please attach the entire log. I know I’d had issues like you’re describing but the new version cleared it up for me.


#3

You can get it here:

Rather a messy log due to 20+ mph winds that were blowing the scope around so the autoguider would take a long time to settle.

Thanks for looking at it.

Kent


#4

Looks like your dome is slaved to the mount. In this case, we do not call park on the mount if the park command for the dome fails (just in case parking the mount after dome park failure will unceremoniously slam your gear into something). In terms of the dome failure, I am not exactly sure what this means:

[2/15/2016 12:50:00 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: Error in Park : CheckDotNetExceptions ASCOM.DigitalDomeWorks.Dome Park System.InvalidOperationException: Remote operation refused (atomic remote operation already in progress)

My only guess is that the dome is still busy closing the shutter and refuses the command to park. @Jared usually handles most of the observatory stuff… he may have some ideas.


#5

Thanks for looking at it Ken. The dome actually successfully closed but threw a bunch of errors such as the one you show. I see your logic there, in case it is a roll-off roof or something. Maybe Tim Long at Tigra Astronomy will see this and comment; I think he did the Home Dome ASCOM driver.

It’s not a big issue for me. Although I would prefer the dome close first (think rain), I’ll try changing the observatory settings to park the mount first so if the dome errors out, it won’t affect the park.

Regards,
Kent


#6

I don’t recall seeing Tim Long post here, if you want to contact him then it’s best to do so directly. If that’s one of his drivers he will want to hear about it.

However looking at the log there seems to be a close shutter command followed by a dome park command immediately afterwards. The park command is rejected with an InvalidOperationException. This could all be said to be correct, the dome is not in a state where it can be parked and so the error is returned.

Better may be to close the shutter and wait for it to finish closing before sending the park command.

Chris


#7

Thanks Chris. I’ll contact Tim and see what he says. Like I say, It’s not a big issue for me. I do want the dome to work right, though.

Kent


#8

Based off of Chris’ comment it sounds like you may need to select either park or close the shutter but maybe not both. Park may have the effect of closing the shutter and returning to a home position, or just doing nothing and staying where it’s at. Park can mean different things to different devices. I would first disable the option for “Mount Park Closes Shutter” and just leave “Park Observatory with Mount” checked and see what happens. If that doesn’t get you want you want try the reverse.

If that still doesn’t work let us know and we can see if we can work something out :slight_smile:

Thanks,
Jared


#9

This may be relevant.


#10

Thanks Jared. I will try some things and see.

Kent


#11

OK. 2.5.0.12 will ensure that shutter commands complete prior to sending any other commands (synchronous shutter operations).


#12

I thought that the dome/shutter errors (reasonably) caused the mount park not to happen. Can you tell that the shutter close command completes even with the errors?

Regards,
Kent


#13

The reason the mount did not park is because the the dome park failed. The dome park failed because we sent commands to it faster than it likes to handle them (close shutter followed by park with no delay in between). Now we just wait until the shutter reports close, then we park the dome. Success here will allow the mount’s park command to be issued.

I didn’t see any errors that weren’t related to the “atomic operation” issue.


#14

Thanks for working on the issue.

Regards,
Kent


www.mainsequencesoftware.com