CTRIO2 Encoder feedback usage

[BobO]

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.

[Controls Guy]

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.

[ATU]

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.

[Controls Guy]

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.