@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. 
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
Are you actually going to be that close? I park my PMX flat OTA and CW bar at 90deg not that I need to but the homed position is not that much different.
I actually unpark and home manually, did try the home on connect option in the ASCOM driver but as now don’t start and connect PHD, leaving to SGP to do at the start of the sequence it used to double home, would be good if the ASCOM driver only actioned the home on first device connection.
@trevorn That might be a reasonable compromise. If the action of parking >> homing does not hit the roof, then that would still be able to be controlled by SGP in its normal startup. The FLT132 is quite long.
I’ll also have to check what happens if you do not use ‘home on connect’ in the TSX ASCOM driver. I cannot remember if TSX itself has an option to home on connect - which would solve your problem.
Hole digging for the pier reached an unexpected problem… I didn’t find Richard III but I did find a sewage pipe. I’m going to have to move the site.
@Chris - a daft question - is there any reason why one ASCOM driver cannot access the COMs of another ? In other words, If I issue an instruction to my Dome ASCOM driver to open the roof can it in turn access the ‘ok to open’ is TRUE of another driver? I don’t want to dig myself another proverbial hole in the wrong position.
Not seen that option in the TSX but does not mean it is not buried in there somewhere, for now it is not an issue as always start manually when I am around and happy to leave it knowing everything will close for weather or something goes wrong. With the current scope have no issue with the roof closing regardless of if the mount managed it.
Couple of us are planning a remote obs at a friends in Scotland and at that point a lot of what you are talking about will be required, along with sequence pausing/restart, intelligent event selection etc - think that may be on the road map for SGP and hope so and not planning to be fully operational for another 10-12mths so have time.
There’s no fundamental reason why not. You could write a dome driver that handled the dome and a safety monitor which it could use to override the dome/shutter positions.
It would be useful if it also handled the telescope, then the dome could use the telescope position to keep the dome shutter aligned with the telescope and the telescope could be parked before the roof was closed.
You may recognise what I’m describing here. It’s the existing telescope/dome hub setup - a safety monitor has been added but that’s all.
The big question - who is going to put the bell on the cat 
Extending the existing ASCOM hubs isn’t really an option, they are written in VB6 and it’s getting very difficult to develop in VB6 now, It’s been obsolete for many years.
What’s needed is a replacement that’s written using a modern development environment, probably C#.
But quite frankly I’m getting a bit tired of everyone asking for more functionality and no one doing anything to contribute. It’s time some other people did more.
If you want a commercial solution then ACP is a pretty good product. It’s not free but the cost is representative of what it takes to develop and particularly maintain this sort of thing.
Chris
Thanks Chris - since the Arduino will be in C++, it makes sense for me to continue in C# for my ASCOM driver. When I’m done writing, I would have a go at a fully fledge hub too. I need something to occupy my retirement.
I have a bit of catching up to do first… my book on C is the original Kernighan and Ritchie from 1978. I managed to find my C++ reference, from 1990. Doesn’t time fly. I’m used to programming in assembler, so I have to get my head around modern operating systems.
One of the reasons I like SGP is it packages the most useful functionality of MDL / ACP in a neat and reliable package. I know MDL/ACP have strong followers, especially those who run in scripted fashion. I’m just not one of them.
I had another think about your suggestion of allowing SGP to home the mount through the first TSX connection - yes I could shrink the pier by a few inches and it would clear my biggest scope…but the mount continues to track once it is homed and would eventually see stars if the weather never improved. The wrong kind!
I think the safest option is to Park, which is a stationary status when the sequence aborts/completes and hope in the future that SGP does the initial connection to the mount when it detects the weather clears.
@Chris In regards to ASCOM TSX driver - to avoid SGP and PHD2 independently connecting and homing the mount twice…I just had a thought - if I connect SGP and PHD2 through a telescope hub to the TSX ASCOM driver, surely there would only be one homing event of the mount, on the first connection? Is that right?
Wouldn’t it be best to home on slew or tracking start? Essentially before a slew check if you need to home. If you do then report slewing and then home and finally slew to the requested location.
I’m not a fan of unexpected results for ASCOM methods. For instance my G11 will turn on tracking just because you connect to the mount. And while homing on slew is a little bit of an “unexpected result” you’re at least expecting the mount to move when a slew is issued. Essentially when the mount needs to start moving you need to get it into what ever state it needs to be to do that successfully with predictable results. Doing things on connect can cause potential issues if you’re not ready for the results.
Jared
Jared - I was thinking that the current implementation of SGP is very very close already. At present, when you start a sequence, all the equipment connects. The only thing I’m thinking is along the lines that when you start a sequence, only the safety monitor connects and SGP waits for the ‘ok to image’ before connecting the rest of the devices and running the sequence as normal. Currently, it all connects but immediately aborts if its cloudy, which is a bit pointless.
The current park/unpark - close/open shutter commands are fine as they are, especially if the settings are persistent.
My controller will be basic to start with- but I was considering layers of refinement: If I add a separate rain detector, it can anticipate good conditions before the clouds fully part and be ready with the roof open. If I add control through to the mount, it can park and close up in an squall and power the systems down in case SGP is not running at the time.
Neither am I! I put the home on first connect function in the TSX driver because it was there before but would avoid using it if possible.
Better to call FindHome explicitly at a time of your choosing.
The way the driver is designed may make it difficult to tell if there’s a previous connection.
Chris
I think this might work within the framework of the existing protocols in SGP and ASCOM resources with an existing mount driver. I’m not up to the task yet of writing my own hub in C# but if it is allowed to have separate ASCOM safety monitors for OK to open and OK to image, then it might be workable as an interim solution. In effect, the observatory takes note of ok to open and SGP would use OK to image. It does rely upon either the imaging or obsy program parking the mount before trying to close the roof.
The hub allows for both observatory and imaging applications to check and control the mount and roof. Both rain and cloud detectors would need to fail for the mount to move with the roof still open. The roof would not be allowed to move unless the mount was parked. If for whatever reason the mount tries to move with the roof not fully open, the park detector would interrupt the power to the mount.
I don’t want to be too restrictive, so the Obsy control app would also have the means to override sensors if required. (Say the mount was not present). It does mean I have to write more code but I think I will learn a lot in the process.
By the way - if this discussion should move somewhere else, please let me know.
Hi,
I have a Seletek Firefly controller and SGP resets observatory control from Roll Of Roof to Dome every time it is restarted. One other guy has this same problem. I updated the newest version and problem still exists.
That doesn’t happen to me. Perhaps it’s a driver issue?
Had this behaviour and also seen it with other systems, never got to the bottom of it. In the end I just created new equipment profiles and others with the problem did the same, been fine since.
1 Like