How much resolution is enough for velocity control using an incremental encoder?

modiconguy

Member
Join Date
Oct 2020
Location
Toronto
Posts
62
A bit of background here:


We use an incremental encoder with a counting module in our PLC configuration. Using dual phase / quadrature counting, we know the position of the motor (which makes several turns) and we can differentiate to find the velocity. We would like to control the velocity of the motor to get the predictable speeds under varying load.


Given the maximum frequency of the counting module, and the maximum rotational velocity of the motor, I think we could clearly identify the maximum encoder resolution that we could support. It should be less than the max frequency (Hz) of the counter divided by the max revolutions/second of the motor, right?


Secondly, given an encoder resolution and a PLC scan time, what's the slowest practical revolutions/second we can expect to get reliable PID control of slow velocities? I'm guessing it would be a rule of thumb like "the time between pulses should be less than 10x the scan time" or similar.
 
Thanks for the response. In our case, the motor is hydraulic, and the valve controller does not support encoder feedback.
Even if it was a VFD, isn't the question still relevant? On any controller with a scan time, how slow is it practical to turn the motor or how low resolution can you tolerate for a certain speed?
 
@modiconguy:
By your name I can infere that your PLC is obviously modicon, but can you try to use a motion controller with your PLC ?.
A motion controller with the right valve can control your hidraulic motor with no problem, and your encoder can be used as you desire.
 
Good point, a motion controller would probably set us ahead, and if we were just getting started I would pursue that further. I should say that since we're somewhat more OEM-type, this encoder is just one-more-thing we're adding to a legacy PLC application which performs well on the motion applications that we've designed.


I'm really just looking for input on the encoder sizing, obviously higher resolution is better as long as you don't exceed the capabilities of the counter. Same question then, how slow can you go on a motion controller and stay stable if you know the encoder resolution and the scan time of the controller?
 
To get the best speed control you should use a Flux Vector VFD
I would recommend Yaskawa GA800 the higher the PPR the better speed regulation
particularly at lower speeds. I like to use 5000 PPR
I have found I can get very good regulation down to zero hz (Position Holding)
You set the speed you want and the VFD will run at that speed within the limits of motor full torque
 
Thanks, good to know that 5000 ppr works well for position holding. I would assume there might be oscillation if we implement it ourselves, but within 1/5000 of a rev is probably better than we need.


See my response to Steve that explains why we're not discussing VFDs.
 
@Modiconguy : I only have experience with Allen Bradley PLCs, modicon only in photos.
But a motion controller can handle your motor the whole range from 0 - to max speed.
In AB a motion controller is asynchronous to the CPU so no problem, it has its own intelligence.
Just in case, I have seen VFD driving hydraulic pumps and controlling flow, Can this be an appropriate solution to you ??
 
Pick an encoder resolution within the limits of the high speed counter module. A 5000 PPR encoder on a 3000 RPM shaft generates a 250 kHz pulse frequency.

Also remember that even if the HSC can keep up with the pulses from the encoder, the PLC may only update the information from the HSC module when it services the I/O.
 
Thanks widelto, I do not want to change to a VFD. I'm happy with the performance of the hydraulic system under PLC control. I'm sorry that this conversation changed to discussing VFDs.


If no one has any further comments on the encoder resolution, I think we should end this thread.
 
if you have a hydraulic system I assume that you are using a hydraulic motor of some sort
can you install a rotary encoder on the motor ?
how about linier encoder or I would look ate a lease measuring system some will give you rate of change feedback
then install a hydraulic servo valve on the feed to the motor / cylinder
I don't see where you need motion control at this point
but all cases the more pules per rev or inch / MM the better
the newer high speed counters cards can handle rates of at least 1 mhz
you have many options available to you just take a little time and see what best meets your needs
 
if you have a hydraulic system I assume that you are using a hydraulic motor of some sort
can you install a rotary encoder on the motor ?
how about linier encoder or I would look ate a lease measuring system some will give you rate of change feedback
then install a hydraulic servo valve on the feed to the motor / cylinder
I don't see where you need motion control at this point
but all cases the more pules per rev or inch / MM the better
the newer high speed counters cards can handle rates of at least 1 mhz
you have many options available to you just take a little time and see what best meets your needs
...and finally, after 11 posts, the conversation circles back to the actual question asked by the OP.

This forum is great at offering alternate solutions to problems, but usually we also manage to address the actual question at some point. Hopefully now that we've circled back to where we started, we can do just that ;)


@modiconguy, unfortunately I don't have the specific knowledge to answer your question, but I can throw a little bit of anecdotal/generic information to hopefully get the ball rolling.

modiconguy said:
given an encoder resolution and a PLC scan time, what's the slowest practical revolutions/second we can expect to get reliable PID control of slow velocities?
As I understand it, your question does not concern itself with how to achieve the slow velocity control; reliable slow-speed velocity control is already achieved by the existing hydraulic motor and controller. You simply want to know the minimum encoder resolution that would enable you to adequately monitor that speed, with sufficient resolution to ensure you are getting an accurate representation of actual speed at all times.

As others have mentioned, as well as the scan time of the PLC, you will also need to consider the update rate of the I/O and the HSC module. All of my modicon experience is quite old so I can't give you specific information, but I can give you an AB-world parallel example. If I have a HSC module on a remote I/O rack, I have to concern myself with (a) the rate at which the HSC module is polled by the fieldbus adaptor, (b) the rate at which that fieldbus adaptor is polled by the PLC, and (c) the rate at which the PLC logic reads and acts on that data (scan time). I would assume there are similar factors at play in a modicon system (and of course, I'm making anotherassumption that you're using a modicon PLC, based purely on your handle).

Once you factor all of those things in, you can work out how often you can *actually* read a change in pulses. I'm afraid that beyond that, my experience only goes so far as to say "two or three times that rate doesn't give you very good results", so I'd suggest that your original suggestion of 10x is probably in the ballpark. But again, that's anecdotal and based on semi-educated guesswork, so I wouldn't take my word for it!

Hope that helps somewhat!
 
What is your application?

A bit of background here:
We use an incremental encoder with a counting module in our PLC configuration. Using dual phase / quadrature counting, we know the position of the motor (which makes several turns) and we can differentiate to find the velocity.
I am assuming you don't really care about position but only velocity as if you are moving a conveyor or feed chain. You don't need to worry about bumping into anything.

We would like to control the velocity of the motor to get the predictable speeds under varying load.
This isn't that hard IF you can accurate measure the actual speed by differentiating the encoder counts. There are problems.
1. is phase delay.
2. sample jitter
3. feedback resolution

Given the maximum frequency of the counting module, and the maximum rotational velocity of the motor, I think we could clearly identify the maximum encoder resolution that we could support. It should be less than the max frequency (Hz) of the counter divided by the max revolutions/second of the motor, right?
Yes and Ditto what Steve Bailey said above about resolution. The more resolution the better. Counting modules usually have limited frequency response and sampling them at irregular intervals will cause sample jitter ( noisy velocities ).
It is best if the counting module computes the counts per second for the PLC.

Secondly, given an encoder resolution and a PLC scan time, what's the slowest practical revolutions/second we can expect to get reliable PID control of slow velocities? I'm guessing it would be a rule of thumb like "the time between pulses should be less than 10x the scan time" or similar.
1 count difference in a 1 millisecond scan provides a resolution of 1000 counts/second. 1 count difference over 10 millisecond is better but then then if the controller has a 1 millisecond scan then the encoder will provide 9 readings of 0 speed and 1 reading of 100 counts/second.

You need to provide a scan time and resolution.
I/we sell hydraulic motion controllers and can read an encoder every half millisecond easily. I also suggest highest resolution encoder you can get.
A good motion controller should be able to handle 8M counts per second.

What are you really trying to do? What are your specifications or goals?
I have a lot of experience in this area.

I usually recommend 10K ppr or 40K counts per revolution minimum.
The more the better.
 
Boy did we drift way off on this one
the origenal was to control velocity to get predictable repeatable positioning
and encoder is necessary for both because he is using a hydraulic system that would rule out a VFD so you will need a motion controller of some type PLC are generally not very good at that you need a control loop program the velocity and final position and let the control do it's thing
where are you getting an encoder with 40K PPR the most i have ever seen is 6K
5k is hard to find and is more expensive then standard
with the 5K the final resolution is 20K PPR 5K X 4

As for the outputs on an HSC module they are not scan time dependent unless you want them to be they work off the counter processor triggered from the High Speed counter value
the only limitation is the high count limit or rollover point
what you are trying to is possible but you will need a hydraulic valve
 
Boy did we drift way off on this one
the origenal was to control velocity to get predictable repeatable positioning
Modiconguy didn't say he needed position control. If he did I would have suggested using an SSI absolute encoder to avoid needing a homing routine.


and encoder is necessary for both because he is using a hydraulic system that would rule out a VFD so you will need a motion controller of some type PLC are generally not very good at that you need a control loop program the velocity and final position and let the control do it's thing
A good hydraulic motion controller can do it all. No PLC is required unless there is a lot of I/O


where are you getting an encoder with 40K PPR the most i have ever seen is 6K
There is a difference between PPR and counts. Encoder decoders can multiply the PPR by 4 because the decoder sees all 4 phases. BTW, I have customers using 17 bit absolute encoders. Now 18 bit encoders are available. That 262144 counts/rev.



As for the outputs on an HSC module they are not scan time dependent unless you want them to be they work off the counter processor triggered from the High Speed counter value
the only limitation is the high count limit or rollover point
what you are trying to is possible but you will need a hydraulic valve
So if a HSC module updates every millisecond, how does a PLC take advantage of that if the PLC will sample at different intervals. The HSC needs to be able to provide a counts/second value at all times an not be dependent on the PLC scan time as you suggest. What about acceleration? counts/second^2.
 

Similar Topics

Hi all, Have a client with a wastewater plant, I was asked to change the scaling for a CL2 analyzer that was replaced. I was a bit shocked when...
Replies
10
Views
3,875
I am new In a CCW and as a beginner I am trying to learn programming but i am noticing that my CCW software is taking around 1 minute to download...
Replies
2
Views
70
Today I was working on my project for school and we were using a power supply with 24V and we accidentally had the current at 0.9A. We heard a pop...
Replies
9
Views
497
Hi all, Can a machine be "too safe"? I originally wanted to ask a different question about best-practices when switching a machine from non-auto...
Replies
9
Views
920
Good Evening , I have been asked to do some teaching at a community college for industrial automation for some young adults. I'm thinking 2...
Replies
28
Views
10,750
Back
Top Bottom