Hi Randy,
Just a couple of questions and/or comments:
1, Are you starting out with your scope close to focus? You need to be close to focus before using the spg Auto focus?
2. Not sure what kind of scope you have. I have an HD11 with the Rigel nSTEP & STEPPER Motor kit tied to the primary mirror focuser. My backlash is set to 1,500 steps and my steps is set to 250 with 9 points.
Not sure if this helps any.
Regards,
mahaffm
Hi Gene,
Thanks for getting on this. I agree the 1.2 seconds should allow for any mechanical ringing to settle down in that amount of time.
Where are you going to post the driver update? if the weather ever clears Iād like to give it a try as well.
Regards,
mahaffm
Hi mahaffm,
For testing purposes only, a fixed, not selectable delay.
Here is a link
http://www.astrogene1000.com/products/gcusb_nstep/GCUSB_nSTEP_v6.0.7_sgpdelay.zip
Download and extract to someplace
Copy the file inside over to
C:\Program Files (x86)\Common Files\ASCOM\Focuser>
Rename C:\Program Files (x86)\Common Files\ASCOM\Focuser\GCUSB_nSTEP.exe to GCUSB_nSTEP.6.0.7.exe
Rename GCUSB_nSTEP_v6.0.7_sgpdelay.zip to GCUSB_nSTEP.exe
With an admin CMD prompt
C:\Program Files (x86)\Common Files\ASCOM\Focuser>gcusb_nstep.exe /regserver
You will need to do the /regserver thing again if you copy the original back to GCUSB_nSTEP.exe
It should be somewhere between 2 and 3 seconds.
You can see the results in the Traffic Window with āIsMovingā check box ticked. Please remember, do not try and minimize the traffic window, it really does not like that! You can close the traffic window, just not minimize.
Let me know!
Gene
Thanks Gene. It will be the weekend before I get time to test the update, (Indoors only - Weatherman says rain/snow for the foreseeable future). Do I need to do anything with updating the Firmware? I do not have the latest firmware loaded, I do not have the one that allows for motor reversing.
Regards,
mahaffm
Hi mahaffm,
The new firmware is not required for the newer drivers. It only adds the reversing and nothing new since the 2015 version. The new driver will allow you to try and set the reversing phases but will be ignored by the firmware.
For the ASCOM side. an update based on more input from freestar8n after he gave it a test drive.
I added a user settable delay, albeit not brought out through the handbox but can be tweaked using ASCOM profile explorer.
In ASCOM profile explorer, after running the new version (linked below) first time to populate the profile, look for:
ProfileRoot->FocuserDrivers->GCUSB_nSTEP->SGPMove2Delay
Default value I set is same as yesterdays build, 210.
This is very roughly units of 10ās of milliseconds, so 210 should be 2.100 seconds (very roughly)
Here is a link for second spin, basically same install instructions as version yesterday.
http://www.astrogene1000.com/products/gcusb_nstep/GCUSB_nSTEP_v6.0.7_sgpdelay2.zip
Gene
Who can I upload an SGP error log file to? Finally got a relatively good curve on the first try tonight which held some what, then all of a sudden I start getting focuser error message. Rigel software still controlled the focuser when SGP would not but the HFR take one preview never changed when I had to resort to manual focus. Another rare clear night blown again.
Regards,
Randy
Thanks Gene for the new posting.
I had tried the original version with the delay of about 2.1s and it was improved but I guess I need a little more delay time - so your new version is welcome.
I installed the new version and was able to use the profile explorer to change that delay setting - so I should be able to test it all next clear night.
Thanks,
Frank
Hi Gene,
I have everything running as well, in doors. all seems to be running as designed. At first the SGP backlash comp didnāt seem like it wanted to work with the new test software but after restating everything all seems to be working now. Not sure when Iāll ever be able to get out for an actual run, all clouds for the foreseeable future.
I think what Ken/Jared did by adding in the focuser reverse direction feature and now Geneās ASCOM software update to include the delay feature, which should allow the primary mirror to settle, should go a long way helping the SGP autofocus process for folks using SCT primary mirror focusers.
Thanks,
mahaffm
Have lowered my backlash to 1400 and now 1200. I still have issues where SGP just runs wild with the focuser and finally gives me an out of range error message. After several reboots and reconnects it ran a curve, then on next autofocus it did the same thing, focuser out of range error. The ascom controller continues to move the focuser but just trying ascom manually for focus, the HFR preview no longer seems to update after the above out of range error.
Regards,
Randy
Hmm - well I have a result but itās not what I expected. Iām afraid it looks like I misinterpreted what was causing the trailed images during autofocus. Itās something I have seen with two separate cameras: SX and QHY - both of which are shutterless and fast. But oddly my ASI-1600MM does not show this issue - nor does my atik 383L+, which has a shutter.
So Geneās code seems fine and is exactly what I thought would fix the problem of a camera that was being exposed too quickly. But even with delays of 4 seconds there is almost no improvement that I could see. This made no sense to me until I realized that the problem may not be in the scope/mirror - but in the camera. My guess now is that the focuser is being moved prematurely, while the camera is still exposing. Has anyone seen something like this? It wouldnāt be specific to SCT and focusing with the primary - except that sctās will cause the stars to shift a bit - while a crayford would not. In other words - you wouldnāt notice if this was happening.
Is there possibly something odd about how SGP knows the exposure is over and the focuser can move? I am doing 2s autofocus exposures - and if the focuser moves during even the final 100ms of the exposure it would be bad.
I encourage others who have a problem getting sharp autofocus images to try the Rigel delay and see if it helps. Unfortunately it looks like the focuser may just need to wait a bit more for the exposure to end. At least thatās my theory.
When I replaced the QHY174 camera with the ASI-1600mm and did autofocus - the stars were perfect and the focus curve was also. Both are shutterless cameras and both used 2s exposures - with a Rigel delay of 4s or so after each focus move.
Frank
Why is a delay needed? To settle the focuser? Weād need SGP and the ASCOM logs from the focuser to be able to be able to correlate the two things together.
If anything SGP is very cautious with āImage Complete.ā We donāt consider an image to be done until it has been downloaded and (if a sequence image) saved to disk.
Thanks,
Jared
Itās hard for me to know exactly what is happening - but using two different cameras I get perfect images with one and consistently streaked stars in the other - during autofocus. And the one that streaks has no moving parts - while the one that works well has a fan. The one that streaks is also very light and rigidly attached.
The streaks are short and sometimes the stars are just elongated - but it only happens during autofocus runs. If I just sit there and take an image with sgp - the stars are fine.
Are you sure that with qhy5iii-174 the image was actually exposed as commanded? Maybe it is pulled from a buffer that is old. It may not be well synchronized with what sgp is telling it to do.
I donāt think the rigel has ascom logs - Iām not sure. Iāll see what I can find.
If other people have problems like these - please share your experience. This does seem weird.
Frank
Hi Jared,
[quote=āJared, post:32, topic:4544, full:trueā]
Why is a delay needed? To settle the focuser? [/quote]
I believe for those of us that are focusing with the primary mirror we need a small delay after the mirror focuser stops and before the autofocus image is kicked off to allow for the mechanical system to settle, I call it āRing-outā. It appears the way the autofocusing works is that as soon as the position is reached, the request to take the image is activated but the system has not settled down so those with shutter-less cameras see elongation or fat stars. Depending on the position of the scope there will be a various amounts of mechanical ringing thus longer for the system to settle down depending on the pointing position. For those that use cameras with shutters it is not that noticeable as there is a slight delay with the camera to allow the shutter to open. I use both and have noted this.
Iām working with Gene on his GCUSB_nSTEP ACSOM driver testing out a delay that will not tell SGP that the focusing move is complete until after the move and delay has expired. However, thereās seems to be a bug that after the second focusing position is reached, SGP is ignoring the delay. Itās as if SGP is ignoring the IsMoving and as soon as the position is reached on the position counter kicks off the image request.
It would be really great if SGP would put in a small delay between Autofocusing moves, maybe user input or a fixed amount, so the mechanical system can settle down a bit before the autofocus image is kicked off.
Thanks,
Mark
If you can provide the ASCOM logs and SGP logs for the same run we can check on that.
Thanks
Jared
I donāt believe the GCUSB_nSTEP ACSOM has a place for the log file, at least I could not find one. There is a ASCOM API traffic window but it is very limited.
below is the SGP log file
.sg_logfile_20170128111447.txt (44.4 KB)
Also, hereās what I sent Gene from the ASCOM traffic window
Hope this helps,
Regards,
Mark
Mark,
The timeouts in backlash routine are in the SGP log file provided
[1/28/2017 11:16:48 AM] [DEBUG] [Focuser Backlash Thread] Backlash thread failed to complete! Timeout!
The log does not match up with the positions in the Traffic window but as you have stated offline, this happens every time (your issue)
Gene
Iām not clear but it sounds like there are two issues - one is sgp not checking for āIsMovingā and the other is a timeout due to backlash compensation.
If SGP is not checking for IsMoving then that explains why the delay fix did not work. Have we confirmed that is the case?
The other issue is SGP timing out on a long backlash event. Is that a problem? I had seen that when I used the robofocus controller but it didnāt seem to impact the autofocus routine.
Well I still think SGP should provide the delay after focus - because there is no way for the focuser to provide that delay without ālying.ā Either it needs to say IsMoving when it isnāt moving, or it needs to give a false position when it is actually at the final target position - or both I guess.
Frank
I donāt want to speak for Gene but one thought he mentioned offline is the issue might be a racing issue. Maybe when IsMoving goes false SGP sees it right before the ASCOM delay routine kicks over, so it might appear SGP is ignoring the IsMoving where in fact it saw it first before the ASCOM delay kicked in so now the Image is being taken and the delay timer is running. this might also explain why Iām seeing the delay after the image is done, because the timer is still running not allowing the next move until it times out. so once the timer has expired it moves to the next position but again SGP sees the IsMoving = false before the ASCOM delay does and you have the image kicking off as soon as it reaches position and the ASCOM delay timer kicking in.
This seems to explain why the ASCOM delay is not helping.
And yes, I agree having a small delay to allow the system to settle before taking the image during autofocusing would be the best solution. But thatās up to Ken/Jared to decide if it makes sense to do so. I hope they consider it.
BTW = If you want to test it out, set the ASCOM delay to 1000, which is approximately 10 seconds, and youāll clearly see what is happening.
Regards,
Mark
Besides the ongoing curve issue, the focuser timeout has become even more of a problem. Not sure if this is the same issue discussed here. The log is Greek to me. I did not have AFS packs enabled, but maybe something in this log is of help. Wits end!
Regards,
Randy
sg_logfile_20170128181436.zip (151.9 KB)
SGP does check IsMoving. I think what is happening is that the backlash is timing out while waiting for the initial move to take place. There is a 60 second timeout in place which would get triggered on the move from the last focus point moving to the new āin focusā point. Currently reworking this now to behave a little better.
Thanks,
Jared
