16 replies to this topic

[Sirius Chaser]

Does any one know if CPWI has any command line arguments? Like to tell it to auto connect to a telescope. Or if there are anything else like it that can connect to N.I.N.A and through the WiFi link?

[alphatripleplus]

You are more likely to get an answer if you ask the moderator team to move this topic to the Astronomy Sofware & Computers forum.

[Sirius Chaser]

You are more likely to get an answer if you ask the moderator team to move this topic to the Astronomy Sofware & Computers forum.

Oh, okay, I think I overlooked that one when I was looking for the right forum to post in. How do I request them to move it?
 

[alphatripleplus]

Oh, okay, I think I overlooked that one when I was looking for the right forum to post in. How do I request them to move it?
 

Click on the "Notify Moderator" button at the bottom of your opening post and put in your request.

[kaymann]

Until they move your post - When I was on doing beta testing with CPWI, CLI was never mentioned or tested.

[Sirius Chaser]

Until they move your post - When I was on doing beta testing with CPWI, CLI was never mentioned or tested.

Looks like it did get moved. But no CLI uses would be... well... CLI would be really useful.

[aescaffre]

I would also need such a cli.
Use case: remote observatory , electricity is cut during the day for saving on solar panel-filled battery. Then because I have to launch cpwi and click on the connect>usb buttons manually, can’t fully automatize acrosss several days and need a Manuel step every nights.
🙏

[dghent]

When an ASCOM client sets the Connected property in CPWI to true, ASCOM semantics demand that the driver connect to the device. There would be no need for this CLI or other such discussion if they made that part of CPWI compliant with the expectations set out by the ASCOM specs.

[Bob Denny]

Maybe it's my imagination, but I seem to see a disproportionate number of issues with CPWI being used by ASCOM speaking apps like NINA, SGP, Sharpcap, CdC, etc. I see that PlaneWave is "allied" with Celestron for this. Meanwhile I essentially never see (or experience with my own commercial software) problems with Planewave mounts/devices (PWI software/drivers) which are ASCOM compliant.  I have zero standing with this as I don't own Celestron products. Have any of you registered tech tickets so that Celestron knows about the problems? They may operating in "ignorance is bliss" mode. One of software's most unfortunate aspects is "no news is good news". 

[ButterFly]

Cpwi works fine with ascom.

Celestron products come in a wide array, with many alignment options available. Some of those options are only available with specific mounts types (such as altaz or eq), with others available only with certain hardware (such as autoalign and autoguide).

Autoconnect is a good idea, if one doesn't change setups. Autoconnect with a cli saved profile number is also a good idea. Suggest it to celestron.

[ButterFly]

When an ASCOM client sets the Connected property in CPWI to true, ASCOM semantics demand that the driver connect to the device. There would be no need for this CLI or other such discussion if they made that part of CPWI compliant with the expectations set out by the ASCOM specs.

CPWI is alignment software.  If you just "connect" to it through ascom, when the device isn't ready or aligned, that leaves developers down the line in a  very  dangerous position.  Breaking the scope, mount, or anything attached to it is a very real possibility.

 

Ascom in no way is able to handle doing the alignment by itself.  For example, in PlateAlign, one must at least select "Quick Align" first, after having placed the mount in the setup location.  Then, and only then, is ascom in a position to be able to translate a command to move it to a desired location.  Otherwise, one could start in any random position, with no alignment, then send the scope crashing into the mount.

[Bob Denny]

Thank you @Butterfly. Maybe what I'm seeing is operator errors.

 

 

Ascom in no way is able to handle doing the alignment by itself....

Exactly, and by design. It's typical that the Telescope Control system (TCS) handles alignment, PE (if applicable), encoder  ticks, servo power, and other mount specific technologies. ASCOM interfaces are device independent.

[ButterFly]

Cpwi does distinguish, through ascom, "sync here" and "add an alignment point to the model".  It has a special ascom action to add that alignment point.   PlateAlign is literally built around the latter for cpwi.

 

Many mounts do happen to "add an alignment point to the model" in some way through ordinary "sync here"s, though, like my Skywatcher through SynScan Pro app, eqmod, or gs server; and my Nexus DSC.  So this program works on my Skywatcher mount, as well as my Nexus DSC (with weird goto slewing).  It just sends an ordinary sync if it's not cpwi, rather than the special action.  The latest version of SynScan Pro app has a similar plate solving alignment available, but it's only based on astrometry.net solvers at the moment, and doesn't let you choose the points where the trees aren't.

 

My alpaca spoofing mount "driver" is basically a dumbed down version of PlateAlign, with a server attached.  It takes in an ascom camera and mount, and plate solver, then broadcasts that as an alpaca telescope.  So, all my gotos from SkySafari and the like iterate to a tolerance - with whichever mount I happen to be using.  I don't even bother aligning my AZEQ6 or AVX anymore if it's already dark out.  I just start it in home position, with the first goto off by a few degrees.  By the fifth or so goto of the night, it barely needs to iterate, if at all.  If it's still light out, I may as well run a routine to align while I wait.  If I connect to ServoCat directly through ascom, rather than to the Nexus DSC, I can't run an alignment routine at all, so it's just iterating based on the dsc alignment.  With ArgoNavis as the DSC, I can't add any syncs to the model at all.

 

If this sort of distinction between SyncToCoordinates and AlignToCoordinates becomes more prevalent, it would be nice if ascom added that to its methods, with a corresponding CanAlign property to let developers know.  How mounts handle it at present is all over the place, but it may eventually settle on something.

[Bob Denny]

I get this. Actually in my own app I have a simple 6-term pointing corrector. Like you (but within the app) I also do pointing updates with plate solves, and then add alignment points to the model, taking care not to "load up" the model with points clustered in places over the sky. Then it "broadcasts" a classic ASCOM Telescope for other apps to use (like planetariums) giving them corrected pointing. It is always updating the model with new/replacement points.

 

But this feature has fallen into disuse with proper pointing models such as Bisque's TPOINT, Astro-Physics' APCC, and PlaneWave PointXP. Pointing correctors that operate within the mount's control system. This architecture can provide dynamic corrections to tracking as well as slewing/pointing so that's the better place to implement it. In the case of Bisque and Planewave, you build the model offline and simply disallow SyncToCoordinates() ... the mount reports CanSync = false. In the case of Astro-Physics, it's like you describe... you have a choice of Sync or "Additional Align" (your AlignToCoordinates). 

 

Your suggestion to add AlignToCoordinates() and CanAlign is worthy of review. The way to get the ball rolling is to post on the ASCOM Driver and Application Development Support Forum with the background and suggestion. The general principles covering interface additions are described in the ASCOM Interface Principle. Also keep in mind that this is a long process. I don't expect the new additions in Platform 7 specs to come into common use for years. Both app and device makers have to move forward.

 

As it is today, the use of Action() (as you described for CPWI?) is entirely appropriate. I know Astro-Physics makes use of the older CommandXxx() methods (which are deprecated now... they were introduced ages ago to provide LX200 serial command pass-through :-)). But they are also using an escape. 

 

The question will be whether apps would want to know (or care) that when syncing that they should or should not add new points to the model, and whether app developers would be drawn to this feature in the future. It, like Homing, is kind of device specific. For example, early on there was a discussion on whether FindHome() belonged in the interface, or whether the mount should come up ready to use, already homed. I can say that over the years, the need to home some mounts and not others, and testing whether it is already homed, and when to look, created pain for automation.

[ButterFly]

It is indeed too early to add anything as a standard yet.  Even how mounts handle syncs is mount dependent.  Developers have no idea what the mount is actually doing to get that refined local pointing.

 

For standard DSO imaging, models mean very little.  A much simpler PID control is better equipped to handle RA + Dec tracking, as well as actual rather than modeled refraction.  TPoint and the like were designed for large fixed observatory setups back in the day of CRTs and giant computer boxes.  For we mere mortals, adjusting the collimation of our dobs will throw off a model!  Either you do another run quickly, or hope that the model is solid enough to be simply rotated.

 

For pure visual, double stars and satellites are the places where models are very helpful for me.  I can go through a 100 doubles in less than an hour.  Pointing is the key to that.  For satellites, they are going across the sky, very quickly, and only once!  For general observing, the ad hoc model of refining alignment through syncs is working out very well.  It just gets better over the course of the night.

 

Having these very tiny and very powerful general purpose computers at the scope is still fairly new.  There is still lots of room for experimenting with what works for what.  A standard too early can just stifle innovation.  CPWI does indeed use the Action method to do its alignment refinement.  Even though there's only one action available right now, that doesn't prohibit other Action methods that try out different things.  Maybe, if for some particular mount type, one method does prevail, and for enough mounts types, then it's a good time to start considering standard input approaches.  It's too early for that.

 

Back to the command line arguments, though, the situation is very similar to FindHome.  CPWI wants to ensure that the mount is in a ready state for remote control.  It's just dangerous otherwise.  As developers, we know best how to use our own products, but general users will always know best how to break them.  Avoiding permanent breaking by ensuring a ready state is a decent approach.  You can slap as many "Do not stand on chair" stickers as you want onto a chair, but at the end of the day, you really should know people will stand on the chair.  That sticker won't really help you for liability purposes in front of a jury, because they all stand on chairs too, and it really won't help you in a market where people can just get chairs that don't hurt to stand on.  Unfortunately, that leaves people who know what step ladders are, and who aren't too lazy to go and get them, with bulkier chairs.  Asking Celestron for an autoconnect feature is all that we can do, but they still get to decide whether they trust us enough not to stand on chairs.

[Bob Denny]

100% on target with all of that reference to the standards. Thanks!

 

I should add that models (at least the ones I referenced) are for mostly for flexure. PID can’t do that. It requires a mechanical model with coefficients that model the mechanics of the optics, imaging package, pier, etc. Here’s Patrick Wallace’s TPOINT site. The Bisque pages mention the widespread professional usages but Patrick goes into engineering detail here. He is generally considered to be the world expert on this among professional astronomy engineering people. 

Edited by Bob Denny, 21 December 2024 - 08:58 PM.

[JacquesTalbot2]

I would also need such a cli.
Use case: remote observatory , electricity is cut during the day for saving on solar panel-filled battery. Then because I have to launch cpwi and click on the connect>usb buttons manually, can’t fully automatize acrosss several days and need a Manuel step every nights.

Did you found a solution to your problem (need to click on the connect>usb buttons manually) ? I have the same problem to automate restart when there is a power cut. I am able to autorestart my mini-PC autologin et restart CPWI and NINA. I tried an ASCOM  powerShell scripting, was able to communicate with the ASCOM CPWI driver but was not able to set connected =$true 

 

16:28:58.389  [Pipeline Execution Thread] INFO:    Connected property TRUE but CPWI is not connected to mount.  Attempting to reconnect...

16:28:58.389  [Pipeline Execution Thread] INFO:    Submitting synchronous request: /mount/reconnect
16:28:58.389  [Pipeline Execution Thread] INFO:    could not communicate with CPWI, request =/mount/reconnect
16:28:58.389  [Pipeline Execution Thread] INFO:      ERROR: ASCOM.DriverAccessCOMException (0x00000000): could not communicate with CPWI, request =/mount/reconnect ---> System.Net.WebException: The remote server returned an error: (500) Internal Server Error.
   at System.Net.HttpWebRequest.GetResponse()
   at PWLib.Net.WebUtils.HttpGetString(String url, Int32 timeoutMsec)
   at ASCOM.CPWI.AscomTelescopeThread.Request(String urlPath)
   at ASCOM.CPWI.AscomTelescopeThread.Request(String urlPath)
   at ASCOM.CPWI.AscomTelescopeThread.SubmitRequest(String request)
   at ASCOM.CPWI.Telescope.get_IsMountConnected()
   at ASCOM.CPWI.Telescope.<>c__DisplayClass20_0.<set_Connected>b__0()

   at ASCOM.CPWI.Telescope.LogCall(String logPrefix, Action action)

Edited by JacquesTalbot2, 08 May 2025 - 07:33 AM.