simulating a digital control loop
in [Design]
|
From: Helmut Sennewald on 29 Mar 2010 13:59 > .. > I can simulate it as an analog loop using LT Spice, as I'm familiar > with that and could get it done quickly. It would be handy if I could > also use the same model in digital mode, which would add sampling > delays and maybe even quantization. > > Any thoughts on how to do this? > ... > John Hello John, LTspice has a sample/hold device. It's named "sample" and you can get it from [Special Functions]. It allows to sample and hold a signal with the edge of a clock signal. Additional B-sources can be used to do the math in the loop. Even quantization is possible with the help of int() functions in the B-sources. Best regards, Helmut
From: Jerry Avins on 29 Mar 2010 14:20 Tim Wescott wrote: > Fred Bartoli wrote: >> Tim Wescott a �crit : >>> Fred Bartoli wrote: >>>> John Larkin a �crit : >>>>> I'm designing a gadget that uses an ARM uP, with 12-bit mux'd ADC and >>>>> a 10-bit DAC, to essentially make a current and voltage regulated >>>>> power supply. The ADC will measure voltage and current and the DAC >>>>> will control a fairly soft source-follower series-pass mosfet. The >>>>> customer load could be most anything. >>>>> >>>>> I think it would be time-effective to simulate the control loop while >>>>> the PC board is being fabbed, so we don't have to play with dynamics >>>>> as much in the critical delivery path. >>>>> I can simulate it as an analog loop using LT Spice, as I'm familiar >>>>> with that and could get it done quickly. It would be handy if I could >>>>> also use the same model in digital mode, which would add sampling >>>>> delays and maybe even quantization. >>>>> >>>>> Any thoughts on how to do this? >>>>> >>>>> I note here that more and more formerly-analog control loops, things >>>>> like switching power supplies, motor drivers, power amps, will be >>>>> going digital in the future. Some of the ARM chips are selling for >>>>> under a dollar. Analog parts will, I think, increasingly be used for >>>>> things like amplification, and less for computation. >>>>> >>>>> John >>>>> >>>> >>>> It can easily done with spice. >>>> >>>> The software delay can be modeled as a TLINE provided it is constant >>>> in your system. >>>> For switchers you model the switch as an averaged one (continuous >>>> model). The sampling action is modeled by a 2 poles TF (look at >>>> Ridley's paper "Accurate and practical small signal model for >>>> current mode control", or I can try to dig in one of my previous HDs). >>>> >>>> With good modeling you can have average transient and AC (loop >>>> gain,...) simulations which are real close to the actual circuit. >>>> >>>> That won't give you quantization though, and I guess this can't be >>>> modeled as with sigma delta since you have a first order loop and >>>> probably an almost constant signal. >>>> >>>> Maybe, but I never tried this, you can discretize the loop (only for >>>> transient analysis) with use of B "arbitrary sources" within which >>>> you use some integer part function. I don't know whether LTspice >>>> support B sources, but you should find something equivalent... >>>> >>>> >>> Quantization looks like infinite gain, though, so unless it is >>> wrapped inside of a sampled-time section it'll really slow down -- or >>> completely crash -- the simulation. >>> >>> You can analyze fairly well for quantization by treating it as noise >>> at the magnitude of the quantization, and the worst possible >>> frequency. Just inject a signal at the quantization point, do a >>> frequency sweep to figure out the sensitivity of the output to the >>> quantization, and take the worst spot. >>> >>> Quantization always seems to seek to do the most damage possible, so >>> treating it as worst case isn't paranoid. In this case, it really is >>> out to get you! >>> >> >> It's been a while I've looked at this but IIRC it's only one bit >> quantizer that have infinite gain. Multibit quantizers, as I guess >> John will use since he has plentiful bits ADC/DAC, have unit gain. >> I once used an ARM with 12b ADC/DACs to build a low OSR SD converter >> with real high resolution at almost no cost (the ARM was mandated for >> other things). Of course it wasn't more linear than the DAC on large >> signals, but the app was OK with that... >> > At the point of the quantization step the input moves an infinitesimal > amount, and the output moves a finite amount. That's an infinite gain. > With a 12-bit device, it happens 4095 times, instead of once. It really plays havoc when computing a simple "derivative". Jerry -- Discovery consists of seeing what everybody has seen, and thinking what nobody has thought. .. Albert Szent-Gyorgi �����������������������������������������������������������������������
From: John Larkin on 29 Mar 2010 14:53 On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <jya(a)ieee.org> wrote: >Tim Wescott wrote: >> Fred Bartoli wrote: >>> Tim Wescott a �crit : >>>> Fred Bartoli wrote: >>>>> John Larkin a �crit : >>>>>> I'm designing a gadget that uses an ARM uP, with 12-bit mux'd ADC and >>>>>> a 10-bit DAC, to essentially make a current and voltage regulated >>>>>> power supply. The ADC will measure voltage and current and the DAC >>>>>> will control a fairly soft source-follower series-pass mosfet. The >>>>>> customer load could be most anything. >>>>>> >>>>>> I think it would be time-effective to simulate the control loop while >>>>>> the PC board is being fabbed, so we don't have to play with dynamics >>>>>> as much in the critical delivery path. >>>>>> I can simulate it as an analog loop using LT Spice, as I'm familiar >>>>>> with that and could get it done quickly. It would be handy if I could >>>>>> also use the same model in digital mode, which would add sampling >>>>>> delays and maybe even quantization. >>>>>> >>>>>> Any thoughts on how to do this? >>>>>> >>>>>> I note here that more and more formerly-analog control loops, things >>>>>> like switching power supplies, motor drivers, power amps, will be >>>>>> going digital in the future. Some of the ARM chips are selling for >>>>>> under a dollar. Analog parts will, I think, increasingly be used for >>>>>> things like amplification, and less for computation. >>>>>> >>>>>> John >>>>>> >>>>> >>>>> It can easily done with spice. >>>>> >>>>> The software delay can be modeled as a TLINE provided it is constant >>>>> in your system. >>>>> For switchers you model the switch as an averaged one (continuous >>>>> model). The sampling action is modeled by a 2 poles TF (look at >>>>> Ridley's paper "Accurate and practical small signal model for >>>>> current mode control", or I can try to dig in one of my previous HDs). >>>>> >>>>> With good modeling you can have average transient and AC (loop >>>>> gain,...) simulations which are real close to the actual circuit. >>>>> >>>>> That won't give you quantization though, and I guess this can't be >>>>> modeled as with sigma delta since you have a first order loop and >>>>> probably an almost constant signal. >>>>> >>>>> Maybe, but I never tried this, you can discretize the loop (only for >>>>> transient analysis) with use of B "arbitrary sources" within which >>>>> you use some integer part function. I don't know whether LTspice >>>>> support B sources, but you should find something equivalent... >>>>> >>>>> >>>> Quantization looks like infinite gain, though, so unless it is >>>> wrapped inside of a sampled-time section it'll really slow down -- or >>>> completely crash -- the simulation. >>>> >>>> You can analyze fairly well for quantization by treating it as noise >>>> at the magnitude of the quantization, and the worst possible >>>> frequency. Just inject a signal at the quantization point, do a >>>> frequency sweep to figure out the sensitivity of the output to the >>>> quantization, and take the worst spot. >>>> >>>> Quantization always seems to seek to do the most damage possible, so >>>> treating it as worst case isn't paranoid. In this case, it really is >>>> out to get you! >>>> >>> >>> It's been a while I've looked at this but IIRC it's only one bit >>> quantizer that have infinite gain. Multibit quantizers, as I guess >>> John will use since he has plentiful bits ADC/DAC, have unit gain. >>> I once used an ARM with 12b ADC/DACs to build a low OSR SD converter >>> with real high resolution at almost no cost (the ARM was mandated for >>> other things). Of course it wasn't more linear than the DAC on large >>> signals, but the app was OK with that... >>> >> At the point of the quantization step the input moves an infinitesimal >> amount, and the output moves a finite amount. That's an infinite gain. >> With a 12-bit device, it happens 4095 times, instead of once. > >It really plays havoc when computing a simple "derivative". > >Jerry Derivatives usually cause more trouble than they do good. My "PID" controller will almost certainly have D=0. John
From: Tim Wescott on 29 Mar 2010 15:15 John Larkin wrote: > On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <jya(a)ieee.org> wrote: > >> Tim Wescott wrote: >>> Fred Bartoli wrote: >>>> Tim Wescott a �crit : >>>>> Fred Bartoli wrote: >>>>>> John Larkin a �crit : >>>>>>> I'm designing a gadget that uses an ARM uP, with 12-bit mux'd ADC and >>>>>>> a 10-bit DAC, to essentially make a current and voltage regulated >>>>>>> power supply. The ADC will measure voltage and current and the DAC >>>>>>> will control a fairly soft source-follower series-pass mosfet. The >>>>>>> customer load could be most anything. >>>>>>> >>>>>>> I think it would be time-effective to simulate the control loop while >>>>>>> the PC board is being fabbed, so we don't have to play with dynamics >>>>>>> as much in the critical delivery path. >>>>>>> I can simulate it as an analog loop using LT Spice, as I'm familiar >>>>>>> with that and could get it done quickly. It would be handy if I could >>>>>>> also use the same model in digital mode, which would add sampling >>>>>>> delays and maybe even quantization. >>>>>>> >>>>>>> Any thoughts on how to do this? >>>>>>> >>>>>>> I note here that more and more formerly-analog control loops, things >>>>>>> like switching power supplies, motor drivers, power amps, will be >>>>>>> going digital in the future. Some of the ARM chips are selling for >>>>>>> under a dollar. Analog parts will, I think, increasingly be used for >>>>>>> things like amplification, and less for computation. >>>>>>> >>>>>>> John >>>>>>> >>>>>> It can easily done with spice. >>>>>> >>>>>> The software delay can be modeled as a TLINE provided it is constant >>>>>> in your system. >>>>>> For switchers you model the switch as an averaged one (continuous >>>>>> model). The sampling action is modeled by a 2 poles TF (look at >>>>>> Ridley's paper "Accurate and practical small signal model for >>>>>> current mode control", or I can try to dig in one of my previous HDs). >>>>>> >>>>>> With good modeling you can have average transient and AC (loop >>>>>> gain,...) simulations which are real close to the actual circuit. >>>>>> >>>>>> That won't give you quantization though, and I guess this can't be >>>>>> modeled as with sigma delta since you have a first order loop and >>>>>> probably an almost constant signal. >>>>>> >>>>>> Maybe, but I never tried this, you can discretize the loop (only for >>>>>> transient analysis) with use of B "arbitrary sources" within which >>>>>> you use some integer part function. I don't know whether LTspice >>>>>> support B sources, but you should find something equivalent... >>>>>> >>>>>> >>>>> Quantization looks like infinite gain, though, so unless it is >>>>> wrapped inside of a sampled-time section it'll really slow down -- or >>>>> completely crash -- the simulation. >>>>> >>>>> You can analyze fairly well for quantization by treating it as noise >>>>> at the magnitude of the quantization, and the worst possible >>>>> frequency. Just inject a signal at the quantization point, do a >>>>> frequency sweep to figure out the sensitivity of the output to the >>>>> quantization, and take the worst spot. >>>>> >>>>> Quantization always seems to seek to do the most damage possible, so >>>>> treating it as worst case isn't paranoid. In this case, it really is >>>>> out to get you! >>>>> >>>> It's been a while I've looked at this but IIRC it's only one bit >>>> quantizer that have infinite gain. Multibit quantizers, as I guess >>>> John will use since he has plentiful bits ADC/DAC, have unit gain. >>>> I once used an ARM with 12b ADC/DACs to build a low OSR SD converter >>>> with real high resolution at almost no cost (the ARM was mandated for >>>> other things). Of course it wasn't more linear than the DAC on large >>>> signals, but the app was OK with that... >>>> >>> At the point of the quantization step the input moves an infinitesimal >>> amount, and the output moves a finite amount. That's an infinite gain. >>> With a 12-bit device, it happens 4095 times, instead of once. >> It really plays havoc when computing a simple "derivative". >> >> Jerry > > Derivatives usually cause more trouble than they do good. My "PID" > controller will almost certainly have D=0. I quibble with that 'usually'. "Very often", perhaps, and the trouble that's caused is often bad enough to make you shudder every time you think about turning up the derivative gain. A judicious amount of derivative, in the form of a lead-lag with closely spaced zero and pole, can often do a world of good -- when it's not snarling you up in 2nd-order effects, of course. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: John Larkin on 29 Mar 2010 15:45
On Mon, 29 Mar 2010 12:15:18 -0700, Tim Wescott <tim(a)seemywebsite.now> wrote: >John Larkin wrote: >> On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <jya(a)ieee.org> wrote: >> >>> Tim Wescott wrote: >>>> Fred Bartoli wrote: >>>>> Tim Wescott a �crit : >>>>>> Fred Bartoli wrote: >>>>>>> John Larkin a �crit : >>>>>>>> I'm designing a gadget that uses an ARM uP, with 12-bit mux'd ADC and >>>>>>>> a 10-bit DAC, to essentially make a current and voltage regulated >>>>>>>> power supply. The ADC will measure voltage and current and the DAC >>>>>>>> will control a fairly soft source-follower series-pass mosfet. The >>>>>>>> customer load could be most anything. >>>>>>>> >>>>>>>> I think it would be time-effective to simulate the control loop while >>>>>>>> the PC board is being fabbed, so we don't have to play with dynamics >>>>>>>> as much in the critical delivery path. >>>>>>>> I can simulate it as an analog loop using LT Spice, as I'm familiar >>>>>>>> with that and could get it done quickly. It would be handy if I could >>>>>>>> also use the same model in digital mode, which would add sampling >>>>>>>> delays and maybe even quantization. >>>>>>>> >>>>>>>> Any thoughts on how to do this? >>>>>>>> >>>>>>>> I note here that more and more formerly-analog control loops, things >>>>>>>> like switching power supplies, motor drivers, power amps, will be >>>>>>>> going digital in the future. Some of the ARM chips are selling for >>>>>>>> under a dollar. Analog parts will, I think, increasingly be used for >>>>>>>> things like amplification, and less for computation. >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>> It can easily done with spice. >>>>>>> >>>>>>> The software delay can be modeled as a TLINE provided it is constant >>>>>>> in your system. >>>>>>> For switchers you model the switch as an averaged one (continuous >>>>>>> model). The sampling action is modeled by a 2 poles TF (look at >>>>>>> Ridley's paper "Accurate and practical small signal model for >>>>>>> current mode control", or I can try to dig in one of my previous HDs). >>>>>>> >>>>>>> With good modeling you can have average transient and AC (loop >>>>>>> gain,...) simulations which are real close to the actual circuit. >>>>>>> >>>>>>> That won't give you quantization though, and I guess this can't be >>>>>>> modeled as with sigma delta since you have a first order loop and >>>>>>> probably an almost constant signal. >>>>>>> >>>>>>> Maybe, but I never tried this, you can discretize the loop (only for >>>>>>> transient analysis) with use of B "arbitrary sources" within which >>>>>>> you use some integer part function. I don't know whether LTspice >>>>>>> support B sources, but you should find something equivalent... >>>>>>> >>>>>>> >>>>>> Quantization looks like infinite gain, though, so unless it is >>>>>> wrapped inside of a sampled-time section it'll really slow down -- or >>>>>> completely crash -- the simulation. >>>>>> >>>>>> You can analyze fairly well for quantization by treating it as noise >>>>>> at the magnitude of the quantization, and the worst possible >>>>>> frequency. Just inject a signal at the quantization point, do a >>>>>> frequency sweep to figure out the sensitivity of the output to the >>>>>> quantization, and take the worst spot. >>>>>> >>>>>> Quantization always seems to seek to do the most damage possible, so >>>>>> treating it as worst case isn't paranoid. In this case, it really is >>>>>> out to get you! >>>>>> >>>>> It's been a while I've looked at this but IIRC it's only one bit >>>>> quantizer that have infinite gain. Multibit quantizers, as I guess >>>>> John will use since he has plentiful bits ADC/DAC, have unit gain. >>>>> I once used an ARM with 12b ADC/DACs to build a low OSR SD converter >>>>> with real high resolution at almost no cost (the ARM was mandated for >>>>> other things). Of course it wasn't more linear than the DAC on large >>>>> signals, but the app was OK with that... >>>>> >>>> At the point of the quantization step the input moves an infinitesimal >>>> amount, and the output moves a finite amount. That's an infinite gain. >>>> With a 12-bit device, it happens 4095 times, instead of once. >>> It really plays havoc when computing a simple "derivative". >>> >>> Jerry >> >> Derivatives usually cause more trouble than they do good. My "PID" >> controller will almost certainly have D=0. > >I quibble with that 'usually'. "Very often", perhaps, and the trouble >that's caused is often bad enough to make you shudder every time you >think about turning up the derivative gain. > >A judicious amount of derivative, in the form of a lead-lag with closely >spaced zero and pole, can often do a world of good -- when it's not >snarling you up in 2nd-order effects, of course. One way to avoid overshoots is to pre-shape the demand input, like using an adaptive slew limit or some such. I've done that in steamship throttle controls where you don't want to stress the plant too much, and NMR temperature controllers where a modest overshoot can poach some enzyme that a hundred rabbits died to make. John |