.zero() does not seem to "reset" the motor on X27s

[timkettering]

Ive been experimenting with your library and a X27 motor. And it seems like the results of zero() are unpredictable. The motor can come to a "zero" at various places. I have looked at the code for zero() and it just seems to unwind all existing steps, but I dont see how it determines whether the motor has actually run into the mechanical stop.

I'm hoping you can give some clarification how this should work. Cheers!

[guyc]

zero() is the reset/calibration function; it turns the motor backwards enough steps to ensure the motor is against the lower stop. It makes no assumptions about starting position and has no way to know if the motor has hit the stop, so it just steps enough to hit the stop from any position. It's okay to step against the stop when you overshoot - it causes a bit of clicking but no damage.

If you are getting unpredictable results here are some potential causes: you could have a slipping needle, a needle that is too heavy (or more correctly requires too much torque to turn), insufficient coil voltage, or too little delay between steps (the default interval is pretty safe, so it should be okay). There are stop-less versions of the motor too, which will never hit a stop and will just spin a full 360 degrees. Those are pretty uncommon and need an external sensor to detect zero.

[guyc]

zero() is the reset/calibration function; it turns the motor backwards enough steps to ensure the motor is against the lower stop. It makes no assumptions about starting position and has no way to know if the motor has hit the stop, so it just steps enough to hit the stop from any position. It's okay to step against the stop when you overshoot - it causes a bit of clicking but no damage.

If you are getting unpredictable results here are some potential causes: you could have a slipping needle, a needle that is too heavy (or more correctly requires too much torque to turn), insufficient coil voltage, or too little delay between steps (the default interval is pretty safe, so it should be okay). There are stop-less versions of the motor too, which will never hit a stop and will just spin a full 360 degrees. Those are pretty uncommon and need an external sensor to detect zero.

[timkettering]

hi, thanks for the quick response. i've been playing around w/ the source since the original post. i have a x27 switec with a 3d printed plastic needle that is pretty firmly attached (and which hardly weighs anything), and using the code supplied in the library along with the example that is provided (switecx25example). i have not modified any defaults in the code other than adding a 1 second delay between zero() and the 1/2-way position in the example code, to better distinguish between the two phases.

what i do is upload this code to the arduino, then hit the "reset" button to run the program over and over. so the results should be repeatable w/ same results over and over.

usually it moves back, hits the stop and then moves 1/2 way around (as the example code should). but at a few occasions, it will just shake a bit in place and not go anywhere. at other times, it will move and seemingly bounce off the stop, coming to a stop at a different place, then that new place becomes the "zero" for all future resets until this occurs again.

i can't rule out that theres damage to the switec. i only have one unit with me right now, but i have six more coming in. i will try to rule out the damage, but it seems to work okay other than the odd behavior with zero().

just to ensure, the arduino 5V output should be adequate to drive the motor (just one motor, no other things are being operated). correct?

[timkettering]

hi, thanks for the quick response. i've been playing around w/ the source since the original post. i have a x27 switec with a 3d printed plastic needle that is pretty firmly attached (and which hardly weighs anything), and using the code supplied in the library along with the example that is provided (switecx25example). i have not modified any defaults in the code other than adding a 1 second delay between zero() and the 1/2-way position in the example code, to better distinguish between the two phases.

what i do is upload this code to the arduino, then hit the "reset" button to run the program over and over. so the results should be repeatable w/ same results over and over.

usually it moves back, hits the stop and then moves 1/2 way around (as the example code should). but at a few occasions, it will just shake a bit in place and not go anywhere. at other times, it will move and seemingly bounce off the stop, coming to a stop at a different place, then that new place becomes the "zero" for all future resets until this occurs again.

i can't rule out that theres damage to the switec. i only have one unit with me right now, but i have six more coming in. i will try to rule out the damage, but it seems to work okay other than the odd behavior with zero().

just to ensure, the arduino 5V output should be adequate to drive the motor (just one motor, no other things are being operated). correct?

[guyc]

It sounds like some steps are being missed intermittently. In my experience this means either under-voltage or exceeding maximum step frequency. I would start by checking the voltage at the output of your IO lines with a multimeter, since it's simple. Even if you think it should be okay, it pays to check it. I've wasted a lot of time checking everything else because I was sure the voltage was okay when it wasn't. One possible cause is driving the Arduino with a 5V external supply instead of say 12V. The regulator knocks the voltage down enough to cause problems. Also check your connections to the 4 motor pins are nice and tight if you are using slip-on connectors.

The step period during the reset is defined by this constant.
#define RESET_STEP_MICROSEC 800
Try cranking that way up; maybe double it and the motor should rotate half as fast during reset. See if that eliminates the intermittent failure. If it does it tells you something - but honestly that reset rate should be nowhere near the limits of the motor.

I'm always interested to see how these issues resolve so I can better understand the causes of failure, so please do keep me posted. This code is being used by lots of people so I'm pretty confident the issue is not the library.

[guyc]

It sounds like some steps are being missed intermittently. In my experience this means either under-voltage or exceeding maximum step frequency. I would start by checking the voltage at the output of your IO lines with a multimeter, since it's simple. Even if you think it should be okay, it pays to check it. I've wasted a lot of time checking everything else because I was sure the voltage was okay when it wasn't. One possible cause is driving the Arduino with a 5V external supply instead of say 12V. The regulator knocks the voltage down enough to cause problems. Also check your connections to the 4 motor pins are nice and tight if you are using slip-on connectors.

The step period during the reset is defined by this constant.
#define RESET_STEP_MICROSEC 800
Try cranking that way up; maybe double it and the motor should rotate half as fast during reset. See if that eliminates the intermittent failure. If it does it tells you something - but honestly that reset rate should be nowhere near the limits of the motor.

I'm always interested to see how these issues resolve so I can better understand the causes of failure, so please do keep me posted. This code is being used by lots of people so I'm pretty confident the issue is not the library.

[timkettering]

thank you for your comments. i agree with you that odds are far more likely that its an issue w/ my motor or setup, but i wanted to make sure i understood the expected behavior of the library and the stepper motor itself before i went looking for an issue that may not be an issue.

i will verify this with another motor as soon as i get them - and we will know whether there is something worth pursuing or not.

thank you again!

[timkettering]

thank you for your comments. i agree with you that odds are far more likely that its an issue w/ my motor or setup, but i wanted to make sure i understood the expected behavior of the library and the stepper motor itself before i went looking for an issue that may not be an issue.

i will verify this with another motor as soon as i get them - and we will know whether there is something worth pursuing or not.

thank you again!

[timkettering]

its me again. i received six new X27 motors in the mail today. (just for reference, i am using them on the x25 breakout board that was devised by therengineer.com).

I reset all the x25 code back to the version found on this github repo and plugged in the arduino.

i tried your suggestion and increased the step period during the reset, from 800 to 2800 and ran the x25 example code, the needle moved much slower during the reset. (and it did not seem to go to the full left stop, but just to the full right stop before moving back to the center). but when entering needle positions in the serial monitor, it moved accurately to all the places. so it seems that zero() is functioning (if the lack of full left stop is indeed correct).

so it would seem there is a voltage issue, but what i find odd is that the needle moves much quicker during serial monitor inputs and has no trouble there hitting all the expected places. but during the zero(), it needs to move a lot slower??

hopefully you can give some insight.

[timkettering]

its me again. i received six new X27 motors in the mail today. (just for reference, i am using them on the x25 breakout board that was devised by therengineer.com).

I reset all the x25 code back to the version found on this github repo and plugged in the arduino.

i tried your suggestion and increased the step period during the reset, from 800 to 2800 and ran the x25 example code, the needle moved much slower during the reset. (and it did not seem to go to the full left stop, but just to the full right stop before moving back to the center). but when entering needle positions in the serial monitor, it moved accurately to all the places. so it seems that zero() is functioning (if the lack of full left stop is indeed correct).

so it would seem there is a voltage issue, but what i find odd is that the needle moves much quicker during serial monitor inputs and has no trouble there hitting all the expected places. but during the zero(), it needs to move a lot slower??

hopefully you can give some insight.

[guyc]

Very interesting...

Before I launch into code stuff, one thing we haven't
discussed I think is the needle position. The internal stops determine
the range of motion of the motor, but don't put any conditions
on the position of the actual needle. If you have a gauge that
spans 315 degrees, it is up to you to get the needle oriented
on the axle so that the needle lines up with the sweep of your
gauge. It occurred to me that when you say the needle doesn't
go to the full left stop, you may be making the assumption that
the needle itself is already aligned in a meaningful way.
When you call zero() the motor should run
backwards until it hits its stop - the direction of the needle
at that point is entirely dependent upon how you have placed
the needle on the axle. To get the placement right, I zero the motor, then
gently rotate the needle on the axle into the position it should be in at
zero.
That may be obvious, or not, but I want to cover all bases.

So moving on, assuming that there was no confusion about the
needle orientation, it sounds like the zero function isn't working,
but the setPosition/update code is. That is possible I guess,
since they use quite different logic.
The logic in the zero function is really dumb - it just steps backwards at
a fixed
time interval as many steps as you have specified for the motor - usually
945 steps.
Conversely, setPosition/update use an acceleration table to shift from slow
steps to faster steps once the needle is moving. It starts out at 3000mS
and
moves up to 600mS per step pretty quickly.

Since setPosition/update seems to work,
I think you could try using the following code to
improvise a replacement for the zero() function:

motor1.currentStep = motor1.steps-1; // tell the motor that it is at

full-scale deflection
motor1.setPosition(0); // tell the motor to return
to the zero position
while (motor1.currentStep>0) motor1.update(); // call update until it
returns to zero

That should force the motor against the lower stop, and reset the
currentStep
to 0 which is what zero does, except this will walk the motor up
to speed more slowly, maybe useful if you have voltage issues.
So just replace the call to motor1.zero() with
the 3 lines above. If it works, we have a really
good indication of what is happening.

To be clear, here's what the expected behaviour is, assuming
you are running the sample code from
https://github.com/clearwater/SwitecX25/blob/master/examples/X25SerialControl/X25SerialControl.ino

1. the motor should run backwards and hit the lower stop.
   You can tell it hit the stop by the clicking sound, and by the sudden
   end of rotation, but NOT necessarily by the needle position, unless
   you have already manually oriented your needle.
2. the motor should run forward to the center of the range.
   Again the needle itself may not be a good indication
   unless you have already aligned it.

Hope that moves things forward.

Cheers,
Guy

On Tue, Dec 31, 2013 at 12:46 PM, Tim Kettering notifications@github.comwrote:

its me again. i received six new X27 motors in the mail today. (just for
reference, i am using them on the x25 breakout board that was devised by
therengineer.com).

I reset all the x25 code back to the version found on this github repo and
plugged in the arduino.

i tried your suggestion and increased the step period during the reset,
from 800 to 2800 and ran the x25 example code, the needle moved much slower
during the reset. (and it did not seem to go to the full left stop, but
just to the full right stop before moving back to the center). but when
entering needle positions in the serial monitor, it moved accurately to all
the places. so it seems that zero() is functioning (if the lack of full
left stop is indeed correct).

so it would seem there is a voltage issue, but what i find odd is that the
needle moves much quicker during serial monitor inputs and has no trouble
there hitting all the expected places. but during the zero(), it needs to
move a lot slower??

hopefully you can give some insight.

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31381397
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[guyc]

Very interesting...

Before I launch into code stuff, one thing we haven't
discussed I think is the needle position. The internal stops determine
the range of motion of the motor, but don't put any conditions
on the position of the actual needle. If you have a gauge that
spans 315 degrees, it is up to you to get the needle oriented
on the axle so that the needle lines up with the sweep of your
gauge. It occurred to me that when you say the needle doesn't
go to the full left stop, you may be making the assumption that
the needle itself is already aligned in a meaningful way.
When you call zero() the motor should run
backwards until it hits its stop - the direction of the needle
at that point is entirely dependent upon how you have placed
the needle on the axle. To get the placement right, I zero the motor, then
gently rotate the needle on the axle into the position it should be in at
zero.
That may be obvious, or not, but I want to cover all bases.

So moving on, assuming that there was no confusion about the
needle orientation, it sounds like the zero function isn't working,
but the setPosition/update code is. That is possible I guess,
since they use quite different logic.
The logic in the zero function is really dumb - it just steps backwards at
a fixed
time interval as many steps as you have specified for the motor - usually
945 steps.
Conversely, setPosition/update use an acceleration table to shift from slow
steps to faster steps once the needle is moving. It starts out at 3000mS
and
moves up to 600mS per step pretty quickly.

Since setPosition/update seems to work,
I think you could try using the following code to
improvise a replacement for the zero() function:

motor1.currentStep = motor1.steps-1; // tell the motor that it is at

full-scale deflection
motor1.setPosition(0); // tell the motor to return
to the zero position
while (motor1.currentStep>0) motor1.update(); // call update until it
returns to zero

That should force the motor against the lower stop, and reset the
currentStep
to 0 which is what zero does, except this will walk the motor up
to speed more slowly, maybe useful if you have voltage issues.
So just replace the call to motor1.zero() with
the 3 lines above. If it works, we have a really
good indication of what is happening.

To be clear, here's what the expected behaviour is, assuming
you are running the sample code from
https://github.com/clearwater/SwitecX25/blob/master/examples/X25SerialControl/X25SerialControl.ino

1. the motor should run backwards and hit the lower stop.
   You can tell it hit the stop by the clicking sound, and by the sudden
   end of rotation, but NOT necessarily by the needle position, unless
   you have already manually oriented your needle.
2. the motor should run forward to the center of the range.
   Again the needle itself may not be a good indication
   unless you have already aligned it.

Hope that moves things forward.

Cheers,
Guy

On Tue, Dec 31, 2013 at 12:46 PM, Tim Kettering notifications@github.comwrote:

its me again. i received six new X27 motors in the mail today. (just for
reference, i am using them on the x25 breakout board that was devised by
therengineer.com).

I reset all the x25 code back to the version found on this github repo and
plugged in the arduino.

i tried your suggestion and increased the step period during the reset,
from 800 to 2800 and ran the x25 example code, the needle moved much slower
during the reset. (and it did not seem to go to the full left stop, but
just to the full right stop before moving back to the center). but when
entering needle positions in the serial monitor, it moved accurately to all
the places. so it seems that zero() is functioning (if the lack of full
left stop is indeed correct).

so it would seem there is a voltage issue, but what i find odd is that the
needle moves much quicker during serial monitor inputs and has no trouble
there hitting all the expected places. but during the zero(), it needs to
move a lot slower??

hopefully you can give some insight.

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31381397
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[timkettering]

i am driving the motor off the Arduino Nano (and using the 5V output). it seems that a value less than 1500 for RESET_STEP_MICROSEC will lead to inconsistent zero results.

[timkettering]

i am driving the motor off the Arduino Nano (and using the 5V output). it seems that a value less than 1500 for RESET_STEP_MICROSEC will lead to inconsistent zero results.

[timkettering]

regarding setting the needle position. when i have the motor unpowered, the needle is free to move (since the motors are disengaged, or whatever it is they're doing inside the case). i can move the needle around and feel where it hits the stops.

i marked on paper just below the motor the low and high stops. so i can see where the needle should be stopping. i hope that answers your question above.

i also ran the code replacement you suggested, and it (visually) moved in the same manner as the zero() function, but a lot faster.

[timkettering]

regarding setting the needle position. when i have the motor unpowered, the needle is free to move (since the motors are disengaged, or whatever it is they're doing inside the case). i can move the needle around and feel where it hits the stops.

i marked on paper just below the motor the low and high stops. so i can see where the needle should be stopping. i hope that answers your question above.

i also ran the code replacement you suggested, and it (visually) moved in the same manner as the zero() function, but a lot faster.

[guyc]

Just re-read this thread to try to get insight as I think I'm missing
something.
You wrote:

(and it did not seem to go to the full left stop, but just to the full
right stop before moving back to the center).
I think this is the key.

The reset code in the sample code here:

https://github.com/clearwater/SwitecX25/blob/master/examples/X25SerialControl/X25SerialControl.ino
and also the code in the README here:
https://github.com/clearwater/SwitecX25
do NOT run against the full right stop at all.

The fact that you are seeing it go to the full right stop then center
suggests maybe you have the polarity reversed on your motor connections
(which makes it run in reverse). Try swapping motor pins 1 and 4 which are
the white and
red wires in this picture:
http://guy.carpenter.id.au/gaugette/resources/2012-04-04/imgp9232.jpg

On Tue, Dec 31, 2013 at 2:09 PM, Tim Kettering notifications@github.comwrote:

regarding setting the needle position. when i have the motor unpowered,
the needle is free to move (since the motors are disengaged, or whatever it
is they're doing inside the case). i can move the needle around and feel
where it hits the stops.

i marked on paper just below the motor the low and high stops. so i can
see where the needle should be stopping. i hope that answers your question
above.

i also ran the code replacement you suggested, and it (visually) moved in
the same manner as the zero() function, but a lot faster.

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31383181
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[guyc]

Just re-read this thread to try to get insight as I think I'm missing
something.
You wrote:

(and it did not seem to go to the full left stop, but just to the full
right stop before moving back to the center).
I think this is the key.

The reset code in the sample code here:

https://github.com/clearwater/SwitecX25/blob/master/examples/X25SerialControl/X25SerialControl.ino
and also the code in the README here:
https://github.com/clearwater/SwitecX25
do NOT run against the full right stop at all.

The fact that you are seeing it go to the full right stop then center
suggests maybe you have the polarity reversed on your motor connections
(which makes it run in reverse). Try swapping motor pins 1 and 4 which are
the white and
red wires in this picture:
http://guy.carpenter.id.au/gaugette/resources/2012-04-04/imgp9232.jpg

On Tue, Dec 31, 2013 at 2:09 PM, Tim Kettering notifications@github.comwrote:

regarding setting the needle position. when i have the motor unpowered,
the needle is free to move (since the motors are disengaged, or whatever it
is they're doing inside the case). i can move the needle around and feel
where it hits the stops.

i marked on paper just below the motor the low and high stops. so i can
see where the needle should be stopping. i hope that answers your question
above.

i also ran the code replacement you suggested, and it (visually) moved in
the same manner as the zero() function, but a lot faster.

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31383181
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[timkettering]

hey! yeah that was correct. the wires were swapped and now the motor runs against the left stop. i also reverted back to using the motor.zero() code and the value back to 800.. and it seems to work fine now... i will test this out further and hopefully that will be the end of the issue here.

thanks so much for your help! i am working on developing a digital conversion for an analog tachometer i have on my 1971 Honda motorcycle. And this is a pretty critical part, haha!

:)

[timkettering]

hey! yeah that was correct. the wires were swapped and now the motor runs against the left stop. i also reverted back to using the motor.zero() code and the value back to 800.. and it seems to work fine now... i will test this out further and hopefully that will be the end of the issue here.

thanks so much for your help! i am working on developing a digital conversion for an analog tachometer i have on my 1971 Honda motorcycle. And this is a pretty critical part, haha!

:)

[guyc]

Very awesome project! Is it a CB?
I gather have become quite the venerable (and valuable) classics.

On Tue, Dec 31, 2013 at 3:41 PM, Tim Kettering notifications@github.comwrote:

hey! yeah that was correct. the wires were swapped and now the motor runs
against the left stop. i also reverted back to using the motor.zero() code
and the value back to 800.. and it seems to work fine now... i will test
this out further and hopefully that will be the end of the issue here.

thanks so much for your help! i am working on developing a digital
conversion for an analog tachometer i have on my 1971 Honda motorcycle. And
this is a pretty critical part, haha!

:)

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31384790
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[guyc]

Very awesome project! Is it a CB?
I gather have become quite the venerable (and valuable) classics.

On Tue, Dec 31, 2013 at 3:41 PM, Tim Kettering notifications@github.comwrote:

hey! yeah that was correct. the wires were swapped and now the motor runs
against the left stop. i also reverted back to using the motor.zero() code
and the value back to 800.. and it seems to work fine now... i will test
this out further and hopefully that will be the end of the issue here.

thanks so much for your help! i am working on developing a digital
conversion for an analog tachometer i have on my 1971 Honda motorcycle. And
this is a pretty critical part, haha!

:)

—
Reply to this email directly or view it on GitHubhttps://github.com/clearwater/SwitecX25/issues/4#issuecomment-31384790
.

Guy Carpenter
Clearwater Software, Australia
Tel: 0409 637 109

[timkettering]

yes, its a Honda 1971 Honda CB350. All of the CBs are classics, but some of the CBs, especially the larger 550 and 750s are very highly desirable and have premium prices... the CB350 was made in far larger numbers and are more readily accessible for a reasonable price. :)

[timkettering]

yes, its a Honda 1971 Honda CB350. All of the CBs are classics, but some of the CBs, especially the larger 550 and 750s are very highly desirable and have premium prices... the CB350 was made in far larger numbers and are more readily accessible for a reasonable price. :)

[timkettering]

Last night I got all the wiring in place and the code all sorted out, the new motor works perfectly and there are no issues w/ the code! I'll close this out as a "working as intended" 👍

[timkettering]

Last night I got all the wiring in place and the code all sorted out, the new motor works perfectly and there are no issues w/ the code! I'll close this out as a "working as intended" 👍

[timkettering]

Hi! Its me again. I actually have something to add to this issue.

[timkettering]

Hi! Its me again. I actually have something to add to this issue.

[timkettering]

Given your useful feedback, and initial testing done right when I closed out this issue, it seemed resolved, but now that my prototype has moved into more exhaustive testing and refinement, I am again encountering issues with inconsistent zero-ing results.

I have been experimenting with calling zero() repeatedly and approximately 80% of the time when I call zero(), it will correctly position the needle at zero. But the remaining 20% of the time it leaves the needle in an unacceptable position and often will require resetting the device again until it correctly zeros again.

I went back and tried increasing the RESET_STEP_MICROSEC value to something greater and at a point above 1600, it will correctly zero() without any trouble.

But what's interesting is that going from 800 to a slightly higher value, like say, 1000, actually leads to even worse results. A value of 1000 pretty much means it never will zero correctly. it just sweeps back to zero stop, stops somewhere in the middle. So to me it seems to suggest that there is some other factor in play here and not just simply a matter of increasing the microsec value == increased reliablity of the zero()

[timkettering]

Given your useful feedback, and initial testing done right when I closed out this issue, it seemed resolved, but now that my prototype has moved into more exhaustive testing and refinement, I am again encountering issues with inconsistent zero-ing results.

I have been experimenting with calling zero() repeatedly and approximately 80% of the time when I call zero(), it will correctly position the needle at zero. But the remaining 20% of the time it leaves the needle in an unacceptable position and often will require resetting the device again until it correctly zeros again.

I went back and tried increasing the RESET_STEP_MICROSEC value to something greater and at a point above 1600, it will correctly zero() without any trouble.

But what's interesting is that going from 800 to a slightly higher value, like say, 1000, actually leads to even worse results. A value of 1000 pretty much means it never will zero correctly. it just sweeps back to zero stop, stops somewhere in the middle. So to me it seems to suggest that there is some other factor in play here and not just simply a matter of increasing the microsec value == increased reliablity of the zero()

[timkettering]

Running off a 5V arduino (Nano) - the only way I can get consistent zero() results is to slow RESET_STEP_MICROSEC to a value of around 2000. I will just move ahead with this value in place for now.

[timkettering]

Running off a 5V arduino (Nano) - the only way I can get consistent zero() results is to slow RESET_STEP_MICROSEC to a value of around 2000. I will just move ahead with this value in place for now.

[guyc]

Have you done any tests to see if the needle positioning is reliable? I would write some code to move forward and backwards between two points and make sure it continues to position accurately. The problems you are experiencing are unusual, so I'd be worried there is something fundamentally wrong. One possibility is that your needle requires high torque to turn which would be the case if it is either very long or heavy. You could test that by replacing the needle with a piece of tape which has virtually no torque and see if your results change. If your zeroing problems are due to high torque, my suggestion would be to use the acceleration code for zeroing. In fact that should probably be the default - I'll keep that in mind when I next update the library.

[guyc]

Have you done any tests to see if the needle positioning is reliable? I would write some code to move forward and backwards between two points and make sure it continues to position accurately. The problems you are experiencing are unusual, so I'd be worried there is something fundamentally wrong. One possibility is that your needle requires high torque to turn which would be the case if it is either very long or heavy. You could test that by replacing the needle with a piece of tape which has virtually no torque and see if your results change. If your zeroing problems are due to high torque, my suggestion would be to use the acceleration code for zeroing. In fact that should probably be the default - I'll keep that in mind when I next update the library.

[timkettering]

Hi - thanks for the input. I am using this in a project where I am converting an analog tachometer to a digital input.

I have tested on three different X27 motors (with similiar results). I have written a test library that simulates the tach input and you can see the video I made of it here (https://www.youtube.com/watch?v=DMgwbGH8ITU). I have left this test cycle running for over 8 hours and the needle position is accurate even after the extended test. The needle is a lightweight aluminum pointer.. It has virtually no weight (when I hold it).

Your comment regarding the acceleration code is also what I am starting to lean towards. The only issues I am encountering is when I use the zero() function. If the motor zero()s correctly, then the test cycle can run for hours and the needle positioning is accurate all through.

It is my suspicion that the immediate acceleration and deacceleration of the zero() routine that causes problems. By sloping up the acceleration and deacceleration, it may be less disruptive.

[timkettering]

Hi - thanks for the input. I am using this in a project where I am converting an analog tachometer to a digital input.

I have tested on three different X27 motors (with similiar results). I have written a test library that simulates the tach input and you can see the video I made of it here (https://www.youtube.com/watch?v=DMgwbGH8ITU). I have left this test cycle running for over 8 hours and the needle position is accurate even after the extended test. The needle is a lightweight aluminum pointer.. It has virtually no weight (when I hold it).

Your comment regarding the acceleration code is also what I am starting to lean towards. The only issues I am encountering is when I use the zero() function. If the motor zero()s correctly, then the test cycle can run for hours and the needle positioning is accurate all through.

It is my suspicion that the immediate acceleration and deacceleration of the zero() routine that causes problems. By sloping up the acceleration and deacceleration, it may be less disruptive.