Autofosus not working with ASA AAF3 focuser?

Hello
I have ASA10 with ASA absolute AAF3 focuser.
I can not do an autofocuser with SGPro because I have an absolute AAF3 focuser.
AAF3 focuser works so that the position is constantly oscillating in a thousandths.
example of focuser:
3.356- 6
3.356-7
3.356-6
3.356-7
SGPro is constantly waiting and can not return to the desired position.
Would you please advise me?
Could you please help me
Peter

Generally focusers expose “steps” and SGP tells the focuser to go to that position. The AAF3 uses an encoder and exposes the position back to SGP which is not normal to the ASCOM standard. Is there a way to have the driver expose steps?

Thanks,
Jared

Hello,
I wrote to ASA.
My question was whether they can help with the problems that AAF is not working properly
They wrote to me this:

No nothing yet.

We would need to change firmware, software, and the Ascom driver for this, which compromises the absolute reading we are putting out.

Have you talked to the SGP people about their software being unable to deal with high res absolute encoder output

Can you solve the problem why AAF absolute focuser tiny right with your software?
PETER

It should be pretty simple for ASA to fix this by converting the values in the driver to steps, since their ASCOM driver doesn’t follow the standard this is something that ASA should fix, not force software develops to support their non-standard ways of handling things

I agree with @Xplode here… I do apologize sincerely for placing you in the middle here. That said, a standard is in place for a reason. I would recommend something like this for the ASA driver:

  • ASCOM driver is asked to move to position 4.5
  • ASCOM driver finishes moving and got to wherever it got to (right now this might be something like 4.49
  • The ASCOM driver, here, is in possession of the original request position and also knows when it is done moving. At this point, instead of oscillating based on an encoder value, use software to force it to the requested value.

People seem to be suggesting that the ASA focuser returns positions in mm as a fraction, such as 3.456 mm Is this true for the ASCOM driver output? If so then it’s not ASCOM compliant. The position is defined as an unsigned integer. Returning the position in microns, such as 3456, would be fine.

I don’t think there is anything in the ASCOM standard that specifies the accuracy with which a target position is reported, or the noise on the position reported.

AIUI what is happening is that SGP is waiting until the focuser returns IsMoving as false, then reads the position and if it’s incorrect fails.

That seems to me to be a misinterpretation of the ASCOM standard.

Or is IsMoving not checked and SGP waits for the focuser position to match what was requested? I would also be uneasy about that, with backlash there’s nothing to stop a focuser reporting the target position as it goes past it when doing the backlash move.

I would be very uneasy about suggesting that the driver lies about the position it has reached. What if it has really not reached the correct position due to slippage of some sort?. Wouldn’t it be better to be aware of where it really was?

It very much looks like the driver is not ASCOM-Conform.

For Peter: I would suggest you get the ASCOM Conformance Checker from here:

https://ascom-standards.org/Developer/Conformance.htm

and run it to test the ASA driver. At the end of the log file the checker will produce, you should see:

If there are errors, the driver is not compliant, and it will most probably not be reliable with SGP. You may also try to send the results to ASA.

Kind regards,
Horia

Hello,
ASA was willing and modified the AAF driver so that AAF does Round Last Digit.
I tested AAF with new driver and SGP autofocus.
It works at 50% :frowning:
The program (SGP) already communicates with AAF.
The Autofocus SGP runs correctly, the program performs the curve and determines the position of the correct focus.
An error occurs at the end.
Autofocus SGP determines the focus position, for example, 2.556.
Autofocus SGP sends AAF to the desired position 2,556.This is OK.
But!
AAF will send SGP Round Last Digit focus information to 2,550.
SGP does not process the information as correct and autofocus remains frozen.
Don’t end the process.
I’m sad about it, we can’t handle this problem in SGP???
Because AAF no longer changes the ending number but makes a round Last Digit.

It’s not clear to me what you are explaining. Are you saying that SGPro asks the focuser to go to 2556, but it will only go to 2550? Or maybe something else?

SGPro will eventually timeout and issue an error.

SGP makes a curve that has a focus value (example 2.253). OK
AAF goes to position 2,253. (I see it on ASA focuser software) .OK
BUT!
In SGP in autofocus is recorded position 2,250.
Autofocus SGP does not complete the process.

I am still confused. Are you referring to HFR values or Focuser position? It would be easier if you sent logs showing the issue.

I still write about the focus position.
I’ll try to send a diary.

OK, I understand what you are saying now, but… we will still need logs. You might want to turn focuser logs on also since what we will likely find is that the ASCOM driver for the focuser is not reporting its position properly. What version of SGPro are you using?

I did with Ascom diagnostics ACC focuser, these are the results
I’m using the last very SGP.
I sent SGP logs, also ASA ACC logs

19:25:18.131 Registered Device Type Focuser
19:25:18.131 Registered Devices ACCServer.Focuser - ASA ACC Focuser
19:25:18.133 DriverCompatibility ProgID: ACCServer.Focuser, Bitness: Bits32
19:25:18.134 DriverCompatibility Found 32bit ProgID registration
19:25:18.134 DriverCompatibility Running on a 64bit OS, 32bit Registered: True, 64Bit Registered: False

To where did you send logs?

Hi, Ken. Peter’s english is not very good, so I will try to explain this problem. I made the tests with him. ASA focuser reports real position from encoder. The position 3.123 in ASA software is reported to SGP as 3123. Here is what we found out:
Original ASCOM driver (if you send the focuser to position 3123) reports position 3123 +1 or -1 point around this position. It is oscilating in time each 0.5 second. SGP autofocus fails with high probability, because after SGP sends the focuser to desired position, it has probability about 50% that it will read the correct position or the position shifted by +1 or -1 point. During autofocus routine when the SGP is moving the focuser 7 times, it is nearly imposibble 7 times in line to read the correct position, not shifted +1 or -1. If SGP will accept as a correct position position shifted by +1 or -1 point, then the SGP focusing routine will not fail. However, this would require the SGP to incorporate with what accuracy it should accept the focuser position.
New ASA ASCOM driver is able to round the last digit so it reports its positions each time with 0 at the end. So the position 3123 is reported as 3120, but also each posion 312x is reported as 3120. This eliminates the oscilating last digit but the SGP focusing fails at the end because it is extrapolating best focus position let’s say at position 3234 and the focuser is really at position 3.234 but it is reported to SGP as 3230 which is not 3234 as expected.

I sent it to
forums@mainsequencesoftware.com

or send me email…

Thanks, I understand. This is not the first time this issue has been brought up. This is something that will need to be addressed in the ASCOM driver itself and not within SGPro. It should be simple enough to adjust in the driver without causing clients using the driver to make approximations.

1.) ASCOM driver takes absolute positioning command
2.) ASCOM driver moves ASA focuser to wherever it thinks that position is or the closest approximation to it
3.) ASCOM driver determines the move was successful and holds its own internal information about position.
4.) ASCOM driver returns the requested position as the current position

It can’t be true that the focuser is shifting position while idle and it must be true that the focuser will arrive at the requested position.

I don’t think the ASCOM specification says anything about the accuracy with which the focuser arrives at the target position. This looks like an additional SGP requirement.

This seems like a fairly self-evident requirement that literally every other focuser in the market has managed to abide by…