Motors not reversing with Control in Sky Planetarium


Gerry Byrne
 

While bench testing using Sky Planetarium I cannot "nudge" my motors in reverse using the Control function (Connections/Control). They will simply continue in the same direction as in a slew or a tracking no matter what control command I use. This obviously will complicate centering objects being viewed. I have swapped wires around and managed to reverse the direction of turning of the motors both slewing and tracking but the problem persists: motors only turn the same way when "nudged".

I am having difficulties with GPS (have posted on this issue elsewhere). Could this be a part of the problem?
Gerry 

--
Copernicus


Gerry Byrne
 

I should add I am using FYSETC S6 V2 with LV8729 drivers.
Gerry

On Sat, 15 Jan 2022 at 10:42, Gerry Byrne via groups.io <byrnegerardf=gmail.com@groups.io> wrote:
While bench testing using Sky Planetarium I cannot "nudge" my motors in reverse using the Control function (Connections/Control). They will simply continue in the same direction as in a slew or a tracking no matter what control command I use. This obviously will complicate centering objects being viewed. I have swapped wires around and managed to reverse the direction of turning of the motors both slewing and tracking but the problem persists: motors only turn the same way when "nudged".

I am having difficulties with GPS (have posted on this issue elsewhere). Could this be a part of the problem?
Gerry 

--
Copernicus


--
Copernicus


Khalid Baheyeldin
 

Maybe there is backlash in your motors and/or gears?
If you reverse and there is backlash, then the motors will move, but you will not
see the star move in the eyepiece/camera.

See the Wiki on how to adjust the backlash.


Gerry Byrne
 

Khalid,
I can actually watch the motor sprocket turn and the gear wheel turns with it. I don't believe backlash is involved. I think there is something in the configuration settings, or in the motor itself. For example I have chosen go-to targets where, in the normal course of events, the motor would have to reverse to reach it but in every case the motor turns in the same direction. This is simple bench testing indoors so an eyepiece is not involved. But were I looking through an eyepiece, outdoors, I don't believe the object would appear but that it would be a good distance away.

I have spare LV8729 modules and I might swap them over if only to eliminate them from suspicion.
Gerry


On 15/01/2022 21:47, Khalid Baheyeldin wrote:
Maybe there is backlash in your motors and/or gears?
If you reverse and there is backlash, then the motors will move, but you will not
see the star move in the eyepiece/camera.

See the Wiki on how to adjust the backlash.


--
Copernicus


Mike Ahner
 

On Sat, Jan 15, 2022 at 05:44 PM, Gerry Byrne wrote:
the motor would have to reverse to reach it but in every case the motor turns in the same direction.
Hi Gerry,
I wonder if your DIR pin is toggling properly. It should change from HIGH to LOW or LOW to HIGH with each required direction change. I'm not familiar with FYSETC, but if you had to wire anything, I suggest checking your soldering, wire connections, etc. If you have a bad connection and the DIR pin never toggles, then the stepper driver will not change direction.

-Mike 


Gerry Byrne
 

Mike,
That's a very good point. However I'm using a FYSETC S6 V2 which requires very little soldering. At the same time I have been using a temporary bench  testing connection between the driver and the Axis 1 stepper motor. Could this be an issue, I wonder? I shall re-run the test, this time using the wiring harness, and the driver, for the second motor in its place.

Where does the DIR pin occur? Is it on the main processor? or the driver card (LV8729)? Perhaps I have incorrect, or faulty jumpering? I'll check through them one at a time.
Gerry


On 16/01/2022 02:27, Mike Ahner wrote:
On Sat, Jan 15, 2022 at 05:44 PM, Gerry Byrne wrote:
the motor would have to reverse to reach it but in every case the motor turns in the same direction.
Hi Gerry,
I wonder if your DIR pin is toggling properly. It should change from HIGH to LOW or LOW to HIGH with each required direction change. I'm not familiar with FYSETC, but if you had to wire anything, I suggest checking your soldering, wire connections, etc. If you have a bad connection and the DIR pin never toggles, then the stepper driver will not change direction.

-Mike 


--
Copernicus


kevin
 

I plugged a LV8729  driver in reversed once ( in a different board ) and afterwords when installed correctly it would only work in one direction. New one worked OK.

I don't have one of those boards but presumably you have the FYSETC pinmap loaded, anyone know if there are there any changes between board revisions required?


Gerry Byrne
 

1. I swapped the wiring for the two motors but both continued to  drive one direction only, no reversal possible either in slewing mode or using the control in an attempt to "nudge" the motors in a reverse direction. Both motors resolutely continued to turn anticlockwise only.
2. I swapped the LV8729 drivers for two spares but there was no change in behaviour. Both motors continued to only turn clockwise. The replacements spares had not been adjusted yet for VRef but, apart from getting very hot,  they appeared to act normally. I then put the original drivers back on the board.

It occurs to me that the following might be factors: I am giving the motors arbitrary instructions without setting Lat and Long or time and paying no heed to parking or unparking from home position. Could this be an issue?

Ideas?
Gerry







 

On 16/01/2022 09:36, Gerry Byrne via groups.io wrote:
Mike,
That's a very good point. However I'm using a FYSETC S6 V2 which requires very little soldering. At the same time I have been using a temporary bench  testing connection between the driver and the Axis 1 stepper motor. Could this be an issue, I wonder? I shall re-run the test, this time using the wiring harness, and the driver, for the second motor in its place.

Where does the DIR pin occur? Is it on the main processor? or the driver card (LV8729)? Perhaps I have incorrect, or faulty jumpering? I'll check through them one at a time.
Gerry


On 16/01/2022 02:27, Mike Ahner wrote:
On Sat, Jan 15, 2022 at 05:44 PM, Gerry Byrne wrote:
the motor would have to reverse to reach it but in every case the motor turns in the same direction.
Hi Gerry,
I wonder if your DIR pin is toggling properly. It should change from HIGH to LOW or LOW to HIGH with each required direction change. I'm not familiar with FYSETC, but if you had to wire anything, I suggest checking your soldering, wire connections, etc. If you have a bad connection and the DIR pin never toggles, then the stepper driver will not change direction.

-Mike 


--
Copernicus


--
Copernicus


Gerry Byrne
 

Kevin,
As you may see from my latest post I tried some spare LV8729s and it made no difference. But that doesn't rule out the probability I may have got duds!
Gerry



On 16/01/2022 11:04, kevin via groups.io wrote:
I plugged a LV8729  driver in reversed once ( in a different board ) and afterwords when installed correctly it would only work in one direction. New one worked OK.

I don't have one of those boards but presumably you have the FYSETC pinmap loaded, anyone know if there are there any changes between board revisions required?


--
Copernicus


Gerry Byrne
 
Edited

Here are my Axis Stepper Driver Config.h settings. Can they explain the fact that the motors will only turn in one direction?
Gerry


// AXIS1 RA/AZM
// see https://onstep.groups.io/g/main/wiki/6-Configuration#AXIS1
#define AXIS1_STEPS_PER_DEGREE 16955.5555 //  12800, n. Number of steps per degree:                                          <-Req'd
                                          //         n = (stepper_steps * micro_steps * overall_gear_reduction)/360.0
#define AXIS1_STEPS_PER_WORMROT    160000 //  12800, n. Number of steps per worm rotation (PEC Eq mode only:)                <-Req'd
                                          //         n = (AXIS1_STEPS_PER_DEGREE*360)/reduction_final_stage

#define AXIS1_DRIVER_MODEL         LV8729 //    OFF, (See above.) Stepper driver model.                                      <-Often
#define AXIS1_DRIVER_MICROSTEPS        16 //    OFF, n. Microstep mode when tracking.                                        <-Often
#define AXIS1_DRIVER_MICROSTEPS_GOTO  OFF //    OFF, n. Microstep mode used during gotos.                                     Option
#define AXIS1_DRIVER_IHOLD            OFF //    OFF, n, (mA.) Current during standstill. OFF uses IRUN/2.0                    Option
#define AXIS1_DRIVER_IRUN             OFF //    OFF, n, (mA.) Current during tracking, appropriate for stepper/driver/etc.    Option
#define AXIS1_DRIVER_IGOTO            OFF //    OFF, n, (mA.) Current during slews. OFF uses same as IRUN.                    Option
#define AXIS1_DRIVER_REVERSE          OFF //    OFF, ON Reverses movement direction, or reverse wiring instead to correct.   <-Often
#define AXIS1_DRIVER_STATUS           OFF //    OFF, TMC_SPI, HIGH, or LOW.  Polling for driver status info/fault detection.  Option

#define AXIS1_LIMIT_UNDER_POLE        180 //    180, n. Where n=150..180 (degrees.) Max HA hour angle + or - for Eq modes.    Infreq
#define AXIS1_LIMIT_MAXAZM            360 //    360, n. Where n=180..360 (degrees.) Max Azimuth + or - for AltAzm mode only.  Infreq

// AXIS2 DEC/ALT
// see https://onstep.groups.io/g/main/wiki/6-Configuration#AXIS2
#define AXIS2_STEPS_PER_DEGREE 16955.5555 //  12800, n. Number of steps per degree:                                          <-Req'd
                                          //         n = (stepper_steps * micro_steps * overall_gear_reduction)/360.0

#define AXIS2_DRIVER_MODEL         LV8729 //    OFF, (See above.) Stepper driver model.                                      <-Often
#define AXIS2_DRIVER_MICROSTEPS        16 //    OFF, n. Microstep mode when tracking.                                        <-Often
#define AXIS2_DRIVER_MICROSTEPS_GOTO  OFF //    OFF, n. Microstep mode used during gotos.                                     Option
#define AXIS2_DRIVER_IHOLD            OFF //    OFF, n, (mA.) Current during standstill. OFF uses IRUN/2.0                    Option
#define AXIS2_DRIVER_IRUN             OFF //    OFF, n, (mA.) Current during tracking, appropriate for stepper/driver/etc.    Option
#define AXIS2_DRIVER_IGOTO            OFF //    OFF, n, (mA.) Current during slews. OFF uses same as IRUN.                    Option
#define AXIS2_DRIVER_POWER_DOWN       OFF //    OFF, ON Powers off 10sec after movement stops or 10min after last<=1x guide.  Option
#define AXIS2_DRIVER_REVERSE          OFF //    OFF, ON Reverses movement direction, or reverse wiring instead to correct.   <-Often
#define AXIS2_DRIVER_STATUS           OFF //    OFF, TMC_SPI, HIGH, or LOW.  Polling for driver status info/fault detection.  Option
#define AXIS2_TANGENT_ARM             OFF //    OFF, ON +limit range below. Set cntr w/[Reset Home] Return cntr w/[Find Home] Infreq

#define AXIS2_LIMIT_MIN               -91 //    -91, n. Where n=-91..0 (degrees.) Minimum allowed declination.                Infreq
#define AXIS2_LIMIT_MAX                91 //     91, n. Where n=0..91 (degrees.) Maximum allowed declination.                 Infreq


On 16/01/2022 12:09, Gerry Byrne via groups.io wrote:
Kevin,
As you may see from my latest post I tried some spare LV8729s and it made no difference. But that doesn't rule out the probability I may have got duds!
Gerry



On 16/01/2022 11:04, kevin via groups.io wrote:
I plugged a LV8729  driver in reversed once ( in a different board ) and afterwords when installed correctly it would only work in one direction. New one worked OK.

I don't have one of those boards but presumably you have the FYSETC pinmap loaded, anyone know if there are there any changes between board revisions required?


--
Copernicus


--
Copernicus


Howard Dutton
 

On Sun, Jan 16, 2022 at 04:05 AM, Gerry Byrne wrote:
It occurs to me that the following might be factors: I am giving the motors arbitrary instructions without setting Lat and Long or time
Its a good idea to do this.

and paying no heed to parking or unparking from home position.
Parking functionality is separate from home/homing (the default startup position,) generally its best to ignore parking until/unless you need it.

Could this be an issue?
I seriously doubt it.


Howard Dutton
 

On Sun, Jan 16, 2022 at 04:37 AM, Gerry Byrne wrote:
Here are my Axis Stepper Driver Config.h settings. Can they explain the fact that the motors will only turn in one direction?
There are no settings in Config.h that'd cause what you are describing.


Howard Dutton
 

Could check the DIR pins on the drivers to see if they go from 0V to 3.3V as they should when you change directions.  Just be super careful to only touch the yellow pins with the volt meter probe.


kevin
 

Is that photo Gerry's ?, the jumpers are set to SPI mode


John Petterson
 

Let's identify where the problem is.  Try downloading a different planetarium program and use that instead.  Cartes du Ciel is one option for PC, there are others.

Do the motors run in correct/both directions when you have it slew to a location?  From one of you comments it appears they do not.  I suspect your cables, I had a similar issue but these tests below can help confirm that.

Assuming that you have verified the jumpers on the FYSETC are set correctly (see Kevin's comment):

What is the overall configuration?  Do you have a Wifi or network add on?  Using the Android App or the web interface can be helpful if either are available.

If you set

     #define AXIS1_DRIVER_REVERSE          ON

     #define AXIS2_DRIVER_REVERSE          ON

 

and then reload the software, does the direction change?  If not, then it is probably the cables - hard to point to driver cards if 4 of them are behaving the same.

And remember that movements around the pole can be confusing for a GEM.  See question 2 in the FAQ.

You can also send movement commands directly to the OnStep via the USB using the Arduino serial monitor (I think, someone will correct this if I am remembering incorrectly).  See the command protocol page of the Wiki.

John


Gerry Byrne
 

I wonder if my Jumper settings for the motor drivers are correct? Here is a photo of my settings for the two LV8729 drivers on Axis 1 and Axis 2.
Gerry

--
Copernicus


Gerry Byrne
 

Some good ideas there John. I've separately posted my Jumper settings. I'll start with the Serial Monitor commands, then substitute another program before moving on to the other tests.Gerry

On 16/01/2022 19:17, John Petterson wrote:

Let's identify where the problem is.  Try downloading a different planetarium program and use that instead.  Cartes du Ciel is one option for PC, there are others.

Do the motors run in correct/both directions when you have it slew to a location?  From one of you comments it appears they do not.  I suspect your cables, I had a similar issue but these tests below can help confirm that.

Assuming that you have verified the jumpers on the FYSETC are set correctly (see Kevin's comment):

What is the overall configuration?  Do you have a Wifi or network add on?  Using the Android App or the web interface can be helpful if either are available.

If you set

     #define AXIS1_DRIVER_REVERSE          ON

     #define AXIS2_DRIVER_REVERSE          ON

 

and then reload the software, does the direction change?  If not, then it is probably the cables - hard to point to driver cards if 4 of them are behaving the same.

And remember that movements around the pole can be confusing for a GEM.  See question 2 in the FAQ.

You can also send movement commands directly to the OnStep via the USB using the Arduino serial monitor (I think, someone will correct this if I am remembering incorrectly).  See the command protocol page of the Wiki.

John



--
Copernicus


Gerry Byrne
 

Howard,
Yes, I'm getting a voltage change when I select a change of direction in the control box for Axis 1. It goes from 3.3 to 0 and back again when I press W, then E. But the motor does not change direction. I have not performed this test for Axis 2 but I imagine the results will be similar.
Gerry



On 16/01/2022 13:19, Howard Dutton wrote:
Could check the DIR pins on the drivers to see if they go from 0V to 3.3V as they should when you change directions.  Just be super careful to only touch the yellow pins with the volt meter probe.



--
Copernicus


kevin
 

Is the voltage change measured with the driver board plugged in, and is it on the driver pin or underneath on the main pcb, maybe a dry solder joint somewhere if it affects all drivers?


Gerry Byrne
 

The board is plugged in and powered (It was actually set to tracking). The probes are touching the driver side pins, not the PCB beneath.
Gerry

On 17/01/2022 20:28, kevin via groups.io wrote:
Is the voltage change measured with the driver board plugged in, and is it on the driver pin or underneath on the main pcb, maybe a dry solder joint somewhere if it affects all drivers?


--
Copernicus