Roof automation observations

buzz · February 12, 2016, 10:21am

In the case of my roll-off-roof obsy, I have been trying to think of a way to start up everything automatically. I need to park my mount before I move the roof. In the design of my roof controller, I have sensors that prevent the roof moving unless the mount is in a safe position but currently I have no method to prevent a mount slewing into the roof .

Exploring the slave options for start of sequence I had a near disaster last night that by pure luck did not damage anything, missing the rafters by an inch. These are some observations:

a) In the case of a Paramount, when it is parked and powered down, when it powers up, it does not know that it is parked. -> That can mean that if the imaging software uses the park status to kick off roof opening and unpark, this will fail. In the case of a Paramount, it also has to be homed first, before it will slew. So long that auto-home is disabled on ASCOM connection, there is no risk of a collision but the sequence will not start up from ‘cold’. At least for Paramount users, you have to prime the system first and then hibernate it, rather than booting from cold park position. (For remote obsy that are permanently powered, this may be no big deal)

b) Because of a), I pre-prepared the mount, powering it up and homing it with the roof open and then parked it, closed the roof and left all the hardware and software running. In SGP, I got caught out by the ‘slave to telescope’ option resetting itself when I restarted the sequence At the start of sequence, it did not attempt to open the roof and slewed to target, neatly inserting itself between two roof beams.

c) At end of sequence - so long as I remembered to reset the ‘slave to telescope’ option in the control panel, everything went well - since I have fail-safes in the roof controller, the worse outcome is that the mount does not park and the roof stays open.

d) Thinking through this - it looks increasingly unlikely that I can achieve a true automatic startup from cold. Even from a hibernate state, while the ‘slave to telescope’ option self-cancels it is too dangerous to rely upon human nature to set this option each time I start a sequence or reset it each time I restart a sequence.

e) As a consequence of the above, I need to develop an independent fail-safe - preventing the mount slewing into a closed roof. I think the only way I can do this is with my independent Obsy App, which monitors physical roof and mount position sensors. It will need to issue an immediate ABORT to the mount, if the mount park sensor detects movement while the roof is closed.
f) In regard to the self-cancelling ‘slave to telescope’ option - clearly in my case it is a liability - what is the error state with making it stick?

Chris · February 12, 2016, 11:44am

There was an update to TSX and the ASCOM driver that may help. TSX added some commands to allow park without disconnect and to connect without unparking. You need ASCOM driver 6.1.5813 and TSX build 9240 or later.

Details are in the documentation for the ASCOM driver.

I’d be interested to hear if this helps. If there are issues then as usual driver logs will be needed.

Chris

buzz · February 12, 2016, 12:56pm

thanks Chris - I’m guessing I have those since I have the latest builds. That is not really the issue anyway and I don’t think there is any bug as such. When I power up the mount and connect, it does not know it is in a parked state (The ASCOM atpark command does not respond its parked. Equally it does not say it is tracking either.) Basically, the PMX is dumb and blind until it homes. After homing, when I park the mount the atpark command correctly identifies it is parked.

Jared · February 12, 2016, 3:15pm

What version of SGP are you using? In the latest beta there is now the option to “Slave on Sequence Start” this should slave things prior to the first slew no matter if the “Slaved” checkbox is checked or not. You can find this in the Observatory Slave Settings.

Jared

buzz · February 12, 2016, 3:30pm

@Jared
Ah - I am using beta 2.5.0.11 but I had not realized the purpose of that feature. thanks for that.

I will still add some code to my obsy app and take the precaution of monitoring both roof and mount sensors and abort any slew that occurs when the roof is closed. One good thing I did find out was that I can use both Chris’ OK to image and OK to open ASCOM drivers at the same time (for SGP and my roof automation respectively) using data from the same Boltwood DAT file.

Chris · February 12, 2016, 6:09pm

I hate it when people say this.

buzz · February 13, 2016, 8:45am

@Chris - my Arduino currently broadcasts its status every 4 seconds and the ASCOM driver event-handler keeps an up-to-date local status for instant response from apps. The Arduino has roof and mount position sensors and I’m going to modify the code so that it broadcasts immediately if the mount starts moving with the roof closed. The observatory app will pick up on this and send an abort command to the mount, which should stop it in its tracks. That will be my failsafe - which shouldn’t be needed…
I’m also going to introduce a hibernate command into my obsy app - that homes and parks the mount safely, ready for SGP to wake it up at the right moment. This is something specific for the PMX as I think quite a few other mounts’ drivers remember the mount status on power-up.

update: now have my App checking the mount and roof status and turning tracking/slewing off it detects anything with the roof closed. Just need some clear weather to test the hibernate function.