SGP incorrectly ending sequence because 'Unsafe' when it is actually 'Safe'

It sounded like file access early on in the thread. Then you confirmed it in the log.
Can Jamie tweak the CW code to rename the last read file as data-bak.txt (or what ever format it is) then write a new one. Each time renaming the previous one, before writing the new one? Then have SGP access the .bak file? Also if it’s checking at 120 seconds. Changing that to 240 would make the chance of file access being less frequent. Also what about changing the CW update/file write time?

I have a CW too and if it rains, I really don’t want a 4-5 minute delay. Things could be soaked in 60 seconds. Might be something to throw at Jamie via email or in the CW forum? I’m just setting mine up for safety and I’d first like to get it to close for clouds/unsafe… I just found it only does this DURING a sequence? I’m more often open not during a sequence than during. 50/50 at best.

Another option would be the READ of the file (that is being written) to do a error check for a open file and (on error) wait 10 seconds and try again. That would always get by the problem.

Hi Gav. Did you ever get your issue sorted? I have just read the whole thread as a result of Ron’s latest post.

I have occasionally had an issue early on into a run with SGP reporting an unsafe condition when CW reports all green. There are two issues I have. Number one: despite no changes in configuration, SGP is sometimes unable to read the .dat file. I have to go through the rigmarole of pointing SGP at the correct file, typing in passwords and such like. (I have asked Windows to remember the password, but sometimes it seems forgetful.)

The second issue is a disparity in time between CW and the local machine. My Solo seems to lose time occasionally. If it ends up 2 minutes or more out from the Windows machine SGP sees this as an error (understandably). I have spoke with Jaime about this, and he tells me that the Solo/CW should be updatng its time continusously, so that this shouldn’t happen. I did think I had cured this some time back when I uninstalled a piece of time-keeping software (the name of which I forget now). However, the issue does come back from time to time. To fix this one, I have to log on to the AAG config screen - this always shows the correct time - then I do set time and save settings, and all returns to normal a short while later.

It would be nice not to have these issues. I suspect they are more to do with Windows and networks tha nit is to do with CW or SGP…

I may take a look at that Yahoo group.

I may have experienced this myself a few weeks back, to the point where I turned off the safety monitoring in SGP. I did not have the energy at the time to look at it in more detail or try to solve (was dealing with too many other issues!). I’ll try to turn this back on and track it more closely next time out.

DaveNL

Yes, the problem of the false positive Unsafe condition causing an unnecessary obsy shut down in SGP was solved by Jaime with the release of a new driver back in September 2016. In SGP the AAG driver will use the last file result if it can’t read the file. It will do this ten times before throwing an error. Works a treat. So, make sure you are using the latest version of the AAG driver.

Steve - I’m afraid that I can’t help with the Solo problem as I don’t use a Solo, just the CloudWatcher in Master mode on my obsy PC. I’m sure Jaime will have thoughts and solutions - he is always a great help.

Ron - I totally agree about the desire for safety checking to happen when the system is running but not during a sequence. I often use SGP without running a sequence, especially when setting up a new project, and end up glued to the CloudWatcher and my All-Sky-Camera checking conditions manually.

Last night to test - I was nearing the end of a sequence. So I manually changed cloud temp to be unsafe. SGP’s button changed from green to red and a notice popped up that the sequence would stop in (counted down a timer).

I waited. It shut down the sequence (and said it would park mount etc). Nothing happened? shutter stayed open and nothing parked?

Please see here:

Thanks,
Jared

@PhotoGav - how does one know what version of CW driver is installed? I assume this is different than the installed program version?

Tried turning on the CW safety monitor over the weelend. It seemed to work ok for a couple hours but then got an unsafe. Not due to weather conditions, but due to a file save time-out issue:

image

Not sure why there was such a lag in the file save/refresh process. I’m open to suggestions :=)

DaveNL

Dave, I’ve had a look on my system and can’t work it out! All I can suggest is that you check the Lunatico website and download the current version. I see that you are using the Weather Centre, I wonder if that has something to do with the issues? Whatever, the Cloudwatcher Yahoo group is probably the best place to post your questions.

Hi Gav
I went looking for the Lunatico Yahoo group the other day. The only one I could find seemed to be completely in Spanish. As I struggle enough with English … You wouldn’t happen to have a link, would you?

Steve, join this group: https://groups.yahoo.com/neo/groups/lunaticoastro_en/conversations/topics It is definitely in English!!

Thanks Gav. After several Captcha attempts, I managed to join!

Good stuff, I hope you sort the issues. Is this happening at home or at the Spanish set up?

At home. Going backwards at the moment though. I now have CW reporting as UNSAFE, and yet every safety switch is showing itself as being Safe. Double checked time and date, and all that is good, so this is a real mystery. I will e-mail Jaime…

Aaarrrggggh, major infiltration of Gremlins. What a PITA. Good luck sorting it out. At least the Spanish kit is in operation and gathering data.

Just thinking - could you use the CW without the Solo? That would at least identify which of the two elements is creating the issue.

Gav, Steve

There is a setting to set the delay to the Safety Switch status change when conditions change from Unsafe to Safe. I recall that this delay is 300s by default. Thus, when conditions change from Unsafe to Safe, for 300s every measure will be displaying Safe whilst the switch will remain Unsafe until the 300s has elapsed.

Is it this feature you are observing? Or is it something else?

Maybe not helpful, but I am not seeing any delay between Solo and CW data readings. I will however, pay close attention over the next night’s imaging.

Barry

I don’t think so Barry. I had the AAG webpage window open for the best part of the night and it remained unsafe throughout. I monitor the Safety Switch relay using a Dragonfly Sensor and that showed unsafe throughout the night too.

Gav: I do wonder about the Solo - I am not really sure what it brings to the table - other than it being another bit of hardware for us to fetishise over. You get a nice webpage looking thing, but SGP just needs to look at a silly old file. When you use the CW without the Solo, where is the sld file located?

The sld file is in the location that you put it in with the settings in the CW app - I forget which tab that is on, but it is in there somewhere… My obsy laptop has just started the latest Windows mega update (with no apparent user benefit), so I can’t look I’m afraid!

So that can be anywhere? On the C: drive, for example?

Exactly, wherever you want it to go. I have a folder on my desktop called ‘AAG Files’ or somesuch, then point to that folder and file from within SGP. When it is all connected, toggle the Unsafe limits buttons in the CW app and watch the SGP icon turn from green to red and so on! Fingers crossed…