I have set up a Park position in Sitech for my Mesu 200 mount. Parking and UnParking via Sitech is extremely reliable. As soon as I hit the Park button in Sitech.exe the mount slews to the Park position.
In SGP Pro, however, Parking and UnParking is a bit hit or miss. Sometimes it seems to work, however, even when it does work there is a significant delay before the mount starts slewing (this is of the order of 10 seconds or so). At other times, I hit the SGP Park button and nothing whatsoever happens.
At present this is not a huge problem and I can live with it. However, at some point down the line I would like to go fully automatic and it would be great if I could get this to work.
Whilst doing other tasks in the observatory yesterday I did try a few Parks and UnParks, and again got the inconsistent behaviour. I attach both of the log files from yesterday:
Can anyone see what is going on? Incidentally, the new version of Sitech now offers 3 park positions. I donāt know how this could be made to work with SGP. I got the erratic behaviour when I was using the old version too, though.
SGPro have very little control over what happens when we ask your mount to park. We literally call one method (scope.Park()). What happens after that is executed in software that SGPro does not control. The difference here is that the park command you say is reliable is not filtered through ASCOM (I donāt think). SGProās call is.
Have you tried setting the park position through ASCOM to see if that makes a difference?
Not sure if I can say anything helpful. I have been keeping SiTech and SGP up to date (including beta versions of SGP). The Park seems to be working mostly reliably and fairly instantly. Having said that I had to abort due to weather (yet again) just a few minutes ago. This time there was a 5-6 second delay before the SGP instruction parked the mount. I donāt suppose it matters too much, but I am not sure I have 100% confidence in it.
Thanks again Jared. For various reasons (automated sky model building being the main one), I have been trying out Maxim DL. I have to say that Maxim seems to be able to Park and Unpark my SiTech/Mesu every time without issue. SGP remains very flaky on parking. I estimate that SGP will park the Mesu only 80% of the time (and sometimes, as you say, there is a delay). Maxim parks as if I have pressed the āParkā button in the Sitech interface - it is nearly immediate and, as I say, it has been 100% reliable so far.
In my home observatory this is not a big issue since I physically monitor everything, and I can always jump over to the Sitech interface to Park if I need to. However, I am considering a remote set up which I would want to operate with less āsupervisionā, and this obviously would be problematic without reliable parking and unparking.
I wonder why it all works perfectly in Maxim but not SGP. Incidentally, I find the Maxim interface considerably more clunky than SGP and would much prefer to use SGP.
I canāt really say. Both application (very likely) call the very same ASCOM method to park (Telescope.Park()). There is not special code here. I can only think that there is something that SGPro is waiting on that sometimes resolves and sometimes does not. The only other difference is that SGPro is pretty aggressive in the way it talks to your mount and maybe the driver does not care for it.
The logs you provided are no longer available, but SGPro may be waiting on the guider to stop before it issues park. This might explain the delay, but does not explain the failure. I have just modified SGPro such that it no longer waits for the guider to stop.
Thanks for the reply Ken. The idea about guiding is interesting since I have not yet got a rigid procedure in place (in my head) for shutting down and it is certainly possible that guiding is still trying to run when I press Park. SiTech will Park when I am still (inadvertently) guiding (I just get the ping and āStar Lostā message from PHD).
I can provide you with more logs if that would be helpful. I will also be interested to try out the modified version of SGP when it is available. (Will it be in 2.6.0.22?)
You could also verify if it is ASCOM by doing a very simple script to park the mount (or call that script within SGP too) - if it was SGP taking time to issue the command, if you told it to abort at a precise time, you would see in the ASCOM log file when the command was issued.
Thanks for responding. Iām not sure how to write scripts - Iāve never tried one. Although I let SGP take care of most things, I am fairly āhands-onā when it comes to starting up and closing down. Once my āfinalā esposure for the evening is done, I click the on-screen button to warm the camera and then click the on-screen button to park the mount. (To be clear I am not (yet) trying to get the sequence to unpark - run sequence - park.).
It is only the Park button in the SGP interface that doesnāt work reliably. The Park button in my SiTech mount control window works every time. And, as far as I can tell, the Park button in the Maxim DL works 100% of the time too. (So I wonder what the āscript testā would add, even if I could write one.).
If I could have the Maxim DL level of reliability within SGP, I would be an extremely happy bunny. Perhaps it is related to the autoguiding, because I do not follow a rigid checklist and it is perfectly possible that sometimes I will click the Park button whilst PHD is still trying to guide. I guess I need āParkā to over-ride all other considerations (or at least all that I can think of).
My aim, you see, is to become more automated - especially to incorporate a weather shutdown automatically. But, my mount MUST park before my roof can close - or else I will be a very unhappy bunny.
Just for the moment we are still trying to trace the cause. Youāll find a great many SGP users were prior MDL users, myself included. We abandoned MDL for reliability and support issues.
Iāll pull a generic script together and you can try it. Park instructions are odd - on my Avalon mount, it uses synscan system and the handset does a park, but the ASCOM driver does not support it. MDL and SGP sometimes use their own drivers for particular pieces of hardware where it offers an improvement over ASCOM (PHD2 does too). Do you know if your SiTech control window is using an ASCOM driver (it would likely bring up an ASCOM chooser window when you first try and connect).
Thanks again Buzz. The SiTech controller is, as far as I am aware, using an Ascom driver. Certainly, whatever I am setting up (PHD, Maxim) it is the standard Ascom interface that pops up.
I have also spoken with Barry Wilson. He has suggested I change SGP to use POTH. I will probably give this a go later today - the results might be useful for diagnostic purposes.
I appeciate your time on this. I am quite happy to try your script, but I donāt speak computer so you might have to bear with me and endure some really stupid questionsā¦
OK. I donāt want to tempt fate, but I may have discovered what the issue is. SiTech offers you the opportunity of building and then using a horizon file. I have built such a file and normally have it switched on. My āParkā position is almost certainly a little below that horizon. SiTech doesnāt seem to mind this (indeed I can set 4 Park positions - I have one that points at my LED flats panel which is obviously well below the horizon).
SGP seems not to like the horizon file. Indeed, I noticed that with the horizon enabled I could Unpark the mount but it would quickly offer me the āUnparkā option again.
So I unticked the horizon file in SiTech and tried again. Unpark and Park worked every time (I probably tried it a dozen times). Each time, though, there was a delay of around 10 seconds between issuing the Park command and the mount actually beginning to move. Iām not sure what is to be gained by having a delay - SiTech and Maxim are immediate.
I tried replicating the problem by selecting SiTech and POTH as my telescope. It didnāt seem to make any difference. With the horizon file turned on, the mount is unreliable in Park. With the horizon off, both SiTech and POTH parked and unparked normally (but with the same delay).
I hope this is helpful to people.
Now I have two issues to solve:
How do I stop SGP following a target below my horizon? (Is there a āminimum altitude to imageā feature?)
Is there a way of confirming that the mount is parked before I take the big step of closing the roof?
I think it should be as simple as this: (Pile in anyone if I have it wrong). Use notepad and save it as a .VBS file.
set c = CreateObject(āASCOM.Utilities.Chooserā)
c.DeviceType=āTelescope"
id = c.Choose(ā")
set scope = CreateObject(id)
scope.Connected = true
scope.Park
scope.Connected = false
Maxim connects via the same Ascom driver, but I recall that when I installed the demo, it asked me to make sure that any horizon limits were disabled. (I could test what happens if I donāt disable them, but I am going away for a few days). I hope that helps.
In regard to horizons - scopes can be finicky. If I recall correctly my Paramount has a custom park position but would refuse to park under the horizon. I think the latest daily build fixed this. It would be worth checking whether the Mesu has similar limitations.
