I’ve not run into that as a chronic problem. FWIW, I’m now using a CEM120 non encoder mount. A few weeks back I took the plunge and cleaned up all of the cables. So nothing hangs off the scope.
This meant using the in and out USB connections. For the most part everything works well. And when it does, this is a very nice setup. However, at times I have exercised the guider or the camera or the focuser multiple times prior to starting a sequence for whatever reason. I’ve learned from experience that at those times I really need to reboot the computer and scope.
thanks for chipping in , I am 99.9% sure this is not a hardware problem
I have spent a long time with various manufacture’s of my hardware with drivers and firmware to make it as SGP
friendly as possible .
I have a suspicion that its a timing issue with my camera driver/firmware/hardware as it takes quite a few seconds for my camera to be ready for a exposure and do not know if SGP is waiting long enough
But of course I could be wrong
Ok I think I have found the problem . not sure how to resolve it but here we go
My focuser connects ok and sgp thinks all ok
when I go to autofocus , the focuser answers sometimes very slowly or it seems not at all , If the focuser is slow
or does not move sgp hangs . if the focuser moves in time happy days
I do not know why my focuser is erratically slow ( hardware or driver or sgp not sending commands ? )
so perhaps sgp should at least say focuser error rather than crash , are we able to see if focuser commands are being sent ?
We always try and do this where possible. Sometimes, due to the very low level of the software we interact with (driver level), sometimes we transfer flow control to the driver and we never get it back… thus we have no ability to trap the error (at least in that thread). The only way to combat this is to create another parallel running thread that serves as a “watchdog”. For obvious reasons, we cannot create one of these for every type of equipment failure (we do certainly have watchdog threads for lots of things in SGPro). Anyhow… that’s probably more info than you were looking for…
For this particular issue, we call in to the focuser driver to have it temporarily shut down its internal temperature compensation logic. It seems like if your focuser is moving then bad things happen… maybe? Either way, we never return from this call and we cannot continue.
It would be helpful to grab the focuser logs that correspond to the SGPro logs so we can see both sides.
Almost anything in tech is possible, but in this case, I will say that doing this is unlikely. SGPro was not architected with inherent distrust of the drivers it uses. Because of this, when some things die in SGPro, they cannot be resurrected without restart. In order to do what you are asking, we would need to rewrite major aspects of SGPro that account for self-healing and never trusting a driver to do what it says it will do. For the most part, these situations are resolved through careful, polite discussion with the driver author and don’t require special software to cope with external bugs. SGPro is very good about reporting issues with drivers as long as that driver actually returns control. If it doesn’t we are stuck.
We have discussed rearchitecting the way in which we communicate with gear and, at some point, we would like to abstract it away from the main sequence flow, but these things require time.
This can mean a lot of different things. I would need to see logs to understand what you are doing when you are manually focusing. There is certainly a path in some manual focus routines where SGPro will still disable internal temperature compensation.