PID loop sample rates and resolution

[arvidb]

I'm out on uncharted water (for me at least) here... any comments appreciated.

I'm not sure how to design the servo controller I'm building. It should have nested PID loops with the inner loop controlling speed and the outer controlling position. For this I need to measure speed and position.

Position is easy: just keep track of encoder counts. Speed will also be measured with the help of the encoder, but how long should the sample time be, and at what resolution?

Just as an example: maximum encoder count rate 2 MHz. 12 bit speed data: +/-2047 gives sample time of just over 1 ms (1 kHz) for the speed loop.

The position loop should be run slower than this to allow the speed loop to react to its commands. Question is, how much slower? Let's say 10 times, which gives an update/sample rate of position of 100 Hz.

As an example of time constants for a servo motor, my 200 W motors have 5.4 ms inductive time constant and 0.4 ms inertia time constant (free running so will of course be a lot higher when connected to a machine).

Now since this will be a discrete PID controller it should have a sample rate of >10 times the bandwidth of the system it controls - I think. I have no idea how to relate this to the time constants mentioned above.

Also, will the rates mentioned above be fast enough to react to disturbances (like a tooth biting into material)?

?

Arvid

[bunalmis]

5.4 ms inductive time constant and 0.4 ms inertia time constant

0.4ms must be 0.4 sec.

1msec speed servo loop time and 100 msec position servo loop time enough for your application.

But if you want to draw circle by 2 pid controller and motors your position servo loop time must decrease (1msec)

At the past I have same question therfore I used 100 micro sec for the position servo loop time.

If I want to design new digital pid controller I select 1msec servo update time for position servo. Because I read following talented article.

http://www.control.com/Papers/mc-ic_html

This is same type question.

http://www.control.com/1026178513/index_html

1msec very long time for 2MHZ encoder pulses this is true but PID need error.

Also this article really good.

http://www.control.com/944512714/index_html

[mmjpotter]

I think a 1kHz position loop and a 100kHz speed loop should provide good control for general machining applications, but I'm not sure that the same encoder can feed both loops. Don't you think the speed loop will require a much higher resolution?

[arvidb]

bunalmis: thanks for those links! They were great! They seem to indicate that 100 Hz position servo update rate and 1 kHz speed update rate should be adequate. But you suggest 1 kHz position loop update rate? Is this just to be on the safe side?

Mike: you also suggest 1 kHz position loop update rate. This then would require at least 10 kHz speed loop update rate, I guess? 100 kHz would be even better, of course. It would be great if you could elaborate on this a bit.

It should be possible to measure speed with the encoder - I have seen papers describing it. Look at application notes for TI motor control DSPs for example. There are (at least) two ways to measure speed with an encoder:

1) Count encoder counts in a certain time span, or
2) Measure time between encoder counts.

1) seems easier to implement to me; just count during 1 ms and the number of counts is directly proportional to the speed. If max encoder count rate is 2 MHz this gives 12 bits of resolution (-2 MHz to 2 MHz <=> -2000 to +2000 counts). Here resolution is proportional to sampling time, but longer sampling time means older information.

The resolution here would be 1 kHz, or 60 RPM with a 250 pulse/rev encoder. If top speed is 3000 RPM this is equivalent to less than 7 bits of resolution. Enough? I don't know. With my 2048 pulse/rev encoders and 4500 RPM top speed, I would get >10 bit effective resolution.

2) I guess is a bit more difficult to implement: speed = (counter freq)/(counter counts between encoder counts) * (scale factor). I guess it would also require filtering of some sort. The faster the encoder count rate, the shorter the time required to measure. Resolution? Max resolution should be limited by counter frequency (could easily be 20 MHz).

But what about slow speeds? I guess a new encoder count is not required between each reading of the speed (and update of speed loop). If no new encoder count has been received, we know that the speed cannot have increased (much), so the old slow speed measurement should still be valid (?). If we allow the counter to be, say, 24 bits, a whole second could pass between each encoder count and we would still get a valid reading.

I recall that in at least one of the application notes mentioned above they switched between the different methods depending on the current speed.

Now that I write this, I can really see the benefits of method 2), so I guess that's the way to go. Unless I have missed something? Hmm...

Arvid

[bunalmis]

Yes you can use incremental shaft encoder instead of tachometer.

But encoder dont give good results for precision servo. Therefore we must use
tacho + shaft encoder. (My idea)

Did you see any professional servo systems without tacho? (Big cnc controller)

I think Texas Instr. suggest shaft encoder but this suggestion for not precision motor drivers. (for speed control of 3 pahese asynchron motor and brushless motors) Our application need more precision.

If you don't need more precise servo you can use single position loop.

[arvidb]

Motorola Application Note AN1931 describes speed regulation of a 3-ph PM motor with only encoder feedback.

My Yaskawa servos (SIGMA series) claims speed regulation range of 1:5000 with load regulation of 0.01 % at rated speed, over 0-100 % load. This is also with encoder only (2048 pulses/rev = 8192 counts/rev). They don't mention regulation at lower speeds though. They also don't say anything about how fast it reacts to load changes.

The Gecko drives use position loop only, don't they? And if they work for many people, then at least I'm gonna think more about the possibilities to implement a speed loop with encoder as feedback device. It should give even better results than the Geckos, and it would be interesting!

Arvid

[bunalmis]

Steady state error importand but transient responce more importand.
We can use position encoder if we interest by only steady state responce of speed application. (This application may be video and voice recorders, CD/ RW, hard disks)

But cnc servo positions system need very low tracking error.

Therefore i think fast and precision servo systems use tacho generator for inner loop. (?)

I dont know the error of Gecko while system fly. I remember Gecko has 128 bit overflow counter. Therefore error may max 127 count on the fly.

Who can say ? Does axis motors of industrial big CNC machine use tacho? Else are there only shaft encoder ?

[ESjaavik]

My drives use resolvers. Which means the motor position is measured using an analog method. But of course it is digitized in the drive. It depends on the drive how high resolution it uses. It seems this is a widely used method. But it's not cheap.

[mmjpotter]

I prefer tacho feedback and this is the method I use with my control.
Usdigital make an encoder/tacho called ETACH2 this has a sample rate of 10kHz and they claim no cogging or ripple at low speed. Have a look at this link www.usdigital.com/products/etach2 it might provide some ideas.

[arvidb]

Mike, thanks for the link. It shows it should be possible to get by with only encoder feedback (deriving speed data from it). I guess I just have to try it!

Einar, arent resolvers a kind of analogue absolute encoders? I believe their useful resolution is relatively low (also kind of like a quad digital encoder).

I believe modern (expensive!) servo systems use sin-cos quadrature encoders. These are not resolvers, but have perhaps 2000 sin+cos cycles per revolution. With interpolation their useful resolution can be up around 1,000,000 counts per rev! So these can be used without problems to get both speed and position.

Arvid

[ESjaavik]

The resolver is a rotating transformer fed by a sinewave signal on the input (rotor). Then it has 2 output windings that are 90 degrees out of phase with each other (sin-cos). Then the drive measure these voltages and can thus find the position of the rotor. Thus the resolution depends on the resolution of the conversion from the analog voltage to the digital part of the drive. The accuracy can be quite high, but the electronic parts needed are not simple, neither are they cheap. The resolver mounted on the motor contains no electronic parts. It's just a rotating transformer. So the only ways to destroy it are mechanically breaking it, or applying high enough voltage to break down the insulation or burn the windings. It is both mechanically and electronically tough. And it's low impedance.

But for making a DIY drive, it's probably not a good choice.