Possible guider restart issues in 226

With the current crop of restart on safe changes, I decided to play safe tonight and I disabled disconnect on sequence end and camera warmup, hoping that a restart would be smoother. The guider (PHD2) in the guider settings, still had disconnect on sequence end enabled.

SGP ran shut down for safety issues as soon as the timed image started, though I am not certain why, since it is dry and cloudless. Putting that to one side, I restarted the sequence, without touching PHD2 and SGP stalled, waiting for the guider. PHD2 did not reconnect to the equipment and even manually connecting PHD2 while SGP was waiting for the guider did not free things up.
After various sequence restarts, disconnects etc. the only way I could get SGP and PHD2 to play nicely was to completely exit both and reboot SGP and its sequence. (Friday 13th syndrome?)

The disconnect and warmup settings are a unique combination for me which I don’t normally use but the behavior suggests SGP does not reconnect PHD equipment, if its disconnecting at end of sequence option is disabled? Problems kicked off around 21:00.

https://www.dropbox.com/s/j8j8hxjrby8u66w/sg_logfile_20190913193943.txt?dl=0

I have just had a similar thing happen to me, the sequence restarted ok and the camera started cooling, roof opened scope slewed to target…everything was ok… but PHD2 was disconnected so the sequence stalled at autofocus.

Log
https://ws.onehub.com/files/6p11ilgd

@buzz @martin_h

This issue is really the same as the other issue. Restart on safe is not properly running through the auto connect procedure… guider included. We will address.

In terms of the shutdown due to unsafe. This code doesn’t have much complexity. There are only two ways a safety monitoring device can shut down the sequence.

  1. The safety monitor reports it is unsafe
  2. The safety monitor connection is severed

Not sure if the Boltwood puts out logs, but it may provide insight if you can see what it was doing at ~21:00.

Ken - many thanks. I have found something useful. The safety log file showed an unsafe condition at 20:59
reason: “Unsafe, reason: Time since last measure too long”

That rings a bell - I think the default refresh time for the AAGCloudwatcher is the same as the timeout period for the Boltwood Safety Monitor. It is right on the cusp and any sudden system activity can provoke an issue. I discovered this some time ago but I thought I changed the interval in AAGCloudwatcher / Boltwood. I’ll see if I have somehow reset it.

@jaime
Ola Jaime, I am trying to understand a timeout UNSAFE condition with the AAGCW through the ASCOM safety monitor. I’m running the AAGCW in Master mode. There is a time-out option in the ASCOM Safety monitor that is set to 60 seconds. What is the frequency of the AAG DAT file update? I’m wondering if a small delay could cause an infrequent issue.

gracias
Chris

Hi Chris,

if my memory is any good the file is written after every read period. Makes sense for your case?
Let me know if you need 100% confirmation, I can check that tomorrow.

You’re welcome!

Thanks Jaime. It would be good to know.

Hi Chris,

so it turns out it does save it every cycle, but then each cycle does not take exactly the same time, depending on a number of factors. The average will match the (user defined) cycle period.

So, with the standard 10s cycle, it can save as soon as 5 secs, as late as 15 secs.

In any case I’d make the timeout at least 4 or 5 times the cycle; unless your observatory is in a specially dangerous place, the odds of having a weather catastrophe in the between the CloudWatcher loses communication and the PC detects that, is … astronomical :slight_smile:

Hope this helps!

Restart on Safe works fine on beta 242…many thanks

Thanks. I will load the new version try it tonight. I think I may need it, considering the forecast.