I have been trying to upload the logfile but it’s 7.24 megabytes and the forum keeps telling me that the file is too large Twice this week the scope failed to park and I don’t know what’s wrong…how do I upload the logfile here? What am I doing wrong? (up till last week it parked ever ytime perfectly well. I’ve changed nothing)
Help!
Pablo Lewin
Member of the TESS subgroup 1.
You will have to put the file into a sharing service such as dropbox.
WOW! Why didn’t I think of that? Thank you! and here it is, thank you in advance
Pablo
The failure occurred at about 4 or 5 AM on July 11th by the way…
Can you give some details of the mount, observatory etc.
My mount sometimes parks but fails to report back that it is parked. It seems to be a device driver / communication issue.
Sorry buzz, I didn’t see this. Celestron C14 Edge HD with CGE Pro mount. SGP was working great till recently it all started failing as far as the parking is concerned. Unfortunately SGP has no customer support so I will have to consider other more serious options since I need this scope to support the TESS program…Thanks and good luck
Pablo - software doesn’t change itself - but hardware can become unreliable.
You sent a huge logfile and I had to trawl through it. At 21:20 SGP threw an exception because your telescope ASCOM driver did not respond and SGP timed out. There are no attempted parks around 4 oclock and around 5, you had an event park (for flats?) and then it appears it tried to move the mount, but it will not, as it is parked. I think the debugging of this is at an early stage and it is foolhardy to draw conclusions. You need to know the actual time of the problem and also have the log files for the ASCOM drivers for the same time. That will tell you what tried to do what, and the outcome. There are a number of us who have hundreds of unattended hours with SGP with parking and dome controls. Yes, we have the occasional gremlin in a version, but they are consistent. I have had more issues from devices (through ASCOM but not necessarily ASCOM itself) than with SGP itself.
Have you asked for support? This is a hobby for most of us and it takes a little effort on our part to help developers help us. I know several SGP users who started with a ‘serious option’ and ended up here.
Thanks Buzz…I will fix the problem somehow.
Good luck
Pablo
PS Do you work for SGP by the way? I thought one asked for support here on this forum…
Pablo the forum is a general one about SGP related stuff as well as for asking help. There is no ‘ticket’ system. The developers chime in when it is clearer that more informed help is required. I’m just one of several amateur users with several years experience. We try and help out where we can, as many of us have had similar head-scratching moments too.
Hi Buzz I have several questions and then I will upload the ASCOM files because this is really limiting my observing time. As a reminder I have a Celestron C14 Edge HD on a CGE Pro mount. I’ve been using SGP for years and never had a problem till recently when I upgraded to the latest SGP build.
I have a roll off roof observatory (small ) that requires me to park the scope on the east side for a photoelectric switch to be activated showing that the scope is perfectly parked and then SGP sends a signal to the roof controller to close it. Without that switch being activated the roof will NOT activate (I also have safeguards).
My workflow in the past was to manually set the home position in the hand controller because it is my BELIEF that the park position is set against the mechanical switch position and not a RA and DEC that can change when you plate solve the scope thus not allowing the photocell to be activated.
Whenever I set the park position form SGP I BELIEVE it sets it against RA and DEC and it can change if you do repeated plate solving such as when centering the scope.
At any rate the scope when I test it at the beginning of the observation run will park perfectly and I seem to have a problem when I park for calibration which is by the way what I do all the time in other words
- Ligths
2)park before calibration
3)close the roof
4)calibration run
5)shutdown sequence when done.
I also keep the park scope checked in in SGP in case it gets cloudy so I have two park elements checked at the same time in SGP, park before calibration in the sequence and also park when sequence ends.
The failure that I experience is after the lights are done and I’ve selected park before calibration the scope will move a few degrees and not park and then when I press park manually nothing happens and the button goes from park to unpark back to park never staying at park.
have you seen or heard this before?
I’m doing serious science for the TESS satellite program and I need to get this fixed ASAP somehow before the satellite starts beaming data down to earth…
Any help you can provide will be appreciated.
Thanks!
Pablo Lewin
Well I did an experiment, I uninstalled and reinstalled the Celestron ASCOM driver and that didn’t do help, once again at the end of the sequence the scope instead of parking it moved a few degrees and didn’t park properly. Then I disconnected the mount from the sequence and shutdown SGP, then I immediately started SGP again connected the mount and sent the park command and this time it parked perfectly well. I then ran a sequence till the end again and once again when it came time to park it just moved a few degrees then I repeated the above actions reconnected and once again the park command worked.
It;s not ASCOM, it’s SGP…I’m writing this fin the hopes that someone will tell me what’s wrong with it.
Thanks
Pablo Lewin
Not likely to be SGP. SGP is sending a park command to the ASCOM driver. The driver and the mount do the actual interpretation of the command.
Thank you Desert Sky, and yet when I exit from SGP and reconnect and send the park command it works well for a few minutes…hmmm
Park positions are normally an Alt/Az position, not a RA/DEC one. When you set the park position, is that done from SGP, or directly with your mount/handset? I just wonder if there is a conflict here.
It is more likely to be ASCOM / driver getting hung up in some way. I think the action of closing SGP will disconnect the COM and in effect reset it when you open SGP again. We cannot rule out SGP taking some part in this… while DesertSky is right, the commands are sent out, there is always the other dimension, timing. It is not impossible there may have been some tiny change in the timing of the commands that may be causing an issue. The complexities of synchronous and asynchronous commands pop up every so often.
Pablo - can you give us the version number of SGP that worked for you? Did you also change the ASCOM platform too (there was a new one recently). Armed with that data, I would fire off a note to Ken and Jared and ask if anything changed in the park/close routines that may be contributing.
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?