I have made this request before but I’m not sure it was a formal feature request.
This is pretty simple and should only involve a few lines of code - and it shouldn’t impact other features.
If MG is the guider, then turn off, then on guiding as usual. Currently dithering is supported and works well - by registering a remote message handler - then “posting” the message when you dither.
The same would work for guiding/unguiding - as described here:
For unguiding, you just post MG_RemoteUnLock, then post MG_RemoteUnGuide
For guiding, just post MG_RemoteLock, then post MG_RemoteGuide
Normally I start a sequence with guiding enabled and I would like to incorporate automated focusing and switching/centering of objects - but I can’t without being able to control guiding.
Note that this would also allow meridian flips and so forth - since MG has all the logic to do that by itself. It just needs to turn off, then on, guiding when going to the other side.
It’s nice that SGP supports dithering for MG and the overall combination works well as shown by my recent results. This additional functionality would make it much more powerful.
I’m not really following you. So… when SGPro would normally stop and restart PHD2… is this the same time you would want MG to be turned off and on? Like when switching targets or flipping?
Yes - this is pretty simple. Any time you change targets you would need to stop guiding, then start again. MG has two commands that are needed: Lock to lock onto a bright guidestar in the scene (it will find and choose it), and Guide to start guiding. When you stop guiding, you just unlock, then unguide.
If you are autofocusing with OAG you would also want to do this - with any guide software. If you are using a guidescope you might want to stay guiding - but I’m not sure how SGP distinguishes that. But the need to stop guiding - or not - during autofocus would apply to any guide software.
You already have code for dithering - so you are already registering a remote windows message handler and then invoking it - so this would add two more calls to register - and then you would invoke them just as you do dithering - at the places you already do it when turning on and off guiding. The message should be sent with postmessage - in which case there is no delay or handshaking. Just send it off and carry on. So even if MG isn’t running, SGP won’t care.
It would be more complicated to monitor the guiding and wait for it to settle after re-starting - but a time delay would be good if possible - after guiding restarts.
Most of my work is with OAG at long focal length, and I would need very accurate centering to be sure the guidestar appears as it should. But this should work fine for guidescope guiding.
There is a command to pause guiding during focus. It sounds like your software would follow a similar flow to PHD2.
Do you have a way to pass off the settling part of it? For instance when I use PHD2, I just tell SGP I want it to be less than a certain amount of movement in pixels and it waits until that point. Can your software pass that back to SGP?
Even better, could your software mimic the PHD2 server? It would make it easier to support overall.
I implemented all the remote stuff years ago to make it easy for apps to talk to MG. So there is no handshaking involved.
MG does send UDP messages that can be monitored - which tell things about the guidestar brightness and NS/EW error in arc-seconds. The messages are simple to catch and parse. But for guiding I would just use a time delay. But if you wanted to handshake and make the code as similar as possible, you could catch the udp messages. I don’t think I documented them but I can provide info. It is a simple message output every second, with info on the guidestar.
I am currently adding features for a new release and could do something specific to make this easier. But I wouldn’t want to change the basic design. MG is controlled by remote windows messages, and it talks to other apps by UDP broadcast. It was implemented this way many years ago.
Build 2.4.3.1 has the first attempt at implementing this… not sure if it works or if there is a good way to test it or not (forgot if you implemented a simulator). Can check later, but doing a hundred other things at the same time.
I was able to try this last night and everything seems to be implemented correctly - but MG had an ascom error when guiding started and I will need to look into it. It is likely something I need to fix - but it is strange.
If this had worked properly it would have demonstrated automatic switching of objects and landing the guidestar on the small oag video sensor - which would have been very promising. Everything did work and the guidestar appeared - but guiding did not start as it should have.
I include a log for your interest - but the problem appears to be on my end.
Yes - I was a little surprised to see the repeated calls to lock and guide - but it should be ok for mg to receive this. Even if this is a problem - again I can deal with it on my side.
I think that right now it has a slight side effect that it will switch the target guide location to wherever the guidestar is when guide is called again - but that would only be a tiny shift. Either way - I can change the code to make sure it is ok - assuming that those calls fit most naturally into sgp in that way. In other words - I assume it is calling it repeatedly because that is how the calls fit into the existing code - and you aren’t doing it on purpose.
Normally they would only be called once though - but it shouldn’t be a problem.
There appears to be about 1 second between lock and guide - and that is probably good. A 5 second gap may be needed - but I hope not. I will look at my code.
As a side note - when MG dithers - guiding is left on and doesn’t need to be stopped and restarted. In fact it shouldn’t be stopped and restarted. Dithering has always worked fine in SGP because it just sends the dither message - and then I have an interframe delay to allow recovery of guiding. The extra guide call may be related to dithering - but either way it should be ok. But it would not be ok to stop and start guiding either side of a dither.
The extra guide call is not related to ditering. It is related to the the fact that there are several options now in SGPro that can stop / pause guiding at the end of an integration. Because of this, we just call resume guiding before every frame. We get away with it because PHD2 does not care… If we tell it to resume guiding and it is already guiding, it just keeps guiding… but if an option the user has selected paused guiding, it will always make sure guiding is turned back on prior to the next sub.
We do not attempt to do this…you can see in the logs that they are all calls to resume guiding. Stop is only called when we are about to move targets.
If MG hates this, we can be more careful about when it is called by storing assumed state of MG (pretty easy to do)… I’ll take your lead.
I have been very busy and am now travelling - so I haven’t been able to look into it. But I will try to shortly. The ball is in my court and I am hopeful I can fix things on my end with a new release. Either way I will aim to report soon.
I did take a look at this and it is very strange. When I send commands to lock and guide using my own separate code to MG it works fine - but with SGP MG reports an ascom error when the guide command is sent. Is there something else going on in the code related to ascom autoguiding that sgp is doing? Is it sending the Guide command to MG more than once?
Sorry - I have been on vacation and had lost mental track of your earlier replies.
Well this is strange but somehow the sequence of calls is causing a low level get_Connected ascom call to fail - and I worked around it by adding a slight delay between sgp turning on guide - and having guide start. So - it looks fixed on my end and will be available in the next MG release. But now I need to test it more with an actual sequence.