Park Failure and I don't know why

Sequence Generator
21

The only good data I have is the first park that I mentioned in my first response. This appears to work. What I don’t know is if this causes the mount to end up at the park position. This is the same as the Home position used by the HC.

I need answers to these questions:
Does a move to Home made using the HC move to the position you expect?
Do you get any messages on the HC display?
How was the Park position set?

The problem I see is that when the park command is send during the sequence run there is still a lot going on, in particular something is sending move commands and I’m concerned that these commands, which inevitably go to the hardware, are interfering with the park command. The first park command I saw was when very little else was going on, other than SGP asking the telescope hardware for the sidereal time.

The second seemed to leave the telescope hardware in a strange situation and I wonder if this is because there are so many other commands being sent to the hardware. Maybe some hardware command is interfering with the park hardware command.

22

Hi Chris, thank you for the response.

I set the Home position through the HC and when I command it from the HC it works flawlessly, then I connect SGP and command it manually to “park” and it works flawlessly.

Then as part of a sequence when it finishes taking images and it’s about to take flats I can program it to park (which I do) before taking flats and now it only moves a few degrees and it doesn’t park…in fact sometimes the manual “park” button will stay at “parked” instead of changing to “unpark” like it’s supposed to haver parking…

Then I will set it up to just take a few lights and “park” when the sequence ends and once again it only moves a few degrees and won’t park…

Paradoxically SGP seems to “hang” so when I try to exit the program it won’t so I have to do a “Control-Alt_Del” and exit that way.
Once I start it up again and connect and try to park manually, low and behold, it parks perfectly well…

I’ve been using this program for years this way with no problem. Now that I’m doing serious work I’m considering a expensive but serious solution like ACP Observatory control or Prism.

SGP is like home to me, I know it inside and out but unfortunately due to the lack of support the time has come for me.
I thank you most kindly for your efforts Chris!

Pablo

23

PS no messages from the HC other than being ready.

24

could this be PHD still guiding the mount at the time the park is issued? or are they large moves as chris mentioned earlier in the thread?

rob

25

Hi Rob

I made sure that I selected stop guiding when slewing but that didn’t help either…

Otherwise it works great but without perfectly parking the mount so the roof can close and start taking flats It’s no longer useful to me…

Thank you

Pablo

26

OK just checking, since chris says that something is sending commands to the mount.

rob

1 Like
27

Thanks Pablo, That’s good, it means that the log shows a good park and a failed park.

Yes Rob, what is happening is that PHD is sending guide commands to the mount while the park is in progress, this is what causes the park to fail.

PHD is under the control of SGP and I would expect that SGP would stop guiding and wait for it to stop before continuing with the park process. According to the log that was posted earlier SGP is only attempting to stop guiding after the park command has been sent.

[07/10/18 21:19:21.987][DEBUG] [Telescope Thread] ASCOM Telescope: Park message received.
[07/10/18 21:19:21.988][DEBUG] [Telescope Thread] ASCOM Telescope: Sending park…
[07/10/18 21:19:45.046][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
[07/10/18 21:20:40.453][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
[07/10/18 21:22:09.412][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
[07/10/18 21:22:17.790][DEBUG] [Telescope Thread] ASCOM Telescope: Error in ParkTel! : Timed out waiting for received data (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Timed out waiting for received data
— 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 443)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 483
at ASCOM.DriverAccess.Telescope.Park() in C:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 728
at qr.br(String& A_0)
[07/10/18 21:22:17.790][DEBUG] [Telescope Thread] Error parking telescope: Error in Parking Telescope! See logs.
[07/10/18 21:22:17.791][DEBUG] [Telescope Thread] Attempting to stop PHD2 guiding…
[07/10/18 21:22:17.791][DEBUG] [Telescope Thread] Checking PHD2 state…
[07/10/18 21:22:17.791][DEBUG] [Telescope Thread] PHD2 GetPhdStatus - Pre-Wait : LostLock
[07/10/18 21:22:17.791][DEBUG] [Telescope Thread] Sending to PHD2:
{“method”: “get_app_state”, “id”: 1001}

It would help enormously if SGP were to be a little more helpful instead of leaving PHD to cope with the mount being pulled out of it’s control.

I can do things to prevent the guide commands from interfering with a park command but these will mean that PHD will get new errors when it tries to send guide commands.

This really needs to be fixed by SGP, their current behaviour is pretty hostile to the driver and other applications.

28

CHRIS! you nailed it!

Thank you! It was indeed the autoguider. I just finished an experiment where I deselected the autoguider from the control panel and ran a simple sequence to take 5 lights and then park and shoot the calibration files and it worked.

Then I did the same with with the autoguider connected back up and once again it ONLY moved a few degrees, paradoxically SGP hung up ,meaning that sgp was locked as if in a loop it was totally non responsive. Then I checked PHD2 and it was still trying to guide in other words it was sending pulses but not locked on any guide star, then I checked the HC and the display was BLANK nothing displayed.(It should say CGE Ready or something like that).

I then realigned the mount, connected it back up to SGP, once again deselected the autoguider and tried it twice with a simple sequence and lo and behold, presto it worked perfectly well, shot the images, parked, shot the calibration files and went into it’s shutdown sequence.

Since it’s perfectly polar aligned and since I use PEMPrO for the mount PEC I can easily shoot 2 minute subs unguided (probably more) so for the TESS program I’m back in business (Unless something changes).
I wonder if someone can contact the creators of SGP to implement the changes that you recommend.

Thank you again Chris

Pablo

29

Thanks for trying that and letting us know.

Ken and Jared should be monitoring this forum so should see this conversation. Hopefully they will fix the way that SGP manages things.

1 Like
30

I recall an option to stop guiding during slewing. I think it is in PHD2. Is this a possible solution.

31

Worth a try, The driver should report slewing as true during the park process.

32

Using PHD2 in “other options” there’s no option to stop guiding during slewing…only during backlash, download or autofocus but not during slewing

33

Not so. In the guiding tab in the brain, there is an option ‘stop guiding when mount slews’

34

OH, I thought you meant SGP…OK, That’s a good one. I will try that tonight of the smoke from the nearby forest fires subside…Thanks Buzz!