I don’t know if this is a bug or just an unfortunately but expected behavior with my Rigel nStep focus motor, but when I pressed “Zero” in focus control I thought it would reset the current value to “0” but instead it started rolling in the focuser. My fault for not knowing what the button would do, but I knew the absolute value of the focuser was way off and that it would crash if allowed to “go to Zero”, so I tried to stop it. The Stop button did nothing and I could not send any counter order that might have reversed the focuser on it’s way to self destruction. I had to unplug the motor to stop it. It sure would have been nice if “Stop” actually stopped the motor!
All of this functionality is tested as working in 2.5 (inclusing the stop button). This means e sent a stop message to your focuser… after that it’s out of out hands. To troubleshoot effectively, we would need both the SGPro and ASCOM focuser logs. Without them we can only give assumptions.
Hi Ken, I had the same issue that I couldn’t stop movement of the focuser, but I believe it’s two problems together.
Rigel nStep focuser controller don’t like power spikes if it runs from the same battery with other equipment. Sometimes it looses the connection to port and when you try run the application it throws you an error.
Last night, I tried to connect to focuser from SGP and usually it runs the GCUSB application as normal. This time GCUSB throwed an error that it couldn’t find the focuser on it’s port, but SGP focuser connection button became green and showed that it is connected successfully. I decided to ignore the application, as SGP made the connection and tried to move the focuser by pressing Focus For Lum.
Focuser started to move and all seemed fine, only I noticed that it had past the Lum filter position steps and continued to move out wards. I noted that something wrong and hit the stop focuser button and it didn’t help, focuser continued to move out.
I had to pull the power and usb cable from the controller to stop it and then reconnect all back, reset the position and it worked fine again.
I believe SGP had sent the stop command to focuser, but it never received it because of lost connection to port, but how it was able to make it move in a first place and show the green button that it is connected? Something definitely wrong here.
Unfortunately, GCUSB don’t keep any logs so it’s only the SGP log that I have here: https://www.dropbox.com/s/ve3z0gna2aw90g6/sg_logfile_20160212181115.txt?dl=0
Looking at the code, there may actually be an issue with halt that is specific to the Rigel nStep. I don’t have one to test with, but I think it should be able to call halt now without issue (not sure though).