Encoder requirements for a motion application (low speed/holding positions).

[rpicatoste]

Dear all,

I am trying to figure out the resolution that I need for an application where I plan to use Field Oriented Control and motors that will stop and hold in fixed positions.

I have found, in addition to how difficult the topic is, only a rule given somewhere else in this forum where it is said that Siemens has a rule of thumb like this:
PPR > 275/RPM_min

The thing is that I do not have an specification for RPM_min, but I do need to avoid strange effects at very low speeds/holding positions like the motor shaking and so on.

Am I approaching this the wrong way? Probably I can use a different control scheme to avoid the speed loop in stopped positions? Now I am using a PI closing the loop on speed by setting the quadrature current that is needed, and a P controller for the position loop.

Any help or guidance will be very welcome! And regarding the project if more info would be helpful let me know which.

Thanks!
Ricardo

 

[sreid]

One rule to apply is that the position accuracy can't be better than +/-1 encoder count. And it is often less especially if there is friction in the system.

 

[rpicatoste]

Hello sreid,
Thanks for your answer. However more than the positioning I am struggling with the speed loop ... I think that the questions could be summarized in:
- Is it possible with just a linear controller (PI) to have a good behavior of the speed loop using an encoder?
- What resolution should the encoder have to achieve that good behavior?

The outer loop, in position, will be as precise as the sensor + actuator, but it is more tricky with the speed because of the position time derivative.

Thanks again,
Ricardo

 

[sreid]

It is a difficult question.

One criterion might be: a minimum of two encoder edges per servo update time (set a minimum RPM).

Also, the servo gains can't be extremely high as there is a "Velocity Estimation Time Delay" which subtracts phase margin from the velocity loop.

 

[Skogsgurra]

I think that I am guilty of the 275 PPR/RPM/min thing. I used it as an example that encoders needn't be 4096 PPR in every application. If you use Field Oriented Control, there is usually no need for an additional speed signal - a good sensorless speed oriented Control takes care of the speed.

Then, you can use a fairly simple encoder to keep your load in position. If you feel that you must use a PI controller (instead of a P controller), there will always be a cyclic adjustment when the load drifts away from the target position. That little movement can usually be tolerated. But, if a small error can be allowed, then a P controller should be used. You will not have the small adjustments, but you will have a load dependent target error. Small, yes, but still.

BTW, I recently visited a plant where someone had specified a 5 kPPR encoder and had lots of problems when running near top speed. We changed the encoder to a plain vanilla 1024 PPR encoder and everything worked as it should. Cable capacitance was too much for the 5000 unit, but the 1024 had enough time to reach threshold levels even when running at top speed.

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

 

[controlsdude]

Would you not use a brake when you stop for a length of time. Then you would not worry about holding a motor at zero speed.

Move table to exact position
zero speed motor
set brake
stop motor
perform function
start motor at zero speed
release brake
repeat above

 

[cswilson]

As others have said, it is very difficult to give a firm answer to this questions, especially without good specifications of what position and velocity jitter can be tolerated. Even with these specs, it is not so easy.

To answer your most basic question, can you get a decent speed loop with just a position encoder, the answer is yes. It is done all the time, and has been done this way for at least 25 years now.

As to the required resolution, I can only give you some rules of thumb. I wouldn't go below 1000 ppr (4000 counts per rev after decode). If you can go higher without a lot of additional cost and without exceeding transmission or reception frequency limits as Skogs points out, I would advise it. It will lessen the chances of failure, however defined.

Many controllers just estimate velocity by taking the backward difference of successive position samples. This can lead to unwanted quantization noise and roughness. There are possibilities to improve this both through software means (state estimators) and hardware means (high-frequency timers on the encoder inputs). A lot depends on your flexibility and capabilities.

Curt Wilson
Delta Tau Data Systems

 

[rpicatoste]

Thanks a lot for your answers, they are very helpful (and a relieve to see that is not only for me that is not simple!).

controlsdude using a brake is not an option since the system is already there and cannot be changed.

For the minimum resolution again, the expression for the error with fixed time sampling is:
w_err = 2*pi/(N*T)
where N is the encoder resolution and T the sampling time. Using it from the controller design I can get a minimum resolution if I am able to give the maximum w_err.

In my case the current loop is 1.5 kHz, and the rule I have found for the maximum bandwidth of the outer loop is to be at least 4 times slower than the inner loop. I take advantage to ask: do you consider it enough? There is not that much margin since there will be another outer loop for the position.

Even if later I set the bandwidth lower, I use this value to decide the sampling rate of the digital controller. The rule I know is to sample at least 20 times faster than the closed loop bandwidth. This means sampling at 7.5 kHz and the error with 4096 pulses per revolution becomes 11.5 rad/sec which seems rather high.

With sensorless speed estimation (sensorless because why don't directly measure speed, but position, right?), is there any way to quantify this error, or to predict it? (so I could decide about the resolution needed in the encoder).

Thanks again! and sorry for the big post.

 

[mikekilroy]

Sounds like you are designing your own vector drive from the floor up. Unless that is your intent, you probably should consider asking the supplier of the drive what is required for your application. A lot of your performance results will be the result of the drive design. For instance, some will take as simple as a 256 LINE per rev sine encoder and divide it down into hundreds of millions of real pulses per rev for higher performance you won't get from a 4096PPR encoder. Lots of details THEY know about THEIR drive and they will likely be real happy to share with you and help you customize and pick the best encoder for your application.

That said, we do full positioning vector drives with 256 tooth square wave encoder feedback all the time and have very solid positioning and smooth low speed performance. Again, it will depend a LOT on the technicalities of the drive you pick.

When one has a positioning application, they usually have a position repeatability and accuracy spec; without knowing those, one cannot pick the minimum encoder resolution. On the other end of the scale, drives hav a max freq input limit on their encoder inputs, so without knowing your max speed, one cannot be sure to pick a low enough resolution to keep out of trouble.

Keep in mind also that PPR is not LPR: encoders are typically speced in LINES per rev; the drive typical multiplies this by 4 to get PULSES per rev. So don't get confused with that and get an encoder with too many lines that ultimately the drive cannot handle at whatever your max speed is.

http://www.KilroyWasHere<dot>com