Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

SGP & AAG CloudWatcher

PhotoGav

By PhotoGav
in Discussions - Software

Recommended Posts

PhotoGav

PhotoGav

Posted
Posted

I am trying to integrate an AAG CloudWatcher with SGP and a Pulsar Dome. The Cloud Watcher (CW) works perfectly, but SGP has shut down twice this evening due to 'Unsafe' conditions. Conditions could not be safer - it's a stunning night out there, haven't seen it so clear and dark for quite some time. That just makes it all the more frustrating.

Anyway, SGP shut down at 12:15pm, but there is no record in the CW log file to say that it was 'Unsafe'. Quite the opposite, the CW is accurately reporting perfect 'Safe' conditions.

Does anybody have any ideas why this would be happening?

My only theory is that I believe SGP decides that it is 'Unsafe' if it can't communicate with the Safety device. How can I see if that is the case and more importantly how do I stop it happening? At the moment I have disconnected the CW from SGP, though it is still running and I am keeping an eye on it.

 

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted
6 hours ago, sloz1664 said:

The answers you are looking for are posted on the SGP forum site. You need to download Chris Rowland's Ascom driver from the Ascom site + the exec file "patch" from the AAG site.

 

steve

Thanks Steve - I had all of that installed and working already. However, the good news is that last night it all co-operated perfectly and I had five hours of trouble free imaging (except for a dome control unit freeze, but that's a different matter!). The only thing I had changed was to tick the 'Trace' option in the SGP settings dialog for the safety device. No idea why this should make it work, but it worked. So, if it continues to work next time too, I will be a happy chappy!

Link to comment
Share on other sites
daz

daz

Posted
Posted

Gav

The SGP log file should tell you...

Assume you have tweaked the parameters on the CW device to reflect when dark / clear is safe?

There is an option (tick box?) somewhere - not at home so can't check exactly where - to tell SGP that an unknown condition is Unsafe. Might be in the CW device settings....

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted
3 hours ago, daz said:

Gav

The SGP log file should tell you...

Assume you have tweaked the parameters on the CW device to reflect when dark / clear is safe?

There is an option (tick box?) somewhere - not at home so can't check exactly where - to tell SGP that an unknown condition is Unsafe. Might be in the CW device settings....

Thanks Daz. The SGP log file just says something like 'Shutting down due to Unsafe conditions', nothing more than that. I'm not sure where that unknown = unsafe check box is, I've seen it on the Solo settings screens, but not on the normal CW settings. It's probably safer like this anyway. The main thing is that the CW works correctly and reports the right conditions. I have seen SGP shut down because CW has reported unsafe conditions - so it really does work. There were just some wierd false unsafe reports getting through. The trace option seems to have solved that, but I do need to run some further sessions to see if that is really the case. Hopefully I will get a bit of a chance tonight and over the next few nights.

Link to comment
Share on other sites
steppenwolf

steppenwolf

Posted
Posted

I only had a mild flirtation with SGPro but I seem to recall that it doesn't have much in the way of 'fine tuning' the output from the AAG CW so that it is either 'safe' or 'not safe' so 'cloudy' is seen as being as bad as 'overcast' and 'light' is as bad as 'very light' so you may find that you need to look more closely at the AAG CW unit parameters. I'm pleased that you have an apparent fix but can't immediately see how enabling trace could affect the outcome of an alarm.

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted
Just now, steppenwolf said:

I only had a mild flirtation with SGPro but I seem to recall that it doesn't have much in the way of 'fine tuning' the output from the AAG CW so that it is either 'safe' or 'not safe' so 'cloudy' is seen as being as bad as 'overcast' and 'light' is as bad as 'very light' so you may find that you need to look more closely at the AAG CW unit parameters. I'm pleased that you have an apparent fix but can;t immediately see how enabling trace could affect the outcome of an alarm.

Quite, no idea why it makes it work. I'll probably find after further testing that it doesn't work. It might be due to things happening a little slower as the log file write takes long enough to make the ASCOM driver catch up with itself and not report a fake unsafe. The CloudWatcher unit works perfectly and I have the Unsafe conditions set usefully correctly and that all works fine. I think the Unsafe reports getting into SGP were something to do with USB to Serial flakiness and the ASCOM driver and SGP being very sensitive and cautious.....

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted

That's a damn pain. Please do let me know if you work out what the issue is.

My dome control unit froze twice in the early part of last night's session. I got fed up with it, thought to hell with it and left it running until 3:30am this morning, not caring if it fell over as the Moon was too bright really anyway. I woke up to find that it behaved perfectly.... Why did it work that time and not others?!?

Link to comment
Share on other sites
martin_h

martin_h

Posted
Posted

I've left a message on the AAG yahoo group. At first I thought it might be USB lag but remembered I'm using the solo which runs over the network so it can't be that, it might be the unknown=unsafe setting, will have to wait for another clear night to play with it. Strange that it's worked fine for months, hey ho!

Link to comment
Share on other sites
martin_h

martin_h

Posted
Posted

Reply....

Hi Martin

Seems as if they are being caused by network errors, that is sgpro (or the safety driver) not being able to access the data from the solo, else the unsafe period would be triggered

Best regards

Jaime

 All very well but that doesnt explain yours as you are running via USB?

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted

Interesting Martin - that makes some sense. I hope that it provides you with a clue to a fix though. As you say, it doesn't explain my direct USB connection issues. Having said that, I have successfully run several complete sessions now with no erroneous 'Unsafe' shut downs, so I am almost confident that the CloudWatcher and SGP are now good friends.

SGP and the dome control unit on the other hand have had a bit of a falling out. Though I have been running SGP with the mount pointing at Vega and the dome slaved to it, with no problems for over two hours this afternoon. This is suggesting that it is when something else is running in a proper imaging session that things go wrong with the control unit, or at least communication with the control unit. Mmmm....

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted

Looking through the trace file for the dome control unit, it does get hammered once it is set to slave to the mount... I have no idea where the frequency is set though?!

I'm guessing that once other things are starting to communicate, e.g. PHD2, then it all falls over, perhaps?

Computers, huh, can't live with 'em, can't live without 'em!

 

Link to comment
Share on other sites
  • 1 year later...
RonKramer

RonKramer

Posted
Posted

I know this is a 2 year old topic.  But I just got my cloudwatcher/solo.   While SGP does show a green button or a red button as safe and unsafe... it will not close my NexDome shutter unless a sequence is running.  50% of the time I'm not running a sequence.  I might just be grabbing a 30 min frame and focus image to pull one quick sub. 

SGP guys give long drawn out excuses why they can't add a close string when the button turns red.  So I'm on my own.

I can close my dome at the dos command line (or .bat file) by sending    echo C# > com3

I'm running the AAG CW & Solo safety driver setup.  It asks for select file  (I enter it) I click "check file" it says it's fine and currently "SAFE" now.

So all good - reading safe/unsafe.  And I have a command I can sent to open or close the shutter of the dome.

Problem is - the driver doesn't ask for a string to send it unsafe.  It would be so easy to add? 

Ideas how I can get it to close is unsafe at any time?


 

Link to comment
Share on other sites
PhotoGav

PhotoGav

Posted
  • Author
Posted

Ron,

Im sure that there is a place in the AAG Windows App (though I don’t know about the Solo side of it as I just run the AAG app) to set a script file that is run when an Unsafe event occurs. I can’t help with the contents of the script, but I’m sure there’s a clever coding type on here that has the answer. 

Good luck and I look forward to hearing that you have it up and running very soon. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.