Thank you! Played with it for a little bit and you’re
right. In the auto focus we were not correctly
blocking for focus moves. This seems to be a fairly
recent change. I’ll address it and get it ready for
the next beta.
Thanks for the detailed information. Unfortunately, I am out of time for the next few days. If anyone is inclined, they are welcome to test out the new changes. If they work, awesome, if not, I’ll attempt to address next week.
Quck update. I purchased, downloaded and Installed the new version SGPro V188.8.131.52 onto my systems. Now it’s a waiting game for some clear nights to show up to tests. Based on what Gene posted yesterday, the fix looks promising.
I’ve tested as well and it seems better, at least a delay after the focus position has been reached is honoured.
I couldn’t get Astrogene’s simulator running so modified the ASCOM simulator to add a delay and set it to 5 seconds. With 184.108.40.206 the next focus image was acquired almost instantly showing that SGP had started the image acquisition before the focuser had reported that it had stopped while with 220.127.116.11 it waits until until IsMoving returns false.
The various ASCOM logs show this all quite clearly.
The issue with SGP was seen and confirmed last Feb, the original correspondence stated as such (quoted previously in this thread). Also as stated in the thread, the mount and the rotator have arbitrary delay settings available for the user. I gave up out of frustration of being ignored last time around, anything that I thought got in the way of pooh-poohing the real issue this time around is not something I was willing to accept, which is what I took your comments to be, all it took was a little research to see the issue.
I really appreciate that Gene put in so much work to help identify the problem. I have worked with Gene over the years both with his guide interface and his focuser and really appreciate his can-do approach.
I also want to thank Mark for resurrecting this issue when others of us had just plain given up - largely out of exhaustion. And thanks to the SGP developers for giving it another look.
I’m glad this bug was finally found, but I think an important thing to note is that this problem has been reported numerous times - and in each thread there are other people saying they have the same problem and want some kind of delay.
Here is my post from July '16:
So I think many more people were impacted - including those with Crayford focusers who wouldn’t even have noticed focus was changing during exposure. Now that the bug has been identified it should be more clear how many people were affected. I’m just not sure about other people who had this problem and didn’t have a different camera to switch to. Did they just give up on autofocus and sgp?
There were many assumptions going on - but a key point in all of it is - SGP autofocus just doesn’t work at all with my current setup. Can it be fixed?
My assumption was that a delay was needed and the exposure is happening too soon after the movement. At the same time - the counter assumption was - my setup is weird and has problems - and adding a delay is not justified since things seem fine for most people.
When a user has a fundamental problem that kills overall functionality - it is quite irksome to be told that efforts to fix it should not be attempted since it would violate some “pure” concept of the software design. Especially when things like delays are all over the software - and it isn’t pure in the first place.
At the core - I was a user with a setup and a camera - and autofocus just did not work at all - because every focus image was streaked. If you can’t autofocus with your setup - most of sgp’s features are useless because otherwise you need to focus manually during the imaging session.
Meanwhile - I was able to use other cameras and it all worked fine - so I did have a fallback. But since it worked just fine with other cameras - it was evidence my equipment was working fine and something else was causing a problem with the other cameras during focus. There was a bug in there - and it was insidious - but certain setups showed the problem consistently.
If anyone has had ugly focus curves and erratic autofocus behavior - this fix may help - and they should look at their autofocus images to make sure the stars aren’t streaked.
And even if their curves have looked good so far - they have a chance to improve now if focus was changing during exposure and they didn’t even know it.
Update on the Auto Focus (AF) “IsMoving” bug. Last night the clear skies God was looking favorably upon us North East Ohio folks and I was able to test out the fix that Ken made to the AF “IsMoving” bug in V18.104.22.168. and the bug appears to be fixed. AF is now waiting for the “IsMoving” before kicking off the AF image request. I am getting the best V-curves I’ve ever gotten with this Camera/Scope. However, I did find I needed a 2 second delay that I was able to do using Gene’s The nSTEP ASCOM Driver that he integrated a user input delay into his focuser driver 6.0.7. Anything less than 1.5 seconds and I was not getting a very good V-cure graph so I landed on 2 seconds to be on the safe side. See before and after graphs below:
After fix with no delay
After fix with 2 second delay
I still believe adding a user input delay into the AF would be a benefit. As I believe any mechanical that is moving, ie Telescope, Filter Wheel, Focuser, and Rotator would all benefit.
I wish to thank Gene and Ken for their work on finding and fixing the bug!
BTW Ken you are not going to believe this but now I am seeing that the camera is taking images before the rotator stops. I’ll post this on another thread later but see image below. Maybe when you fixed tor AF bug something got broke between the rotator and camera.
I’m hesitant to jump in here both because I’m late to this thread, and because I have no expertise on this at all. But I’ve been using the Rigel system on my pre-Edge (ie, moving mirror) C11 for years with no real trouble. A couple years ago Frank pointed out that the focuser was ending focus in the wrong direction, and Gene modified the software to solve that. Since then, no problems with AF. I get good v-curves almost every time. I use an SXVR-H694 camera - no shutter - so maybe that has something to do with it. But it’s working well. Maybe that adds a data point to help with this issue.
Thanks for the info. The bug appears to be fixed as of 22.214.171.124. I just recently downloaded, installed and tested 126.96.36.199 last night and it appears the AF is now waiting for the “IsMoving” to return false before taking the image during AF. I think, depending on the the equipment, most folks never noticed this problem. In fact I never experienced the focusing issue until I started using the QHY174 camera. I’ve been using SGPro for around 2 years before this issue appeared. Gene worked with the SGP developers to identify the bug and got it fixed, BTW thanks again Gene.for the help on this. Also @freestar8n, Frank. was using the same camera and experience the same AF issue. It does appear to be something related to the type/brand of camera and maybe the focuser driver that appears to be more susceptible when the “IsMoving” is not being honored by the AF routine in SPG.
Anyway the short story is the AF “IsMoving” bug appears to be fixed!