SGPro 3.1.0.402: Focuser doesn't move

The focuser doesn’t move

OS: Microsoft Windows 7 Professional
Ver: 3.1.0.402
.NET: 4.7.2

Focuser: FLI PDF
CCD: G2-4000

During autofocus SGP send the command to move to the focuser, but it doesn’t move. The autofocus works with the previous versione (4.1.0.319)

Steps to Reproduce this Issue

Start autofocus (sometimes at stars, sometimes at check focus)

Logs

Not sure. Your focuser timed out after being asked to move, but the next call to restore the focuser to the original position seemed OK. Is this repeatable? Even after cycling power to the focus controller?

One thing that is interesting is that SGPro asks your focuser to go to 3980 (starting at 3230). It never arrives at this position and when we query it after timing out, we find that it is at 3180. This movement isn’t even in the right direction. This makes me think that something else besides SGPro sent a movement command to the focuser. Was anything else connected to it? Did you accidentally press any buttons on the controller itself or on the controller’s native control app?

If this is reproducible, we will need the focuser’s logs in order to proceed.

Thank you for your adivce.
It really seems that something move the focuser, but I don’t know how. The only software connected to the focuser is SGP.
Yesterday I try a lot with the beta version 3.1.0.390 and the focuser random doesn’t move (usually at start focus sequence or at starting new position when it doesn’t found the focus). Today I try the last version and it doesn’t move just the very first time, then I try again and it works. Now I couldn’t try because there are too many clouds. I’ll check again as soon as possible.

Ok, Check with the author of the focus driver to see how you can enable logs for the focuser and we will take a look.

the driver author told me that there is no log and so to solve the problem we have to find another way. Today I tried again and at the start it had the same behavior: at the time of starting the focuser procedure it moved back and then stopped.

This is not really a good answer…

This really sounds like a problem with the ASCOM driver. Not having any way to prove or disprove this theory is unhelpful. What focuser are you using?

The only thing I can recommend is that maybe, after connecting to the focuser, go ahead and move it manually a couple times before starting the sequence. Maybe this will allow you to bypass that first move?

The focuser is the FLI PDF, I know that is not a good answer and it doesn’t help us. I’ll try, but with this bad weather is it impossible to try :frowning:

Ascom has a DriverAccess log which logs everything sent to the driver and returned from it.

@pk825 Chris is correct… I forget this exists for ASCOM devices. There may be other ways to enable DriverAccess logging, but you can open the “ASCOM Diagnostics” app and turn it on like this:

image

You should be able to do some basic movement testing indoors… meaning, you can check, if after connection, the first move is always messed up or if the position lands where you think it should.