Expert PID Tuners?

[Chris Elston]

I have a question about hardware in relationship to PID tuning. Let's suppose I have a DC motor controlled by a PWM controller. And I have a quadature encoder with an A and B phase. The encoder however only has a resolution of 300 pulses per one revolution of the encoder shaft in relation to feedback of the motor shaft. Which isn't that great...almost one encoder pulse is one degree on the motor. I can't connect a gearbox, it's mainly just a follower encoder one-to-one. Because the resolution is so low, and let's say I want to control this motor for position, would it be very difficult to tune the PID? Or no matter what the parameters are in any control system, a PID should be able to be tuned? In other words, is there a point where your feedback system isn't what it's cracked up to be when trying to tune your PID? Or does it amount to response time? If your feedback hardware has a low resolution, then you have to trade off response time or what I call a sluggish PID loop? It will tune or settle, but it takes it longer to get there and can't be as responsive? Any thoughts for those of you that have designed PID systems?

[ianbuckley]

While there will be minor issues as to how tight you can tune a loosely tied feedback related to hunting vs. stiffness, what you really need to worry about is final resolution. How tightly are you trying to control the end actuator? If you are trying to control to the nearest degree, obviously you won't be able to do that with 300 counts per rev. As a general rule, I try to have >=5 counts per unit I am trying to control. For example, if I need to control to the nearest degree of actuator movement, I try to get at least 5 motor encoder counts per degree of motor actuator movement. This might not be practical without any gearing, and the rule of thumb might not apply directly because you automatically have no backlash if there is no gearing. I would still try for 3 counts per controlled unit even in this case. So, 300 counts per rev should be safe if you are trying to control to the nearest 3.6 degrees or so. In any case, for tuning purposes, the biggest factor is motor sizing. If the motor cannot provide the torque neccessary, obviously it won't do the job. When the motor is oversized, you lose resolution in the amplifier - you are using only a small band of the amplifier capability while the controller resolution is set up for the whole range. Just my two cents.

[Peter Nachtwey]

[waynes]

I agree with ianbuckly about the response not being a major issue, but rather the accuracy. If the set point needs to be precise (like in this case- position control), the feedback needs to be of high resolution/ accuracy. The only thing that might held you out is to read the falling edge of the A/B pulses to effectively double your resolution. I know that not all position controllers have this.

[Peter Nachtwey]

Well you would be wrong. High resolution is required for proper motion control as well as for the position control. In fact it is even more important while moving and accelerating. Only by having fine feedback resolution can one calculate accurate velocities and accelerations. The goal of the motion control designer and the system integrator is to make the system appear to be as close to a analog system as possible. This means one should have fine resolution and sample times. I always recommend using 10000 line encoders which will provide 40000 counts per revolution. To prove my point I have made a simple model of a motor system. I ran two simulations. The first simulation takes the perfect model positions and quantizes the position into 40000 positions per revolution. The second simulation quantizes the perfect model positions into 300 positions per revolution. One can see the high resolution system can follow the 1 Hz sine wave almost perfectly. One can tell because the actual position is covering the target position at almost all points. This isn't the case with low resolution encoder. The smallest error that is detectable is 1/300 of a revolution and that causes huge swings in the ouput which causes non-linearities. The low resolution system can't track the target position at all. ftp://ftp.deltacompsys.com/public/PDF/Mat...pid%20mrplc.pdf The only difference between the two simulations is the resolution of the feedback. One can try all they want and they will never get the low resolution system to perform as it should. Hopefully this will convince everyone to get the highest resolution encoder they can so they don't waste their time trying to tune systems low resolution feedback.

[Chris Elston]

Peter, This is really excellent information. Thanks very much for your advise. I have a question on your MathCad. Did you make the formulas yourself within MathCad or is that a built in function out of the box that has some feature to calculate PIDs? I've been wanting to get MathCad but don't know much about it.

[Peter Nachtwey]

I developed the formulas myself using control text books. The difference between what I do and the text books is that I like to solve the problem symbollically. I haven't seen these equations posted anywhere on the internet. I use a technique called pole placement instead of pole cancellation. I would not recommend Mathcad right now. The customer support is poor and the software is unstable. I have to save often because it crashes. Depending on what you want to do I would recommend Scilab or Maple. Scilab is free and is like a super calculator and simulation environment. Maple is the king of symbolic processing but cost money.

[panic mode]

interesting, one learns something every day...

[Sleepy Wombat]

Thanks for the pointer to Scilab Peter... i seemed to remember using it in the very early days of its development, and had forgotton about it till now...improved heaps...

[Peter Nachtwey]

Sleepy, I have known about Scilab for many years but I have always used Mathcad. Mathcad is OK for symbollic processing and simple simulations like the one pointed to the link above. However, my simulations are getting more detailed so I need something better. I have just started to learn Scilab. I have bought a book called "Modeling and Simulation in Scilab/Scicos". I recommend this book to get you kick started. In the future I will use Scilab to do more simulatons. The Scilab simulations will not as look pretty as the Mathcad .pdfs and the readers will have get involded by cuttting and pasting the program in the posts into their scilab editors but the rewards will be great. What if? 1. What if you could change resulution of the encoder. 2. What if you could change the update time T. 3. What if you could change the system gain and the corner frequency, alpha? 4. What is the effect of the derivative gain. 5. How does the derivative gain and encoder resolution interact? 6. What happens if the amplitude and frequency of the sinewave is changed? 7. What happens when the value of lambda, the desired response, is changed. Scilab would allow one to experiment and find out.

[ianbuckley]

I suppose I should have asked for more information. I was making a general statement about general applications. Most industrial applications are not 1Hz sine wave movements. They are move to a specific point (accurately), settle quickly, wait a relatively long time for something to happen, then move to the next point. Of course, the more resolution you have on your feedback, the better the following response will be - that is pretty intuitive. 10,000 line per revolution encoders are obviously better than 300 line encoders. However, they are not always available for anywhere near the same price. Until very recently, the high end standard was 1024 lines. And yet, applications have been working sufficiently well to do their intended tasks. As resolutions go up and processing speed goes up, the performance will get better and better. But let's not pretend that you have to spend the premium money for maximum resolution in all cases. Perfect following throughout the whole profile, while imperative in some tasks, is not always required. To answer the original question, yes there is a point where the resolution of your feedback is insufficent for the application, and therefore not "what it's cracked up to be." But at which resolution point this happens totally depends upon the application. Some applications, such as focusing laser mirrors, require extreme resolution becasue they have to follow the intended profile very closely. The typical pick and place application probably can do with less than the very best. This is where the rule of thumb to which I was referring comes into play. Of course, if you can get someone to pay the premium price (whether it is required or not) go for it - you will get better performance out of the control loop, assuming the rest of the system can handle it.

[Peter Nachtwey]

Ian, we both should have asked for more information. However I knew that even if the motion controller mulitplies the lines by 4 it would still be bad. My example is very conservative as the axis is only moving at 2*PI inches per second and accelerating at (2*PI)^2 inches per second squared which is only 1/10th a G. This is not a matter of being perfect, close to perfect or good enough. Chakorules chances with the original encoder is none. Hopefully he would have mentioned a gear box if it existed. I tried to make the point that one can NOT just use the position accuracy to select feedback resolution. BTW, this example will probably show up in a magazine someplace. I will probably multiply the 300 counts by 4 to be fair. 1200 counts per rev isn't as ugly but it still doesn't tune up as nicely. 4000 counts per revoution gets rid most of the following errors but the quantizing effects on the output would probably damage a drive or over heat it quickly. I don't think I would have a hard time selling anybody on the idea of using a 10000 line encoder and using setup time and ROI from higher though put. Think about this. An error of one count at 4000 counts/rev will cause the output to change 10 more than a error of 1 count when using 40000 counts/rev. If the quantizing of the output is the limiting factor then the gains using 4000 counts/rev would need to be 1/th of a system using a 40000 count/rev encoder.

[TimWilborne]

One comment on the 10000 line encoder. The main reason we don't use the high resolution encoders is they are not as durable as the lower resolution encoders. 1024 is a high as we go. And yes, it is a trade off between reliablity and stablity for us. We had some with 600s on them but they were not smooth at all. 1024 seems to be our happy number. One question I have for Chakorules. Are you wanting to use the 300 line encoder because of with the RPM you need to run you will be hitting the high limit on the PWM, your feedback, both, or none of the above?

[Chris Elston]

None of the above, it's an existing design and I am tearing it apart, meaning "bashing it with slang, wording, engineering questions, etc"....

[TimWilborne]

Oh ok, well I think Peter and Ian got the PID under controls, just wondering why the encoder would be that low

[ianbuckley]

Peter, You are right, of course, about the performance of the whole system - easier tuning, faster performance (again - assuming the rest of the system can keep up) - being better. I guess I was just assuming he was trying to do something simple on the cheap. With that assumption, the most glaring problem would be final resolution. I guess I have more experience with customers focused too heavily on up front costs than I'd like. Or maybe I need to work on my sales skills. I was also trying to point out something that a lot of people new to motion control miss - inertia matching. When sizing a regular on/off induction motor, many designers simply make sure they have enough motor. If it is oversized, the only penalty you really pay is monetary. The motor will perform just fine in almost all cases. Obviously if the sizing is ridiculously out of whack there will be issues, but a 10HP motor will work fine in a spot where only 5HP is required almost all of the time. When you get into servo control, matching the load is much more important. If the motor is double sized as in the case above, the controller only has 50% of the resolution available to the amplifier. You aren't using the upper half. Even if the feedback resolution is perfect analog and the gains as tight as can be, you are still limiting your performance on the other end of the system. As a side note, designers should make sure that the feedback controller can handle the pulse rate from the encoder at the speeds to be controlled as well. This is becoming less of an issue, as even the lower cost/performance controllers are getting faster, but still worth a cursory check. Ian