Thank you Buzz, you caught me in the middle of sending a thorough email to Chris Rowland the developer of ASCOM
I have the latest version of EVERYTHING as of last night, the Platform, SGP and Celestron Driver.
When SGP sends the park command during a sequence whether for acquiring calibrating plates or end of sequence it will move just a few degrees and stay there with the park switch showing “parked” and not unparked THEN I exit SGP and re start it , connect the mount and then I send manually the park command and lo and behold it parks perfectly well…perfect, the I try a sequence again with only one image to force it to park as an end of sequence and once again it doesn’t park just moves a few degrees…then rinse and repeat.
Yes, I think it was Chris who wrote the Celestron driver. He will need the ASCOM log file as well as the SGP one.
I just sent him both files and the mount trace file as well, thanks…
Thanks for the files. Let’s dig into what is going on, there is a lot happening.
From what I can see when you start at 20:12:22 the mount thinks it is in some start mode, the Ra is reported as 12hrs and the Dec as 0. Tracking is off so these don’t change. That looks like a typical state after the mount has been turned on and not aligned.
Then at 20:24:06 an Unpark command is sent, followed by a start tracking command.
The unpark sends a wake up command to the mount and the Ra and Dec are now reported as Ra 4.26080560684204, Dec 53.77357006073
Some axis move commands are sent and by 20:25:08 the mount reports it is at Ra 22.1635422706604, Dec 59.0366864204407, That seems like a large move, especially as the movers were at rate 4. Could some high speed move have been done using the HC?
Everything seems to be working correctly.
At 21:11:57 see the start of the park command. This is a message to the HC to move to the HC Home position. The slew finishes at 21:12:27 and after a 1 second settle time at 21:12:28 a Hibernate command is sent to the mount. Park seems to be complete. The 30 second slew time seems reasonable.
*** Did you issue a Park at that time and did it complete?
Then at 21:12:40 I see an Unpark command. This sends a wake up command to the mount which undoes the hibernate done by the park. The alignment done before the park should be preserved.
The hibernate and wake up commands are the same as the HC commands.
The Park position is the same as the Home position that you can set using the HC. it is NOT a Ra and Dec position, it is an axis position Using Ra and Dec would not work because they are changing and park/home needs to be a fixed axis position.
What this means is that you need to set the Park/Home position and I think that you can do that either by using the HC or by using the ASCOM commands.
What I would do is check this independently of SGP by writing scripts that implement the ASCOM Park, Unpark and SetPark commands. There may be some on this forum.
The partial SGP log starts at 03:40:53 and I can see the start of another Park command at that time. The slew to the park position starts but never seems to finish.
There is a lot going on here, I am seeing guide commands being sent and this may be confusing the hardware. After that things seem to go wrong.
What to do?
I can try to prevent other hardware commands being sent to the hardware during the goto home command but all I can do is throw exceptions. The applications will need to manage these new exceptions.
What is really needed is for the hardware to be set to a state appropriate to parking the scope. Guiding should be stopped and so should image acquisition. Neither of these can be expected to work while the mount is being parked That can only be done by the primary application.
Hope this helps,
Chris
Hi Chris I am now able to respond ,
I’ve been on the road. The 21:11:57 is a manual command from SGP and it did not park the mount, this is where the mount moves a few degrees and then settles instead of parking which takes a while because the scope has to be parallel with the ground thus allowing the photoelectric cell to activate the roof.
I sent you the partial SGP file (I think the full file is posted on this thread) to focus on the attempt at 03:40 am that’s when it was supposed to fully park to tale calibration images…it didn’t park , it just moved a few degrees…the strange/peculiar situation is that when I exit SGP the start it again and connect to the mount it will work nominally and park the scope when I activated manually but once I try the command as part of the sequence…I have the same problem…
What I’m going to do when I get home is to uninstall SGP and install it again to see if that fixes the problem, maybe I can roll back to an earlier version of SGP…I’ve never had this problem before it started since I updated to the last SGP build…I’m at a loss. Once again thank you for your time.
Pablo
Update. I rolled it back to sgp 2.6 and I have the same problem. When the park command is sent it moves a few degrees and parks . Then I exit the program reconnect the mount send a park command and I will park perfectly well…Chris will write a modified ASCOM driver for me to try. I’m frankly at a loss because everything else works well and now this? Maybe it’s a program interaction in my computer?
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.
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
PS no messages from the HC other than being ready.
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
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
OK just checking, since chris says that something is sending commands to the mount.
rob
1 Like
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.
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
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
I recall an option to stop guiding during slewing. I think it is in PHD2. Is this a possible solution.
Worth a try, The driver should report slewing as true during the park process.
Using PHD2 in “other options” there’s no option to stop guiding during slewing…only during backlash, download or autofocus but not during slewing
Not so. In the guiding tab in the brain, there is an option ‘stop guiding when mount slews’
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!