I am in the process of integrating an AAG CloudWatcher (CW) with SGP and a Pulsar Dome. CW is working perfectly, but SGP has twice tonight terminated the sequence because of an ‘Unsafe’ status. I have checked the log file of CW and it has not reported an ‘Unsafe’ moment at all tonight.
Any ideas as to why SGP is incorrectly thinking it is unsafe and how I can fix this frustrating hiccup? I have had to disconnect the CW.
Hi Gav. I’m on my hols so recalling this rather than checking a setting in my obs PC but the triggering of the Unsafe mode may be happening because the driver loses connection with the CW, bringing the CW into an unknown state which triggers an Unsafe mode.
I had this occurring the first few times I was using my CW because I played around with the frequency duration of the read times (is it set to a default of 120 secs or some similar value?). I seem to recall this setting is in the dialogue box which pops open when you click on the connect symbol in the sequence window.
Check that it is reading 120s.
HTH
Barry
Thanks Barry. I will check that setting.
I ran a test yesterday evening and after about an hour or so SGP shut down the obsy. I checked what the heck was going on, only to discover that it really had clouded over!!
Have a great holiday.
Gav.
Oh dear… It happened again.
I checked that value in the settings for the ASCOM safety device in SGP and it was set to 120s. I started a sequence and all seemed to be fine, but about 10 minutes into the sub it shut down. No unsafe status messages were reported by the CW, so I have no idea where SGP is getting this unsafe report from. I set it all running again and about twenty minutes into the first sub it shut down, but this time it was due to cloud and an unsafe report from CW. So it can work properly.
SGP admin - do you have any bright ideas please?!
What Safety Device are you using? The Boltwood Monitor? Also we’ll need logs to investigate this.
Please see here:
Thanks,
Jared
Jared,
Thank you for your reply. Here is as much information as I can supply:
I am using an AAG CloudWatcher from Lunatico Astronomia. It appears to be working perfectly. The problem occurred at 22:03:21 yesterday evening (07-08-16). SGP started ‘Shutting down due to Unsafe Conditions’ though as far as I can tell this was a false ‘Unsafe’ event. There was a second shut down due to an ‘Unsafe’ event at 22:40:39, but this one was real, correctly generated by cloud cover.
I have put three files online for you to download from here:
They are:
WOStar71.sgf - the SGP settings file
sg_logfile_20160807214303.txt - the full SGP log file
CloudWatcher.csv - the CloudWatcher log file
I look forward to hearing your assessment of all of this info.
How does SGP receive Unsafe events - where can they come from? The first Unsafe event was definitely not generated by the CloudWatcher device, so I hope that you can shed light on which bit of the system could be generating these false Unsafe events.
Many thanks,
Gav.
I am delighted to report that I managed five hours of imaging last night without a single erroneous ‘Unsafe’ event. The CloudWatcher and SGP behaved perfectly. The only change that I have made is to tick the ‘Trace’ option in the settings screen for the safety monitor in SGP. Quite why that should make everything behave I have no idea, but the important thing is that it did behave. Fingers crossed for the next session!
The Trace option that you mention is actually in the CloudWatcher ASCOM driver, all SGP is doing is starting the driver setup dialog.
In some way it’s a shame that it works like this because it means that the erroneous unsafe events will be difficult to see.
It looks as if the unsafe messages were coming from the driver, even though they don’t appear in the driver csv file. Maybe the time taken to write to the trace log is enough to stop something going wrong.
A possibility is that SGP will interpret any error in communicating with the safety device as an unsafe condition. Jared will know if that’s the case.
Yes, any “hiccup” in communication will be treated as an unsafe condition. There is no buffering on these. IE we don’t want until we get 2-3 “rounds” of unsafe to close things up. If we get an unsafe condition for any reason, even just for a split second, things get closed down. We don’t know what the trigger is, it could be raining and you probably want it shut down pretty fast if so.
Thanks,
Jared
Chris & Jared, thank you for your replies. I think that it is probably the USB to Serial converter via a USB hub that is creating the hiccups - that is a guess, but the Prolific driver seems to be a bit flakey, so I will point the finger at that. Anyway, the great thing is that ticking ‘Trace’ appears to have made it work and if it works again next time and the time after that and forever more, I will be a happy imager!
If it doesn’t work next time or in the future, I will be back to ask for your further assistance no doubt!
That’s my experience with them. It would be better if they straight forwardly didn’t work. Get a FTDI based adaptor.
Yup, on my list of things to get!
Hello again,
Unfortunately it happened again last night… SGP shutdown everything due to an Unsafe event. I have changed the USB to Serial cable to an FTDI based one for the CloudWatcher. I have put the ASCOM log file here:
You can see that at 01:44:57.232 something odd happens, it tries to read the file twice, then at 01:45:07.235 there is an ‘Exception reading file!’. Then sure enough SGP shutdown at 01:45:07. SGP log file is here:
So, something definitely went slightly awry. If you have any ideas on why, they would be greatfully received. Even better, ideas on how to stop it happening again would most definitely be welcomed!
Thank you in advance.
Gav.
Hello Jared & Chris (or anyone out there who might be able to help with this one),
I had another spurious shut down due to Unsafe event last night. Checking through the logs it follows this event in the ASCOM.AAGCW log:
00:34:08.420 Exception reading file! The process cannot access the file ‘C:\Users\Gavin\Desktop\AAG Files\AAG_CCDAP4.dat’ because it is being used by another process.
I checked progress of imaging before going to sleep and noticed that this had happened so restarted things. The run made it through to the end at 03:43. However, there was another ‘Exception reading file!’ event an hour or so after the end of the run, so it is happening quite regularly.
So, the question is, how do I stop these Exceptions? What is it that has the problem reading the file and why? I presume that it is the ASCOM driver that is trying to read the .dat file to report through to SGP on the Safe/Unsafe status. It can’t read the file, so SGP takes that as an ‘Unsafe’ event and kicks into the Shutdown routine. That’s quite fair enough, but how can I stop this problem happening. What is the other process that is using the file?
The only change that I have made is to ‘upgrade’ the USB to Serial cable connected to the FTDI chipset cable, but that is meant to be better!
Please help!
Thank you,
Gav.
You need to talk to the driver manufacturers, cloudwatcher I think. It looks as if there could be a clash between some process that is writing to the file and the driver that is trying to read it. They seems to do a retry but maybe need to do more.
Chris R
Hi Chris,
Thanks for the reply. I guess that it is a clash between the CloudWatcher app writing to the .dat file at exactly the moment when the ASCOM driver tries to access the .dat file - do you agree?
I am hoping that you are Chris Rowland the developer of the ASCOM driver for the AAG CloudWatcher - is that the case? If so, how complex is it to make the driver try again before throwing an exception?!
Thanks,
Gav.
Gav,
Sorry to hear you are still having intermittent issues (the worst sort). Not sure whether you purchased the AAG via Lunatico Astronomia? If so, it may well be worth contacting Jaime and/or posting on the Yahoo Group, if you haven’t done so already.
Barry
Post the question on the Cloudwatcher Yahoo Group, I have found them very helpful in the past
Hi Barry,
Yes, a solid pain! I thought I’d got rid of the problem too. I did indeed purchase the AAG from Lunatico Astronomia and I sent them an email explaining the situation today. Their auto-reply informed me that they are away for the whole of August! Luckily tomorrow is the 1st September, so hopefully they will be able to offer some help with the problem soon.
Still loving the Obsy though!
Gav.
Thanks Martin - I’m trying to do that now.