This might already in be the product and I just didn’t find it, but it recently came up …
With CGE Pro mounts the grease on the gears has a tendency to thicken up as the temperature drops, putting an excessive (and damaging) load on the motor during slews. To compensate for that I adjust the slew rate that the program will use based on the season/ temperature … as it gets colder I’ll slow down the slew rate to make it easier for the motor to slog through the grease …
I didn’t see where I could adjust the slew rate to use on the mount anyplace … could someone point out where I would make that adjustment either in a profile, a sequence or in a DragScript Goto X action?
If that’s not available, could I make a feature request for that ability? One potential way would be in the equipment profile on the Mount tab have the ability to select “fast”, “typical” and “slow” rates using a dropdown combo populated from the ASCOM profile for the mount type selected … so I could choose a “fast” rate of 2deg/ sec, a “typical” rate of 45’/sec and a “slow rate” of 45"/sec, or whatever the mount communicated it would support
Then, in the various DragScript Goto X actions another drop combo where I could choose the “fast”, “typical” or “slow” slew rate to use for that action so that the DragScript doesn’t need to “know” the specific mount speeds
So in use in the mount profile for my CGE Pro I would choose “fast” as 1.8deg/sec, “typical” as 50’/sec and “slow” as 45"/sec and in the summertime when I build my DragScript I would select the “fast” speed as my Goto X action, in the fall select “typical” as my speed and in the winter when the grease thickens choose “slow” as the speed …
In ASCOM interface at now there’s not a properties or methods to change slew speed. Also in the interface to planetarium actually supported like mounts control in Voyager. In the mount ASCOM setup dialog if you find this property you can set it manually but just in this way. Sorry. For example in my AP mount you can change in the ASCOM Dialog and save in profile of mount.
I guess it depends on how you’ve implemented the “slew” functionality … if you are using the v3 ASCOM.DeviceInterface interface then you can query the ITelescopeV3.AxisRates property (which is a required property for v2 and v3) which will return you an array of the tracking rates the scope supports … that’s where you could populate the “fast”, “normal” and “slow” enumerators in the profile tab from …
Also from the ITelescopeV3 interface you have a MoveAxis method which takes a rate from the AxisRates array … that’s where you could pull the “fast”, “normal” and “slow” values from in the sequence when you make that call to move the scope …
If you’ve implemented the “slew” functionality however with SlewToCoordinates or SlewToTarget (or the Async versions) then that won’t work, since they just take a position and off they go … and I can understand doing it that way, as with MoveAxis you have to send a “stop” command which is tricky to do at just the right time and dangerous if the mount misses the “stop” and potentially hits a limit …
On the other hand, in cold weather (especially with the Celestron mounts) the worm drive grease thickens once the temperature drops below 0C and REALLY thickens below 10C … Celestron in fact doesn’t advise people to use the mount below 0C. The thickened grease causes a problem because it increases the load on the motor, leading to motor burnout at the default slew speed; for that reason most people (should) simply stop using the mount once it hits 0C unless you can lower the slew rate to something that the motor can still make progress with without burning out. I’ve been able to use CGE Pro mounts down to -5C provided that I slew at a very slow 30’/sec rate … so if there’s a way to get a “SlewToXSlowly” action using MoveAxis that would be great!
If not though I can use the Celestron utility to update the mount firmware using mode 9 to limit the slew speeds as well …
I did not consider the way you indicated as impractical for Voyager. I can not use to point anything else other than the slew with coordinates and async. Furthermore, not all the mounts would show the list of speeds. In a multi-control automation system I have to use common calls implemented in most cases.
The way forward is that of string commands via ASCOM. I have used them successfully for the FS2 system. Find out if your mount driver (the low level driver) has a string command in protocol to set the slew speed and its parameters. I can put it in the Voyager control interface as a customization to use for those with your mount.
That’s a good idea, but a few things interfere with that … first, Celestron doesn’t have anything I can find to pass in a CommandString method to change the slew rate; you can do that with the handset but the handset doesn’t use ASCOM. Second, this kind of command would need to be passed to the mount prior to any kind of slew operation, which means as an initialization string … and I could do that already by writing a simple ASCOM program to send that string to the mount and have that triggered by an external program in DragScript, so no need to add that to Voyager. Finally, if we have the ability to send some random command in CommandString then a user could also take the mount out of a known state into an unknown state which would really complicate things …
I think that other than supporting a MoveAxis “slow slew” in Voyager this will need to be filed under “not possible due to lack of vendor support” … and even a MoveAxis “slow slew” will be tricky due to not knowing when to “stop” …
I’m going to play around with writing a simple Telescope ASCOM driver that does it’s own MoveAxis based on the focuser temperature property, current position and target position … it will read the current AxisRates, read the current position, read the focuser temperature, determine a safe AxisRates speed from the temperature, calculate a slew time duration to new position based on that result, say 600sec, do a MoveAxis at the safe rate for a portion of that duration, say 60sec, read the position, recalculate the duration, repeat until the calculated duration is less than 10sec) and then exit. I’ll also have to make sure I don’t hit any boundary conditions (meridian flip, hard limit, etc.) along the way, probably just exit at that point …
By having this run as an external program and combining it with a DragScript SlewToTarget call I should be able to get 90% of the way there … the idea is that my MoveAxis driver gets the mount “pretty close” to where it needs to be and then the DragScript SlewToTarget finishes the job …
… while I’m at it I’ll add another ASCOM program which will also be run as an external program and it will check the AxisRates from the mount against the temperature returned from the focuser temperature property … if the AxisRates is higher than what is safe for the temperature the external program will return an error code which DragScript will detect and abort the sequence … as I’d rather miss a sequence than burn out a motor! That should provide a nice safety check before a DragScript SlewToX call is made which could damage the mount at the default slew rate …
CommandString solve all the problem … i can add a flag in the mount tab and send commandstring to set a defined value (a filed) of rate at connection in the init sub in interface for mount control. Just need to ask protocol of mount (serial protocol) and send the right command…if you can do with the handpad at 99% is possible to do with a serial command. we can start searching or asking the protocol
I can put an RS232 protocol analzyer between the handset and the mount, that will find an ASCII string and I can see if sending that with a CommandString would work for changing the default rate …
Rather than adding a flag or something to the mount tab (which could get really complicated really fast) what might be better would be a new action in DragScript of “Send Command” on the Actions->Mount tree which would take an ASCII string as an input and send that when invoked, putting the return string into a string variable that could then be checked. This would get you out of the mount business, as it would be responsibility of the DragScript implementor to “get it right” and would allow a user to send a mount specific command at a time of their choosing …
Taking that a bit further, if there was a new DragScript Action subtree of “Focuser” with the action “Read Temperature” which would call the ASCOM Focuser.Temperature property and return that into a counter value (you could multiply the return by 100 to convert from the double into an int) then I could use that in the DragScript to set the appropriate mount slew rate via the “Send Command” action … those two capabilities would eliminate the need for both of my external ASCOM programs I’m fiddling with …
Yes i can add the DragScript “Send CommandString to ASCOM Mount” and also add a block to retrieve the focuser temperature (x100 is ok now in the future i can create a new variable of type float). Tell me when you have the string.
Both of those will be very useful, thanks! Unfortunately there are some snags with the Celestron string … first, it appears that different models of the mount support different levels of the command based on the firmware revision … that makes getting the code to “stick” is problematic. Next, it appears that the hand controller turns off tracking prior to the rate modification (which makes sense) but makes a “single string” harder to accomplish. Finally and more troubling, it appears that if you send the string to mounts without the latest firmware revision it never returns with the ‘#’ ack code … it just sits there. All of those make a simple send of an update string problematic. I have a simple program that does a CommandString to the mount so I can do my experiments, if I find something I’ll let you know … but again, the ability to even send the CommandString is a big win, as is the Focuser temperature check!
We can start to solve your problem only relative to your mount revision and firmware … options will be relted to firmware version and model with disclaimer.
Without question, any kind of Action which is a DirectCommand to the ASCOM target is an advanced one … and at this point I think it’s too dangerous to cobble together some string to send to the mount. My current plan is to create my own external ASCOM program to use MoveAxis as I described to get “kind of” close and then let Voyager to a SlewToTarget after that executes to finish up …
Putting a bow onto this box … it looks like although the Celestron mounts I have take a MoveAxis command at the proper rate, there is just so much hysteresis in the system that it’s essentially unusable … the mount swing left, then right, then back left … it’s like watching a noodle man. No bueno.
I think it would be really useful at some point to have a DirectCommand action to an ASCOM target as a part of DragScript, but for now I think I’m just going to reprogram my mounts at the 30’/sec rate and leave it there, winter or summer … Leonardo has already added the ability to get focuser temperature as a DragScript variable, so I can completely shut down operations when the temperature gets below 0C in all cases to save my motors …
Leonardo, a question … suppose that I have a sequence that has been using the “fast” slew rates so now you have all kinds of good timing metrics to know how long the slew should take, once I switch to “slow” rates and slews get 10x slower, will the sequence notice this and recalculate the expected slew times for the sequence absolute stop time? Thx!
The data is from mobile mean weighted … AI can choose weight … target change pointing time … no one can know the exact time for pointing just more time more better return values. Voyager monitor last 50 slewing …
Interesting thread. Craig, you dig deep my friend!
The Paramount mounts have an embedded temperature sensor and you can just set a slew rate to be used below a given temperature. The setting is in TheSkyX. I think it reads the temperature only from the Paramount control board, so I doubt it would work with your Celestron. But it’s a nice place to put that kind of control - “closer” to the mount so programs higher up the stack don’t need to worry about it.
In fact, it seems like the kind of thing Celestron should put as a configuration parameter in their firmware (hand controller?) especially if they have more of an issue around 0C. That’s not very cold! I’m imaging now at 19F with both the MyT and a CEM60 (my micro-farm compared to yours, Craig!) and no problems on either one.
Agreed, it WOULD be nice if Celestron would have something like that … but they don’t, only a notation in the users manual saying “don’t use this below freezing” …
The problem isn’t in imaging per se, it’s in the additional load on the mount that the cold weather brings with the grease getting less like honey and more like molasses. The Celestron motors are servo motors, which means they will ramp up the pressure to “get the job done” until something gives: the mount moves, the motor burns out or the motor control board burns out. That’s what makes pier collisions and cable drags so dangerous … the motor will keep torquing away until (see above). In the case of cold weather the motor is working not only to move the scope but also do it through the molasses … it puts an extra strain on the motor. I don’t have direct evidence, but the two times I’ve burned out a motor control board BOTH happened when it was cold outside (below 30F) and I’ll bet you that the cold was a factor … which is why I lower the slew rates when it’s cold, to let the motor not work so hard. When a CGE Pro motor or control board burns out that’s basically game:over for the mount (replacement motors/ boards are around $700 each when you can find them, if you can find them, a used CGE Pro mount is about $2K) … so I’m really careful with the mounts!
Ed at Deep Space made a suggestion a few weeks ago that I’m already following: adjust the clutch screws so they engage just enough to move the axis but if there’s any resistance the clutch will slip … so, if the motor really wants to move and the mount doesn’t I’m covered. It’s a delicate dance, getting enough “stick” that you can function without losing the “slip” but I’m getting the hang of it … luckily with plate solving if the clutch “slips” a little bit and my goto’s don’t a plate solve/ slew fixes it …
