New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.zero() does not seem to "reset" the motor on X27s #4
Comments
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. |
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? |
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. 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. |
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! |
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. |
Very interesting... Before I launch into code stuff, one thing we haven't So moving on, assuming that there was no confusion about the Since setPosition/update seems to work, motor1.currentStep = motor1.steps-1; // tell the motor that it is at
That should force the motor against the lower stop, and reset the To be clear, here's what the expected behaviour is, assuming
Hope that moves things forward. Cheers, On Tue, Dec 31, 2013 at 12:46 PM, Tim Kettering notifications@github.comwrote:
Guy Carpenter |
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. |
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. |
Just re-read this thread to try to get insight as I think I'm missing
The reset code in the sample code here: https://github.com/clearwater/SwitecX25/blob/master/examples/X25SerialControl/X25SerialControl.ino The fact that you are seeing it go to the full right stop then center On Tue, Dec 31, 2013 at 2:09 PM, Tim Kettering notifications@github.comwrote:
Guy Carpenter |
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! :) |
Very awesome project! Is it a CB? On Tue, Dec 31, 2013 at 3:41 PM, Tim Kettering notifications@github.comwrote:
Guy Carpenter |
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. :) |
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" |
Hi! Its me again. I actually have something to add to this issue. |
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() |
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. |
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. |
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. |
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!
The text was updated successfully, but these errors were encountered: