Topics

Backlash on Super Polaris with direct coupling of planetary gearbox?

Ivan Cohen
 

Hi all,

first I want to thank you all because I completed a MaxPCB that is working great! I upgraded my old Super Vixen from the 80s. It used to run from a SkySensor (the black version). Goto speed was 30x and 60x sidereal on RA and DEC respectively, which was painfully slow. Now using TMC5160 at 24V, motor 17HM19-1684S, I can see it turn ;-)

Now for the question: I'm using GT2 belt and pulleys (48 and 16 teeth). There is some backlash. Part comes from the motor holder 3D printed in PLA, and I'm still working to improve it. However because I heard there is an issue of backlash with the Super Polaris I am considering to remove belts and pulleys. I would connect the motor directly to the worm gear through a 5:1 or 10:1 precision planetary gearbox from ebay. I would use metal parts to attach the motors. Has anybody tried something like that?

Thx

Ivan

Khalid Baheyeldin
 

Usually, the gearboxes have more more backlash than pulleys would.
A pulley system with the correct shaft bore should have only negligible backlash.

When people convert mounts (or just buy a belt kit, such as Rowan's), they always go for pulleys to avoid gears, which inherently have backlash.

On the other hand several people use the planetary motors successfully with great results. Go to the Showcase page, and search for Markus CGE, and follow the links to see his magnificent images.

Maybe the backlash is in the worm gear/wheel? Remove the pulleys and check by hand and see if there is wiggle.

Rafael Barberá Córdoba
 

Maybe the backlash is in the worm gear/wheel? Remove the pulleys and check by hand and see if there is wiggle.
Yes, that the problem. At least with the EQ5 “flavor” of this mount. The backlash comes from the horizontal freedom on the worm axis and from the gap between this worm and the driving crown. But the pulleys and belts usually didn’t add noticeable backlash. 

Ivan Cohen
 

Thank you for your help!

I figured out one point is the 3D printed motor holder was wearing out. So I 3D printed with thicker walls etc and motion is better.

Now there is another very weird thing with the RA axis. RA goto is basically behaving in a very strange way. Goto is not going to the right coordinates when I look at the sky. So I tried to debug the problem home. I think the clearest evidence that something is wrong is that if I ask to go to current coordinates, then on the status page the coordinates instantly changed to some other distant value (for from current), RA axis turns, and reaches another unrelated value.

I use onstep 3.16. configuration is the same for RA and DEC. The mount is a Super Vixen. The hardware is a MaxPCB2 with two TMC5160, a clock DS3231 (and BME280).

Any idea how to proceed from there? I will try to turn ON microstepping for goto...

Khalid Baheyeldin
 

On Fri, Jul 31, 2020 at 10:15 AM, Ivan Cohen wrote:
I will try to turn ON microstepping for goto...
Since you use the MaxPCB, you don't need microstepping for goto. The microcontroller is fast enough to not need that.

As for the main problem, does the motor stop moving during the slew and make a high pitched noise?

Ivan Cohen
 

The motors turns fine. Actually they seemed to work ok at desired slew rate 5 and I decreased this value to 1 to be on the safe side. I also increased the acceleration distance from 5 to 8. Plus I performed the tests without the telescope and counterweights. All the same. Motors don't jam or make any strange noise.

I can't figure out why the display of the position suddenly jumps to different RA coordinates as soon as I launch the goto. And the target value is not what I had typed in!

Thx!!!

Khalid Baheyeldin
 

On Fri, Jul 31, 2020 at 12:19 PM, Ivan Cohen wrote:
I can't figure out why the display of the position suddenly jumps to different RA coordinates as soon as I launch the goto. And the target value is not what I had typed in!
I don't know ...

For me, when I want to be sure that the scope is pointing right, I connect it to a planetarium (SkyChart, KStars), or use one on my phone (KStars Lite is free). Then start a slew to a star in the east, and see if the mount actually points to the east, then do the same for a star in the west.

Ivan Cohen
 

That is what I tried last might. From the home position I tried to align on a star in Uma (not too far from polaris). the mount would tend to go in the right direction, but was way off when it completed goto. So I thought this is a mechanical problem. However today there is no load, DEC goto works fine. RA is wrong. Furthermore when I ask to return home it does! So I really suspect the problem has to do with software. I don't see what config settings could be wrong, or if i should try another version, or if there is any test I could run to help understand better.
Thx!!!

Khalid Baheyeldin
 

What you are saying leads me to guess that it is a mismatch between the actual gear numbers and what you have in the config.
If this is so, then the mount will return correctly to its home position.

For example, your calculation for steps per degree assumes 1/16 microstep but you are setting it to 1/8.
Or a miscalculation of gear ratios.

Ivan Cohen
 

I checked that multiple times in the excel file and config.h

144 teeth
48/16=3 pulley ratio
64 microsteps

what puzzles me is that even if had made a mistake there, the RA coordinate should not change suddenly after I initiate a goto. and the final RA coordinate should match the target, especially when I request a goto to the current position.

Maybe something I do wrong when using OnStep? Maybe some init I forgot? Or some issue with the code? I am familiar with the Arduino environment, so I don't expect I did something wrong, but that's always possible. My last astronomy was in the 80s with the first Sky Sensor, so maybe I missed something in all the new features provided by onstep?

Dave Schwartz
 

I think you are going to have to post an exact description of what is connected and a precise, step-by-step description of a minimal session that produces the problem for you so that someone can try to reproduce it.

On 2020-07-31 1:06 p.m., Ivan Cohen wrote:
I checked that multiple times in the excel file and config.h

144 teeth
48/16=3 pulley ratio
64 microsteps

what puzzles me is that even if had made a mistake there, the RA coordinate should not change suddenly after I initiate a goto. and the final RA coordinate should match the target, especially when I request a goto to the current position.

Maybe something I do wrong when using OnStep? Maybe some init I forgot? Or some issue with the code? I am familiar with the Arduino environment, so I don't expect I did something wrong, but that's always possible. My last astronomy was in the 80s with the first Sky Sensor, so maybe I missed something in all the new features provided by onstep?

Khalid Baheyeldin
 

On Fri, Jul 31, 2020 at 01:06 PM, Ivan Cohen wrote:
what puzzles me is that even if had made a mistake there, the RA coordinate should not change suddenly after I initiate a goto. and the final RA coordinate should match the target, especially when I request a goto to the current position.
I saw part of that: no updates for a while, then coordinates jump. It was when I was developing the HAL for the FYSETC S6, and I had the max rate set too low. OnStep would be overloaded and not able to provide a response to the client applications.
Setting the HAL max rate correctly solved this. This is not something a user should do, only OnStep developers when testing new hardware. So it is not the case here. And you have a MaxPCB which is as fast as it gets.

But I did not see the other part: wrong coordinates after reaching the destination.

Maybe something I do wrong when using OnStep? Maybe some init I forgot? Or some issue with the code? I am familiar with the Arduino environment, so I don't expect I did something wrong, but that's always possible. My last astronomy was in the 80s with the first Sky Sensor, so maybe I missed something in all the new features provided by onstep?
Are you using 3.16 or master? If master, then go back to 3.16 because it is stable.

Ivan Cohen
 

I use 3.16, connected with wifi. I use my android phone as hand control and a PC to monitor the status.

One thing I didn't understand on the web page is how to choose the align star. clicking on "1" or "accept" does not bring up any window or menu to select the star used for align. I made sure popup windows are allowed. What should it look like?

Thx!!!

Ivan Cohen
 

Thank you Dave, I will prepare that

Khalid Baheyeldin
 

If you are using an Android phone, then install the OnStep app, and then do the alignment from there.
It will give you a list of stars to choose from.

Rafael Barberá Córdoba
 

Around NPC the RA values could be misleading, because they jump around for few degrees around NPC. Don’t look at the RA to close to the NPC. Goto Vega and then form there to another nearby stars and look at the RA figures on this goto. They should be “normal”

Ivan Cohen
 

The hardware and config:

Ivan Cohen
 

The mount: 

Ivan Cohen
 

1/Turn on the MaxPCB2

2/Connect from android phone

3/"Home (Reset)"

4/Start tracking (Sidereal Rate)

5/Check coordinates (in my case RA 04h00m52s, DEC 89°59'06")



6/"Enter Coordinates", enter the current coordinates



7/Press OK. In this exemple I don't understand where the RA=11h31.9m come from



8/Press Goto. The DEC axis is stil, that's ok. The RA moves by almost 2h in this example.

Ivan Cohen
 

the images that did not go through: