EETimes

Embedded Systems October 2000 Vol13_11

Issue link: http://dc.ee.ubm-us.com/i/71842

Contents of this Issue

Navigation

Page 97 of 181

LISTING 1 typedef st ruct { doubLe dState; doubLe iState; doubLe iMax, iMin; doubLe } SPid; doubLe UpdatePIO(SPid * pid, doubLe error, doubLe position) { doubLe pTerm, dTerm, iTerm; pTerm = pid->pGain * error; II caLcuLate the proportionaL term II caLcuLat e the integraL state with appropriate Limiting pid->iState += error; if (pid->iState > pid->iMax) pid->iState = pid->iMax; eLse if (pid->iState < pid->iMin) pid->iState = pid->iMin; iTerm = pid->iGain * iState; II caLcuLate the integraL term dTerm = pid->dGain * (pid->dState - position); pid->dState = position; return pTerm + dTerm + iTerm; } iGain, pGain, dGain; II Last position input II Integrator state II Maximum and minimum aLLowabLe integrator state II II II integraL gain proportionaL gain derivative gain P.ID controller code~' '. . smoo th things o ut over the lo ng term you can get away with a somewhat uneve n sampling rate, but it needs to ave rage o ut to a constant value. At worst, your sampling rate should vary by no more than ±20% ove r any] 0- sample inte rval. You can even get away with miss ing a few samples a long as your average sample rate stays within bounds. Nonetheless, for a PI controllel' I prefer to have a system whe re each sample falls within ±1 % to ±5% of the correct sample time, and a long-term ave rage rate that is right on the button. If you have a controller ulat needs to push ule plant hard, your controller output wi ll pend signiiicant amounts of time outside the bounds of what your drive can actually accept. This condition is called saturation. If you use a PI controlle r, then all ule time spent in saturation can cause the inte- grator state to grow (wind up) to very large values. When the plant reaches ule target, the integratol' value is still very large, so me plant drives beyond the ta rge t whi le th e integrator unwinds and the process reverses, This situation can get so bad ulat the sys- tem never setues o ut, but ju t slowly oscillates around the target positio n. Figure 15 ill ustrates me effect of FIGURE 8 0.8 0.8 0.6 ~ 'u; c:: 0.. 0 0.6 0.4 0.2 0 0 '" i" , , , , , , " , , . , , , ", , , , : ' : --- , , , ", , ,. " : , , , , , , .. .. .. .... " 0.2 0.4 :-.- ..- .,._-~- .------- .. - _ Input - - • pGain = 10 - - • pGain = 5 pGain =2 __ • pGain = 1 , : 1 integrator windup. 1 used th e motor/ controller of Figure 13, and limited the motor drive to ±0.2. Not only is controller output much greater man ule drive available to the moto r, but the motor shows severe overshoot. The motor actually reaches its target at around five seconds, but it doesn't reverse direction unti l eight seconds, and doesn 't settle o ut until 15 seconds have gone by . The easiest and most direct way to 0.6 Time 96 OCTOBER 2000 Embedded Systems Programming 0,8 deal wim integrato r windup is to limi t ule integrato r state, as I showed in my previous code example. Figure 16 shows what happens when you take me system in Figure 15 and limit the integrator term to the available drive output. The controller output is still large (because of the proportional term), but me integrator doesn't wind

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11