In a previous post about plate solve, I reported an issue where SGP attempted to change the filter to clear but it never completed nor timed out which then caused some plate solve recovery issues.
This report seems to be similar but occurred during a sequence while changing to the clear filter. The UI symptoms where that the filter reported "Moving.." but after a couple of minutes it had not happened nor had an error been reported. I then tried to abort the sequence but apparently SGP could not complete the abort because of the filter. After disconnecting and unplugging the filter and then reconnecting. It was not possible to change the filter manually in SGP but when the sequence was restarted it was able to set the filter. The relevant part of the log appears to be this:
[6/4/2016 10:42:42 PM] [DEBUG] [Sequence Thread] Setting filter: Clear...
[6/4/2016 10:42:42 PM] [DEBUG] [Sequence Thread] Moving filter wheel, isMoving, check 1...
[6/4/2016 10:42:42 PM] [DEBUG] [Sequence Thread] Moving filter wheel, isMoving, check 1 is complete...
[6/4/2016 10:43:58 PM] [DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model...
[6/4/2016 10:43:58 PM] [DEBUG] [MF Update Thread] Performing serialize...
[6/4/2016 10:45:03 PM] [DEBUG] [Main Thread] User requested sequence abort...
This shows the start of the filter change up to the abort request. While this was happening the light was lit on the filter controller which suggest it might have been stuck, however, I was expecting SGP to return a timeout error or something similar. Interestingly, the remaining filter changes in the sequence had no problems. There may be an issue with the filter but SGP needs better error handling/reporting. I have access to the filter communication protocol so I will do some testing and/or write my own ASCOM driver. Any insights you can gather from the log could help me with the testing.
The full log file is here: https://www.dropbox.com/s/2l4fvgtckapi39c/sg_logfile_20160604210757.txt?dl=0