Odd behavior for dome/roof slave settings

After you have connected everything have you checked if the slave to scope is ticked still, you need to tick that after you connect scope and roof/dome - the act of connecting the scope will force an untick of the box - mentioned it before on a different thread, can set it be ticked in the profile and you think all is ok but it is not, right pain and could easily lead to a wet obs if you forget to double check it is still set.

Have a reminder to to check now when I start a sequence and a note on the bedside cabinet to remind to check.

I was hoping it may have been sorted in one of the recent betas…

Trevor

1 Like

I am guessing you use Tools/Options/General Options to display a popup when starting a sequence to do the same.

1 Like

Exactly, need to ensure I check - love SGP but the whole slave to part is not really fit for purpose as it stands.

1 Like

Hey Buzz,

I have a ROR and I have to park my mount in order for it to close. I have a Foster Roof Controller (it’s OK, mostly because of the software sometimes not working after updates).

I can tell you that slaving your roof to the scope works. I dunno why the simulator isn’t working… but my shed works so I can tell you SGP will do what it’s supposed to do :).

You do need to tick that darn box every time… like everyone else, I have a reminder to check my focus and to make sure the roof is slaved to the mount.

cheers guys - that would be it. I’m going to write a simple driver for the ROR and have a hardware lockout that prevents the roof from moving if the mount is not in the park position. It will consist of a tiny mirror on the end of the dovetail, which reflects a beam back on itself at the park position. If the mount is not parked, the beam is broken and its relay stops the roof moving.

This is an issue specific to the .NET Dome Simulator which was discussed a while back on this forum Bug Report - Dome & Scope Slaving - #6 by Jared - Sequence Generator - Main Sequence Software

It appears that the .NET Dome Sim runs in the same memory space as SGP rather than it’s own process. So SGP and the .NET Dome Sim get in a tug-o-war with each other because of some threading weirdness. If you use the old Dome Simulator it will likely work just fine.

Thanks,
Jared

It should be fixed in the next ASCOM platform release.

Chris

Buzz, I have a sensor I bought online for about 20 bucks. I’ll post a link in about 24 hours or so…

It integrates really well with my foster controller.

thanks - it could be useful - the motor kit comes with a photo sensor, used to stop a gate crushing your car - but it is rather big. The motor controller has a number of convenient inputs - open, close and an interrupter, that I would plan to use with SGP. If for whatever reason the mount did not park, the interrupter pauses the roof movement until the beam is made, i.e. the mount is parked. I just need to write a simple dome shutter ASCOM driver for a USB controlled set of relays to have full computer control.
If the slave settings are made persistent in SGP and Ken/Jared consider pausing a sequence start until the ASCOM safety monitor says the skies are clear, I should be able to do fully automatic sequences on the off-chance of good weather. happy days (or nights)

Here is the thread I posted on it over at Foster Systems. I was using two of them. One failed after about 3 months. You can get them on eBay or on Amazon. They work really well!

Chris

Thanks - that is perfect - and I can plug and play that into the existing motor controller too. I just have to put the mirror on the end of the dovetail plate.

I was going through all the error states and also figured that I need to do a safety lockout to prevent the mount homing when the roof is closed. If one does not set it up right, the act of connecting to TSX can home the mount before the roof opens. This is where the ASCOM driver developers earn their keep!

1 Like

@mads0100

I have been thinking about the architecture of SGP working with weather, mount and obsy systems without making it device specific.
In the case of the PMX, upon connection and power up, the mount needs to home. In my case, that must only occur with the roof open. It is going to get very complicated very quickly as not all mounts need to home when they power up.
This is my current thinking, feel free to chime in:
SGP assumes the roof is in a safe position to start an image sequence and currently uses ASCOM safety monitor to park the scope, or park at the end of sequence and close the roof. With a hardware failsafe - the roof will not close until the mount is parked.

For opening - this is more tricky, since SGP will want to connect to all the equipment and in the case of a Paramount trigger the mount homing, which could bang into the roof. (Unparking a Paramount has nothing to do with homing.)

I think I’m looking at a stand-alone roof controller, with its own separate rain detector, which opens the roof based on rain, rather than cloud and uses the previously mentioned hardware safety lockout for the mount position. It will be written as an ASCOM dome controller. Since rain will cease before cloud disappears, when SGP decides to go for it, the roof will already be open, which its ASCOM interface will confirm. SGP will then connect to the mount and it will home itself ready for the slew and center. If I need to provide a safety lockout in case SGP does not sense the roof position prior to imaging- I can have my roof controller interrupt the power to the mount if the roof is shut.
Does that make sense?

PS - I’m checking out the rain sensor RG11 from Hydreon.

Could this be where the option of two safety sensors could be useful?
SafeToOpen and SafeToImage.

SafeToOpen is used to open the observatory, connect everything, home the mount etc.
Then imaging starts when SafeToImage says it’s OK.

Chris

@Chris Absolutely - but at present SGP, AFAIK, only uses one for sequence control. I’m guessing I can always separate the controls at a later stage with separate ASCOM drivers, even if it goes through the same Arduino PLC. (I’m slowly getting to grips with ASCOM and assume one cannot have an ASCOM driver that bridges multiple devices that traditionally have their own)

Can I assume that one would want some sort of “has to stop raining for “X” minutes built in”? Being from Oregon, I am all too familiar with rain that starts and stops dozens of times daily. Without that, my roof would be opening and closing as often as a revolving door.

The option to have multiple safety monitors is there, it could be done in SGP or in some other Astronomy Control Program that handles things such as deciding when it’s safe to operate and triggering applications to do this.

ASCOM is nothing more than a set of interface definitions. It says nothing about how they are implemented.

There could be one application implementing everything, one application for each interface, one interface being implemented by several different sets of hardware. It’s all up to the driver developer.

Don’t assume that the ASCOM specification forces any particular implementation.

Chris

Sounds like England. Maybe you need a glass roof and a set of windscreen wipers. :slight_smile:

SGP currently has it setup so that you slave the roof to the mount, it will open the roof then move the mount. If you have specific requirements prior to starting the sequence (I don’t understand what homing does?) then you either need to script it prior to start or start your requirements manually prior to starting your sequence.

Homing is SB mount thing wherein there is a sensor on each axis at a specific point. Each time you power up the mount, it has to be moved to that “home” position prior to being able to point the mount properly. It basically tells the mount where it is at to start. The standard home position is typically about 45 degrees from the SW horizon. You can specificity (in the driver) for it to home on first connection (or not). When it homes it will seek that position and once found, begin to track normally at the sidereal rate. I typically like to watch what is happening on startup so have home on connect disabled. I just tell it to home from TheSky when I start at night.

Not just SB, The EQ8 and CGE Pro mounts also have home sensors. They both home with the OTA pointing at the pole with the counterweight shaft pointing down.

Chris