Roof did not close

Sequence Generator
#1

Just finishing a sequence. All went well until it was supposed to park and close the roof as a pre-event for the darks. I thought I had read all the instructions and set everything right, the mount did park but no roof closure. I was watching so just hit the control panel button for roof close and it then closed but did not do it by itself. Screen captures of what I think are the three relevant settings. Did I miss something and, if so, what?

Should “park observatory with mount” have been checked? I thought that was not relevant for roofs.

#2

Can you post your log?

Thanks

Jared Wellman
Co-Owner and Developer
Main Sequence Software
www.mainsequencesoftware.com

#3

Yes, it is quite large (210 mb) the latter part being many errors:

Full Log File

It looks like the problems began as you see below, it appears that scope had been disconnected from TheSkyX (it had, I noticed that in TheSky status). I did think that was odd since it seemed to me that should have just said “Parked” in TheSkyX. I can have the roof close first if that would help as there is no risk of roof strike with my system.

Also, FYI, if you park the scope from within TheSky, it just says “Parked” and not “Not Connected” which is what
it was saying after it parked during the sequence.

Is it possible there is some setting within the Generic ASCOM hub that is causing the disconnect after park? I cannot find a detailed setup for that hub although I did note in ASCOM Profile Explorer that in the profile for Hub.Telescope there is an option for AdvancedSetup that is defaulted to “False”.

[6/4/2014 3:16:09 AM] [DEBUG] [Sequence Thread] Event[3] frame count: 0/8…
[6/4/2014 3:16:09 AM] [DEBUG] [Sequence Thread] Getting next event (3)…
[6/4/2014 3:16:09 AM] [DEBUG] [Sequence Thread] Running event related park…
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] PHD Advanced: Stop
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] PHDA: Sent command (PHD_STOP)…
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] PHDA: Received (0)…
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] Autoguider (PHD) stopped Successfully
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Park message received.
[6/4/2014 3:16:09 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Dome slave set to park mount first, parking mount.
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera status check: Unknown (12)
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera: end exposure called…
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera: read data…
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera: starting readout…
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera: reading lines…
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SBIG Guider Camera: end readout…
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SgApi - Guider Capture Complete
[6/4/2014 3:16:12 AM] [DEBUG] [API Guider Capture Thread] SgApi - Guider Image Added to Repo
[6/4/2014 3:16:12 AM] [DEBUG] [Unknown] SgApi - Guider image retrieved
[6/4/2014 3:16:15 AM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[6/4/2014 3:16:15 AM] [DEBUG] [MF Update Thread] Performing serialize…
[6/4/2014 3:16:34 AM] [DEBUG] [Sequence Thread] ASCOM Telescope: Error in IsSlewing : Not connected to TheSky. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Not connected to TheSky.
— End of inner exception stack trace —

#4

Just FYI, in case it is the Generic Hub, I activated the advanced setup and that dialog is below as currently set.

I also wondered if, since SGP is connected to the roof direct to Maxdome, perhaps the Generic Hub should have the
“dome” option turned off (that can be done from the profile explorer)? Or maybe “dome” in SGP should be set to the generic hub and let that handle the roof? Fortunately, I can try most of these things in daytime by capping the scope and using short darks for “exposures”. Let me know what you think I should do or try but it does look to me like the disconnection from the scope is the culprit. I just need to know why it does that.

#5

Unfortunately that’s not enough context for the log. Can you zip and post it on dropbox or someplace similar? Zipping should reduce the size 10x for text.

Also I’ll address the large log size. Most of that is because of the SBIG Guider which doesn’t need to log every frame.

Thanks,
Jared

#6

Here it is (1.6 meg):

Log File

#7

More testing was done, here are the results:

When the Generic Hub was selected for both Scope and Observatory in SGP and “Park Mount First” deselected in [Slave Settings] it did work and caused the roof to close as the scope was parking and after the scope was parked the first frame of the darks set was started before the roof was closed (closure takes about a minute with my roof). It did still disconnect the scope as well as parking it, however, instead of just parking it.

Selecting Generic Hub for Scope and Maxdome II for Observatory (the settings I used last night) behaved exactly the same way. Of course, last night “Park Mount First” selected.

So it appears deselecting “Park Mount First” in [Slave Settings] did get the roof to close but only by commanding that first, thereby avoiding the issue as opposed to solving it. It will work (because my roof is scope-safe), but would not with a roof that was not.

Here is the log file for the test runs:

Test One Log File

#8

It looks like when the mount is parked that it disconnects from TheSky and no longer communicates with the ASCOM driver. This is problematic as we need to know when the mount is finished parking. I’m not sure why the driver disconnects the mount upon park, this is not standard behavior. I think you’re going to have to take this up with the ASCOM developer that wrote this driver.

[6/4/2014 9:38:21 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Park message received.
[6/4/2014 9:38:21 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Dome slave set to park mount first, parking mount.
[6/4/2014 9:38:21 AM] [DEBUG] [Sequence Thread] Moving filter wheel, isMoving, check 2…
[6/4/2014 9:38:38 AM] [DEBUG] [Sequence Thread] Moving filter wheel, isMoving, check 2 complete…
[6/4/2014 9:38:38 AM] [DEBUG] [Sequence Thread] Checking for auto manual focus (pre)…
[6/4/2014 9:38:38 AM] [DEBUG] [Sequence Thread] Finished sending frame capture. Entering wait mode…
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE message received…
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SBIG Camera: CaptureImage…
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SBIG Camera: Start exposure…
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SBIG Camera: exposure time = 3000
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SBIG Camera: shutter is closed…
[6/4/2014 9:38:38 AM] [DEBUG] [Camera Thread] SBIG Camera: capture command sent…
[6/4/2014 9:38:40 AM] [DEBUG] [CP Update Thread] ASCOM Telescope: Error in IsSlewing : Not connected to TheSky. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Not connected to TheSky.
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 284
at ASCOM.DriverAccess.Telescope.get_Slewing() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1104
at a3.IsSlewing()

Thanks,
Jared

#9

OPERATIONAL QUESTION: Can I assume that this would not cause any other problems (aside from a larger log file)? I really do not have to park the mount first with my system and any frames I take after the roof closes and the mount parks can be done with the mount disconnected.

No idea who the developer is or how to contact them. I did post this to the ASCOM Yahoo Group, maybe someone knows.

There has to be someone out there using a Paramount ME and SGP with a dome or roll-off. It is a very common mount, even more so for permanent observatories. It is hard to believe this has not been a problem for someone else.

I wonder if I should post a new “one line” thread asking if anyone is using this combination?

#10

If you do not use the option to park the mount first things should work fine, but like you mentioned the log will grow quickly as there is a thread that is monitoring the mount which is where that large error is coming from.

Looking at the ASCOM sim it looks like there is an option to “Disconnect on Park” so maybe this isn’t “against the grain”, although this is the first implementation that I’ve heard of that does this. I’ll address this in SGP to better handle this.

Thanks,
Jared

#11

Agreed, it does not make much sense to disconnect on park by default since park can be used for more than just shut down and storage. If it made sense they would disconnect on park by default in TheSky, which they don’t.

This makes me really glad I redid the roof on my roll-off in 2009 since before that it was much lower and would have required park before close.

Ironic that this issue makes me uncheck “Open Roof First” which was the profile save issue in the other thread so that is no longer an issue for me at least.

It would be great if this could be addressed since park before close is the “right” way to operate most of the time and the only safe way in some observatories.

Thanks!

#12

Unfortunately TheSky does disconnect on park for external control. The ASCOM driver handles this in Park. It waits for slewing to finish or Connected to be false and then returns. The mount is parked (as far as we know) when the driver returns from the Park command.

There’s nothing that can be done about the error on the Slewing command. TheSky is not connected so all that can be done is throw an exception.

The original code was done by Bob Denny and I added guiding but I’ve got fed up with providing free support for TheSky.

#13

Thanks. This agrees pretty much with a replay I got over on ASCOM forum, which I will quote below.

As I said, I sure am glad that I built my observatory so that there is no possibility of a roof strike on close regardless of
scope position. That seems to mean that there are no functional consequences of this other than a huge log file (and that’s what delete is for).

I have to assume that this could be dealt with in SGP but would have to include some code specific to TheSkyControlled telescope usage. What a pain in the butt for the coder! Just another result of the biggest problem with astronomical software, too many cooks in the kitchen, all with their own recipies.

Public Property Get AtPark() As Boolean

’ Err.Raise SCODE_NOT_IMPLEMENTED, ERR_SOURCE, _

’ “Property AtPark” & MSG_NOT_IMPLEMENTED

'

' Conform Requirement

'

' Must be implemented if CanPark = True, but we have no

' way to tell as parking disconnects. If we're connected

' then we can't be parked.

'

CheckConnected

AtPark = False

End Property

It is well known that some telescopes are “dead” after parking and the above source snippet makes it clear that is definitely the case with TheSky. The Telescope standard doesn’t explicitly say so, but hints at it: “Some telescopes must be power-cycled before unparking”. The evidence suggests that applications have to deal with this situation. The Park() method is synchronous, i.e. blocking: it doesn’t return until the park operation is complete. If it returns without throwing an exception, then an app can safely assume that the scope is parked.

Bob Denny is the author of the TheSky Controlled Telescope driver, and he might have more to say on the matter, but I would anticipate that this is a limitation within TheSky’s scripting interface and SGP will just have to find a way to deal with it.

In these situations, it is often useful to run Conform against the driver in question. Conform is the final arbiter of ASCOM compatibility and will tell you in one unequivocal document whether the driver conforms to all the relevant ASCOM requirements. Conform is part of the ASCOM Developer Tools.

#14

Yes, the fix I put in place should handle this. Essentially if the scope disconnects at park we disconnect the scope from within SGP. This should stop other things from attempting to query it.

Thanks,
Jared

#15

FYI, I ran a sequence last night with both a flip and a roof close and park and darks and it all worked nicely when I had
park before close unchecked.

Will the change show up in the next regular release?

Thanks Jared! Nice to see that quick a response. It must be a pain to deal with problems you did not cause, but I suppose that is common in astronomy with it’s multitude of equipment, drivers, and authors.

#16

Yes, it will be out in the next release. I’m not sure when that will be,
probably here in the next couple of weeks.

Thanks,

Jared Wellman
Co-Owner and Developer
Main Sequence Software
www.mainsequencesoftware.com

#17

I did get to thinking that maybe there is an alternative to parking that would not disconnect the mount.

  1. Slew to a specific Alt and Az as opposed to RA and Dec.
  2. Stop mount Tracking

Kinda parking w/o parking.

As I recall, “stop tracking” is what ACP did in some wait situations with the Paramount ME as I recall seeing that in the status window in TheSky.

I do recognize that this may not be worthwhile to bother with to correct a problem that is really one caused by Software Bisque and has no operational effect for any known current SGP customers (since I can close my roof first with no danger). I throw it out there more to be sure the idea has been mentioned than because I either want, need, or expect it. Things are working nicely for me as is at this point in time.

#18

This is an old thread I know but I am seeing this issue within SGP, I use a Paramount MX and TheSky Controlled Telescope driver and have noticed the mount is disconnected after the park command.

This is not a major problem as have plenty of disk space and clean the logs regularly and also like CCDMan my roof can close with the scope in any position but this thread seems to indicate a work around was put into SGP.

@Jared - did the change go in to disconnect the scope, my log is full of attempts to access the mount after it has parked and disconnected.

See from 02:41:09 is the following log

As an aside an enhancement to SGP maybe an option to disconnect all equipment after the camera has finished cooling or x mins after end of seq. I currently have a separate power control program that powers all the equipment off x mins after park but obviously it is still all connected in SGP.

#19

[quote=“trevorn, post:18, topic:287”]
I use a Paramount MX and TheSky Controlled Telescope driver and have noticed the mount is disconnected after the park command.
[/quote] This is a “feature” of TheSky, sending a park command causes the mount to be disconnected.
There’s nothing that can be done other than work round it.

Chris

#20

Thanks Chris, I understand that having read though this whole post, my question was more did the workaround Jared suggested make it into SGP, and if it did why am I seeing the same issue,