Hello Hy,

I've studied the code and logic, and had a look at the iOptron RS-232 syntax. I ran another schedule last night the same as before, and encountered the same stuck state. Here's what I've found:

- The iOptron error I mentioned above did not recur. The debug output was indicating that the mount responses to get_status and get_position were mixed up. That is, the command string ":GLS#" for status was returning the response for the command string ":GEP#" and visa versa. That looks like a mount firmware problem, or perhaps something wrong in a FIFO buffer somewhere. At any rate, the error did not repeat, and so I'll ignore it for now.

- What I did see is that, when the scheduler went to sleep, it parked the mount, emitting a "Mount parked" info string into the log. It then went into a perpetual "Checking shutdown state" loop. Looking at the code, the next state would have been SHUTDOWN_PARK_DOME. I presume it got stuck there as the message "Checking shutdown state" repeated all night.

I have a dome, but that is on another system. This particular system does not have a dome. But to my surprise, the schedule I am running has "Park Dome" checked. I generate my .esl files in python using templates. I bet I imported a template .esl file that was generated on my other system that has a dome.

So my hypothesis is that the scheduler was trying to park a dome that does not exist. By checking "Park Dome" in the GUI, the scheduler state machine would see that parkDomeCheck->isChecked() is True. But inside parkDomeCheck, domeInterface.isNull() also returns True since there is no dome. But the immediate return from domeInterface.isNull() does not set the shutdownState to SHUTDOWN_SCRIPT, which would be the next step. Instead, it stays in SHUTDOWN_PARK_DOME, causing the loop to repeat.

Tonight I will have a chance to run this again with "Park Dome" unchecked in the schedule. Weather and full moon might wash out tonight's run, so it might be a couple days.

Read More...