LTSpice trouble with .op using 2-pole opamp

[Chris Carlen]

Hi:

I have LTSpice 05/24/04 version. The circuit attached won't .op with
the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?

I stuck the B source in so I could use an ideal opamp in place of U4 and
still get the clipping. So the B is redundant with the 2-pole opamp
installed.

Cut out the 2-pole and install an ideal amp, and the circuit converges
in .op just fine.

Anything can be done about this?

I have this trouble a lot when using the parametrized opamps. Bummer
because I like them when modeling systems when I don't yet want to think
about component specs.


Thanks.



Good day!



--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[Mike Engelhardt]

Chris,

I have LTSpice 05/24/04 version. The circuit attached won't
.op with the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?

I stuck the B source in so I could use an ideal opamp in
place of U4 and still get the clipping. So the B is
redundant with the 2-pole opamp installed.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.

As it also does if you then remove the B-source and use 2pole
opamps throughout to automatically limit the output voltage
to the supply rail limits, as in the file below. BTW, a
better drafting approach might be to use the UniversalOpamp
symbol which allows you to select the simulation level without
picking a different symbol. See ./examples/Educational/
UniversalOpamp.asc for further details.

--Mike

--- fix.asc ---
Version 4
SHEET 1 1812 680
WIRE -352 -128 -352 -192
WIRE -352 -272 -352 -336
WIRE 240 -992 208 -992
WIRE 208 -992 208 -848
WIRE 208 -848 240 -848
WIRE 208 -848 176 -848
WIRE 304 -992 352 -992
WIRE 352 -992 352 -832
WIRE 352 -832 304 -832
WIRE 96 -848 -32 -848
WIRE 208 -784 208 -816
WIRE 208 -816 240 -816
WIRE 208 -224 208 -256
WIRE 208 -256 240 -256
WIRE 176 -288 208 -288
WIRE 224 -400 208 -400
WIRE 208 -400 208 -288
WIRE 208 -288 240 -288
WIRE 304 -400 352 -400
WIRE 352 -400 352 -272
WIRE 352 -272 304 -272
WIRE 0 -288 -32 -288
WIRE -176 -336 -352 -336
WIRE -176 -288 -240 -288
WIRE -128 -352 -128 -480
WIRE -32 -480 -32 -560
WIRE -32 -480 -32 -288
WIRE -128 -272 -128 -224
WIRE 688 -416 768 -416
WIRE 1296 -112 -240 -112
WIRE -240 -112 -240 -288
WIRE -128 -480 -32 -480
WIRE 352 -832 384 -832
WIRE 352 -272 384 -272
WIRE 896 -416 944 -416
WIRE 944 -416 944 -368
WIRE 944 -416 992 -416
WIRE 1120 -368 1120 -416
WIRE 1120 -416 1072 -416
WIRE 1120 -416 1296 -416
WIRE 944 -256 944 -304
WIRE 1120 -304 1120 -256
WIRE 1296 -304 1296 -416
WIRE 1296 -224 1296 -112
WIRE 64 -288 96 -288
WIRE 208 -496 208 -528
WIRE 208 -528 240 -528
WIRE 176 -560 208 -560
WIRE 240 -704 208 -704
WIRE 208 -704 208 -560
WIRE 208 -560 240 -560
WIRE 320 -704 352 -704
WIRE 304 -544 352 -544
WIRE 352 -544 352 -704
WIRE 656 -384 656 -352
WIRE 656 -352 688 -352
WIRE 656 -448 656 -480
WIRE 656 -480 688 -480
WIRE 704 -528 768 -528
WIRE 768 -528 768 -416
WIRE 624 -528 544 -528
WIRE 544 -528 544 -432
WIRE 544 -432 624 -432
WIRE 496 -832 544 -832
WIRE 544 -832 544 -544
WIRE 544 -432 544 -272
WIRE 544 -272 496 -272
WIRE 416 -272 384 -272
WIRE 416 -544 384 -544
WIRE 416 -832 384 -832
WIRE 592 -368 592 -400
WIRE 592 -400 624 -400
WIRE 384 -544 352 -544
WIRE 1568 -464 1568 -512
WIRE 1680 -512 1680 -464
WIRE 1568 -592 1568 -656
WIRE 1680 -592 1680 -656
WIRE 816 -416 768 -416
WIRE 544 -544 496 -544
WIRE 544 -544 544 -528
WIRE 96 -560 -32 -560
WIRE -32 -560 -32 -848
WIRE 272 -304 272 -336
WIRE 272 -336 304 -336
WIRE 272 -240 272 -208
WIRE 272 -208 304 -208
WIRE 272 -576 272 -608
WIRE 272 -608 304 -608
WIRE 272 -512 272 -480
WIRE 272 -480 304 -480
WIRE 272 -864 272 -896
WIRE 272 -896 304 -896
WIRE 272 -800 272 -768
WIRE 272 -768 304 -768
FLAG -352 -128 0
FLAG 208 -784 0
FLAG 208 -224 0
FLAG -128 -224 0
FLAG -352 -336 Vref
FLAG -240 -288 Vp2
FLAG 384 -832 Vi
FLAG 384 -272 Vd
FLAG -240 -48 0
FLAG 944 -256 0
FLAG 1120 -256 0
FLAG 208 -496 0
FLAG -128 -480 Verr
FLAG 688 -480 Vdd
FLAG 688 -352 Vss
FLAG 592 -368 0
FLAG 384 -544 Vp
FLAG 768 -416 Vc
FLAG 1568 -464 0
FLAG 1680 -464 0
FLAG 1568 -656 Vdd
FLAG 1680 -656 Vss
FLAG 304 -336 Vdd
FLAG 304 -208 Vss
FLAG 304 -608 Vdd
FLAG 304 -480 Vss
FLAG 304 -896 Vdd
FLAG 304 -768 Vss
SYMBOL voltage -352 -288 R0
WINDOW 3 -325 56 Left 0
WINDOW 123 -325 84 Left 0
WINDOW 39 0 0 Left 0
SYMATTR Value PULSE(5 5.1 0.1 1u 1u 2 4)
SYMATTR Value2 AC 1
SYMATTR InstName V1
SYMBOL e -128 -368 R0
SYMATTR InstName E1
SYMATTR Value 1
SYMBOL res 80 -832 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R1
SYMATTR Value {1/Ki}
SYMBOL cap 240 -976 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL res 208 -384 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R2
SYMATTR Value {Kd}
SYMBOL cap 0 -272 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C2
SYMATTR Value 1
SYMBOL res 800 -400 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 95 56 VBottom 0
SYMATTR InstName R4
SYMATTR Value 1
SYMBOL res 976 -400 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 95 59 VBottom 0
SYMATTR InstName R5
SYMATTR Value {Km}
SYMBOL cap 928 -368 R0
SYMATTR InstName C3
SYMATTR Value {1/Kf}
SYMBOL cap 1104 -368 R0
SYMATTR InstName C4
SYMATTR Value {1/(Km*Kf)}
SYMBOL res 1280 -320 R0
SYMATTR InstName R3
SYMATTR Value {1000*Km}
SYMBOL res 80 -272 R270
WINDOW 0 64 54 VTop 0
WINDOW 3 63 58 VBottom 0
SYMATTR InstName R6
SYMATTR Value {Kd/(f1*10)}
SYMBOL res 80 -544 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R7
SYMATTR Value 1
SYMBOL res 224 -688 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R8
SYMATTR Value {Kp}
SYMBOL res 400 -816 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R9
SYMATTR Value 10k
SYMBOL res 400 -528 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R10
SYMATTR Value 10k
SYMBOL res 400 -256 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R11
SYMATTR Value 10k
SYMBOL res 608 -512 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R12
SYMATTR Value 10k
SYMBOL voltage 1568 -608 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V2
SYMATTR Value {Vdriver}
SYMBOL voltage 1680 -496 M180
WINDOW 0 24 104 Left 0
WINDOW 3 24 16 Left 0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V3
SYMATTR Value {Vdriver}
SYMBOL Opamps\\2pole 656 -416 R0
SYMATTR InstName U4
SYMBOL Opamps\\2pole 272 -272 R0
SYMATTR InstName U2
SYMATTR Value2 Avol=100K GBW=10Meg Slew=10Meg
SYMBOL Opamps\\2pole 272 -544 R0
SYMATTR InstName U3
SYMATTR Value2 Avol=100K GBW=10Meg Slew=10Meg
SYMBOL Opamps\\2pole 272 -832 R0
SYMATTR InstName U1
SYMATTR Value2 Avol=100K GBW=10Meg Slew=10Meg
TEXT 120 0 Left 0 !.params Kp={0.204871*2*pi*f1} Ki={1*2*pi*f1} Kd={0.0104926*2*pi*f1} f1=10
TEXT 122 58 Left 0 !.op
TEXT 120 -56 Left 0 !.lib opamp.sub
TEXT 968 -600 Left 0 !.param fc=1
TEXT 968 -552 Left 0 !.params Km=1000 Kf={2*pi*fc/0.643594}
TEXT 968 -648 Left 0 ;For 2-pole cascade low-pass:
TEXT 1520 -384 Left 0 !.param Vdriver=15

 

[Helmut Sennewald]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> schrieb im Newsbeitrag
news:c910dm05ab@news2.newsguy.com...

Hi:

I have LTSpice 05/24/04 version. The circuit attached won't .op with
the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?

Hello Chris,
you made a mistake with the B-source LIMIT() fnction.

You have used V=limit(v(Vc),v(Vss),v(Vdd)) , but it have to be

V=limit(v(Vss),v(Vc),v(Vdd))

That's the reason why it hasn't work for you.

Please make the correction and it will work as intended.

Best Regards,
Helmut

 

[Chris Carlen]

Helmut Sennewald wrote:

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> schrieb im Newsbeitrag
news:c910dm05ab@news2.newsguy.com...

Hi:

I have LTSpice 05/24/04 version. The circuit attached won't .op with
the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?



Hello Chris,
you made a mistake with the B-source LIMIT() fnction.

You have used V=limit(v(Vc),v(Vss),v(Vdd)) , but it have to be

V=limit(v(Vss),v(Vc),v(Vdd))

That's the reason why it hasn't work for you.

Please make the correction and it will work as intended.

Best Regards,
Helmut

Thanks for the input Helmut.

I think my usage is correct. Since

limit(v(Vc),v(Vss),v(Vdd))

is equivalent to

min( max(v(Vc),v(Vss)), v(Vdd))

that means I am first choosing the greater of my Vc versus Vss=-15V,
then choosing the lesser of that result (which will be Vc if Vc is not
clipping) and Vdd=15V.

The proof is in the data, which are consistent with the intended operation.

The problem really seems to be with the op-amp models. When I change
the 2-pole to an ideal, then it works, and the clipping B source works
as advertized.

Good day!




--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Chris Carlen]

Mike Engelhardt wrote:

Chris,


I have LTSpice 05/24/04 version. The circuit attached won't
.op with the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?

I stuck the B source in so I could use an ideal opamp in
place of U4 and still get the clipping. So the B is
redundant with the 2-pole opamp installed.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.


As it also does if you then remove the B-source and use 2pole
opamps throughout to automatically limit the output voltage
to the supply rail limits, as in the file below. BTW, a
better drafting approach might be to use the UniversalOpamp
symbol which allows you to select the simulation level without
picking a different symbol. See ./examples/Educational/
UniversalOpamp.asc for further details.

--Mike

Trouble is I get many strange quirks and other problems when using your
more generalized models.

I will post a list of problems later when I get some time to categorize
them all...

Thanks for the assistance.

Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Mike Engelhardt]

Chris,

I have LTSpice 05/24/04 version. The circuit attached won't
.op with the 2-pole op-amp as shown.

Any idea how to make it more amenable to converging?

I stuck the B source in so I could use an ideal opamp in
place of U4 and still get the clipping. So the B is
redundant with the 2-pole opamp installed.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.


As it also does if you then remove the B-source and use 2pole
opamps throughout to automatically limit the output voltage
to the supply rail limits, as in the file below. BTW, a
better drafting approach might be to use the UniversalOpamp
symbol which allows you to select the simulation level without
picking a different symbol. See ./examples/Educational/
UniversalOpamp.asc for further details.

Trouble is I get many strange quirks and other problems when using your
more generalized models.

I will post a list of problems later when I get some time to categorize
them all...

It's better to e-mail examples to the e-mail address on the Help=>About
box. That's the address for support.

--Mike

 

[analog]

Chris Carlen wrote:

I have LTSpice 05/24/04 version. The circuit attached won't .op
with the 2-pole op-amp as shown.

You are quite right. This is interesting as at first blush it looks
like it should be all sweetness and cream, not a stubborn old maid.
But, no matter, I've never come across a shrew that couldn't be tamed.

Any idea how to make it more amenable to converging?

Yes, there are several things you might consider changing.

The impedance levels around your opamps are too low. During the hunt
for an operating point the voltages on Verr can get big enough to
overpower U2's ability to maintain virtual ground and flip the sense
of the gain through the opamps. This may cause the solver to latch
up on a false operating point. These impedances should all be at
least 1000x higher.

I stuck the B source in so I could use an ideal opamp in place of
U4 and still get the clipping. So the B is redundant with the
2-pole opamp installed.

Good try, but the real problem lies with the error amp that takes the
difference between Vref and Vp2. This voltage doesn't go to zero
rapidly enough when the solver resorts to source stepping.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.

Yes, the limiter actually makes things worse because it puts too
large of a bump in the solver's solution trajectory.

Anything can be done about this?

Yes, make certain that the output of the difference amp approaches
zero faster than anything else when the solver goes into source
stepping mode. One way to do this is to multiply the difference
amp's output by a unity node (1 volt dc). After the operating point
is found, obviously multiplying the output by unity will not change
it, but during source stepping this will force the node to monotonic-
ally fall to zero (no sticky trajectory bumps) and do so much faster
than it otherwise would. If necessary the troublesome node may be
multiplied by the unity node more than one time.

I have this trouble a lot when using the parametrized opamps.
Bummer because I like them when modeling systems when I don't yet
want to think about component specs.

This is a red herring. Keep your opamps and fix the problem at its
source. -- analog

Here's your circuit file back at ya' (beware word wrap).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 4
SHEET 1 1812 680
WIRE -304 -192 -304 -224
WIRE -304 -304 -304 -336
WIRE 240 -720 208 -720
WIRE 208 -720 208 -640
WIRE 208 -640 240 -640
WIRE 208 -640 176 -640
WIRE 304 -720 336 -720
WIRE 336 -720 336 -624
WIRE 336 -624 304 -624
WIRE 96 -640 -32 -640
WIRE 224 -224 240 -224
WIRE 176 -256 208 -256
WIRE 224 -336 208 -336
WIRE 208 -336 208 -256
WIRE 208 -256 240 -256
WIRE 304 -336 336 -336
WIRE 336 -336 336 -240
WIRE 336 -240 304 -240
WIRE 0 -256 -32 -256
WIRE -176 -336 -304 -336
WIRE -176 -288 -208 -288
WIRE -128 -352 -128 -400
WIRE -32 -400 -32 -448
WIRE -128 -272 -128 -224
WIRE 608 -368 672 -368
WIRE 1136 -160 -160 -160
WIRE -208 -160 -208 -288
WIRE -128 -400 -32 -400
WIRE 336 -624 368 -624
WIRE 336 -240 368 -240
WIRE 864 -416 896 -416
WIRE 896 -416 896 -384
WIRE 896 -416 928 -416
WIRE 1040 -384 1040 -416
WIRE 1040 -416 1008 -416
WIRE 1040 -416 1136 -416
WIRE 896 -272 896 -320
WIRE 1040 -320 1040 -272
WIRE 1136 -384 1136 -416
WIRE 1136 -304 1136 -160
WIRE 64 -256 96 -256
WIRE 224 -416 240 -416
WIRE 96 -448 -32 -448
WIRE 176 -448 208 -448
WIRE 224 -528 208 -528
WIRE 208 -528 208 -448
WIRE 208 -448 240 -448
WIRE 304 -528 336 -528
WIRE 304 -432 336 -432
WIRE 336 -432 336 -528
WIRE 576 -336 576 -304
WIRE 576 -304 608 -304
WIRE 576 -400 576 -432
WIRE 576 -432 608 -432
WIRE 624 -480 672 -480
WIRE 672 -480 672 -368
WIRE 544 -480 496 -480
WIRE 496 -480 496 -432
WIRE 496 -384 544 -384
WIRE 464 -624 496 -624
WIRE 496 -624 496 -480
WIRE 496 -384 496 -240
WIRE 496 -240 464 -240
WIRE 384 -240 368 -240
WIRE 384 -432 368 -432
WIRE 384 -624 368 -624
WIRE 528 -352 544 -352
WIRE 368 -432 336 -432
WIRE -416 -496 -416 -528
WIRE -304 -528 -304 -496
WIRE 720 -368 672 -368
WIRE 752 -384 752 -416
WIRE 752 -416 784 -416
WIRE 752 -272 752 -304
WIRE 496 -384 496 -432
WIRE 496 -432 464 -432
WIRE 224 -608 240 -608
WIRE -160 -160 -208 -160
WIRE -32 -448 -32 -640
WIRE -32 -400 -32 -256
WIRE -416 -608 -416 -640
WIRE -416 -640 -400 -640
WIRE -304 -608 -304 -640
WIRE -304 -640 -288 -640
WIRE -144 -496 -144 -528
WIRE -144 -608 -144 -640
WIRE -144 -640 -128 -640
FLAG -304 -192 0
FLAG 224 -608 0
FLAG 224 -224 0
FLAG -128 -224 0
FLAG -304 -336 Vref
FLAG -160 -160 Vp2
FLAG 368 -624 Vi
FLAG 368 -240 Vd
FLAG -208 -96 0
FLAG 896 -272 0
FLAG 1040 -272 0
FLAG 224 -416 0
FLAG -128 -400 Verr
FLAG 608 -432 Vdd
FLAG 608 -304 Vss
FLAG 528 -352 0
FLAG 368 -432 Vp
FLAG 672 -368 Vc
FLAG -416 -496 0
FLAG -304 -496 0
FLAG -400 -640 Vdd
FLAG -288 -640 Vss
FLAG 752 -272 0
FLAG -144 -496 0
FLAG -128 -640 u
SYMBOL voltage -304 -320 R0
WINDOW 3 127 -67 Right 0
WINDOW 123 22 94 Left 0
WINDOW 39 0 0 Left 0
SYMATTR Value PULSE(5 5.1 0.1 1u 1u 2 4)
SYMATTR Value2 AC 1
SYMATTR InstName V1
SYMBOL Opamps\\opamp 272 -688 R0
SYMATTR InstName U1
SYMBOL Opamps\\opamp 272 -304 R0
SYMATTR InstName U3
SYMBOL res 80 -624 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R1
SYMATTR Value {1/Ki}
SYMBOL cap 240 -704 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C1
SYMATTR Value 1
SYMBOL res 208 -320 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R2
SYMATTR Value {Kd}
SYMBOL cap 0 -240 R270
WINDOW 0 32 32 VTop 0
WINDOW 3 0 32 VBottom 0
SYMATTR InstName C2
SYMATTR Value 1
SYMBOL res 768 -400 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 95 56 VBottom 0
SYMATTR InstName R4
SYMATTR Value 1
SYMBOL res 912 -400 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 95 59 VBottom 0
SYMATTR InstName R5
SYMATTR Value {Km}
SYMBOL cap 880 -384 R0
SYMATTR InstName C3
SYMATTR Value {1/Kf}
SYMBOL cap 1024 -384 R0
WINDOW 3 -41 149 Left 0
SYMATTR InstName C4
SYMATTR Value {1/(Km*Kf)}
SYMBOL res 1120 -400 R0
SYMATTR InstName R3
SYMATTR Value {1k*Km}
SYMBOL res 80 -240 R270
WINDOW 0 64 54 VTop 0
WINDOW 3 63 58 VBottom 0
SYMATTR InstName R6
SYMATTR Value {Kd/(f1*10)}
SYMBOL Opamps\\opamp 272 -496 R0
SYMATTR InstName U2
SYMBOL res 80 -432 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R7
SYMATTR Value 1
SYMBOL res 208 -512 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R8
SYMATTR Value {Kp}
SYMBOL res 368 -608 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R9
SYMATTR Value 10k
SYMBOL res 368 -416 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R10
SYMATTR Value 10k
SYMBOL res 368 -224 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R11
SYMATTR Value 10k
SYMBOL res 528 -464 R270
WINDOW 0 32 56 VTop 0
WINDOW 3 0 56 VBottom 0
SYMATTR InstName R12
SYMATTR Value 10k
SYMBOL voltage -416 -624 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
WINDOW 0 32 30 Left 0
WINDOW 3 14 100 Left 0
SYMATTR InstName V2
SYMATTR Value {Vdriver}
SYMBOL voltage -304 -512 M180
WINDOW 0 39 85 Left 0
WINDOW 3 14 10 Left 0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V3
SYMATTR Value {Vdriver}
SYMBOL bv 752 -400 R0
WINDOW 3 1 163 Center 0
SYMATTR Value V=limit(v(Vc),v(Vss),v(Vdd))
SYMATTR InstName B1
SYMBOL Opamps\\2pole 576 -368 R0
WINDOW 0 20 -27 Left 0
SYMATTR InstName U4
SYMBOL voltage -144 -624 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
WINDOW 0 32 30 Left 0
WINDOW 3 14 100 Left 0
SYMATTR InstName V4
SYMATTR Value 1
SYMBOL bv -128 -368 R0
WINDOW 3 38 177 Left 0
SYMATTR InstName B2
SYMATTR Value V=V(Vref,Vp2)*V(u)
TEXT -32 -792 Left 0 !.param Kp={0.204871*w1} Ki={1*w1} Kd={0.0104926*w1}
TEXT -30 -750 Left 0 !.op
TEXT -32 -704 Left 0 !.lib opamp.sub
TEXT 760 -560 Left 0 !.param fc=1 wc=2*Pi*fc
TEXT 760 -528 Left 0 !.param Km=1k Kf={wc/0.643594}
TEXT 760 -600 Left 0 ;For 2-pole cascade low-pass:
TEXT 584 -128 Left 0 ;These PID parameters have been calculated\nso that they produce a numerator polynomial\nfor the compensator Hc(s) that cancels the numerator\nand denominator polynomials of the plant Hp(s).\n The parameter f1 sets the unity gain frequency in Hz for\nthe open loop transfer function which is just 2*pi*f1/s.\nIf you change the 2-pole filter fc, you must recompute the\nPID parameters by hand.
TEXT -112 -128 Left 0 ;Slight modification to original PID includes a high-frequency\nrolloff to the differentiator response, to avoid it producing very\nhigh voltage spikes in response to fast step input changes. \nThis additional pole is far enough above f1 of the open-loop \nresponse that it has negligible effect on the behavior compared\nto a straight differentiator.
TEXT -440 -448 Left 0 !.param Vdriver=15
TEXT -424 80 Left 0 ;Copyright (C) 2004 by Christopher R. Carlen
TEXT -32 -824 Left 0 !.param f1=10 w1=2*Pi*fc
RECTANGLE Normal -80 -464 -192 -656 2
RECTANGLE Normal 128 -176 -96 -208 2
RECTANGLE Normal -64 -240 -176 -432 2

 

[Chris Carlen]

analog wrote:

Chris Carlen wrote:


I have LTSpice 05/24/04 version. The circuit attached won't .op
with the 2-pole op-amp as shown.


You are quite right. This is interesting as at first blush it looks
like it should be all sweetness and cream, not a stubborn old maid.
But, no matter, I've never come across a shrew that couldn't be tamed.


Any idea how to make it more amenable to converging?


Yes, there are several things you might consider changing.

The impedance levels around your opamps are too low. During the hunt
for an operating point the voltages on Verr can get big enough to
overpower U2's ability to maintain virtual ground and flip the sense
of the gain through the opamps. This may cause the solver to latch
up on a false operating point. These impedances should all be at
least 1000x higher.

Hmm. The low impedances are around the ideal opamps. But wait. Let's
look at how ideal they really are. Ah-hah! Looking at the opamp.sub
which is simple enough for me to understand, I see that it is a current
source in parallel with a 1 ohm resistor and a cap. So perhaps there
are indeed issues with the peripheral impedances. I had been imagining
the opamp.sub to be an ideal voltage source output. This is not so.

Ok, so I agree that these opamps shouldn't be subjected to such low
impedances.

Notice that Mike's suggestion was to replace all the opamps by 2pole
types, and remove the B source driving the 1R load at the plant. I did
that and the .op converged. The strange thing is, when I then scaled up
my impedances by 1000 for the PID amps using parameter Km=1000, the
thing is broken again!

Things get wierder when I put back in a B source serving only as an
output buffer on U4. Now it converges for some values of Km such as
1000, 10000, 100000, but not for 100, and not for 2100 and other values.

This points to something else being wrong. But as I presently
understand things I can't imagine what.

So along comes Mr. analog who points at things I would never have
considered, relying on obvious insight into the inner workings of SPICE
that make him a fellow worth listening to. And he says:

I stuck the B source in so I could use an ideal opamp in place of
U4 and still get the clipping. So the B is redundant with the
2-pole opamp installed.


Good try, but the real problem lies with the error amp that takes the
difference between Vref and Vp2. This voltage doesn't go to zero
rapidly enough when the solver resorts to source stepping.

Hmm. Why? The capacitors certainly aren't involved in the .op I am
sure. You are obviously onto numerical algorithm issues rather than
electronic ones. This must require intimate knowledge of the solver
algorithms to understand. So I'll take your word for it at this point,
but I would enjoy some further detailed explanation. I am familiar with
some basic numerical algorithms, so hopefully I can follow along.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.


Yes, the limiter actually makes things worse because it puts too
large of a bump in the solver's solution trajectory.


Anything can be done about this?


Yes, make certain that the output of the difference amp approaches
zero faster than anything else when the solver goes into source
stepping mode. One way to do this is to multiply the difference
amp's output by a unity node (1 volt dc). After the operating point
is found, obviously multiplying the output by unity will not change
it, but during source stepping this will force the node to monotonic-
ally fall to zero (no sticky trajectory bumps) and do so much faster
than it otherwise would. If necessary the troublesome node may be
multiplied by the unity node more than one time.

Very perplexing. How on earth could multiplying v(Vref,Vp2) by 1 change
anything?

One possible reason is that we are multiplying by a voltage of 1 instead
of the constant 1. That likely means that the system matrix increases
its order by one, and this somehow results in a non-singular or no
longer ill-conditioned solution trajectory as you put it. But the
details of just how this is so escape me.

I have this trouble a lot when using the parametrized opamps.
Bummer because I like them when modeling systems when I don't yet
want to think about component specs.


This is a red herring. Keep your opamps and fix the problem at its
source. -- analog

I see. How do you explain Mike's less than effective solution? I would
sure like to hear his input on what you've offered.

Here's your circuit file back at ya' (beware word wrap).

Thanks for the tweaks and the readability improvements. It seems to
didn't mind too much my use of geometrically increasing load impedances
on the passive two-pole network in order to implement two
non-interacting poles rather than just putting in cascaded opamps.
Don't know, just takes less drafting space I suppose.

One minor glitch. You put w1=2*Pi*fc when it should be w1=2*Pi*f1 which
sets the open-loop gain. That way I can make the open-loop gain higher
than the fc of the plant, to experiment with how the controller can
force a plant to maintain control at higher system bandwidth than that
of the plant alone.

This whole thing is a self-teaching program in basic PID control.

I plan to take a linear algebra course in the fall. Might help get me
closer to understanding SPICE guts. I am actually taking it to get
better at control theory. Would like to understand state-space models
and stuff like that, plus general matrix math theory.

Thanks very much for your profound insight. As usual, you have proven
to be a valuable asset to the s.e.* community.

Good day!

--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[analog]

Chris Carlen wrote:

analog wrote:
Chris Carlen wrote:

I have LTSpice 05/24/04 version. The circuit attached won't .op
with the 2-pole op-amp as shown.

You are quite right. This is interesting as at first blush it
looks like it should be all sweetness and cream, not a stubborn
old maid. But, no matter, I've never come across a shrew that
couldn't be tamed.

Any idea how to make it more amenable to converging?

Yes, there are several things you might consider changing.

The impedance levels around your opamps are too low. During the
hunt for an operating point the voltages on Verr can get big
enough to overpower U2's ability to maintain virtual ground and
flip the sense of the gain through the opamps. This may cause the
solver to latch up on a false operating point. These impedances
should all be at least 1000x higher.

Hmm. The low impedances are around the ideal opamps. But wait.
Let's look at how ideal they really are. Ah-hah! Looking at the
opamp.sub which is simple enough for me to understand, I see that
it is a current source in parallel with a 1 ohm resistor and a cap.
So perhaps there are indeed issues with the peripheral impedances.
I had been imagining the opamp.sub to be an ideal voltage source
output. This is not so.

Ok, so I agree that these opamps shouldn't be subjected to such low
impedances.

Notice that Mike's suggestion was to replace all the opamps by 2pole
types, and remove the B source driving the 1R load at the plant. I
did that and the .op converged. The strange thing is, when I then
scaled up my impedances by 1000 for the PID amps using parameter
Km=1000, the thing is broken again!

A simulated circuit may have several numerically valid dc solutions
only one of which usually corresponds to the real circuit's natural
solution.

Things get wierder when I put back in a B source serving only as an
output buffer on U4. Now it converges for some values of Km such
as 1000, 10000, 100000, but not for 100, and not for 2100 and other
values.

Just because you see convergence don't assume all is well. Did you
carefully check the solution's dc node voltages to verify that they
were reasonable? For example, the voltages at the error amp, V(Vref)
and V(Vp2), should be nearly the same and no voltage anywhere should
exceed the +/- rail voltages. I'm willing to bet that at least some
of the "solutions" are anything but.

This points to something else being wrong. But as I presently
understand things I can't imagine what.

So along comes Mr. analog who points at things I would never have
considered, relying on obvious insight into the inner workings of
SPICE that make him a fellow worth listening to. And he says:

I stuck the B source in so I could use an ideal opamp in place of
U4 and still get the clipping. So the B is redundant with the
2-pole opamp installed.

Good try, but the real problem lies with the error amp that takes
the difference between Vref and Vp2. This voltage doesn't go to
zero rapidly enough when the solver resorts to source stepping.

Hmm. Why? The capacitors certainly aren't involved in the .op I
am sure.

Correct. Capacitors become opens and inductors become shorts.

You are obviously onto numerical algorithm issues rather than
electronic ones.

Yes, but it's only a small leap from the electronic to the numeric.

This must require intimate knowledge of the solver algorithms to
understand.

Not really. It just takes a general appreciation of what it must do.

So I'll take your word for it at this point, but I would enjoy
some further detailed explanation. I am familiar with some basic
numerical algorithms, so hopefully I can follow along.

Anything that makes the network approach linearity as either the
sources (or time steps) are scaled back should help the matrix solver
converge on a solution.

Cut out the 2-pole and install an ideal amp, and the circuit
converges in .op just fine.

Yes, the limiter actually makes things worse because it puts too
large of a bump in the solver's solution trajectory.

Anything can be done about this?

Yes, make certain that the output of the difference amp approaches
zero faster than anything else when the solver goes into source
stepping mode. One way to do this is to multiply the difference
amp's output by a unity node (1 volt dc). After the operating
point is found, obviously multiplying the output by unity will not
change it, but during source stepping this will force the node to
monotonically fall to zero (no sticky trajectory bumps) and do so
much faster than it otherwise would. If necessary the troublesome
node may be multiplied by the unity node more than one time.

Very perplexing. How on earth could multiplying v(Vref,Vp2) by 1
change anything?

It can't, except when 1 is less than 1 (which is just what happens
when all independent sources are gradually ramped up from zero during
solver source stepping mode). Then multiplying V(Vref,Vp2) by 1
forces it nearer to zero. Multiplying it by 1 squared reels it in
with even more authority.

One possible reason is that we are multiplying by a voltage of
1 instead of the constant 1. That likely means that the system
matrix increases its order by one, and this somehow results in a
non-singular or no longer ill-conditioned solution trajectory as
you put it. But the details of just how this is so escape me.

You are missing the point. Reflect a moment on how source stepping
works at all to aid convergence.

I have this trouble a lot when using the parametrized opamps.
Bummer because I like them when modeling systems when I don't
yet want to think about component specs.

This is a red herring. Keep your opamps and fix the problem at
its source.

I see. How do you explain Mike's less than effective solution?
I would sure like to hear his input on what you've offered.

Here's your circuit file back at ya' (beware word wrap).

Thanks for the tweaks and the readability improvements. It seems
to didn't mind too much my use of geometrically increasing load
impedanceson the passive two-pole network in order to implement two
non-interacting poles rather than just putting in cascaded opamps.
Don't know, just takes less drafting space I suppose.

I wasn't paying close attention to that part of your circuit, but
the passive network section is supposed to represent the response of
the plant, right? And there is a spot where you obviously had had
another capacitor for an addition high frequency pole.

One minor glitch. You put w1=2*Pi*fc when it should be w1=2*Pi*f1
which sets the open-loop gain. That way I can make the open-loop
gain higher than the fc of the plant, to experiment with how the
controller can force a plant to maintain control at higher system
bandwidth than that of the plant alone.

Whoops, I was only looking at dc convergence issues, so I was
completely blind to that sort of typo.

This whole thing is a self-teaching program in basic PID control.

I plan to take a linear algebra course in the fall. Might help get
me closer to understanding SPICE guts. I am actually taking it to
get better at control theory. Would like to understand state-space
models and stuff like that, plus general matrix math theory.

Should be fun.

Thanks very much for your profound insight. As usual, you have
proven to be a valuable asset to the s.e.* community.

Thanks, but you are too kind. -- analog

 

[Chris Carlen]

analog wrote:

Chris Carlen wrote:
Notice that Mike's suggestion was to replace all the opamps by 2pole
types, and remove the B source driving the 1R load at the plant. I
did that and the .op converged. The strange thing is, when I then
scaled up my impedances by 1000 for the PID amps using parameter
Km=1000, the thing is broken again!

A simulated circuit may have several numerically valid dc solutions
only one of which usually corresponds to the real circuit's natural
solution.

Things get wierder when I put back in a B source serving only as an
output buffer on U4. Now it converges for some values of Km such
as 1000, 10000, 100000, but not for 100, and not for 2100 and other
values.

Just because you see convergence don't assume all is well. Did you
carefully check the solution's dc node voltages to verify that they
were reasonable? For example, the voltages at the error amp, V(Vref)
and V(Vp2), should be nearly the same and no voltage anywhere should
exceed the +/- rail voltages. I'm willing to bet that at least some
of the "solutions" are anything but.

Hi analog, thanks for the input.

Actually, the solutions are quite correct, for I certainly did look for
the reasonableness of the numbers. I know better than to trust a
computer. I've included a copy again of the file which demonstrates
this. Oh, this circuit is slightly different from Mike's suggestion in
that I retain a B for buffering U4. Without that then things are even
worse.

Using Km=1000, 1500, 10000, 50000, 100000 converges to the correct
values. Other Km such as 100, 500, 2000, 5000, fail to converge. Quite
bizarre.

You are obviously onto numerical algorithm issues rather than
electronic ones.

Yes, but it's only a small leap from the electronic to the numeric.

This must require intimate knowledge of the solver algorithms to
understand.

Not really. It just takes a general appreciation of what it must do.

So I'll take your word for it at this point, but I would enjoy
some further detailed explanation. I am familiar with some basic
numerical algorithms, so hopefully I can follow along.


Anything that makes the network approach linearity as either the
sources (or time steps) are scaled back should help the matrix solver
converge on a solution.

I really know little about the DC solve methods. Can you provide a
brief summary? At this point I have noticed there appear to be three
ways it tries to crack the nut. I think the first one must be a
straight linear system of equations solution by the simple method of
A^-1*B where A is the coefficient matrix, and B is the constant term
matrix. The same way I do straightforward linear systems on my calculator.

Then there is this thing called "Gmin stepping". What is that?

Then there is "source stepping". What is that?

Very perplexing. How on earth could multiplying v(Vref,Vp2) by 1
change anything?


It can't, except when 1 is less than 1 (which is just what happens
when all independent sources are gradually ramped up from zero during
solver source stepping mode). Then multiplying V(Vref,Vp2) by 1
forces it nearer to zero. Multiplying it by 1 squared reels it in
with even more authority.


One possible reason is that we are multiplying by a voltage of
1 instead of the constant 1. That likely means that the system
matrix increases its order by one, and this somehow results in a
non-singular or no longer ill-conditioned solution trajectory as
you put it. But the details of just how this is so escape me.


You are missing the point. Reflect a moment on how source stepping
works at all to aid convergence.

Maybe when I get an idea of what it is in the first place ;-)


Ok, have a good day!




--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[analog]

Chris Carlen wrote:

Hi analog, thanks for the input.

Actually, the solutions are quite correct, for I certainly did look
for the reasonableness of the numbers. I know better than to trust a
computer. I've included a copy again of the file which demonstrates
this. Oh, this circuit is slightly different from Mike's suggestion
in that I retain a B for buffering U4. Without that then things are
even worse.

Using Km=1000, 1500, 10000, 50000, 100000 converges to the correct
values. Other Km such as 100, 500, 2000, 5000, fail to converge.
Quite bizarre.

LTspice would easily find valid solutions for them all if you would
just use the unity node multiplier method previously posted. You
really should make this method part of your standard tool set for
cracking tough convergence problems. It has *ALWAYS* worked for me,
and I've used on it on some wildly nonlinear circuits that stubbornly
refused all the usual techniques.

I really know little about the DC solve methods. Can you provide a
brief summary? At this point I have noticed there appear to be three
ways it tries to crack the nut. I think the first one must be a
straight linear system of equations solution by the simple method of
A^-1*B where A is the coefficient matrix, and B is the constant term
matrix. The same way I do straightforward linear systems on my
calculator.

Then there is this thing called "Gmin stepping". What is that?

Gmin is the minimum conductance allowed by the program. The default
value is 1e-12. Gminsteps defaults to 10 and is the number of steps
for Gmin used in solving for the operating point if convergence
initially fails. During gmin stepping, conductances are added to the
matrix diagonal, and reduced by a factor of 10 for each gmin step so
that on the final step the conductances are equal to the gmin variable.
See: http://www.intusoft.com/nlhtm/nl72.htm#Convergence_Methods

I've never done an objective comparison but it seems this method is
less effective than source stepping. IMO, LTspice would do better to
try source stepping first (there doesn't seem to be a standard for
this among simulator vendors).

Then there is "source stepping". What is that?

This algorithm makes uses the foreknowledge that a realistic simulation
always will have a known starting solution when all its sources are set
to zero (i.e. that all node voltages and branch currents are zero as
well). It also takes advantage of the fact that most all nonlinear
elements (e.g. diodes, mosfets, etc.) exhibit linear behavior locally
around zero (all junctions are off and other nonlinearities are, by
definition, operating with small signals).

So, by starting from a known, linear solution the solver can bootstrap
itself up to the normal operating point by gradually ramping up all the
sources. In theory each successful step along the way allows linearly
extrapolating an almost perfect set of initial conditions for solving
the succeeding nearby step.

Problems come when starting at zero doesn't yield a zero output. For
example, a behavioral error amp with a numeric reference voltage in a
difference equation (i.e. "5-V(fb)") will go to 5V when all sources are
at zero (LTspice actually has extended source stepping to B-sources to
address this). Difficulties can also occur when ramping up through
sharp corners or discontinuities in a nonlinear device's characteristic.
Multiplying a trouble point by a unity node voltage helps because it
tends to tilt the solution trajectory slope closer to the expected path,
thereby keeping it locally monotonic so it won't get stuck. See:
http://www.ent.ohiou.edu/~starzyk/network/Class/ee616/Slides/lec05_b.pdf

Hope this helps. -- analog

PS: Keep in mind that I don't have access to the LTspice source code so
my opinions about LTspice's internal workings are just that, opinions.

 

[Chris Carlen]

analog wrote:

Chris Carlen wrote:
Using Km=1000, 1500, 10000, 50000, 100000 converges to the correct
values. Other Km such as 100, 500, 2000, 5000, fail to converge.
Quite bizarre.


LTspice would easily find valid solutions for them all if you would
just use the unity node multiplier method previously posted. You
really should make this method part of your standard tool set for
cracking tough convergence problems. It has *ALWAYS* worked for me,
and I've used on it on some wildly nonlinear circuits that stubbornly
refused all the usual techniques.

I am using your method now for the PID, and will try it for other cases.
At this point, I am mentioning the still broken circuit mainly for
academic purposes.

Then there is this thing called "Gmin stepping". What is that?


Gmin is the minimum conductance allowed by the program. The default
value is 1e-12. Gminsteps defaults to 10 and is the number of steps
for Gmin used in solving for the operating point if convergence
initially fails. During gmin stepping, conductances are added to the
matrix diagonal, and reduced by a factor of 10 for each gmin step so
that on the final step the conductances are equal to the gmin variable.
See: http://www.intusoft.com/nlhtm/nl72.htm#Convergence_Methods

Oh yeah, I had read a little about this once.

Then there is "source stepping". What is that?


This algorithm makes uses the foreknowledge that a realistic simulation
always will have a known starting solution when all its sources are set
to zero (i.e. that all node voltages and branch currents are zero as
well). It also takes advantage of the fact that most all nonlinear
elements (e.g. diodes, mosfets, etc.) exhibit linear behavior locally
around zero (all junctions are off and other nonlinearities are, by
definition, operating with small signals).

So, by starting from a known, linear solution the solver can bootstrap
itself up to the normal operating point by gradually ramping up all the
sources. In theory each successful step along the way allows linearly
extrapolating an almost perfect set of initial conditions for solving
the succeeding nearby step.

Problems come when starting at zero doesn't yield a zero output. For
example, a behavioral error amp with a numeric reference voltage in a
difference equation (i.e. "5-V(fb)") will go to 5V when all sources are
at zero (LTspice actually has extended source stepping to B-sources to
address this). Difficulties can also occur when ramping up through
sharp corners or discontinuities in a nonlinear device's characteristic.
Multiplying a trouble point by a unity node voltage helps because it
tends to tilt the solution trajectory slope closer to the expected path,
thereby keeping it locally monotonic so it won't get stuck. See:
http://www.ent.ohiou.edu/~starzyk/network/Class/ee616/Slides/lec05_b.pdf

Hope this helps. -- analog

Jolly good!


Thanks for the interesting discussion, despite that fact that it is
about electronics which isn't in vogue in this group these days.

;-D


--
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19

 

[analog]

Chris Carlen wrote:

analog wrote:

LTspice would easily find valid solutions for them all if you would
just use the unity node multiplier method previously posted. You
really should make this method part of your standard tool set for
cracking tough convergence problems. It has *ALWAYS* worked for me,
and I've used on it on some wildly nonlinear circuits that stubbornly
refused all the usual techniques.

I am using your method now for the PID, and will try it for other
cases. At this point, I am mentioning the still broken circuit mainly
for academic purposes.

Got it. Bear in mind that unity node multiplication can be sprinkled
throughout a simulation wherever you suspect misbehavior. Differencing
circuits with a lot of dc and gain are always good candidates as are
abrupt limiters and behavioral expressions with node voltages in their
denominators such that when the sources go to zero, the expressions
blow up (something gone small / something gone to zero => infinity).
These types of expressions can be multiplied by the unity node raised
to whatever power required to make them behave.

Thanks for the interesting discussion, despite that fact that it is
about electronics which isn't in vogue in this group these days.

Have you paid a visit to the LTspice user's group over at Yahoo Groups?
It is almost all on topic and spam is actively removed. Helmut
Sennewald is moderator now and does an excellent job of keeping the
group tidy and organized. There are lots of files, link and resources
available, too. See: http://groups.yahoo.com/group/LTspice/

The easiest way to sign up is to first set up a free Yahoo email
account, although any other primary email account can be used as well
(remailers will be rejected). -- analog