DDW Weather Safety and ACP

[Robert Capon]

Hi:

Somebody on the Bisque forum mentioned that DDW's old firmware has a bug such that conflicting close commands from the weather sensor and ACP will cause the dome to stop. So I'm in the observatory trying to recreate that scenario.

I connected ACP and the weather sensor with all "unsafe" conditions turned off. I then slewed the telescope through SkyX to Polaris, which is very near the park position. I waited for the dome to catch up. I then ran an ACP program, a simple loop.

At that point I forced the weather to go unsafe (by clicking on "Light" as an unsafe condition). The AAG sensor immediately went unsafe, and started the dome close. ACP, however, reported "unsafe" but did not run the weather safety script. Why didn't it run the safety script?

Can you suggest an ACP script that I can run during daylight such that ACP will run a weather safety script when the weather goes unsafe.

I want to see what happens when the scope is parked quickly and the dome gets conflicting close signals (one from ACP after the AAG sensor started a close sequence.)

Thanks,

Rob

[Bob Denny]

YOu were on the right track. ACP should have run the safety script. This is the problem we need to solve.

When the safety script runs, it parks the scope (Telescope.Park). With TheSKy, a complex chain of events takes place within ACP due to TheSky always dropping the telescope offline as part of the park operation. I don't want to write up the entire thing here, suffice it to say that you will see some semi-humorous popups that will disappear on their own over the space of a couple of minutes, after which ACP will attempt to close the dome. If the dome is already closing (due to the hardware trigger) all should be well. ACP was designed to handle this (optimal) setup with the hardware signal.

However, the test you are looking for is to see if the close signal from ACP actually halts the close operation which was started by the AAG hardware.

Going back to the beginning, we need to solve the problem where a weather unsafe event does not result in the safety script being run. I will need to see this with my own eyes. As you probably know I am on the home stretch of a douple software release of ACP 7.1 and Scheduler 3.6, so it's a bit busy here. We can do all of this during the day if you can cap your scope for sun safety and if the weather isn't too snowy or windy. Are you available during the day? Of course we could do it early evening so you don't lose observing time.

Give me some times and I'll try to set something up.

[Robert Capon]

Bob-

Yup, I can do it during the day anytime. That's actually handy because I can use "light" as a condition that toggles the safety script. For some reason, ACP is reporting "unsafe" without running the safety script. Please put me on the list after you come for air after 7.1 is released.

in the meantime, if anybody else has any ideas why the safety script isn't running, please let me know.

Thanks,

Rob

[Bob Denny]

One goofy thought... is there an ACP-Weather.xxx script in your Program Files[\(x86)]\ACP Obs Control area?

[Robert Capon]

Hi Bob:

I got it all working, and I also saw the DDW test run very smoothly. In our brief call, you gave me the clue. The ACP timeout period was confounding the results.

I restarted ACP, and connected to the AAG weather sensor. It was cloudy and dark, but I set up the AAG sensor not to report on any of these conditions as “unsafe”. When I connected ACP to the weather sensor, ACP reported weatherscript, and AAG reported “safe” through the console.

At that point I connected ACP to the telescope and dome. After it was connected, I slewed to Polaris from within SkyX. Polaris is near the park position, so that would insure conflicting signals would be sent to DDW from AAG and ACP. At that point, I made sure that the 10 minute timeout period had expired. Then I clicked on cloudy conditions to trigger weather “unsafe” conditions.

At that point, the weather sensor went “unsafe” and sent an unsafe signal to ACP. I know the weather station immediately sent a signal to DDW, because DDW issued warning beeps that the dome was about to move by a computer operation. However, ACP immediately thereafter issued a weather safety script. The DDW action from the weather sensor ceased. The dome went to the park position. After the telescope was parked, the dome went through the close routine. The dome panel indicated that the dome was closed, and I got the popup window from ACP saying: “Gosh, I think the telescope has been parked.”

My problem earlier was trying to run this test without observing the 10 minute timeout period within ACP.

Also, the DDW test was successful. The ACP weather script properly overrode the close signal sent by the weather station.

I plan to write up these results for the Bisque forum to indicate that I was not able to reproduce the conflict between ACP and the weather sensor sending duplicate commands to DDW.

Life is good.

Thanks for your help.

Rob

[Robert Capon]

Here's the report on the Bisque support forum:

http://www.bisque.com/sc/forums/p/20...840.aspx#91840

Rob

[Bob Denny]

Thanks for the report, and I thanked you there as well :-)

Are you OK with respect to the weather script running now? It won't run (again) after an unsafe until that 10 minutes has passed with uninterrupted safe conditions. It sounds like it was running OK in your tests.

[Robert Capon]

Bob:

Yes, I’m convinced that the system is working flawlessly. What I was seeing was the AAG reporting into the control window safe—unsafe—safe—unsafe—safe, all within the 15 minute ACP reset period, so ACP did not run the weather safety script.

But whenever the 15 minute period has elapsed, I’ve confirmed (every time) that ACP clears the AAG reports from the console and correctly runs the weather safety script. So ACP clears all of the AAG messages, and runs the script.

I’ve also confirmed that DDW is correctly handling conflicting signals from the weather sensor and ACP. The weather sensor closes the connection on the two wires going into DDW “Close” terminals, but the ACP weather safety script overrides that command. I tested this with the scope near the park position to insure that the scope would park quickly and the conflicting signals to the dome would occur. Worked every time!

Thank you for your help. My initial test was confounded by the 15 minute timeout period. It happened to be cloudy when I tried my test, so ACP was within the 15 minute period. I forced the sensor to go safe and immediately back to unsafe, so the weather script never ran.

Also, the ACP timeout period is a great feature. I think that’s working very well for me. It just confused me during this particular daytime test on a cloudy day.

Best,

Rob

[Peter Prendergast]

I am astounded that no one has called Jerry at Technical Innovations to inquire about this. But, OK, I have previously...months ago...posted here about this and other issues with the firmware. Playing Russian Roulette with wet gear when a solution is available is indeed perplexing to me. Oh, well its well documented now!
Peter

[Robert Capon]

Hi Peter: At your suggestion, I called Jerry at Tech. Innovations. Jerry indicates that the firmware has not been updated to address the potential conflict that you mention. He indicates that it's something being studied for a possible future firmware release along with several other ideas, and that I indeed have the latest firmware. Also, I don't doubt for a second that you have experienced this problem. I'm only saying that a) I've never experienced a conflict between the close command of the AAG sensor and the ACP command in real-world use, and b) I have not been able to replicate the problem at my observatory despite extensive testing. Perhaps it's a problem either related to your particular setup, or it's very intermittent and difficult to replicate. If it's intermittent in nature, it can be very difficult to diagnose and replicate. All best, Rob