since 2009 I’ve had a permanently mounted 12"LX200 Classic Meade in a domed observatory. The communication between dome and scope is by way of LesveDome driver. I believe that Pierre de Ponthiere’s software (LesveDome) communicates with ASCOM (or POTH?) to make everything work.
Late last year I acquired SGPro for its full automation capabilities. I noticed the problem then, but was dealing with other issues, and am just now bringing it up.
Once the LesveDome (and now LesveDomeNet) drivers are loaded in the observatory computer, they become a “choice” in SGPro for controlling the dome. I have used both versions of LesveDome and all of the SGPro v2.3 and v2.4 since that time. I have also used an older Dell 32bit Vista O.S. and a new Dell 64bit Windows 8.1 system. All do the same thing.
In a session, SGPro will instruct the scope to move to the second target upon completion of the first - followed by the dome. After a “scope settling time”, the image and guide cameras begin to do a plate solve to refine position at the second target. Unfortunately, once the dome arrives at the second target, it then reverses and returns to the previous target position. After a pause it then returns to the second target. This means that the imaging and guide cameras are imaging the inside of the dome rather than the sky.
A workaround is to extend the scope settling time (say 60 to 90 seconds) to allow the dome to wander off and then come back before imaging begins. I’ll try this at the next clear night.
This behavior occurs only when using SGPro. It does not happen when manually using only the Lesvedome/ASCOM controls.
I’ve attached the log from the other night. The dome issue occurred after leaving the target IC1871 and moving to NGC2683. The time was 11:11:08pm, Jan.28th when the slew to NGC2683 occurred.
Are there any thoughts on what might be the cause of this problem, and a possible solution?
This makes it sounds like you are slaving the dome to the scope in LesveDome. Is this the case? If so you should NOT also be slaving in SGP.
Only one thing should be handing the slaving. Whether that’s SGP or LesveDome is up to you. If you want LesveDome to handle the slaving then you should not connect the dome in SGP. If you want SGP to handle the slaving then you should not connect the scope in LesveDome.
I don’t think the Lesve Dome supports slaving so there can’t be a clash between that and the SGP slaving.
I suggest that the Dome.CanSlave and Dome.Slaved properties are read in SGP and the results are at least logged. This will remove all doubt about if there is a clash between the dome and SGP doing the slaving. There’s no need to do it more than once so it could be put in the dome connect code.
Sorry if this sounds like a dumb issue. I’m just trying to find a solution, or satisfy myself that a workaround is the thing to do.
Jared,
I do not double slave the dome. I only slave dome to scope in SGPro. With Pierre’s new NET version of Lesvedome, you have to dig deep even to find where to connect the two. But if allowable, I will try the other way around (i.e. slave with LesveDome and not with SGPro), and see if the behavior changes.
If you have time, and I know you’re busy, would you look at my SGPro log to see if anything looks out of whack at that 11:11:08 (or just prior to) time?
It will be worth turning the LesveDome Trace on. This will generate a log file that should give details of exactly what commands the dome driver is getting.
Post that log as well as a SGP log covering the same time, both showing the error, it should be possible to see exactly what’s going on.
I’ve DrobBoxed both the SGPro and LesveDome logs in the attachment. I’ve posted to Pierre to see if there are other Lesvedome logs available, and also asked him his opinion of what’s in the Lesvedome log.
In the FWIW catagory, I attempted to use the Lesvedome/ASCOM controls to connect and slave the dome and scope together - and this is independent of SGPro. This does work as long as SGPro is not included in the equation. It’s the way I did it before SGPro.
SGPro requires that you connect to the scope regardless of anything else. Otherwise it would not be able to move to target.
And the problem is that the scope has already been connected (and slaved) within ASCOM. At this point, no more connections are allowed. Either a warning note comes up, or SGPro crashes with MS saying it will figure out what happened.
I get the impression that we only know part of the story here.
What is this “LesveDome/ASCOM control”.
What does “already been connected (and slaved) within ASCOM” mean?
If there is some other application controlling the dome as well as SGP then it’s no surprise that it isn’t working properly. SGP and this other application will both be sending commands to the dome driver. This is exactly the problem that Jared described in his first post.
Thanks for your comments. I have clarified this in previous comments, but I know that info tends to get lost when posts are going back and forth.
Lesvedome is a system created by Pierre Ponthiere to provide connection between scope and dome. It includes designs for some DYI hardware (dome rotation counter) and the software to make it operate. The software utilizes ASCOM for communication with the scope and Pierre’s code for communication with the dome. This is probably poorly described, sorry.
Operation is simple. Start the scope, power up the computer and dome electronics. Open the Lesvedome software and click to connect to dome and scope. Then one more click for “slave”. At that point, wherever the scope goes, so does the dome. Call this the “independent method”. Prior to SGPro, this is how I operated when doing imaging.
If you have the Lesvedome software/driver loaded on your computer like me, then it will show up as an SGPro equipment selection in Observatory. I select Lesvedome for the observatory and Meade Classic for the scope. I then go to “other” in Control Panel and hit slave to tie the scope and dome together. I’d call this the “dependent method” since it operates within SGPro.
Now to be clear… there is no way for me to operate both the independent method and the dependent method at the same time. Once I’m connected to scope and dome through one method, I cannot reconnect using the other method. So I’m not confusing the dome by providing two different inputs – at least I do not see how I could be.
The Lesvedome log file I sent with my last post shows that the dome is getting instructions to move to another target, then return to the first target, an then move again to the second. I’ve spoken to Pierre and he sees the same thing. His comment is the dome is getting instructions for the moves and is carrying them out.
This is an interesting problem. Too bad it’s so frustrating. Unless ya’ll have other insights, I would suggest we move on. I’ll put an adequate scope settling value in SGPro to compensate for the dome behavior. Something will likely come up later that will explain this.
ASCOM Dome Control Panel:
This is the LesveDomeNet user interface. A click to “Connect” will connect the LesveDomeNet Dome to the Meade Classic and Autostar I scope.
ASCOM Meade Driver Setup:
Hitting “Setup” from the above window yields the “Dome and Telescope Setup. Hitting “Select Scope” yields the “ASCOM Telescope Chooser”, which shows Meade Classic and Autostar I. Hitting “Properties” yields the” ASCOM Meade Driver Setup".
LesveDomeNet Select Dome Setup:
Hitting “Setup” from the “Dome Control Panel” yields the “Dome and Telescope Setup. Hitting “Select Dome” yields the “ASCOM Dome Chooser”, which shows LesveDomeNet Dome. Hitting “Properties” yields the” LesveDomeNet Dome Setup".
Sequence Generator Pro:
This window shows the selection of "Meade Classic and Autostar I in “Telescope”, and “LesveDomeNet Dome” in observatory.
SGPro Observatory Settings:
Opening “Control Panel” and hitting “Other” and “Slave Settings” brings up the "Observatory Settings.
This looks as if it’s exactly what I have been trying to tell you. Two dome sync applications clashing. ASCOM Dome Control Panel is designed to slave the dome to the scope.
ASCOM Dome Control Panel and SGP are both connected to the dome and telescope and BOTH are slaving the dome and so both are sending move commands to the dome.
Don’t connect using ASCOM Dome. If for some reason you need this connected to start disconnect and close it once SGP is connected.
Try it with ONLY SGP connected to the scope and dome. Closing or preferably not starting the ASCOM Dome control panel in the first place will be the best way to be sure.
At the very least uncheck “Slave Dome to Scope” in ASCOM Dome Control Panel.
Mark,
Can you set the “Update Frequency” in SGP to something like 10 seconds. I think this is causing a race condition in SGP. I’ll validate this evening and if that’s the case add some protection around this. Being 0 means that SGP will essentially hammer your dome and scope fairly frequently to sync things.
Also you should not need to use the “ASCOM Dome Control” at all. I think this is what is confusing. Maybe you’re just illustrating how you do things when not using SGP?
Was this working in 2.3? There were some changes around dome control and polling in 2.4.
I’m away from the house right now. Where would I find the Update Frequency?
I’ll repeat emphatically - I only use SGPro. I do not use ASCOM.
The odd behavior of the dome breaking away, then returning to the scope position was noticeable in 2.3, and when I first began using SGPro. It has been persistent. Since it only showed up when I had two targets per session, i simply limited my nights to a single target.
It’ll be interesting to see if the frequency change affects this behavior.
We aren’t looking over your shoulder, we only know what you tell us.
Your images show ASCOM Dome control being set up.
It shows connections to the Meade scope and the Lesve Dome drivers.
It has Slave Dome to Scope checked.
If these aren’t involved why are you showing them?
Not meant to confuse or torment. I was showing how I use to do it (ASCOM), and how I now do it (SGPro).
I recognize that the more I elaborate to clarify, the more confusion I cause.
Still appreciate your good effort on helping me out.
Thi smay be of no help, however… I use a Pulsar dome with Shelak controller, I attach this along with my mount together via POTH then select Poth to connect in SGP.