Does SGP talk to Planewave's PWI AutoFocus?

Kurious_George · January 23, 2018, 10:07pm

Does SGP talk to Planewave’s PWI AutoFocus? Apparently they have an API and are willing to discuss how to integrate if we don’t already.

Not sure if PWI AutoFocus uses the same technique as the one native with SGP.

Kurious_George · May 17, 2018, 1:49pm

Hi folks, checking if SGP now talks to Planewave’s PWI3 for auto focus? This is the code Planewave provided…

// pw_autofocus.js version 1.2

// This script demonstrates how to use the PlaneWave.AutoFocus COM object
// to control the AutoFocus feature supplied by PWI2 and PWI3. It can be
// called from other programs, such as the “AutoSave” sequencer implemented
// by MaxIm DL, to perform periodic autofocus runs.

var _fso = new ActiveXObject(“Scripting.FileSystemObject”);
var _shell = new ActiveXObject(“WScript.Shell”);
var _shellapp = new ActiveXObject(“Shell.Application”);

function Log(text)
{
var ForAppending = 8;

var myDocs = _shell.SpecialFolders("MyDocuments");
var relativeLogPath = "PlaneWave Instruments\\AutoFocusClient\\Log";
var logPath = myDocs + "\\" + relativeLogPath;
var logFilePath = logPath + "\\pw_autofocus_log.txt";

if (!_fso.FolderExists(logPath)) {
    myDocsFolder = _shellapp.Namespace(myDocs);
    myDocsFolder.NewFolder(relativeLogPath); // Recursively create subdirectories
}

var now = new Date();
var timestamp = now.getFullYear() + "-" +
                Pad(now.getMonth()+1, 2) + "-" +
                Pad(now.getDate(),    2) + " " +
                Pad(now.getHours(),   2) + ":" +
                Pad(now.getMinutes(), 2) + ":" +
                Pad(now.getSeconds(), 2);

var logLine = timestamp + ": " + text;
WScript.Echo(logLine);

var logFile = _fso.OpenTextFile(logFilePath, ForAppending, true);
logFile.WriteLine(logLine);
logFile.Close();

}

function Pad(number, minLength)
{
var numberStr = “” + number;
while (numberStr.length < minLength) {
numberStr = “0” + numberStr;
}
return numberStr;
}

function DoAutofocus()
{
Log(“Initializing PlaneWave AutoFocus library…”);
var af = new ActiveXObject(“PlaneWave.AutoFocus”);

Log("Starting PWI if needed...");
af.StartPwiIfNeeded();
ConsumePlaneWaveAutoFocusMessages(af);

Log("Connecting to focuser if needed...");
af.ConnectFocuser();
ConsumePlaneWaveAutoFocusMessages(af);

var attempts = 0;
while (!af.IsFocuserConnected && attempts < 30) {
    WScript.Sleep(100);
    attempts++;
    ConsumePlaneWaveAutoFocusMessages(af);
}

if (!af.IsFocuserConnected) {
    Log("Focuser is not connected. Aborting...");
    return;
}

Log("Checking if Auto Focus is required...");
if (! af.IsAutoFocusDesired) {
    Log("AutoFocus is not desired at this point.");
    return;
}

Log("Beginning AutoFocus...");
af.StartAutoFocus();

while (af.IsAutoFocusRunning) {
    ConsumePlaneWaveAutoFocusMessages(af);
    WScript.Sleep(200);
}

var successOrFailed = "FAILED";
if (af.Success) {
    successOrFailed = "SUCCEEDED";
}

Log("AutoFocus run " + successOrFailed);

}

function ConsumePlaneWaveAutoFocusMessages(pwAutoFocus)
{
while (true) {
var logLine = pwAutoFocus.NextLogMessage;
if (logLine == null) {
return;
}
Log(logLine);
}
}

try {
DoAutofocus();
}
catch (ex) {
Log("FATAL ERROR: " + ex + ", " + ex.message);
WScript.Echo(“Press enter to continue…”);
WScript.StdIn.ReadLine();
}

Jared · May 17, 2018, 2:28pm

Not at this time. I’m not finding any documentation on PWI3 or the requirements for auto focus. I assume that it would need to be connected to the camera some how?

Thanks,
Jared

Kurious_George · May 17, 2018, 4:02pm

PWI3 connects to the camera using Maxim DL. If I run the .js code above, it does it all, assuming you have Maxim DL installed.

When SGP runs autofocus, could there be an option to call a .js instead and then wait for it to report back it’s done? I’ve never seen it do anything else so that handshake would be simple. Basically unplug the current autofocus and plug in a .js. Then I have full sync between SGP, PWI3 and PHD2. This would be a very powerful feature for non-native support by SGP.

BTW, I tried to use SGP’s autofocus, but it often fails with errors like this…

[05/17/18 01:31:24.532][DEBUG] [Camera Thread] Moving focuser to next position (4506)…
[05/17/18 01:31:24.533][DEBUG] [Focuser Move Thread] Focuser moving to 4506
[05/17/18 01:31:24.533][DEBUG] [Focuser Move Thread] Focuser move call complete
[05/17/18 01:31:34.534][DEBUG] [Focuser Move Thread] Focuser moving to 4506
[05/17/18 01:31:34.534][DEBUG] [Focuser Move Thread] Focuser move call complete
[05/17/18 01:31:38.534][DEBUG] [Focuser Move Thread] Focuser moving to 4506
[05/17/18 01:31:38.534][DEBUG] [Focuser Move Thread] Focuser move call complete
[05/17/18 01:31:42.534][DEBUG] [Focuser Move Thread] Focuser moving to 4506
[05/17/18 01:31:42.534][DEBUG] [Focuser Move Thread] Focuser move call complete
[05/17/18 01:31:46.535][DEBUG] [Focuser Move Thread] Focuser moving to 4506
[05/17/18 01:31:46.535][DEBUG] [Focuser Move Thread] Focuser move call complete
[05/17/18 01:31:47.535][DEBUG] [Focuser Move Thread] MoveFocuserAbsBlocking: Focuser position is stale for 10 seconds, retrying…
[05/17/18 01:31:47.535][DEBUG] [Focuser Move Thread] MoveFocuserAbsBlocking: try counter expired, failing…
[05/17/18 01:31:47.535][DEBUG] [Camera Thread] Focuser move complete…
[05/17/18 01:32:48.040][DEBUG] [Camera Thread] Error in auto focus! Focuser failed to move to the requested position (4506). Focuser reports it is at 4517.

Kurious_George · May 17, 2018, 7:17pm

"Regarding the SGP autofocus issue: it looks like it is unhappy because the focuser is occasionally stopping and reporting that the move has finished successfully even though it is technically a small number of microns away from the intended target. (For example, it was told to go to 5691 but it stopped at 5696). For all practical purposes this doesn’t matter, but it looks like SGP is picky about making sure it’s exactly at the intended target.

I wonder if there might be a setting in SGP to either disable this check or to add some tolerance (accept the focuser if it is within 20 microns of the target, for example)."

Jared · May 18, 2018, 3:24am

If PWI is controlling the camera through Maxim, then they’d need to change PWI to also use SGP in addition to us triggering auto focus through their application. So being able to support this would depend on if Planewave also wanted to make that change.

Thanks,
Jared

Kurious_George · May 18, 2018, 4:03am

Understood. Checking.

Chris · May 19, 2018, 7:32am

It looks as if there’s a need for a standard communication method for things like this, a bit like ASCOM but for higher level communication.

Things such as:

Guiding
Plate Solving
Auto Focus

Maybe also

Precise centering
Slave dome to telescope
Safety monitoring.

Kurious_George · May 19, 2018, 1:57pm

Exactly! Still checking what’s simple.

Kurious_George · May 29, 2018, 6:20am

Hi Chris,

Would it be possible to place some tolerance (fixed or user-entered) on
what the focuser reports back?

Maybe +/- 20 or some user-entered value? This will allow us to check the
SGP autofocus performance with a Planewave CDK24 and Hedrik focuser.

Currently a non-zero delta causes the autofocus to fail with the focuser
out-of-focus with the first (or second or third) autofocus sample point.

Kurious_George · May 30, 2018, 6:37pm

Hi Jared,

Would it be possible to place some tolerance (fixed or user-entered) on
what the focuser reports back?

Maybe +/- 20 or some user-entered value? This will allow us to check the
SGP autofocus performance with a Planewave CDK24 and Hedrik focuser.

Currently a non-zero delta causes the autofocus to fail with the focuser
out-of-focus with the first (or second or third) autofocus sample point.

Jared · June 1, 2018, 12:39am

I don’t think we would allow any “fudge factor” but we may “stop caring”. Essentially just not verifying that the focuser is where we told it to go and hoping that the focuser did the right thing.

No real plan on if/when this would happen. But it’s not the first time that we’ve had a similar issue where a focuser couldn’t get to the location that was requested. Most absolute focusers report steps but some report a different measurement that seems to cause the issue.

Thanks,
Jared

Kurious_George · June 1, 2018, 2:39am

Would you be willing to provide a special build at a cost for the “stop caring” feature?

andychess · August 14, 2020, 9:27am

I’m also experiencing this problem with a Planewave CDK 14. I’ve lost several imaging session as the autofocus routine has aborted the sequence because the focuser hasn’t reported the exact required position. A checkbox to ignore this check and/or a soft warning, would be a huge help.
I don’t want to migrate (downgrade!) to MaximDL, but the autofocus behaviour is proving to be a deal breaker at the moment.

Kurious_George · August 14, 2020, 2:18pm

Andy, even if they fix this, I have not been able to get SGP to match the focus performance of PWI3. SGP often picks up double stars, small galaxies and other non-star objects that can throw the V-Curve off 100+ microns. That was too much for my purposes.

andychess · August 15, 2020, 8:54am

Thanks KG. May I ask you what solution you went for in the end?

Kurious_George · August 20, 2020, 1:11am

Sorry for the delay Andy. Now I just use PWI3 to focus every 2 hours. For me that means getting up at midnight and 2 AM.

My observatory is cooled to ambient, so I’m temperature stable by 9 PM.

The Planewave folks provided me with the code to have SGP talk to PWI3 for focusing. I provided it to the SGP folks but no response. I suspect it’s too small an audience to take it on. I even offered to pay for the development so I could get some extra sleep. (-:

KG

andychess · August 22, 2020, 8:44am

Hi KG,

Thanks for the reply. I also just heard from Jared. I assume that you have Maxim installed as well to run the PWI auto focus?

SGP works flawlessly for me about 70-80% of the time, but I am still getting shutdowns associated with the autofocus routine that cost me imaging time.

I am also prepared to make a contribution to the cost of amending the code in order to disable the position check or at least change the SGP behaviour to avoid aborting the sequence. I have invested a lot of time in getting SGP to work with my setup, especially the 10Micron mount and I really don’t want to have to migrate to a new software platform.

Andy

Kurious_George · August 22, 2020, 2:19pm

Same here Andy. I do have Maxim installed.

I see two issues that need to be addressed that I’m willing to help fund as you are…

Provide an option to disable or place a tolerance on the position check code.
Improve the SGP focus algorithm to “never” pick up double stars, small galaxies, etc. OR, provide an option to interface with PWI3 or Maxim to improve the autofocus quality.

You may not be noticing #2 so much now. But it’s very noticeable with large apertures (e.g., 24") with seeing around 1".

FarnhamMike · October 19, 2020, 8:04pm

Came across this thread only today and so not sure if it is still current.

I have only a modest refractor scope and and am generally happy with the results I get from SGP’s autofocus routine except that on occasions it detects only a very few stars and when this happens the resulting autofocus graph tends to be rather jittery and from a visual inspection I think that SGP is not probably not finding the best focus position.

I’m not familiar with the Planewave Autofocus routine discussed above or how it performs but decided I would take a look at a few of the Autofocus images that I have to hand using the ASTAP Solver CCD Inspector feature.

I don’t have too many AF packs to hand but my observations of the few I do have I have concluded that:

a) ASTAP seems to detect more stars in an image that SGP
b) I think it probable that ASTAP is referencing its star database in the course of its analysis and so consequently think it is ignoring e.g. double stars and small galaxies during in its HFD calculations.

As SGP already has an interface to ASTAP for plate solving I am thinking SGP’s AF routine could be improved if it were possible for SGP to request ASTAP to use its CCD Inspector feature to analyse an SGP AF image and to report back the resulting star count and median HFD value.

In particular I think if SGP’s AF curve fitting routine had ASTAP’s more robust star count and median HFD values available then ultimately this would leadd to a more accurate AF position calculation.

In Excel I have done a very limited comparison of some AF graphs output by SGP against the Median HFD (2 x HFR) values reported by ASTAP CCD Inspector to illustrate my hypothesis.

I imagine that if ASTAP is able programatically to report back a star count and median HFD for a requested image it would be relatively straightforward to use SGPs curve fitting routines to produce a corresponding chart and focuser position for comparison with the current output. Sadly I don’t have the skills to do be able to do this by myself.

I think considerable numbers of SGP users are already using ASTAP fr plate-solving so if this suggestion has merit and is workable it w.ould hopefully not cause issues to the majority of users

My apologies if the idea has already been aired elsewhere.

Regards

Mike

PS: How does one attach an Excel file to illustrate my (limited) analysis?