CTRIO2 Encoder feedback usage

[tmoulder]

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

[BobO]

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.

[b_carlton]

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.

[BobO]

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.

[ATU]

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.   

[BobO]

If you are closing the loop the encoder, it isn't open loop...right? 

[ATU]

The encoder feedback helps a bit, but it is still isn't true motion

 

[BobO]

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.

[ATU]

So if the motor stalled shortly after the move started, it would eventually get there?

[BobO]

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.

[ATU]

Not quite Servo control, but a definite step up over an open loop stepper control and simple encoder.

[tmoulder]

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

[ATU]

Check the configuration in the servo drive, you may be able to set a following error limit that would turn on a fault output.

[BobO]

...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.

[Controls Guy]

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.