Thanks Craig,

I'll see if I can identify something similar to use here in the UK. It's all a bit beyond my know how, so thanks for the pointer.

Cheers,

Geof

---

From: ap-gto@... <ap-gto@...> on behalf of Craig craig@... [ap-gto] <ap-gto@...>
Sent: 03 June 2018 16:05
To: ap-gto@...
Subject: Re: [ap-gto] Switch to inhibit motion

 

 

Geof,

I agree that the ability to control individual equipment power is important. I use a Digital Loggers Web Power Switch for that purpose. Part of my automated observing process is having the necessary devices power up at start and power down at the end. Prism integrates with this particular switch and makes it easy. Or you can write custom scripts to be executed by CCDAP (which I used to use) or anything else that lets scripts run during the observing sequence. You can also log on to the web power switch directly, so if the control computer goes down that’s one way to keep safe and cycle the computer.

-Craig

On Jun 3, 2018, at 10:14 AM, Geof Lewis geoflewis@... [ap-gto] <ap-gto@...> wrote:

Hi Craig,

I'm with you on this one and glad to know that you didn't suffer any damage to your gear. However, it's not just roof crashes that are a problem with the mount tracking under a close roof. Before I installed my C14 on the AP1200 I had a small APO that would not crash into the roof, but one night I forgot to park the scope/turn off the power and the next evening when I opened the obs I found this.....

https://www.dropbox.com/s/ioe83vnx4kkxrmc/Torn%20Y-cable.JPG?dl=0

The mount had rotated the best part of 360 degrees tearing the Dec/RA Y-cable in two, so I'd still like to be able to isolate the power supply to the mount when the obs is closed as a second failsafe, for when I forget again.....!!

Good luck coming up with a solution which I'd love to hear about.

Regards,

Geof

---

From: ap-gto@... <ap-gto@...> on behalf of Craig craig@... [ap-gto] <ap-gto@...>
Sent: 03 June 2018 14:35
To: ap-gto@...
Subject: Re: [ap-gto] Switch to inhibit motion

 

 

Thanks for the suggestions and commentary. For me, the roll-off design works well and is cost effective. I have an interlock that prevents the roof from moving unless the scope is in a safe position. That interlock uses an @opark sensor, which looks for a polarized beam of light (emitted from a unit mounted on the observatory wall) to bounce back from a reflector on the OTA. It’s set up so the reflection only returns to the sensor when the scope is at Park 4. The @park sensor provides a signal to the roof controller as part of a “safety loop”. If any part of the safety loop is broken, the roof won’t move unless the operator overrides the safety indicator- which can be done remotely. I have an IP camera in the observatory so I can take a look at the situation and make informed decisions when something goes wrong. But in normal operations, my observing sessions are almost fully automated. I saw almost because to mitigate risk, I usually open the roof manually, turn off the roof motor, and let the rest of the session progress automatically.

My problem the other night happened because I slewed the scope as part of a test after an automated run had completed- forgetting that the roof had closed. Had there been an interlock on the mount, my mistake would not have caused a problem.

In my mind the ideal solution would to provide an input similar to the safety input on the roof controller that monitors a safety loop for the mount. If the safety loop is open, the mount would not move unless the operator overrides the safety signal. If the safety loop is closed, the mount would operate normally. Unless there’s a hidden input of some kind in the GTOCP4 that could be used for this purpose I doubt we’ll ever it implemented. But I don’t know what’s inside that control box and hope springs eternal:)

Since the crash I’ve had someone out to the observatory to inspect the damage from when I drove the scope into the roof. The good news is that there is no damage! The combination of low speed slews (600x) and hand-tightened clutches seem to have saved the day. I’m sure glad I didn’t crank those clutches down during my recent maintenance visit. One more lesson learned.

-Craig

On Jun 3, 2018, at 4:40 AM, schling@netcabo..pt [ap-gto] <ap-gto@...> wrote:

Hi Craig,

Very interesting thread as I also own what I now know to be a R^4 observatory (and not in my backyard)! Thanks for your insighful comments.

Here is how I minimize my risk (never had a crash):

- Two-axis inclinometer mounted on the scope to give me a level confirmation in addition to what the mount tells me

- Roof and mount power never on at the same time

I have relied on the roof limit switches to confirm the open position without a second, redundant sensor.

In the end, not everything in the observatory can have a back-up, and that holds for the mount and the roof contoller/motor.

In a R^4 observatory you are exposed to both to mount risk (mount failure, unable to park) and roof risk (unable to close). Maybe one could say that the mount risk is higher than the roof risk as a mount is more complex. After many years of experience with my AP mount I’m not so sure :)

But in a non-R^4 observatory you will always be exposed to roof risk. That will never go away.

My feeling is that the incremental risk from the R^4 design is acceptable as long as properly managed. In my case I needed the roof to be as low as possible for purely aesthetic reasons.

Robert