Dome Park Problem

I am experiencing an issue when trying to Park my mount and dome. When I click the Park button the following sequence occurs:

  1. The dome shutter closes (Good!)
  2. The dome rotates to its home position (Good!)
  3. The dome immediately rotates back to sync up with the mount, which hasn’t moved at all yet (Bad!)
  4. The mount parks (Good!)
  5. The dome is left at its sync position, not at its home position (Bad!)

Here is my log file from this evening:

I look forward to hearing what might be the problem here.

Thanks,

Gav.

I have the same problem with my Exploradome/Foster Systems obs. Basically at end of sequence the Telescope will Park and the Dome shutter will close. Most times it looks like the dome tries rotating to the dome’s home/park position, but then shortly thereafter slaves to the Telescope (to the telescope park position).

Have been suspecting that this was a dome ASCOM driver issue. But perhaps there is more involved?

DaveNL

I hope that Jared or Ken can shed some light on this soon. It all worked perfectly in the past (when the mount and dome would park simultaneously), but doesn’t now. The question is whether it is an SGP bug or an ASCOM dome driver bug…?

I reported similar here: Possible Bug/Omission SGP 2.6.0.21 - Sequence Generator - Main Sequence Software

@Kinch

Yup. By the way - what dome are you using?

My reason for parking/homing the dome away from telescope/mount park position is so that the dome will be at the charging position for shutter battery.

I am using a Pulsar dome with Shelyak Dome Tracker

You almost certainly need dome driver logs as well as SGP logs. The dome logs should show exactly what commands are being sent to the dome driver.

If the dome driver doesn’t give good logs then the ASCOM DriverAccess logs should help, these are enabled in the ASCOM driver chooser - menu - Trace - DriverAccess.

It’s interesting to read the replies and good (I think!?) to see that I am not alone with this issue. I have just had a play in the dome, repeating the problem and have generated two log files (SGP & Dome ASCOM), available here:

It is raining, so I didn’t open the shutter. On Park, after the dome had gone to home and back to slave to the mount and then the mount had gone to its park position, I unslaved the dome and sent it to its home position. While it was going to its home position, SGP showed that it was ‘NOT RESPONDING’ in the title and the blue windows circle loop thingy span. I don’t know if that is relevant?

The other thing that I notice is that ‘in the olden days’, when I clicked Park in SGP, both the mount and the dome would go to their park positions simultaneously. Nowadays the mount stays still until the dome has stopped moving. Again, is this relevant?

I hope that the logs help progress this one.

Thank you all.

Gav.

What I can see in the dome log is that it connects, The shutter state is closed. The dome azimuth starts at 179.9 and there is a slew command to 125.3 at 20:55:25.556. This seems to finish at 20:55:50.430. One thing is that the slewing state seems to reported the wrong way round True when the dome is not moving and False when it is.
There’s a Park command issued at 20:55:56.788 and the dome starts moving to 180.0 which s presumably the park position.
The park position is reached at 20:56:20.762 but then, at 20:56:20.842 there’s a slew command to 125.7 which is repeated several times.
The dome moves to this position, reaching it at 20:56:44.811

At 20:57:20.652 there’s a FindHome command and the dome starts moving.
It seems to reach the home position of 179.9 at 20:57:45.978.
Shortly afterwards it disconnects.

The Park and home commands correlate with records in the SGP log.

Could SGP still have the telescope and dome synced and sending slew commands to the dome after sending the park command?

The only anomaly I can see in the dome log is that the slewing state is the wrong way round but that could easily be a logging error. If it is being reported incorrectly to SGP I would expect far more trouble.
Apart from that the dome seems fine. It’s only moving in response to commands that it is getting.

Excellent, thank you for looking through the log Chris.

The FindHome command was triggered by me clicking the ‘Home’ button and I then disconnected everything.

I look forward to hearing the answers to your questions.

Any thoughts / progress on this one please?

I’m having the same problem over here. Using a Lesvedome driver. Don’t have any logs at the moment but if useful, I can create some this weekend?

I have not yet had a chance to dig in here. I will attempt to do so in the near future.

Thank you for the reply Ken. So long as it is on the list and is investigated, that’s great!

Gav.

I just installed v 2.6.0.24, excitedly hoping that the change: “Any park command issued through SGPro will now be followed by a stop tracking command.” would fix the dome rotation issue. Unfortunately there is no difference and the problem persists. Perhaps this version didn’t address that issue? Anyway, here is the SGP log file just in case it might be useful:

Looking in the log file, there is an error when it tries to stop the tracking:

[06/25/17 21:11:57.689][DEBUG] [Telescope Thread] ASCOM Telescope: Park message received.
[06/25/17 21:11:57.689][DEBUG] [Telescope Thread] ASCOM Telescope: closing observatory shutter…
[06/25/17 21:11:57.691][DEBUG] [Telescope Thread] Dome: Closing Shutter
[06/25/17 21:12:41.757][DEBUG] [Telescope Thread] ASCOM Telescope: parking observatory…
[06/25/17 21:12:41.759][DEBUG] [Telescope Thread] ASCOM Dome: Parking…
[06/25/17 21:12:52.521][DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[06/25/17 21:12:52.521][DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[06/25/17 21:12:52.521][DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[06/25/17 21:12:52.521][DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[06/25/17 21:12:52.521][DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[06/25/17 21:13:52.657][DEBUG] [PHD2 Listener Thread] PHD2 - No messages received from PHD2 for 1 minute, checking socket with status…
[06/25/17 21:13:52.657][DEBUG] [PHD2 Listener Thread] Checking PHD2 state…
[06/25/17 21:13:52.657][DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Pre-Wait : Stopped
[06/25/17 21:13:52.657][DEBUG] [PHD2 Listener Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

[06/25/17 21:13:52.657][DEBUG] [PHD2 Listener Thread] PHD2 GetPhdStatus - Post-Wait: Stopped
[06/25/17 21:14:17.506][DEBUG] [Telescope Thread] ASCOM Telescope: Sending park…
[06/25/17 21:14:43.474][DEBUG] [Telescope Thread] ASCOM Telescope: Parked
[06/25/17 21:14:43.475][DEBUG] [Telescope Thread] ASCOM Telescope: Sending post-park stop tracking…
[06/25/17 21:14:43.475][DEBUG] [Telescope Thread] ASCOM Telescope: Setting tracking state to False
[06/25/17 21:14:43.856][DEBUG] [Telescope Thread] ASCOM Telescope: Error in Track : Method RightAscensionRate() function is not permitted while mount is parked or parking. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Method RightAscensionRate() function is not permitted while mount is parked or parking.
— 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 331)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 369
at ASCOM.DriverAccess.Telescope.set_Tracking(Boolean value) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1190
at p8.kg(Boolean A_0)

Good luck Ken & Jared and I have my fingers crossed for a solution to arrive in the fullness of time!

Gav.

P.S. SGP totally rocks!

That fix is unrelated to what you are seeing… our work list is pretty backlogged.

Ken, thank you for clarifying. No surprise it still happens then! Good luck with progressing through the long list. I look forward to future releases.

@PhotoGav

I had some time this morning to try and track this down. I am unable to reproduce this… probably because my initial conditions are not the same or it’s a timing issue (maybe). Either way it seems like @Chris is likely correct in assuming that the dome is still synced with the scope even after park and, as a result, is unparking itself to match the scope. To attempt to correct this, I have made a change that should prevent that from happening, but I am not 100% sure. If you have time, you can test it out with this build:

Hi Ken,

Thank you for the update. I have given it a daytime test and it has half fixed the issue! All seemed to be perfect as I slewed and slaved, then clicked Park. The shutter closed, the dome went back to the home position, the mount slewed back to its home position and all was perfect. I then Unparked the mount and the dome shutter opened and rotated to slave to the mount in the home position. I slewed the mount a bit and the dome synced to the new position. I then hit Park and the shutter closed, the dome rotated to its home position, the mount parked and then the dome rotated to sync to the mount in its home position. I have the mount home point set as due North and the Dome home point set as due South. I attach the log file.

Thanks,

Gav.

I had something similar last night…but the dome eventually got to the proper park position.

End of sequence, telescope instructed to park …see log @ 01:56:32.98. The dome shutter closed and the dome proceeded to park position. The telescope took rather longer to get around to the park position (dome and scope park positions are close to each other). Once the dome got to park position, it moved off again, as if to align with the scope…but stopped at some undefined position. The scope reached its park position and then the dome took off again back to its park position.

At the end, both the scope & dome were in proper parked positions…just appears that the timing is off…i.e. the dome was still “thinking” it should follow the scope even after both received instructions to park. I think I mentioned in a previous thread that at some stage (probably best, just before the park instruction), the “slave to dome” state should be annulled.

Not a lot of info in the log…probably best (if needed) I should make the effort to get a Dome & ASCOM log.
(Mine is a Shelyak controlled Pulsar Dome)

sg_logfile_20170701202929.txt (932.8 KB)