I’ve been using the beta for a few weeks, I’ve noticed an interesting behaviour that I am not sure is a setup problem or perhaps a missing setting.
Sometimes it appears to try to plate solve before the mount has finished rotating - sometimes it does. I never noticed this before with DragScript and Sequences - so I am not sure if it was always there an I am just noticing or if perhaps I’ve done something wrong in my settings.
MaxDome + Paramount setup
Nothing is related to RoboTarget Paul, RoboTarget do not use the Dome.
Plate solving start when the goto is finished and the dome report movements are finished.
All the best
Leonardo
Thanks Leo, I have a situation where my setup keeps taking images of the inside of the dome after gotos during Robotarget.
It is using TSX, Maxdome ASCOM driver and Voyager.
Hi Paul,
like I said Dome is related to telescope goto and not to RoboTarget.
All the best
Leonardo
Understand and agree, but for the sake f completeness I am describing the whole setup that is exhibiting the symptom - i never noticed the problem when I wasn’t using Robotarget
Which log file can I send?
Hi Paul,
Are you still having issues? I use a paramount with a Exploradome/Foster Systems setup. I have not experienced this issue at all with the Voyager Beta. However I have seen this early on when I set up my system to use voyager several years ago and I was using the Sky X dome control. I had to introduce a delay in the dragscript because sometimes there was a delay from when the mount started to move and the dome reacted. Sometimes this delay was up to 30 sec.
I have seen issues with disconnects of the dome driver in the past so no movement of the dome. However it rarely happens. One thing you may want to check is if you see “moving” in the dome widget display when you do a GOTO. I know Voyager does not receive movement info if I am controlling the dome through the Sky X dome control but the ASCOM driver does pass this and show “moving” when only connected to the dome directly with Voyager via the domes ASCOM driver. I also have found it much more reliable when connecting to the dome to make sure I do it via the ASCOM Hub.
Cheers
Jon
I had this problem when using normal scripts from on the fly. With Leonardo’s help I believe I have fixed it by delaying querying the dome state until 10 secs after the start of the requested slew. It’s not that my dome is slow to respond, it normally responds in less than 2 secs but now the script does wait properly for a dome slew to complete.
There may be a slight bit of trickery required still since sometimes the dome is slewed to a position suitable to before the commanded mount slew, gets there and then has to do another slew to get to the final location.
So I make sure now at the start of the script to move the mount and dome to a known good azimuth each before starting tracking with slaved dome.
This is not a good solution how you intend it
Voyager always wait for the dome finish to moving before start a commands.
This means your dome driver report dome is not moving aka 2s is not enough for your driver to start the moving process … 10s can be the right amount of time if you dome for example is busy.
I’ll try with that.
I do notice ( from last night’s run for example) that on managed flip, the action of the flip causes the dome to got to around Az=0 where it stops before it then is told to go to the new telescope azimuth. Is this because the flip is split into two halves and there is a dome slave call at that point ? Or that I havent still configured this correctly 
?
No split absolutely. For configuration of your dome you must refer to your driver settings.
All the best
Leonardo