Actually, that’s a very good suggestion.
From Open PHD2 Forum, "POTH acts as a middle-man and gate-keeper, making sure the various apps are communicating with the mount in an organized way and not interfering with each other."
So … If Jared’s suggestion to change the frequency in Slave settings doesn’t work, I’ll try the POTH route next. Although I’m optimistic about the frequency.
Now I just need some skies.
Thanks,
Mark
Hi Jared et al,
This has been a bit of a long thread, and I apologize if I’ve frustrated the group with my responses to their questions. I genuinely appreciate everyone’s help, and meant nothing else.
The setting of the value “10” in “Update Frequency” (in Slave Settings) did the trick. The dome slewed with the scope to the new target and remained there. Problem fixed.
Could you comment further on why a “0” (i.e. default) setting caused this behavior, while a value of “10” eliminated it?
Thanks again,
Mark
It’s likely a race condition between the slew completing and the piece keeping the dome and scope synced. A slew command to the scope will slew the dome and scope and also block the thread doing the synchronization. However since the synchronization thread is going through as fast as possible it attempts to sync the dome to the scope immediately after the slew completes.
Now I’m not entirely sure why it would cause the dome to move to the previous position. Maybe the scope’s position hasn’t updated yet? I’m not entirely sure about that part.
Thanks,
Jared
Hi Group,
Need to dust off this thread from late January,early February of this year. The issue at the time was:
a) Connect all equipment within SGPro.
b) Point the scope at a focus star with the handset. Dome would follow to where scope was pointing.
c) Start Sequence. This usually involved a delayed start.
d) Scope would then slew to Sequence target. Dome would follow and align with target.
e) Dome would then slew back to previous location (focus star). Scope would remain on target.
f) Dome would then return to Sequence target, and match up (again) with scope.
The “Center Here” plate solve process would fail due to the imaging camera seeing only the inside of the dome rather than the night sky. Looking at dates, this was probably with SGPro v2.4.0.2672 or 2681. The fix was to assign a 10s value to the “Control Panel\Other\Slave Settings\Update Frequency”.
Starting recently, this problem has returned. Not 100% sure without checking, but I believe this started again with v2.4.2.4.
The DropBox files show some of the behavior from last night. The SGPro logfile and Lesvedome logfile provide the timeline. Most of the times quoted below are from the Lesvedome log.
a) Around 9:02 I connected all equipment to SGPro
b) At 9:04:23 I manually slewed scope to Arcturus (west) for focusing. Dome followed (Az 182.8).
c) At 9:25:00 delayed start Sequence began. Scope slewed to target IC5146 (northeast). Dome followed (Az 52.6).
d) At 9:25:42 Dome slewed away from IC5146 and returned to Arturus (previous) location (Az 264.7). Scope remained on target.
e) At 9:26:16 Dome began return to target IC5146.
Thanks,
Mark
Exactly what components are used to connect to the scope and dome?
From a look at the SGP log SGP is connected directly to the Lesve dome driver.
The telescope driver is POTH and this must be connected to a real telescope driver. What telescope driver?
Is POTH also connected to the Lesve dome driver? Something is causing the dome to follow the mount for manual slews.
9:25:42 is when SGP reports the telescope slew has finished as well as the time that the unwanted dome slew starts. If the dome slave process is using the target position for the slew to move to where the dome needs to be when the slew has stopped then this will be when the dome slaving process will resume using the actual telescope position. If whatever is doing this has not updated it’s telescope position then this could be where the bad dome move command is coming from.
What’s needed is to find the source of all the dome move commands.
Exactly how are ALL the components involved in this connected? We know that SGP and PHD2 are applications and that the telescope is connected through POTH. Is POTH also connected to the dome? Is PHD2 connected to the telescope and/or the dome? Through POTH maybe?
If POTH is not involved in controlling the dome can it be eliminated and the telescope controlled from SGP directly without involving POTH? It would be worth trying this even if it means that PHD2 can’t be used.
With a bit of luck this could be replicated in the day, ideally using simulators. That would help lot in finding out what is happening.
Chris
Hi Chris,
thanks for the push in the right direction.
I was able to image two different targets last night, IC5146 and NGC6781, for the full night. At the start the scope and dome slewed from the focus star to IC5146, and all stayed put and tracked properly. At the completion of IC5146, the scope and dome slewed to NGC6781, and again behaved itself.
While not 100% sure, I’m pretty confident the fix works. I should be able to do more testing tonight with a clear sky.
I had begun using POTH for the 12"LX200 in March. Bruce at the PHD2 Open forum recommended to include the Aux Mount feature (using the Meade LX200 driver) in the PHD2 equipment connect. This required POTH so both SGPro and PHD2 could recognize the Meade scope.
Chris, in my rooting around, I found that the old LesveDome driver was called out in the POTH Setup. I suspect there was a conflict between this old LesveDome (in POTH) and the new LesveDomeNet driver in the SGPro equipment. I changed the driver in POTH to LesveDomeNet and the system settled down.
Last night was a bit shaky for other reasons, so I’m hoping to get in a clean session tonight to prove fully the setup. I’ll report back either way.
Thanks,
Mark
This issue just won’t go away. There were two events from the other night that are similar, but slightly different.
The first had the scope slew to target at the start of the sequence, but the dome did not move for several seconds (about 30s).
The second occurred mid sequence during a manual re-focus operation. Here the dome cycled between the focus star and the target. That is after the scope returned to the target, the dome moved back to the focus position, and then after a pause slewed to the target.
The DropBox link includes the Sequence and logs from SGPro, PHD2 and Lesvedome. For those that are up to reading, I’ve included a detailed summary of the key time lines. My profile reflects the current equipment and softwares.
Trying to keep this note brief I do have a couple of thoughts and observations:
- The Observatory Settings Update Frequency now comes with 60s default. I have been using 10s. Might this be relevant and is this worth changing.
- I noticed that the “Slew complete…” statement (sg log) might fall anywhere in among the other lines. The timing makes me think that this reports that the scope has “settled”. Should doing manual things (i.e. frame and focus for re-focus) be avoided until the settle duration is completed?
Many thanks for your thoughts.
Mark
Dropbox - File Deleted
Unfortunately we don’t have logging around the areas where the obs is getting told to slew based on the dome slew. I’ll add some additional logging there and see if we can track down the issue. I’m guessing that the slew based on the telescope slew and the slew based on the timer are overlapping and causing issues.
Additional logging will be in the next beta.
Thanks,
Jared
Thanks Jared,
I appreciate you looking into this. My workaround, as long as I’m using my manual focuser, is to select a focus star close to the same azimuth as the target. Then nutty dome excursions don’t cause the session to abort. Unfortunately, multiple targets (of any distance) have to be avoided.
I’ll be very interested in what further logging data bring.
Mark
I’ve just had some similar issues when connected to a scopedome via sgp. Everything tracks fine until plstesolve then the dome rotates between solves approx 30 degrees so an image is taken of the dome inside.
I tried connecting via the scopedome driver and had no issues with wandering.
I’m on the current beta version and this hasn’t happened before.
Let me know if you need anything else?
Gordon
I should also add this causes sgp to hang on plstesolve and eventually needs closed in task manager.
Looks like gridlock with dome issues!
Here’s my followup from last night. I was using the latest SGPro (v16) with lots of logging for dome behavior.
I paused the sequence about an hour into the run and manually slewed scope (with dome) to a focus star. After focusing, I returned all to the target (using GotoTarget). This is where I would have used the CenterNow button to refine the target position. However, after following the scope back to the target, the dome quickly went back to the focus star position. After (close to) 30s, the dome returned to the target, I used CenterNow, then restarted PHD2 and unpaused the sequence. I did not do another pause and focus routine, and there were no problems after that.
I still think there is some connection between this mis-behavior and the scope settle time. My settle time is 30s, and I see the errant dome excursions as occurring at just about that period.
Anyway, here’s the Dropbox with the relevant info.
Thanks,
Mark
Just a follow-up on my previous post. I’ve been using v2.5.0.17 for a bit, and have not seen a repeat of the described behavior. Good job!
If you guys can find a minute, can you comment on what was done to fix/mitigate the issue?
Thanks,
Mark
There was an error in the hour angle calculation that was resolved. It would only happen during slews and not normal slave moves.
Jared
Thanks Jared.
Mark