Potential Auto Focusing Bug

Sequence Generator
21

@mahaffm

OK, so 2 things are going on here:

  • There used to be code that forced filters to have names. This code was, somehow, removed and your unnamed filter was wreaking havoc inside the code that searches for AF exposure times. This has been corrected… all filters must have names and 2.6.0.21 actually enforces this.
  • There was a bug in the AF settings dialog that allowed for someone to choose to use a filter override for AF, but set the filter to “None”, like this:

    This has also been corrected and “None” is no longer a selectable option for override.

In the meantime, you should be able to correct the issue you are seeing by ensuring that the two bullets above are no longer applicable to your sequence / profiles.

22

Thank you @Ken for fixing. Since no one else wasn’t having any issues with the manual filter wheel and AF I thought I was going crazy, (jury is still out on this :grin:). Interesting though that you found the Auto focus with filter issue as none of my profiles has the Auto focus with filter checked, Somehow this issue must had presented itself while you was chasing the bug. Anyway glad you were able to fix.

I do have one questions. To use the Alnitak Flat Box to takes flats during my sequence, I do in fact need to have the manual filter wheel active in my sequence? is that correct? I thought that is what I read at one point and that is the only reason I’m using the manual filter wheel option is for taking my flats.

Also, I know this thread is getting a little long and I interjected this AF/Manual filter wheel bug in here but I would like bring up my original issue with the IsMoving bug, (See my first posting in this thread) I’m not sure if Jared is looking into it any longer but was interested if there might be any update?

Thanks,
Mark

23

Ya, I came across this issue in my own tests. I was not able to see if you had that option checked.

I’m think about this and I can’t come up with a good reason that a flat box requires a CFW. We have lots of OSC and DSLR folks that use flat boxes.

I don’t think there is anything else to look at from the SGPro side. @Jared made some changes here to be more compatible with the ASCOM contract. Not aware of anything else that needs to be done.

24

Thanks @Ken for the update. I am a little disappointed with not getting the IsMoving issue resolved. Maybe it’s not as big of an issue as I perceive since no one else, (other then @freestar8n), appears concerned with wanting and/or needing a little pause between when the AF move completes and the AF Exposure timer kicks off. SGP is a great piece of software and I really do appreciate what you and Jared have accomplished. You both have really help make this hobby much more enjoyable.

Kind Regards,
Mark

25

At this point I don’t know the problem or the fix exactly - except that with certain cameras the autofocus was unusable due to trailed stars - and with others it worked fine.

To me it is common sense that there should be a user-settable delay after a focus move - just as there are delays for many other system events that involve mechanical motion.

But I’m not clear the issue is a simple delay - or for some reason sgp is not properly handling the IsMoving. It sounds like there was a secondary effect due to a timeout with backlash compensation - but I’m not sure if that is the whole story.

So - I will test it again with the qhy174 at some point and report what I find. It sounds from Mark’s tests that there is still a problem. It may well be affecting others and they just don’t realize it.

Frank

26

I have the same problem here, the focuser is still moving and the camera is already capturing the image. The delay is a very simple fix or another thing as already mentioned is to listen to the IsMoving event.

Adding more information here. I was playing around with the focuser module and noticed that it has some lag in issuing the command to move the focuser. I tried a lot of different application and it was not a problem at all. That lag which is around 1-2 seconds is making it worst specially on high speed cameras.

27

If the sensor was not square on to the plane of focus, rotating it would make a difference to individual star FWHM.

28

The delay won’t fix anything if your focuser isn’t reporting “IsMoving” correctly. I had thought we had addressed these issues with the FocusLynx focusers. If that’s not the case we’ll need logs to investigate.

Thanks,
Jared

29

Hi Jared,

I know for sure that I’m supporting the IsMoving property because I wrote the ASCOM driver. Whenever the motor changes it’s state, it fires an event.

Code below on the ASCOM driver implemtation

            if (message.Contains("POSITION"))
            {
                focuserPosition = Convert.ToInt16(message.Split(':')[1]);
                OnFocuserValueChanged(new FocuserValueChangedEventArgs(focuserPosition, focuserPosition));
                OnFocuserStateChanged(new FocuserStateChangedEventArgs(false));
                this.isMoving = false;
            }

            if (message.Contains("MOVING"))
            {
                OnFocuserStateChanged(new FocuserStateChangedEventArgs(true));
                this.isMoving = true;
            }

And this is on the Client that reports the status of the focuser

    private void SetCurrentState(bool isMoving)
    {
        if (lblAction.InvokeRequired)
        {
            SetCurrentStateCallBack d = new SetCurrentStateCallBack(SetCurrentState);
            this.Invoke(d, new Object[] { isMoving });
        }
        else
        {
            if (isMoving)
            {
                lblAction.Text = "MOVING...";
            }
            else
            {
                lblAction.Text = "READY...";
            }
           
        }
    }

Hope that helps

30

I know this is a while ago but this thread was quoted today.

I’m not sure that the code above does what I would expect. A “POSITION:nnnn” string is sent from the focuser hardware. The code extracts the position value from the string and raises two events, one reporting that the focuser position has changed and the other reporting that the move has finished. isMoving is also set to false. If this “POSITION:nnnn” message is sent before the focuser has finished moving then isMoving will be in the wrong state.

The ASCOM interface code is not shown but if reading the ASCOM IsMoving property uses the value of the local isMoving property then this will return false as soon as the first “POSITION:nnnnn” message has been sent from the motor controller hardware.

Can the hardware send a “POSITION:nnnn” message before the focuser has finished moving to a new position? If so this code will set isMoving incorrectly.