New User - Encoders


smith_barry
 

Hi, I am new to this group and looking to use onstep to control my harmonic drive based mount which has been too long in the making.   From what I gather on the wiki I will need to go for the max series as I have high resolution renishaw encoders on the dec and alt axis.  Is this correct?
Thanks
Barry  


 

Yes. Encoder support is implemented in SmartWebServer (i.e Wemos D1 Mini) and Max series have prepared leads for encoders on DB9 (MaxESP3, MaxPCB) or DB15 (MaxSTM) connector in PCB design itself.


Khalid Baheyeldin
 

Before deciding on encoders, ask yourself why you need encoders?
In OnStep, encoders is for pointing, and not for tracking.

By pointing, this means that you can do things like: release the clutch,
move the tube then engage the clutch and OnStep will still know where
in the sky it is pointing.
Without encoders, OnStep will still point properly, provided that all
motion is done from OnStep's Goto. But it loses track of where it is
pointing if you disengage the motors and move the tube manually.

Encoders are not for RA tracking accuracy though.


smith_barry
 

Thanks for this my initial plan for the mount was to use a scitech controller hence using a DC servos to drive the mount and high resolution encoders to help with monitoring tracking.  However, I am using the Scitech on my more portable Losmandy G11 so looking for an alternative more user friendly option for the (very heavy) harmonic drive system where switching from dc servo to stepper motors will be easy option. 

My only concern may be changing from a high speed servo based gearing to a stepper based gearing due to torque drop off.  My gearing on the RA axis (I and using a GEM config) is 100:1 on the first gearbox and then 80:1 on the much larger second gear box.  With the servo the max slew rate is 2 degrees/s which is quite slow but commensurate with the intended scope (14inch reflector).  Given this I may need to drop the first gearbox down below 50:1.
Thanks again
Barry


Khalid Baheyeldin
 

Forget encoders for now. They are really icing on the cake, not a necessity.

Let us focus on the mechanical part.
Using steppers still works, even for large mounts.

We've had someone who converted a huge mount using NEMA23 steppers,
and had a 16" Newtonian on it. It worked like a charm.

The devil is in the details though, and there are variations.

Your overall physical gear reductions is high at 8,000:1. Usually, mounts are at 432:1
up to maybe ~ 3,500:1, with most at the lower end of that.

If you use the following for RA in the spreadsheet:
71,111.111    = 200 step motor,    1/16 microsteps,    GR1 80.00,    GR2 100.00

You are above the recommended limit of OnStep's steps per degree (61,200).

You can drop microstepping from 1/16 to 1/8, and be within the limits of OnStep.
Like this:
35,555.556    = 200,    1/8,    80.00,    100.00

But at 1/8, the motors could get resonance and stall. You won't know until you
actually try.


 

On Tue, Jan 11, 2022 at 04:38 AM, smith_barry wrote:
encoders on the dec and alt axis
Once again, do we speak about scope pointing encoders (on axis) or encoders for closed loop DC servos?


smith_barry
 

To clarify at the moment I have an encoder on the alt axis for the dc servo motor (which might be better replaced by a stepper motor for use with onstep) and a ring encoder 10 million ticks per rev on the dec end of the alt axis.  The latter could be used for positioning or for real time monitoring of tracking rate.  I note from the wiki that some are trying the latter approach on onstep using the Max series of onstep. 

The reason for asking is that unlike most conventional mounts the harmonic gearboxes do not have a worm for PEC rather they have an intrinsic pattern of speed variation due to physical aspects of the geartrain in my case a primary and secondary gearboxes on the alt axis. 

Until the mount is working and I can measure tracking and goto performance using the stars its all a bit academic but I want to get started with an option that at least gives some hope of correcting the issues that some have raised with mounts fitted with harmonic drives and for that I need to be able to collect data corresponding to the location of the alt axis as precisely as possible.  Accuracy would also be nice but for the moment repeatability would be a good first step.  

The abundance of digital servo drives now also allow onstep to be used to drive ac and dc servo systems so retaining the existing dc servo on my rig might also be an option.  I have used this approach on my bridgeport based cnc conversion via Mach 3 and AC servos.  

Thanks again for your help

Barry


Khalid Baheyeldin
 

On Wed, Jan 12, 2022 at 12:45 PM, smith_barry wrote:
The reason for asking is that unlike most conventional mounts the harmonic gearboxes do not have a worm for PEC rather they have an intrinsic pattern of speed variation due to physical aspects of the geartrain in my case a primary and secondary gearboxes on the alt axis. 
Looks like you are considering encoders in OnStep to adjust your tracking rate.
OnStep does not do that.

Until the mount is working and I can measure tracking and goto performance using the stars its all a bit academic but I want to get started with an option that at least gives some hope of correcting the issues that some have raised with mounts fitted with harmonic drives and for that I need to be able to collect data corresponding to the location of the alt axis as precisely as possible.  Accuracy would also be nice but for the moment repeatability would be a good first step.  
You need to first test out whether the motors would stall when slewing or not, because of your very high reduction ratio.
That is the bigger issue.
Once that works, you can use autoguiding, and be done with it.


smith_barry
 

There is some discussion of the use of encoders to optimise tracking rates in the Wiki under "control" Encoder Support - "Another encoder add-on option is tracking rate control for Eq mounts.  For this a high resolution encoder (exceeding arc-second accuracy and near arc-second resolution) on the RA axis is required.  The encoder tick rate is measured and this is used to adjust OnStep's tracking rate for the RA axis to compensate for gear PE/NPE etc.  There are several options to average encoder rate measurements and to visualize the encoder rate vs. OnStep's tracking rate.  Corrections to OnStep's tracking are issued as guide commands.  This is still an experimental feature at this point so feel free to try it out and report you results (as I will continue to do.)"

But as said I want to first walk and get using the mount.  The pictures below show the alt axis fitted with a DC servo/harmonic drive (RGH14) as I have retrofitted the CNC and Lathe over the years I have plenty of different options for stepper motor size from NEMA 17 to 42.  Sorry no scale, the main HMD unit is around 180mm diameter. Barry
 


Khalid Baheyeldin
 

The key part is:

"This is still an experimental feature at this point ..."


George Cushing
 

With 80:1 GR2 and a reasonable tracking resolution you are always going to be limited to a staid slew rate without a second drive system for slewing.

17777.77778 200 8 50 80

With 50:1 GR2 you still might be able to attain 2°/s.

This setup doesn't cost you much tracking resolution and lets you use stealth-chop.
17777.77778 200 16 25 80
 


John Petterson
 

Barry,

I am one of the few people that implemented encoders on my mounts.  I have a couple of Losmandy mounts with Astro Devices 311,296 step encoders.

I am driving them through a Teensy 4.0 that is also my wired Ethernet connection.  I originally was using a Teensy 3.2 for that internet and encoder interface, but had to make the 4.0 work because the 3.2 could not keep up with the pulses during a slew. I have some serious doubts if any of these processors will track properly with a 10 million tick encoder (about 30x as many pulses as I see) while also running either Wifi or Ethernet links.  Should not be an issue at tracking rates, but if you connect these be certain to test how your slews work carefully.  When I was using the Teensy 3.2 the OnStep would think it has moved about 1/2 as far as it actually moved.

John


smith_barry
 

Hi John, if the microcontroller is doing the quad decode then I agree with what you are seeing.  I am not sure how implementable it is but there are chips that do the quadrature and counting for you and then can download via the I2C bus which might be an alternative.  I have some chips from IC-Haus that allow up to 2048 interpolation of sin/cos encoders but its a good 5 years since I looked at them in respect of communication between the interpolator and microcontroller.  If you cut out the need for quad decode I would think you could just count single pulses on a pin?  OK this would lower the line count by four but you might be able to track a higher overall count rate?
Barry


John Petterson
 

Barry,

A little bit of background is probably valuable at this point.  I have not looked at the code that is servicing that interrupt for a while so it is possible this has some wrong information. If my memory is right the current code updates a second location pointer as the mount is moving, not simply counting pulses but rather recalculating the pointing location as pulses come in. This second encoder location pointer is accumulated on the microcontroller that is running the encoders and network and not directly available on the main processor so doing anything with it is a bit more complex than it looks at first glance.

At some interval depending on your settings it will compare that encoder location with the mount's position and update the mount's position with the encoders reported position if the difference is over a specified value.  (It also moves the data in the other direction when you do an alignment action, setting the encoder's reported position to the mount''s position.) I think it does not do that update during moves however (probably because the time required to move the data between processors makes it less accurate during the moves) but only during tracking, and the comparison value used to determine if it should be updated is generally too high to be valuable in correcting tracking. 

So based on that you may rethink your desire to even use the encoders.  I am happy to have them because I have a Losmandy AZ8 and can point the mount manually wherever I want very quickly and it will resume tracking correctly - not easy to do with an alt-az mount without those encoders.  It also has clutches that allow slippage unless you really lock them down so minor slips are correctable during slews (I simply hit the slew button again a second after it stops and the mount corrects to the right target.) 

If you decide to go forward with the encoders, given the discussion above I think I would be more inclined to try to use a divide by 8 or divide by 16 circuit on each of the two sides of the encoders, seed one of them with half of that number at startup to keep them close to evenly spaced, and feed that output back into the existing software rather than redesigning the whole thing to accumulate counters somewhere else and then try to figure out how to update the pointing position.

John