SGPro and Pulsar motorised Dome slaving an AZEQ6 mount

[PhotoGav]

OK, a little update... I have just been playing in the Observatory and:

First of all I installed the latest beta of SGP, v3.0.0.3, released today, but the dome slaving problems persist. There was nothing in the release notes to suggest I should have expected any different. So, the dome doesn't slave when I click 'slave' in SGP and the dome stops tracking just short of 180º dome azimuth.

I then used POTH to connect mount and dome and set up parameters in POTH. I connected everything up in SGP, unparked the mount, slewed to a point in the sky, went over to POTH and clicked 'slave to dome'... hey presto, the dome responded almost immediately and slaved accurately to the mount. Next I let the mount track away for a while, approaching the crucial 180º dome azimuth (around which it had got stuck earlier), it tracked past that point with no issues whatsoever.

So, the finger is pointing ever more at SGP and something awry going on in there. All in all, I think a useful experiment, so thank you Alec and Steve.

The only problem with using POTH and SGP is that when the mount parks, the dome slaves to that point, i.e. North, rather than going to its own park position, which I have set to South. There doesn't seem to be anything in POTH to control this.

I look forward to hearing how you get on, Alec.

[alcol620]

Thanks Gav, I've had the dome slaving against the mount since mid-afternoon. This is only using POTH with no connections to SGPro. Just about to connect up SGPro and see what happens next. Fingers crossed.

[alcol620]

With the dome slaving against the mount via POTH I have just opened SGPro and done the following. Swistched on the camera and cooling, turned on the focuser and filter wheel, which responds to instruction. Opened PHD with the same setting I had before (mount "on camera" and Aux Mount "EQMOD HEQ5/6 ASCOM") turned on telescope which is set to POTH. It all seems to work without crashing.

The scope responds to nudges from within SGPro and the dome slaves to the new position and continues to slave as the scope turns in sidereal.

Not sure I can try anything else until the stars appear to test guiding and plate solving. Can anything else be tried without stars???

[alcol620]

2 minutes ago, alcol620 said:

With the dome slaving against the mount via POTH I have just opened SGPro and done the following. Swistched on the camera and cooling, turned on the focuser and filter wheel, which responds to instruction. Opened PHD with the same setting I had before (mount "on camera" and Aux Mount "EQMOD HEQ5/6 ASCOM") turned on telescope which is set to POTH. It all seems to work without crashing.

The scope responds to nudges from within SGPro and the dome slaves to the new position and continues to slave as the scope turns in sidereal.

Not sure I can try anything else until the stars appear to test guiding and plate solving. Can anything else be tried without stars???

Just one thing I forgot to mention. I currently don't have the observatory connected/switched on as part of the SGPro Sequence, I assume this is not required as it is being controlled via POTH? Is that correct or should I click it and connect it and named "POTH hub"?

[alcol620]

Further update - for anyone interested.

Started C du C and set to POTH telescope. Now able to click on an object in CduC and hit slew and the mount goes to the object and the dome follows it and then continues to slave. Also using telescope nudge in the SGPro Control Panel, moves the scope and its position in CduC.

Clicking "Park Scope" in Poth sent the scope to its Park position (North) and the dome slaves to the same position. Unlike Gav, this is where my dome's Park and Home positions are, so no problems on this score.

All 100% up to here, the proof of the pudding will be if it holds up over a longer time frame and when all the other features and data are flying about.

 

One question: Any one know why the mount is so much noisier when I am using the SGPro Control Panel telescope nudge than when it is being moved around by other methods??

[Starlight 1]

10 minutes ago, alcol620 said:

for anyone interested

I have been looking very good posts . the plus come by one post on SGP I was looking for only a week or so ago  and do not have anything to do with domes.

[steppenwolf]

Well, if nothing else, POTH has probably confirmed where the problem lies. In my own automated dome, I can uncouple the slaving as a specific command, 'park' the mount and then 'home' the dome but then, I'm not using SG Pro. Is there a way of 'uncoupling' the slaving in SG Pro?

[alcol620]

54 minutes ago, steppenwolf said:

Well, if nothing else, POTH has probably confirmed where the problem lies. In my own automated dome, I can uncouple the slaving as a specific command, 'park' the mount and then 'home' the dome but then, I'm not using SG Pro. Is there a way of 'uncoupling' the slaving in SG Pro?

Certainly looks like it.

Hopefully, when the stars next come out and the full set up can be run the dome will slave with no issues. Thanks for your help and encouragement Steve.

[PhotoGav]

Looks like you’ve had a busy and successful session Alec! You ask several questions:

2 hours ago, alcol620 said:

Can anything else be tried without stars???

Not really - I think you’ve given it a pretty complete test. The next step is to run everything for real and see how long it keeps going for. Hopefully we won’t have to wait too long.

2 hours ago, alcol620 said:

I currently don't have the observatory connected/switched on as part of the SGPro Sequence, I assume this is not required as it is being controlled via POTH? Is that correct or should I click it and connect it and named "POTH hub"?

I don’t know. I set the observatory connection to POTH in SGP, but don’t slave the dome in SGP. I guess this populates the observatory panel with info in SGP and allows control of the dome from within SGP.

2 hours ago, alcol620 said:

One question: Any one know why the mount is so much noisier when I am using the SGPro Control Panel telescope nudge than when it is being moved around by other methods??

Not a clue! That makes no sense at all!

Here’s to hoping we have a clear night soon for some real world testing.

[PhotoGav]

1 hour ago, steppenwolf said:

In my own automated dome, I can uncouple the slaving as a specific command, 'park' the mount and then 'home' the dome but then, I'm not using SG Pro. Is there a way of 'uncoupling' the slaving in SG Pro?

Good question Steve. There is the ability to run scripts from certain points, but I don’t know how to... yet!

Still hoping that the SGP developers sort it all out as it is something that all worked properly a few versions ago.

[alcol620]

Might last action before I turned everything off was to also connect the Observatory up within SGPro (via POTH but without slaving being on within SGPro. It didn't seem to make any difference to anything. Like you say Gav it just means that SGPro can see the observatory via POTH in addition to POTH separately slaving the observatory?

Lets hope for clear skies and a successful outcome.

Not sure how to approach SGPro developers to see if something can be done with the compatibility problems that are going on. I get the impression they done have much time to sort out specific queries like this??? Matthew is this something, as developer of the software, that you can take up?

[PhotoGav]

The developers of SGP (Ken & Jared) are normally very responsive and will apply themselves to these kind of issues. However, at the moment they seem to be deep in to getting version 3 debugged and launched (perhaps so that the new finance model can come into action - I expect a higher cost price, though in mitigation, the various wizards, e.g. mosaic, are included in the price, no longer add-ons as they are currently). So, I think the best approach is to keep posting on the SGP forum about the dome slave issues (and there are various other people with similar issues, so quite a bit of feedback for them to look at). When they have time they will get round to sorting it out, I'm sure. As with all of this astrophotography mullarkey, patience is the key!

At least the system sort of works and with the POTH work-around, it is a bit more stable. Far more difficult to solve is this incessant cloud....!

[alcol620]

I think I will hold back until I have the evidence that POTH solves our problem of slaving drop outs and then use this as a lever to get SGPro to do the same?

[sloz1664]

I have never had an issue with running my dome with MaximDL, which is annoying as I want to use SGPro to drive ALL my equipment. There has to be an issue somewhere with Dome sync and the SGPro software as I am driving my Dome with the Levesdomenet software, which is diffrent to your software.

Steve

[KyleStoke]

I have to say that i run my dome through SGPro and poth and it has never lost sync.

Maybe it is to do with how it is slaved, i do connect to the dome in SGP but slave it in poth.

These are my setting in SGP, pretty much nothing

[alcol620]

2 minutes ago, KyleStoke said:

I have to say that i run my dome through SGPro and poth and it has never lost sync.

Maybe it is to do with how it is slaved, i do connect to the dome in SGP but slave it in poth.

These are my setting in SGP, pretty much nothing

Thanks Kyle

Pretty much what Gav and I will be adopting, so when the stars shine again, hopefully we too will have a fully slaving dome, with no drop outs!! The answer seems to be "keep SGPro well away from anything to do with slaving the mount".

Regards

Alec

[PhotoGav]

Interesting, thank you Kyle. What do you do about closing and parking the dome at the end of a sequence?

[KyleStoke]

1 minute ago, PhotoGav said:

Interesting, thank you Kyle. What do you do about closing and parking the dome at the end of a sequence?

Closing unfortunately that is manual for me. 

Parking, basically at the end of the sequence its set to park the mount through SGP the dome will try to follow the scope to its park position but a lot slower. It ends up parking wherever it happens to be pointing when the scope makes it to home and parks breaking the link in poth.

When I start up again and the dome is re-slaved it will go to the scope home position or if im quick wherever Ive told the scope to slew to.

There probably is a setting to tell it to park at a specific place at the end of a session but seen as it makes no odds to me where it is pointing ive never looked into it.

[PhotoGav]

17 minutes ago, KyleStoke said:

Closing unfortunately that is manual for me. 

Parking, basically at the end of the sequence its set to park the mount through SGP the dome will try to follow the scope to its park position but a lot slower. It ends up parking wherever it happens to be pointing when the scope makes it to home and parks breaking the link in poth.

When I start up again and the dome is re-slaved it will go to the scope home position or if im quick wherever Ive told the scope to slew to.

There probably is a setting to tell it to park at a specific place at the end of a session but seen as it makes no odds to me where it is pointing ive never looked into it.

OK, thank you for the info. It is possible to make SGP run scripts at the end of a sequence, but I don't know how that all works. I have a feeling it might be easier for the SGP lot to fix SGP than for me to make scripts!!

[KyleStoke]

1 minute ago, PhotoGav said:

OK, thank you for the info. It is possible to make SGP run scripts at the end of a sequence, but I don't know how that all works. I have a feeling it might be easier for the SGP lot to fix SGP than for me to make scripts!!

You are not wrong, I was just having a quick look and changed my mind, ill leave it as it is and not mess

[sloz1664]

As I have a dual set-up One imaging thro' MaximDL and one imaging thro' SGpro I'll have the sync running via MaximDL as it knows my park position on sequence end. I fully understand Ken & Jared's commitment to ver 3. I am hoping for a speedy conclusion once the V3 update is completed.

Steve

[alcol620]

Hi folks

Great news with a twist in the tail.

Ran the set up last night utilising POTH and keeping SGPro well away from slaving the dome. Result: it worked flawlessly from early evening until about 2.30 am today. Thanks for your inputs and encouragement to use POTH.

The sting in the tail was the end of the evening/morning. A Meridian flip was due around 2.30 am phone set to wake me up just before, got the time wrong by a few minutes and the flip was already happening. Teamviewer told me all the software had terminated as I heard a bit of a crash. On investigation, the laptop was found on the floor and had shut and closed down. The scope and dome had slewed and slaved. Tried to get the software running again but to no avail

Checked everything over in daylight this morning and found the terminal of the USB cable still in the laptop and the cable laying on the floor. The slewing mount/scope had caught a cable and pulled the laptop off the table onto the floor. Luckily no damage was done to the camera/focuser/filter wheel electronics.

Moral: check and double check that there is no chance of cables snagging as the gear does a meridian flip. Lucky let off for me I think.

Hopefully out again tonight after Guy Fawkes has retired for the night.

Thanks again for the feedback from you all

[PhotoGav]

Excellent and terrible! Relieved to hear that everything is back up and running. Good luck tonight.

 

[sloz1664]

Glad everything is OK and nothing untoward has happened. Although I am confident a Meridian Flip will work flawlessly with my set up. I still have to be there to watch it perform.

I'm imaging now. I also have SGpro well away from slaving the Dome. I have the Dome sync'd with MaximDL. No issues.

Steve

[alcol620]

Thanks guys.

I'm thinking of wrapping a piece of polythene or something like, around the mount, to make the passage of any cables slide easily over any of the protrusions. The altitude polar alignment handle on the AZ EQ6 mount is particularly vulnerable to snagging a cable!!