From: Fred Bartoli on
Fred Abse a �crit :
> On Mon, 29 Mar 2010 19:05:55 +0200, Fred Bartoli wrote:
>
>> I don't know whether LTspice support B
>> sources,
>
> Yes, it does.
>

Ah, thanks.

--
Thanks,
Fred.
From: pnachtwey on
On Mar 29, 11:53 am, John Larkin
<jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
> On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <j...(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
Many systems don't require a derivative gain. It depends on the
number of poles in your plant and we have no idea what you are trying
to do.

I am a big believer in derivative gains since I must tune under damped
systems. The trick is a have very fine resolution feed back that is
almost noise free or a good model. I would use 16 bit analog feedback
devices to get the finer resolution. I was just at a site where I
used the second derivative gain and it was necessary.

Sometime a low pass filter on the output helps too. If you are clever
you can calculate the gains and take the low pass filter into
consideration. This is better than trying to tweak each gain one a
time along with the output filter.

Do you have excess CPU time?

Peter Nachtwey

From: John Larkin on
On Mon, 29 Mar 2010 15:31:02 -0700 (PDT), pnachtwey
<pnachtwey(a)gmail.com> wrote:

>On Mar 29, 11:53�am, John Larkin
><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
>> On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <j...(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
>Many systems don't require a derivative gain. It depends on the
>number of poles in your plant and we have no idea what you are trying
>to do.
>
>I am a big believer in derivative gains since I must tune under damped
>systems. The trick is a have very fine resolution feed back that is
>almost noise free or a good model. I would use 16 bit analog feedback
>devices to get the finer resolution. I was just at a site where I
>used the second derivative gain and it was necessary.
>
>Sometime a low pass filter on the output helps too. If you are clever
>you can calculate the gains and take the low pass filter into
>consideration. This is better than trying to tweak each gain one a
>time along with the output filter.
>
>Do you have excess CPU time?
>
>Peter Nachtwey

This is my VME module, with 12 channels of 4-20 mA isolated outputs.
Each channel has its own ARM with a 12-bit ADC and a 10-bit DAC. The
ADC will measure the voltage drop across a shunt resistor, to get loop
current, and also our terminal voltage. The DAC drives a series linear
mosfet to regulate output. It will behave like a constant-voltage,
current-limited power supply, in that the user can program current and
voltage and it will operate in the appropriate mode, depending on the
load.

It's a 100 MHz 32-bit cpu, and the fastest I can digitize the pair of
inputs is 100 KHz, and I could run the loop at 50 or even 25 KHz, so
there should be tons of cpu cycles available.

John


From: Tim Wescott on
John Larkin wrote:
> On Mon, 29 Mar 2010 15:31:02 -0700 (PDT), pnachtwey
> <pnachtwey(a)gmail.com> wrote:
>
>> On Mar 29, 11:53 am, John Larkin
>> <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
>>> On Mon, 29 Mar 2010 14:20:31 -0400, Jerry Avins <j...(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
>> Many systems don't require a derivative gain. It depends on the
>> number of poles in your plant and we have no idea what you are trying
>> to do.
>>
>> I am a big believer in derivative gains since I must tune under damped
>> systems. The trick is a have very fine resolution feed back that is
>> almost noise free or a good model. I would use 16 bit analog feedback
>> devices to get the finer resolution. I was just at a site where I
>> used the second derivative gain and it was necessary.
>>
>> Sometime a low pass filter on the output helps too. If you are clever
>> you can calculate the gains and take the low pass filter into
>> consideration. This is better than trying to tweak each gain one a
>> time along with the output filter.
>>
>> Do you have excess CPU time?
>>
>> Peter Nachtwey
>
> This is my VME module, with 12 channels of 4-20 mA isolated outputs.
> Each channel has its own ARM with a 12-bit ADC and a 10-bit DAC. The
> ADC will measure the voltage drop across a shunt resistor, to get loop
> current, and also our terminal voltage. The DAC drives a series linear
> mosfet to regulate output. It will behave like a constant-voltage,
> current-limited power supply, in that the user can program current and
> voltage and it will operate in the appropriate mode, depending on the
> load.
>
> It's a 100 MHz 32-bit cpu, and the fastest I can digitize the pair of
> inputs is 100 KHz, and I could run the loop at 50 or even 25 KHz, so
> there should be tons of cpu cycles available.
>
> John
>
>
You may be surprised at how quickly you can use up 1000 CPU cycles.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
From: john on
On 29 Mar, 17:11, John Larkin
<jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote:
> 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

Recently did a sampled oscillator ALC loop using an AVR chip (10 bit
ADC+a bit of free dither and 'Course/fine' PWM as a DAC setpoint). Was
tedious to figure out and redraw various interesting loop mechanisms
in LTspice, so used Powerbasic. Much quicker in trialing a seemingly
infinite number of valid control methods.