next topic »

[on:]

Hi,
I've successfully set three steppers to work.
They are supposed to be 200 steps pr round, but one of them doesn't quite make it. A discrepancy is building up.
It could be the load that the stepper is pulling, and halving the speed by using double torque yields a pretty good precision.
To be infront of any discrepancies, I've tried to count axis-revolutions by way of a photo-interrupters. But they are not reliable either.
I'm sure that I'm not the first to encounter the problem.
How do you tackle it?

Yesterday the sled that one of the steppers pulls got stuck .. and the stepper pulled a 12 cm long strong plastic-band that held it in place into 16 cm. The notion that they are missing torque or dropping steps becourse of heavy load is somewhat far fetched. I've considered looking at the 'time' passing between steps .. but the logic of the code should only count a step once it's been commanded.

I don't really have a clue ..

[Reply #1 on:]

Need some clue about hardware and software before we can give any useful feedback. Are you sure your system has no mechanical slack or slop?

[Reply #2 on:]

If you are missing steps, and it sounds like it then slow the motor down until you do not miss any.
Then take steps ( ) to increase the torque, like running it off a higher voltage with a regulating driver. Or ramping up and down to top speed.

[Reply #3 on:]

If you are missing steps, and it sounds like it then slow the motor down until you do not miss any.
Then take steps ( ) to increase the torque, like running it off a higher voltage with a regulating driver. Or ramping up and down to top speed.

Hi Mike,
For a while I have been very decisive about one thing: If ever you would respond to my postings, I would start out "Hi Mike, How are you today?", but your laughing totally disarms me.
...
as for the problem at hand, i dunno..
If I want absolute precision I run in half-stepping. That's slow and the coil-resistors gets very warm. I think that I underestimate the power of the steppers. They transmit through a screw-axel, so the pull is sort of geared way down.
The action-code for all steppers is a function I call setTime() .. when they've been set to work, they loop passed this code, and if proper time has passed, it takes a step.
Two of the steppers needs to work closely together: Say you want a cross line that doesn't follow the axis, the steppers will have to have different delays to syncronize properly along the slope. I'm pondering if this inter-fingering of two stepper-actions may influence each other .. or rather if the second is influenced. One of the steppers runs flawless. The other might have got a damage. [While we are at the setTime() .. I 'invented' a great detail: If the slope is close to the axis, one stepper may take some very slow steps and 'hang' in a torque - so, all steppers gets a pause() after 5-8 millis. Great burn-out preventer]
i dunno..

http://troelsgaard.net/images/ct_Images/Positioner/DSC01119.JPG
The inner circle is done in full step and misses a little something after visiting all points and return home. The outer is in half-stepping.

[Reply #4 on:]

Need some clue about hardware and software before we can give any useful feedback. Are you sure your system has no mechanical slack or slop?

motor
http://www.let-elektronik.dk/3303-17-bipolar-48mm-stepper.html
driver
http://www.let-elektronik.dk/l298-dualh-bridge-motor-driver.html

I'm afraid that the code has become way too extensive, .. but, if you have some clues of what services could be in trouble, I could find that part of the code.

The setup has some slack. If you notice the picture i posted .. going in a circle sort of cancels any slack at the time of being back home. I actually recently wrote code to compensate for any slack: If the direction of a stepper changes I'll let it take a little detour to hawl in any slack. But I keep an eye on it.
What error I do detect is: Let the stepper take a turn .. that's 200 step. I've marked the axel, and after repeating it's obvious that it does not reach a whole way round. The code is in a stepper-class, so both steppers uses the same code .. just one fails the inspection.

[Reply #5 on:]

but your laughing totally disarms me.

Well it was because of an untended pun I made.

What you should do is to strip the code back and just test the motors to see if they both respond to all steps. Then you know it you have a hardware or software problem.
Running the motor at half steps and then disabling the drivers gives you half a step error because the motor looses position in those fractional steps when de energised.

If the motors check out individually but not when run together then check that you have sufficient current capability with your power supply and add some large bulk decoupling capacitors like 500uF across it.

[Reply #6 on:]

What you should do is to strip the code back and just test the motors to see if they both respond to all steps. Then you know it you have a hardware or software problem.

That's settled then. It's a bit of a fuss, but I often need this single motor test.

Running the motor at half steps and then disabling the drivers gives you half a step error because the motor looses position in those fractional steps when de energised.

I don't think that the half-stepping is a problem. And both steppers are exposed to the same code.
I'm very careful in keeping track of which phase is next .. also after pausing. But it /has/ crossed my mind that one of the stepper might so to speak starts out on the wrong leg. It should max loose 2 steps out of every restart .. that doesn't sound of much, but I'll check it. If it wasn't for the circumstance, that this motor also has a rougher resonance/sound I would actually believe that the problem could be buried here. I do have a lot of resets (instead of pauses where I keep track).

If the motors check out individually but not when run together then check that you have sufficient current capability with your power supply and add some large bulk decoupling capacitors like 500uF across it.

Will do the capacitor thing.
The two steppers alone share a 12V & 2A ... that should be enough to blow me off the table together with the rest of the setup, if something went wrong. But it leads me to something I've pondered on trying: To swap the supply to a 35 or 45V source I've lying somewhere. Somewhere in this tutorial:
http://www.stepperworld.com/Tutorials/pgMicrostepping.htm
I have seen a feedback mechanism that controls the amount of current that the stepper will get .. as a substitute for the coil-resistors. It's not really for dummies like me, but I did notice the change of motor-effect I got from raising voltage and adding coil-resistors. I would like more changes to the better like that. But, as it is now, I've already burned off a set of resistors ... (driver and motor survived ;o) .. /this time, not the previous) .. and I cannot afford to make any mistakes right now.
I did spent time on measuring the actual turn-around of the motor-shaft, and I'm not done on attacking the problem from that side. If I add one of those small & strong magnets to the shaft, then it ought to be no sweat to detect atleast a sharp 1/10 of a round .. the forward move is 1.0 mm pr round giving a 0.1mm precision then. That'll be ok for now. As you probably noticed on the photo .. one cannot really detect errors with the naked eye (a little flatness on the four sides thanks to slack).

[Reply #7 on:]

If you are not supplying power to the motors at all times, and if there is any torque on the motor when you remove power then the motor can move and you are out of position. Proper use of steppers keeps them powered at all times. You can reduce power when not moving, but you must supply enough power to hold position. Sorry, but with no other feedback you have to keep the motor powered to be anywhere near accurate with positioning. A common rue of thumb is that you need steppers with 2 times the required torque.

[Reply #8 on:]

If you are not supplying power to the motors at all times, and if there is any torque on the motor when you remove power then the motor can move and you are out of position. Proper use of steppers keeps them powered at all times. You can reduce power when not moving, but you must supply enough power to hold position. Sorry, but with no other feedback you have to keep the motor powered to be anywhere near accurate with positioning. A common rue of thumb is that you need steppers with 2 times the required torque.

hi kf2qd,
The steppers each moves a sled on a greased rail. Once the step has been accomplished, there is no more torque on the axel. For now, I'll go with the precision this setup gives.
If it really is an issue, both steppers should be exposed to it equally .. it's still only one of them that misses a little. I havn't had time to look at the "starting at wrong phase" possibility. I'll post back on the outcome.

You may say that detecting missing steps is a sort of precautionary measure .. if one step is not pulled through, I can add an extra, but if stepping is gone all together, something serious is wrong. I would like to be able to turn my back on it and feel safe that any eventuality is dealt with properly.
Setups of my photo-interrupters often involves a small capacitor on the receiver voltage, but that's not where the 'jumpiness' is .. and the capacitor would act as a high-pass filter, right? The analog low is well-behaved, but the high is very serrate. I wonder if I could put a low-pass filter on it.

[Reply #9 on:]

Solved it!
I noticed a while back, that I could remedy the apparent missing steps by 'hurring up' the 'time between steps'. That logic would imply that it would be a timer-problem, so I decided to keep track of how far a step-event would overshoot the 'timeBetweenSteps'.
One loop would last about 900 micros and maxSpeed would use 1500 micros. [overshoot of 2*900-1500 at next poll]

I added a MicrosDiscrepancy and a microsSinceLast variable
See where it is used in code:
cStepper::setTime() is a stepper-class function that is polled repeatedly. The variable cStepper::mDelay is the inverse velocity 'constant' indicating an ideal time-between-steps (not to confuse with any delay())

Code:

boolean cStepper::setTime( boolean HalfOrFull ){
if( HalfOrFull ){ cStepper::isHalfStep = false ; }
else{ cStepper::isHalfStep = true ; }
boolean res7 = true ;
if ( cStepper::misOn ){
long microsSinceLast = micros() - cStepper::oldTime  ;
cStepper::MicrosDiscrepancy = microsSinceLast - cStepper::mDelay ;
if( (cStepper::oldTime + cStepper::burnIn) <  micros() ){
// if delay more than burnIn then holding is abandonned
cStepper::Pause() ;
}// end if oldTime + burnIn

if(  ( (cStepper::oldTime + cStepper::mDelay) < micros() - cStepper::MicrosDiscrepancy ) ){
// mDelay microseconds has passed
if( cStepper::HalfStepCounter  < abs(cStepper::destination ) ){
// if stepper has not reached destination:
                                        cStepper::oldTime = micros() ;
if( HalfOrFull ){ cStepper::Step() ;}
else{ cStepper::StepHalf() ;}

res7 = true ;
}
if(HalfStepCounter  == abs( cStepper::destination) ){
cStepper::destination = 0 ;
cStepper::misOn = false ;
cStepper::Stop() ;
//Serial.println("at destination ");
//delay(5) ;
res7 = false ;
}
if(HalfStepCounter  > abs( cStepper::destination) ){
String nm = cStepper::name ;
//Serial.print( nm );
//Serial.println(" exeded" );
//delay(5) ;
didExeed = true ;
//cStepper::deEnable() ;
cStepper::misOn = false ;
res7 = false ;
}
}// end if (oldTime + mDelay) < micros

}// end if cStepper::misOn
else{
res7 = false ;
//Serial.println("setTime are off");
//delay(100) ;
}

return res7 ;
} // end cStepper::setTime //-----------------

My attempt to measure the axis-dial went down the drain in the process, but it's not that urgently needed. It uses 5 true delays of 50 micros .. it beats me why it's stopped measuring properly.