Unsafe condition met while condition is safe


#1

In SGP 2.4 beta I get a lot of “unsafe condition met” while condition is safe.

sg_logfile_20141218102222.txt (55.3 KB)


#2

Hi tcpip, (is that really your name?)

It’s not possible to say why this is happening because all we can see is that something has triggered the weather close down. This is all I can see in the log:

[12/18/2014 10:24:56 AM] [DEBUG] [CP Update Thread] Handling monitoring event (Good Night System, Error).

I’m not convinced the Safety monitor is involved because the Safety light has remained green. There’s a Trace log in the safety monitor, if that’s turned on you will be able to look in the log and see if it’s generating an unsafe state and if so, why.


#3

The safety test also remains safe while SGP comes up with Unsafe condition met, with safety light green:

I guess you meant this with trace log in the safety monitor?

Where do I find this log?

Cheers, Irving


#4

Hi Irving,

[quote=“tcpip, post:3, topic:729”]
Where do I find this log?
[/quote] My Documents\ASCOM\Logs date\Ascom.Boltwood.*.txt

Must add a help button to the setup so people can get to the help file easily.

The log should show exactly why it’s reported unsafe, but the Safety Test seems to indicate that the safety monitor isn’t reporting unsafe.

Chris


#5

Aha, your the developer, Chris?

After turning on the log I see the following entry:
19:25:21.316 IsSafe Get Safe
19:25:21.405 IsSafe Get Safe
19:25:21.421 IsSafe Get Safe
19:25:21.508 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
19:25:21.543 IsSafe Get Safe
19:25:21.611 IsSafe Get Safe

I think it’s such a short period of unsafe it’s not noticeable by a red light in SGP but enough to trigger a unsafe condition. What causing this false unsafe?


#6

Yes I developed the safety monitor.

It looks as if what’s happening is that the real Boltwood might be taking longer to update the file than my simulator.

It doesn’t help that SGP is checking multiple times a second, I’m throttling that so it’s only checking the file every half second but it looks as if I should increase that.

I’ll also put a delay in the check so it will wait longer before trying to read the file again.

It would be nice to get some more feedback before I release a new version - and that could take some time. I have to rely on the goodwill of other people to update the release on the ASCOM site so it’s not something that’s practical to do frequently.


#7

More feed back by other people you mean? I’m willing to test another version.


#8

I’d appreciate it if a few more people could try it to see if some more bugs can be unearthed. It may take a while to get the release version updated (a week or so).
I’m not sure if I can post a test version here and even if I can I don’t want multiple versions floating around, that leads to all sorts of confusion.


#9

Hm, I think I forgot to move this to the throttled polling section after I implemented it…I’ll move that.

Thanks,
Jared


#10

Okay, I’ll just wait for the new versions


#11

Here’s a new version of the safety monitor that should have fixed the problem that Irving is having. If the file read fails it waits a second before retrying.
(upload removed, there’s a less buggy one below)
I’ve also updated the setup and logging, it should all be a little more resilient.

Chris


#12

It was happening with my setup too. You just had to turn off the ‘report unsafe when blank’ and it would ignore it.

Glad it’s fixed now. Irvining, give it a really good ring out before relying on it. of test how your set works during auto focus, plate solving, And recovery mode. Weather station support is the most ‘beta’ of v2.4.


#13

There seems to be somethink wrong with this version.
When I set the boltwood data file in the ascom properties and go back the field is empty.
When run the safety test it hangs and this is the log file:
20:09:47.343 SafetyMonitor Description ASCOM Boltwood OK to Image, version 6.0.5467.19594
20:09:47.353 InterfaceVersion Get 1
20:09:47.353 Connected Set True
20:10:18.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:23.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:28.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:33.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:38.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:43.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:48.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:53.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:10:58.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:11:03.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:11:08.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:11:13.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries
20:11:18.513 IsSafe Get Unsafe, reason: Data line is null or empty after three tries

I tried it also on a differtent PC with the same result.


#14

There’s nothing I can suggest. It works with simulators and I don’t have a real Boltwood to try it on. You seem to be the first person to try this with a real Boltwood. Maybe there’s something about how the real Boltwood writes the data to the output file that means it can’t be read by my driver. I can’t tell.


#15

Hi Chris, thanks for the effort…

I tried with the simulators on both pc’s when above happened. ASCOM.SafetyTest.Test.exe hangs.
I’ll investigate futher.


#16

I’ve had more of a look.

The most likely reason for this is that the file to which the Boltwood monitor is writing the data and the file from which my monitor is trying to read it are different. I know it’s obvious but worth checking carefully.

Another possibility is that the Boltwood monitor has opened the data file in a way that means that the driver can’t open it, not even for reading. I can’t see how that could happen with the simulator unless there’s some security issue. I’ve tried running the simulator as administrator and it was still OK.

It should be possible to open the data file in Notepad, it might be worth posting the file here.

Can other people try this please, or say if they have tried it, especially if it works.


#17

I was right, the data file name was incorrect - empty in fact.
But it was down to me, I’d made a tiny mistake, literally one bit, and it stopped the file name being updated. At least it’s not rocket science. What puzzles me is that I had tested it before posting it.

Here is the new version, this should be more likely to work, and if it doesn’t there will be more information.
Boltwood.SafetyMonitor Setup.zip (807.3 KB)
Chris


#18

Chris, It’s working now, thanks…
Noticed the more detailed log file…very handy. I’ll give it a more extensive test the comming days. keep you posted.


#19

Chris - I’m trying to get up to speed on this but am having a few difficulties. The AAG Cloudwatcher writes a .CSV file and a .DAT file and updates every 10 seconds. I tried your ASCOM driver reading the CSV and writing its trace log. The ASCOM driver and SGP report safe, when the AAG is not in that state.

Currently the ASCOM trace log is reporting IsSafe = Safe, when the AAG CSV is indicating unsafe in the column whose header is ‘safe status’.

edited: I then found a web reference that suggests it is the single line file that is required for CCDAP that is used. In that case, I found a reference for the Boltwood II file format and compared it to the AAG output and I think the single line file is missing some fields.
The reference for the boltwood was here (page 44):
http://www.ea4su.org/utilidades/claritymanual.pdf

Am I on the right track?

regards
Chris


#20

Buzz, you have to set the safety conditions in the ascom driver properties. The ascom driver doesn’t look at the status (safe/unsafe).


www.mainsequencesoftware.com