Potential Auto Focusing Bug

Sequence Generator
11

Hi Jared,

I wanted to ping this again to see if you thought much more about trying to fix the IsMoving bug/issue? If we can get the IsMoving thing worked out, Gene has an updated driver that will allow the user to select a delay so the system can settle in before SGP kicks the image request off during autofocusing.

I truly believe the best solution is to build a delay into the SGP autofocusing process, either fixed or user settable (much like the mount does), to allow for a very small delay, maybe 1 second, between focusing moves to allow the system to settle before kicking off the image. This isn’t important for folks using crayford focuser but I believe it is very important to have a delay for the folks using a primary mirror focuser.

Also, I haven’t had any clear skies so I have not be able to see what’s going on with why I cannot get the autofocusing to take anything longer then a 1 second exposure. If needed, see my previous logs I posted last week.

Kind Regards,
Mark

12

I was able to do a little more testing last night to find out why the autofocusing imaging time is stuck at 1 second. It appears when I have the manual rotator active in the sequence the autofocusing imaging is fixed to 1 second. Even if I have the autofocusing imaging time set to some other value it will always take a 1 second exposure. However, if I deactivate the manual rotator and run the autofocusing, the imaging time is obeyed during autofocusing.

I’m sure it is something I don’t understand with how the manual rotator interacts with the autofocusing process. I was always under the belief that I need the manual rotator active in my sequences so I can take flats as part of the sequence. I use the Alnitak driver so SGP can set the brightness and turn on/off the flat panel.

Anyway, any help on this would be helpful. Maybe I don’t need to have the manual rotator as part of my equipment profile to use the flat panel?

Thanks,
Mark

13

Hmm… that sounds all wrong to me. Can you post a sgf that shows this issue? I can’t think of any good reason that the rotator would affect AF.

14

Hi Ken,

As requested below is the Dropbox link to the Sequence Files. I included the sequence file as well as the equipment profile file. The file(s) were to big to upload here, exceeded the 1,024kb limit by 200kb.

Thanks for taking a look.

Kind Regards,
Mark

15

Not sure if related but in the log based on your sequence ‘Filter 1’ has an AF time of 1 second versus Filter 2 which is 4 seconds.

[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] >> FILTER 1:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] bActive: True
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] sName: None
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] nAfExposureTime: 1

And then this:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] >> FILTER 2:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] bActive: True
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] sName:
[03/18/17 08:24:37.990][DEBUG] [Sequence Thread] nAfExposureTime: 4

All other ‘filters’ have bActive=False

Is it picking up AF time for ‘filter 1’ ?

Gene

16

I did some additional testing this morning on this AF issue.

  1. I simply did the following. (No eqipment profile was used and No Sequence was loaded)
    Camera = Simulator
    No Filter Wheel
    Focuser = Simulator
    When I run the AF this way the AF time is honored.

However

  1. When I run this way
    Camera = Simulator
    Manual Filter Wheel
    Focuser = Simulator
    The AF only takes a 1 second exposure.
    Even if I change the AF exposure time in the Filter Setup window, when I run AF with the Manual Filter Wheel active it still only takes a one second exposure.

When I either have No Filter Wheel or have the Manual Filter Wheel deactivated the AF works fine. There seems to some link between the AF and the Manual Filter Wheel.

Hope this helps isolate the problem.

Regards,
Mark

17

@mahaffm

Before I go deep diving through logs here, I just want to make sure the issue you are seeing is beyond this concept.

When you have no filter wheel selected, your AF exposure time is set here:

When you are using a filter wheel (manual or otherwise), you set AF exposure times individually, per filter, as seen here:

If this is old news to you, we can dig further.

18

Yep, Old news,

This first image below is showing the Camera and focuser connected, (Both Simulators) and in this configuration I have the AF exposure time set to 4 seconds. AF kicks off and runs the 4 second exposure.

AF setup 01.JPG865×659 91.5 KB

This second image below I included the manual filter wheel connect and connected. I also have the AF exposure time set to 4 seconds. AF kicks off but only runs the exposure for 1 second.

AF setup 02.JPG830×646 90.4 KB

It is very easy to reproduce and very repeatable. You don’t need any equipment profile or sequence loaded. Simply select the camera and focuser simulator, select whatever AF time you want and run the AF. it will obey the imaging time. Next add in the Manual focuser wheel, set the filters to whatever value you want. Run the AF and you’ll see that the AF image only takes a 1 second exposure. I’ve run the test on two different PC as well as the previous SGP Beta as well as this newest release, beta x.20, and in every case the AF behaves the same.

Hope this helps.

Thanks,
Mark

19

I think you mean you have it set for 3 seconds? Not being nit-picky, just making sure we aren’t talking past each other. Either way, 1s is not part of this equation. I’ll take a look.

20

Hi Ken,

Sorry, I should had been a little clearer, meaning the AF exposures were set to 4 seconds and the Filter was set to 3 seconds. I believe if you follow the way I tested it, it should be easy to verify on your end.

Thanks again,
Mark

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.