Ran into two problems tonight with 3.1.0.411. During an automated auto focus run, I received notification that the AF run had failed:
However, my Optec Gemini focuser has a max travel of over 115,000 steps so not at end of focus travel.
When opening the Target Settings dialog box (previously existing sequence), the Start / End times get reset to the current time. I did not notice this and when I clicked OK, the end of the currently running sub terminated the run.
Dropbox link to log:
Charlie
Ya, sorry, this was a last minute change to update a library… It had some not-so-great side effects… it is fixed and I will release shortly.
This does not appear to be from SGPro itself, but rather a complete loss of communication with the focuser. Unsure why. Maybe cold weather, power fluctuation. I doubt it’s repeatable unless you are having a hardware issue.
ASCOM Focuser: Error in IsMoving wrapper. : Object reference not set to an instance of an object.
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32 aWrapperTypes, MessageData& msgData)
at ASCOM.DeviceInterface.IFocuserV2.get_IsMoving()
at sq.get_IsMoving()
at sk.b6(Boolean A_0)
Ken:
I did a second run using 3.1.0.411 with an idea of getting more info on the auto focus failure I had the previous night. I ran a couple of auto focus runs manually at start-up, which were successful, but once again, shortly after actually starting the run, I was notified of an auto focus failure. Being ready, I immediately switched to the Optec focuser control software (Gemini Commander) which I always run simultaneously with SGPro. It did not show an error and I was able to move the focuser with no problem. I disconnected Gemini Commander and reconnected successfully and was again able to move the focuser.
Additionally, the USB hub being used by the focuser is also used by the imaging camera, the guide camera, the rotator and the mount and none of those devices reported any problems.
So, this does not prove it was not hardware since there can be intermittent hardware issues but it does cast doubt on it being a hardware issue. At any rate, here is another link to the matching log file.
I am going to revert back to an earlier release to see if the problem persists. I had not seen this issue with earlier beta releases.
Charlie
So something still appears to be going nuts with your focuser not doing what it is told…
The reason for this failure is not the same as the last… this one failed because SGPro asked it to move while temperature compensation was on. I thought I had maybe introduce a bug with that last change, but I went over your logs many times and come to the same conclusion each time: SGPro asks the focuser to turn temp comp off, then later, when AF does run, it is either back on or was never turned off. Would need focuser logs to know.
Yet, at 18:45, the focuser still has temp comp on.
[12/15/19 18:45:27.691][DEBUG] [Camera Thread] ASCOM Focuser: Error in Move(abs) : Moving is not allowed when temperature compensation is enabled
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
at ASCOM.DeviceInterface.IFocuserV2.Move(Int32 Position)
at sq.Move(Int32 val)
at sk.ip(Int32 A_0)
Is there any chance it was turned back on external to SGPro?
Sorry – my fault. I should have specified the time of the failure in question. The error you referenced was caused by me accidentally enabling TC, as you suggested.
I was notified (by email to text msg) of the auto focus failure during the actual imaging run at 19:11 so the issue would have been just prior to that time. I see two successful images in the folder with the last image time stamped at 19:09. So the failure point occurred prior to the third image of the run. SGPro was probably auto focusing due to temperature drop. The auto focus run that was performed as part of “target start” (about 18:45) was successful.
The Optec Gemini focuser is a combo focuser / rotator that is controlled by an Optec hub that connects to a USB hub. So, the USB hub could be fine but something is happening in the Optec hub. I will run some more tests with that in mind.
Charlie
Oh, OK, let me take a look at that time period.
OK, I did find the issue there (at 19:11)… Will be fixed in 3.1.0.415 (will try to release tonight).
As a note, this issue is not related to the original issue reported.
Thanks! I will try 3.1.0.415 tonight.
Charlie
I was able to install and test 3.1.0.415 last night and I am happy to report that I was able to get a 3+ hour imaging run with multiple auto focus procedures without any errors. However, I am still seeing some issues with temperature compensation management.
I have my Optec Gemini focuser configured to auto enable TC at power on so I opened the Gemini software so I could monitor the status of TC while using SGPro.
When I started up SGPro, TC was immediately disabled. I manually re-enabled it.
When I clicked the button to connect to the focuser, TC was immediately disabled. I manually re-enabled it.
I then ran the auto focus routine manually (from docking module) to perform an initial focus of the camera. The auto focus dialog box came up and then just stalled waiting for the focuser to move. I noticed TC had not been disabled. I waited about 60 seconds and then clicked the Cancel button in the auto focus window. I manually disabled TC and ran the auto focus routine manually again and it was successful. I manually re-enabled TC.
At this point, I was ready to run the imaging sequence, so I clicked “Run Sequence” and TC was immediately disabled. I manually re-enabled it.
At this point the sequence ran for 3+ hours with no auto focus issues. This would have included auto focus on temperature change; on filter change; and on meridian flip.
Charlie
I have no explanation for this… I can’t conjure in my wildest dreams how SGPro could possibly change behavior or state of a device it is not connected to…
This one makes more sense, but I have double checked that SGPro is not turning TC off here. I have verified this with the focuser simulator.
This is because your focuser reported that it was no longer connected so SGPro did not try.
You absolutely dont want to do this. Once the sequence starts (nothing to do with Auto Focus), let SGPro manage the state.
So… something very weird is going on… I’m afraid the only path forward is to reproduce these things with focuser logs on. I have no other ideas… It sure seems like the focuser is acting intermittently odd.
Ken:
Thanks for the feed back. I agree this is some unusual behavior. I will do some more testing to see if I can duplicate what I observed. The Gemini focuser software does not show any way to enable a focuser log – are you referring to an ASCOM log?
Charlie
That would work… if the driver has a more detailed log, that is ideal, but a standard ASCOM “DriverAccess” log would also be sufficient.
