New Celestron Mount CGX-L (same as CGX but bigger).
A couple of things, I cant get it to park where it should even though I have set the park position in the Celestron Ascom interface, Evidently it wont report the ‘side of pier’ set as “False”,
After a 2 star alignment plus some calibration stars it works quite well with plate solves resolving in seconds without having to resort to a blind solve so evidently it is pretty aware of where it is pointing.
Also something went haywire with autofocus at around 11:40, clouds possibly? Typically the AF routine runs quite well.
Lastly this sequence failed around 12:38AM I am thinking the guide star was lost for some reason.
Please have a look at this log for me. There is so much data in there I don’t know where to begin to look.
I am not familiar with your mount . However, once the plate solve is done did you sync to your mount ?? That would really mess up flips if you didn’t .
Yes I did do a solve and synch which resolved in seconds using plate solve 2 so it is quite aware of where it is pointing but evidently not aware of which side of the pier it is pointing from.
It will resolve after a flip is caused by say slewing to a star on the ‘other’ side of the meridian with the hand set. Just doesent work in SGP
In the log file it says “Side of pier:False” or something like that.
SGPro logs were never meant to be consumed by the user. If it is not clear what happened during your sequence from the SGPro UI, it is an issue we need to address. Typically, sequence failure will register itself in the sequence event UI here:
With respect to your specific issue, the sequence failed because, during target auto center, SGPro could not solve the image.
Thank you Ken, I am aware of that synopsis of falures I have read it way too many times. I am assuming that that particular sequence failed due to either dew or clouds.
I was actually more interested in the pier flip and parking issues.
This is a new mount so there may be some quirks worth looking into.
[05/17/17 21:47:55.140][DEBUG] [Telescope Thread] Telescope: Exception thrown while querying SideOfPier, setting to false. : Property read ASCOM.Celestron.Telescope SideOfPier is not implemented in this driver. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Property read SideOfPier is not implemented in this driver.
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object args, Boolean byrefModifiers, Int32 culture, String namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object providedArgs, ParameterModifier modifiers, CultureInfo culture, String namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 243)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 279
at ASCOM.DriverAccess.Telescope.get_SideOfPier() in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 895
at p6.jo()
[05/17/17 21:47:55.141][DEBUG] [Telescope Thread] Telescope: CanSetSideOfPier returned False
So evidently that particular ASCOM driver cannot report side of pier?
This is bad… As far as I know, there is no way to work around this issue other than to contact the author and request access to this property. SGPro auto flip supports 2 different ASCOM configurations:
Driver allows for reading SideOfPier (to determine when flip is needed) and driver allows a flip to be executed by setting SideOfPier. This is the ideal scenario and allows for the most reliable flip and the highest degree of flexibility inside of SGPro.
Driver allows for reading SideOfPier (to determine when flip is needed) but driver does not allow a flip to initiate by setting SideOfPier. To compensate for this, we rely on the mount to perform a flip when it is asked to slew to its current position, but only after it has passed the meridian. If the mount does not do this, the meridian flip will fail and there is nothing SGPro can do.
In both cases, SGPro relies on the mount to implement SideOfPier such that SGPro can ask about the mount’s current pointing state (i.e. the property must be at least read-only). Without this, there is not much to be done.
I got ahold of Chris, seems like a nice guy pretty responsive. Anyhow here is his response.
Thanks for the log. What’s happening is that the driver version predates the CGX mount so it doesn’t recognise the type and takes the conservative approach of not allowing pier flip.
This should not be a problem, the specification says that the driver must throw an exception if read of the side of pier state is not available. SGP should trap the error and continue. Pier flip should continue to work if it waits until after the mount has crossed the meridian.
I’m planning a new release of the driver, not sure exactly when, but it will include recognising the CGX mount.
The problem is that the SideOfPier is throwing when we ASK it for the side, not when we command the flip. So we have no way of knowing what side of the pier the scope is on. True if we attempted to set the side of pier and received an exception we would just wait. But if we can’t read it we have no way of knowing if the mount is even in a position to actually flip.
I’m on holiday but I’ll try to comment a bit.
The ASCOM get SideOfPier property is optional. It is totally ASCOM
compliant to throw a not implemented exception. Applications are
expected to try to catch this and handle it.
I’d handle this by sending an experimental get SideOfPier before
starting. If it fails set a flag and use that to manage what you do
during the run. Simplest would be to report to the user that pier flip
is not available. It would be possible to ask the use what to do,
waiting until after the mount has crossed the meridian by a suitable
amount, then attempting a pier flip by doing a slew would be a
reasonable option.
Unless I am not understanding something, this is what we are doing. Handling the exception and reporting that a flip cannot be performed. I think the question was more “why” can we not see the sideOfPier property for this mount.
There is no requirement in ASCOM to implement set or get SideOfPier at all. Throwing a NotImplementedException is totally ASCOM compliant.
The trouble is that SGP requires more than ASCOM compliance. It requires that a particular set of ASCOM properties are implemented. It’s up to SGP how it handles this.
Chris, You may be right (I’m not an ASCOM expert - far from it) but let’s look at this with a bit of community spirit. SGPro emanates from a couple of fanatical enthusiasts who share their skills with the wider AP community and reap a probably very modest return. Celestron is a pure commercial enterprise in it for the money, which is fine. Both entities are doing some good stuff. But with a staff of two or three, SGPro fixes problems pdq. Celestron however, (with a few more staff and resources) launches a new mount targeting the AP community and doesn’t bother to ensure that the ASCOM driver (which is critical to the AP user base) is updated prior to launch. Just a thought!
Right. I don’t think anyone is disputing this. When SGPro detects this, it catches the exception and indicates a flip is not possible. You are right though, we don’t require just simple ASCOM conformance, we require that the telescope implement this property (much like we require a focuser is absolute).
I wish to point out that Chris gets no financial support from Celestron for his excellent efforts on the ASCOM driver, In this regard, Chris is far more like SGP, shared skills with little or no return, than like Celestron. This also means that Celestron has no power over Chris, to fix bugs in a timely fashion, compensate for our limitations, or add support for new mounts.
At the present time, it would be inefficient for Celestron to offer a competing ASCOM driver. Not only that, it would be a little rude, don’t you think? Obviously, if Chris ever abandoned his driver, Celestron would be required to act. But for the time being Chris is the man. I thank him for his efforts so far, and salute his service to the AP community.
In the end, there was no one at Celestron who took responsibility to ensure that ASCOM would be 100% functional with our new mount and all ASCOM’s clients (e.g. SGP). We dropped the ball on that. Next time, I will reach out to Chris to see if there is anything we can do to make it go more smoothly.
To Chris, my sincere apologies for any offense caused, though it was in no way intended. I too thank you for your efforts and salute your service to the AP community. I had (clearly wrongly) assumed that your development of the ASCOM driver was at the behest of Celestron. The purpose of my post was a gentle prod at Celestron whom I felt had dropped the ball, and it was in response to your comment (which I interpreted as being ‘on behalf of Celestron) that SGPro was at fault for expecting too much.
To Derekd, thank you for your timely intervention and clarification which I felt was very positive. I agree it would be inefficient for you to develop a competing ASCOM driver and I do think it would be rude. I also welcome your last sentence regarding ‘next time ….’. I am sure it was implied, but hopefully you have now ‘reached out’ this time.
SGPro emanates from a couple of fanatical enthusiasts who share their skills with the wider AP community and reap a probably very modest return…But with a staff of two or three, SGPro fixes problems pdq.
+1 and many thanks for great product and greater support
wish to point out that Chris gets no financial support from Celestron for his excellent efforts on the ASCOM driver, In this regard, Chris is far more like SGP, shared skills with little or no return
+1 and thanks (even though I don’t currently use Celestron gear with SGP!)
In the end, there was no one at Celestron who took responsibility to ensure that ASCOM would be 100% functional with our new mount and all ASCOM’s clients (e.g. SGP). We dropped the ball on that. Next time, I will reach out to Chris to see if there is anything we can do to make it go more smoothly.
Kudos to Derik/Celestron for being open about situation and offering to do better …
Yes a special thanks to everyone involved. There is a lot of moving parts and a refreshing mea culpa from the manufacturer themselves.
I will have to say that in all other aspects the performance of all of SGP, ASCOM, PHD, and the CGX-L mount itself have been completely satisfying in all respects with the minor exclusion of the side of pier issue.
Even that is easily worked around since the mount can guide some 20 degrees past the meridian so I just end the target before it reaches that point and it works out.
It will be nice though when the SOP and flip issue is worked out so I can get a little more duration on some targets. unfortunately in my location the meridian nearly bisects my viewing range between some trees and other obstructions.
I was a little surprised that the issue had not come to light sooner as surely I am not the only one that has run into it.
Anyhow thanks again one and all for working together and we are grateful for your efforts!
