Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: tmoulder on March 25, 2013, 03:41:54 PM
-
I'm looking to do some simple step-direction motion control with encoder verification on the Do-More platform. I am trying to sort out exactly what the capabilities of this module are.
1. Is the encoder feedback actually used in the motion profile? For instance, if I instruct a move command for 5000 counts, will it output 5000 pulses, or actually move 5000 encoder counts, modifying the pulse train as required?
2. Is there any provision for follower error?
Thanks,
TM
-
1. Is the encoder feedback actually used in the motion profile? For instance, if I instruct a move command for 5000 counts, will it output 5000 pulses, or actually move 5000 encoder counts, modifying the pulse train as required?
You specify a scale factor between the encoder and stepper. The target position is expressed in encoder units and adjusted on the fly. There is a bit of correction that is applied during the move, but that is limited to a few percent. At the end of the move if we are still off, we'll creep to the target. We are considered to be at the target when we are within the specified deadband.
2. Is there any provision for follower error?
I'm going to plead ignorance here. I have heard the term 'follower' used in motion, but am not sure what that means in practice.
-
Following error is just the difference between the current commanded position in the profile and the position as reported by the encoder. Some systems will fault out at a certain level of this error, indicating a problem.
-
Thanks Bernie. Makes perfect sense.
So no, we do not have provision for follower error, part of our heritage as a basic stepper controller. The encoder feedback helps a bit, but it is still isn't true motion, just an improved stepper controller.
It actually would be manageable to add some follower error functionality to the CTRIO2, although due to I/O map space it would be harder to get the value back in real time. It could be done in the form of a register in the output channel that could be accessed via CTREGRD. It would also be pretty easy to a fault threshold and shutdown.
If these are major care-abouts, we are willing to look at adding them to a future version.
-
My opinion, for an open-loop system, monitoring following error, doesn't make sense. If your application requires close monitoring of following error, then perhaps you should consider using a servo.
-
If you are closing the loop the encoder, it isn't open loop...right? ;)
-
The encoder feedback helps a bit, but it is still isn't true motion
;)
-
It is actually closing the loop on the encoder. I say it isn't true motion because it isn't running an algorithm that is predictively tuning based on error. The result is effectively the same though.
-
So if the motor stalled shortly after the move started, it would eventually get there?
-
Probably not. It isn't making any effort to decel and restart, and steppers are usually done once they stall. However, if the linkage slips or there is other mechanical fault, but the motor keeps moving, we will eventually get to the target as defined by the encoder.
-
Not quite Servo control, but a definite step up over an open loop stepper control and simple encoder.
-
Thanks, this is what I suspected.
We are in fact using a yaskawa servo drive, in step-direction mode. The axis has an external glass-slide encoder in addition to the servo motor encoder. The slide is used for the positioning loop. It sounds like a good fit - it will correct if the slide reports position is off, and the system is slow enough to get away with a simple compare to target.
Still, it would be good to offer some sort of following error register, since if the axis were to bind, it would be detected quickly.
Thanks again,
TM
-
Check the configuration in the servo drive, you may be able to set a following error limit that would turn on a fault output.
-
...and the system is slow enough to get away with a simple compare to target.
It's better than a simple compare, but not a true PI or PID type algorithm...it's more of a P with enhancements. It is constantly looking at where it is relative to target and computes the accel, positioning, and decel based on the reality. It can also subtly tweak the decel if it is not tracking where we want. The only time it might get fooled is if the scale factor between the stepper and encoder is significantly wrong (bad config or slippage), of if there were a mechanical fault that caused major disruptions to the apparent position. I generally try to soft-pedal the motion aspects to temper expectation, but it actually performs pretty well.
-
Check the configuration in the servo drive, you may be able to set a following error limit that would turn on a fault output.
At least in the Yaskawa's that I've seen, you can trip on following error and you can also set a torque limit, which would be a good idea especially if you envision jams, so nothing gets broke. :)
BobO, having following error in the CTRIO would help alleviate an issue with open loop step-and-direction commanded systems. (Just closing the loop with the encoder helps fix that) If the step wire gets loose and you lose pulses, you never know the difference, even if you're monitoring the drive for faults like stalls. The drive is happy because it moved the number of pulses that it got, and the PLC doesn't know that's a different number than it sent.
-
It would not be hard to add the following error. To do following, I would just have to use the accumulated pulse count that is normally used as position when not using an encoder, and calc error as the difference between the two. Of course the next thing you will want is to use that error value to adjust the velocity, which would be something of a PP loop.
I'd say the internal work is pretty easy. The harder part is the limited register space I have to work with. I have already done major hair-pulling to get stuff out of the CTRIO2, and more ain't gonna be easy, at least not live. The fall-back would be to use the back door register access CTREGRD, but that wasn't intended to be used in real time. I don't know that it would hurt anything, but that would constitute coloring outside the lines.
-
Don't know if it helps, but I'm more concerned about the following error (and not even a value, just a following error flag with a user-configurable trigger threshold) than velocity correction. And in truth, not even in a panic about the following error.
-
I think most users would be interested in just detecting a stall condition when using a low end stepper driver. If they want more, they'll use a servo, which like in this case, has following error detection. AD Servo's have that.
-
I think most users would be interested in just detecting a stall condition when using a low end stepper driver. If they want more, they'll use a servo, which like in this case, has following error detection. AD Servo's have that.
That's kind of what I was trying to say too. I don't use steppers (or servos in step mode) very much so anything looking like even a slightly more sophisticated app is going to get a servo in positioner mode anyway. I tend to like to offload the positioning to the servo anyhow, just tell it where to go either in terms of numerical location or selection from pre-programmed positions, and just have it tell me when it gets there.