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 
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:
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.
You are right, I’ll try immediately 
The bad news is that there is no information in the log:
just data from the ccd temperature
The good one is that after I upgrade to the last version 403 the problem occurs just the first time I start the focus, then only successes. I need more attempts in order to be sure that the system works fine, so I have to wait for a real massive test.
Thank you for now
I forget if this log is for all device drivers or if there is a different log file for each device. Is there data from anything other than the camera in there?
In the directory there is only one file per DriverAccess and inside there is only information about the ccd.
I try to activated other logs, but I found nothing inside about the focuser:
