Atlas focuser woes

Seems like my software stack isn't working too well with the Atlas focuser:

1. Connecting
When I try to connect the Focuser (from SGPro, TheSkyX and even the POTH hub from the ASCOM driver) I get a "Can't connect to Focuser" error message. I tried to analyze this with POTH (to see which commands are sent). Upon a successful connection, I see:

Focuser Link: False -> True (connected)

Focuser Link: False

Focuser Absolute: True

Focuser Halt  (done)

Focuser TempCompAvailable: False

Focuser Temperature: 29.5625

Focuser Temperature: 29.5625

Focuser Absolute: True

Focuser MaxMaxStep: 0

Focuser Temperature: 29.5625

Focuser Position: 22774

When the connection is unsuccessful, I see:

Focuser Link: False -> True

Focuser Link: False -> False no change

Not much useful information. But after trying various combinations, I noticed that when I just press "Connect" (in either SGPro, TheSkyX or POTH) I get an error message. When I press "Setup" first and then "Connect" all programs connect very reliably. I guess calling the setup program loads the driver or some dll's that are required for the driver to connect and that aren't loaded just by connecting. Or it might be a timeout issue. Contacted FLI support for this.
But at least I have a reliable way to connect.

2. Hanging or ignoring focus move commands
Quite often, the autofocus routine in SGPro would just hang at the initial focuser move. No timeout, no focuser move, nothing. Upon inspection of the log files I could see this exception:

[8/11/2014 10:41:49 PM] [DEBUG] [Camera Thread] ASCOM Focuser: Error in Move(abs) : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80020009): Focuser is currently moving)

   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)

   at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)

   at SequenceGenerator.SafeFocuser.Move(Int32 val)

   at au.Move(Int32 absolutePosition)

Seems as if SGPro thinks that the focuser is still moving from a previous command. Upon further analysis, I found out that this only happens when I use temperature compensation. In this case, SGPro moves the focuser to compensate for a temperature change and then immediately stars the autofocus routine. And the first move of it gets this exception and then hangs.
I also saw the same issue when I try to cancel an autofocus routine. SGPro just moved the focuser to the next position and then tries to move it back to its original position. And the second move gets this exception ... and leaves the focuser WAY out of focus. I sent an email to the SequenceGenerator forum asking for help or if Jared and Ken could fix this.

For temperature compensation I noticed that I can workaround this by setting a short delay between each image. SGPro applies the temperature compensation BEFORE the delay and starts the autofocus routine AFTER the delay.

So, I can at least work around both issues...