SLAVING - stops/sleeps with new dome firmware

Hi yo… There was a major update to NexDome shutter/rotator software and since updating I’m finding that “SLAVING” (stops or sleeps?) on occation. Seems to happen in test when I do a lot of manual slewing via NSEW slew buttons. I’m now testing just normal tracking rate slaving. I asked the firmware author and he said nothing in their code handles that… and that it is a software (SGP) issue. Any ideas?

Here is what happens. I’m slewing around and slaving stops. I simply manually bump the <- or -> manual rotate buttons in SGP control panel and it moves as directed, then after the move it immediately re aligns the slit with the scope. (re slaves). Almost as if it went to sleep.

(SLAVE scope is checked)

On a side note. The new firmware (author says the shutter will open and dome will rotate at the same time). SGP doesn’t allow this? (not a big problem but thought I’d ask).

So in operation, I tell it to open the shutter. (this is about 6 minutes wait). During that time I point the scope at the target and (the dome can/should rotate to be in line with target while the shutter is opening). But rotation WAITS until shutter is fully open. (closed). The firmware and driver author (ascom driver) said this too - it’s a SGP issue.

Thought I’d share. ideas?

SGP should be able to open the shutter and slew the dome just fine. Just make sure that the option to only open/close the shutter at park is disabled. it’s also possible that something changed here. I’ll double check it.

As for the other things we’d need logs. Although it does seem suspect that things were working fine, firware was updated and then things stopped working:


I dont have “At home to open/close” checked.
I’m currently imaging the sun and it’s tracking ok with the scope (dome slit).
however - it does drop out at times and a simple “nudge” of the manual control wakes it up?

I just got the new firmware that is allowing me to finally use the rotator and shutter controls. (works!)
I’d not been able to use the shutter until now. So it’s been about 4 months. During that time, I got 3.1
and just wondered if that could be a issue.

I’ll keep a watch on it. (testing). it seems to drop out during manual slews. (pushing NSEW) buttons quickly.

Firmware author (a friend) said firmware can’t affect these issues. And that to slave - the software needs to look at both devices (rotator and mount) and slave one to the other.

where do you logs save? I’ll grab it up next time it happens.

Links to the logs can be found in the Help menu.

More info can be found here:


I’m testing it with POTH now (no SGP) so far, not drop outs or errors. Once I finish, I’ll go back to SGP control and will capture the log when it happens.

ooops poth also drops. I’ll talk top my friend who’d redoing drivers about it.

I’m actually writing the dome firmware and driver and I’m trying to figure out why Ron is having this problem. It may be something unique to his system as myself and another user aren’t experiencing the issue but we may also have just been lucky.

The driver has no control over slaving, doesn’t know what slaving is even. It just responds to SlewToAzimuth() commands and returns the azimuth value through the Azimuth property so it’s not immediately apparent to me how the driver could be turning off slaving when slaving is entirely within the scope of a controlling application.

My driver does not have a handy control form so it’s not a matter of non SGP originated movement commands taking the dome position out of sync with what SGP thinks should be happening. Well, unless someone opens the settings form and homes or calibrates while tracking - which would not be a driver or SGP problem. Obviously I have no control over the scope so if the handset or driver control form is issuing commands outside of SGP and that’s messing up slaving then there’s nothing I could do about that either.

The ASCOM conform tool is happy with the driver although I found out that I’d accidentally been throwing a methodnotimplemented exception on the Altitude property instead of a propertynotimplemented exception.

However, the driver may be lacking a status response or something that the application is expecting and not getting so my question is, what conditions would cause SGP to turn off slaving by itself?

I honestly can’t help until I get logs. Preferably ASCOM logs from the dome and a corresponding log from SGP.


EASY TO SEE IN HERE - I then nudge the dome with the <- button 0.1 step and it wakes up.

[05/01/18 10:43:18.124][DEBUG] [Dome Thread] Dome: Caught exception while updating status: CheckDotNetExceptions ASCOM.PDome.Dome Azimuth Get System.IO.IOException: The semaphore timeout period has expired.

sg_logfile_20180501104113.txt (26.7 KB)

That looks like it’s coming from the ASCOM driver and just being raised by SGP. Also you may want to update to the latest version of SGP. While I doubt it will address your issue, there were some changes made to the dome slaving where we were querying the dome too quickly.


Ah, I was about to mention we discovered what was probably the cause of his issues.

I was seeing 18 polls for Azimuth() per second on my machine which translates to roughly 1,032 characters per second being sent from the Ardiuno. That basically overloaded the controller and led to all sorts of problems.

Coincidentally I didn’t like the way I was using the Dome properties and Methods to initiate communications so I switched from using the template’s blocking serial calls to asyncronous ones and have the driver polling the controller once per second (roughly 24-40 characters per second) then storing that in the driver. The client can now poll the driver as frequently as the computer can handle and the controller will still see only one poll per second.

I’ll pass on the update information to my users.

I saw that too - I wondered why my log was ever .20th of a second and yours
was much longer. I changed my dome settings from 2 degree error to 4
(hoping that would do it) but maybe it’s something else. I will read your
comments, I didnt have time and something I scanned over about port
numbers. I think you’re right because it use to work (other than sleeping
during slaving). And I did some rewiring and the ports changed. I’ll move
the dome down under 10. (I just got up). I’ll try and catch up and test
thank you!!!

This is always better :smiley: I’m glad our bug helped you to make the driver more robust! Honestly I wish more ASCOM drivers were structured in a way to better protect the hardware. In drivers I’ve written I’ve done internal caching so that the client can’t beat up the hardware too much. Similar idea to the cached polling but I would just fetch if the cache time had expired. Same benefit either way. I haven’t looked at the device templates in a while. This could probably be added into the default ASCOM developer templates which most people use to write drivers to help enforce good behaviors. Really all you need is a semaphore lock around the command in/out to the hardware to keep things atomic and some caching for those values.

Also there is still a bug with the current version and now it’s polling too slow. Essentially SGP is only polling at the slaving frequency which is generally once every 60 seconds. This has been addressed, but not released. You can get around it by lowering the slaving frequency.


Is 60 seconds really too slow? With a 2 degree allowable error the dome moves about once every 10 minutes. The OCD side of me wants way more updates but is it really required?

There are 2 things at play here:

  1. How often we update the UI in SGP to show the dome position
  2. How often the dome position is updated with respect to the scope (slaving)

For 1 this is now 1 second. For 2 you can decide what that update amount is in the slaving settings for the observatory. It has “mostly” always been this way except for the last few versions where this was broke. Currently ( these are accidentally linked so everything is updating at the frequency that you have set in #2.


Oh and the switch was just coincidence. I was finished the rotator code when we figured out the polling frequency was probably the problem. So I just knocked together the shutter code and pushed it out there this morning hoping it works. No shutter or even a a second arduino to simulate one so the users are the alpha testers at the moment.

SO FAR ALL GOOD pmeloy (Pat). Been slaved for about 1.5 hours and still watching it. So far so good.
Now if we can just get SGP to go UNSAFE without a sequence running! If cloudy/rain - CLOSE THE DAMN DOOR! 50% of the time the door is open and SGP is running but not in a sequence. It’s ridiculous to have this trigger happen ONLY IN A SEQUENCE.

That’ll be in the shutter firmware if you have the RG11 hooked up to the rotator. I already have it refusing to open if the rain sensor pin is low. If it’s a different device with it’s own driver then there’s nothing I can do.

yes It’s different. IT’s the solo cloud watcher. If it becomes cloudy or rain (sprinklers come on) it will go unsafe. SGP will light up RED “warning”.

but so far it appears it will only do “unsafe” operation if a sequence is running!?!? When 50% of the time one is not. At least for my usage.