I’ve noticed the following issue on several occasions now - while the dome is tracking a target all is fine until the dome eventually passes by the “Home” magnets, at that point it stops tracking and just stays at Home. How do I get it to keep tracking the target and ignore the “Home” magnet? Needless to say this will ruin a nights imaging, as I will be taking pictures of the inside of the dome - guiding goes all to hell too
I am selecting “NexDome” under “Observatory” in the Equipment list. Should I use something different?
I’ve spoken with someone who has written the firmware code for the Adruino and he has confirmed that it is not something to do with the firmware. He thinks it may be an ASCOM or SGP issue.
How can I determine what is causing this issue? How can I eliminate SGP as the possible source of the issue?
We’d need the ASCOM logs as well as the SGP logs and an idea about what time this happens in the logs. I don’t believe SGP should be doing anything just based on hitting a home position. You could always try moving the dome in azimuth past its home position using another application and seeing what happens. This would point to the ASCOM driver or something downstream being the problem.
The only ASCOM log I could find was for the SX FW (filter wheel). Not even sure if there is an ASCOM log for the NexDome. Is there one just for SGP - if so, any idea where it is on the HD?
Is there an option in the dome’s ASCOM setup dialog that turns the log on/off? The most likely location is in the ASCOM folder in the user documents folder.
This is an issue that I am experiencing too and have reported it several times. SGPro doesn’t slave the dome when the slave box is ticked. Moving the dome one degree from within SGPro has the effect of ‘connecting’ the slaving and the dome moves to the correct azimuth. All works fine and the dome tracks the mount correctly. However, it then stops when it gets to the dome Home point, which I have set at 180°. Again, a small dome move reconnects the slaving. I end up having to monitor an imaging session and ‘nudging’ the dome when it stops moving at the Home point. I thought that this was a bug that was being worked on and am keenly awaiting the next beta release. This thread makes me realise that it is very unlikely to be fixed in 3.0.0.4. That is very irritating…
Should have added - I have spoken with the Pulsar Dome ASCOM developer, who cannot see anything wrong with his code. If I connect to the dome and mount with POTH, everything works perfectly, however I lose the shut down actions from SGPro - not ideal. The slaving all worked perfectly in earlier versions of SGPro, which very much points the finger at an SGPro issue.
The only person who can give chapter and verse about the dome driver log is the driver developer. Hopefully it’s in the driver documentation.
The default place for ASCOM logs is in the My Documents\ASCOM\Logs folder but this could have been changed. Enabling logging is up to the driver author. I put a check box in the driver setup dialog.
Just a thought - I believe that POTH limits what is passed through as a hub to standardized ASCOM commands. When I developed my own ASCOM driver for a ROR, I needed a hub that also passed through very specific commands from my own Obsy control application (these are allowed by ASCOM but of course are not standardized). POTH would not do that, so I switched to the OPTEC ASCOM server. This uniquely is completely transparent to all commands as far as I can tell.
It is possible that this may help if POTH was blocking shut down actions?
I’m glad (sorta) to hear I’m not the only one who is having a problem. My problem is exactly as you wrote - I need to nudge the dome even with the “Slave to Telescope” box checked before the dome will start tracking. The tracking stops everytime the magnet align during tracking and I need to “nudge” the dome again to have it start tracking again.
I also have the developer of the firmware and ASCOM driver looking into it but nothing so far. I will look into the Optecinc download trial.
I have experienced the same problem when last imaging with SGP Ver.3 Beta. I am not at home - so cannot be more helpful with logs etc. at this time. (I did not see this problem before Ver 3). I use a Pulsar Dome with Rigel Dome Controller.
The problem is the same with different Dome drivers, which suggests that the issue is with SGP, don’t you think? Even more so when it all worked properly in the past and the thing that has changed most is SGP?
Thank you Buzz for the alternative ideas, but I really want SGP to work properly again, especially if I am about to have to upgrade to version 3. It is hard to pay for an upgrade when the product has bugs. Yet the product is superb, so I really don’t want to go elsewhere!
Ken, Jared, developers, please tell us that there is a fix on its way…!
Unfortunately, it is often not that simple - these are complex systems, developed by different companies, often to slightly different assumptions. I have had a few circumstances where I was positive it is one issue, and it turned out to be something coincidental. The other thought - is there an ASCOM dome simulator? They are normally robust implementations of the ASCOM interface and can sometimes be used to track down an issue.
Experiment One - Open SGP, connect mount and dome, unpark mount, slew mount to object in the East, slave dome. Result - Dome azimuth remains at 180º. Then ‘nudge’ dome 1º East from within SGP. Result - Dome moves 1º East and then syncs to mount at 131.20º.
Experiment Two - Open Pulsar dome control software, move dome to 165º, close Pulsar dome control software. Open SGP, connect mount and dome, unpark mount, slew mount to object in the East, slave dome. Result - Dome immediately slaves and rotates to azimuth of 132.90º.
Experiment Three - Open SGP, connect mount and dome simulator, unpark mount, slew mount to object in the East, slave dome. Result - simulated dome moves to azimuth of 134.61º.
I noticed that the simulated dome started at an azimuth of 225º for Experiment Three. I unslaved the simulated dome and clicked Home to put it in its home position of 0.00º. I then clicked ‘slave’ and the simulated dome remained at 0.00º. I nudged it 1º East and it moved the 1º and then moved to sync with the mount at 135.73º.
So, there really does appear to be something odd happening with communication between SGP and a dome when the dome is in or very near its home position.
Logs for the session are available here, includes SGP, Pulsar ASCOM and Pulsar Dome logs, I couldn’t find any logs for the dome simulator:
I hope that this gives the developers something to work with and I very much look forward to hearing opinions and progress.
When the dome is at or close to the home position the AtHome property returns true. It can do this at any time when the dome is close to the home position, even if this is as a result of a normal SlewToAzimuth command.
I guess that SGP is checking AtHome and not moving if it returns true, The small slew is enough to cause AtHome to be false. SGP should probably not check this in normal operation.
Chris, you master detective! That makes total sense and I hope it is something that can be sorted out. I first noticed this issue in the late 2. releases and it persists in the 3. betas. I can’t wait for it to be corrected. Dare I say it, I will then have a working system. Oh no, I’ve gone and cursed it all now…!
I am the developer of the NexDome firmware and ascom driver. I can say defintively that any time the dome magnet is in the vicinity of the home sensor, the driver will return AtHome true. This triggers many other things under the covers as well. As an example, this is a stepper driven system and we track dome heading based on motor steps. If the system has any slippage then step counts will be off by a small amount, and when we pass the magnet thru the home sensor, heading is corrected to remove slippage in the system because we have a physical return that gives us an exact heading.
If SGP is not moving the dome when it returns AtHome = true as it tracks thru the sensor, then that would fully explain many of the recent problem reports I’ve been getting.
Again - sorry I cannot supply logs etc. as I am not at home. I can say that I have noticed the fact that the dome requires a nudge before it will track the mount initially at the start of the night. My dome park position is 5° away from the dome home (magnet) position…so I do not think that it is an “At Home” true/false related issue.(What you are saying makes perfect sense and makes an obvious answer…but I am not yet convinced that is it exactly. Hopefully I can test next week).
