Kind friends

Please know that the following is an attempt to understand (as opposed to 'critique') the 'ways of Spice' -- I assure you this is utterly without 'attitude'! I approach this matter (and any responses) in an open, receptive and, most of all, grateful state of mind!

So... Here's the deal:

In an attempt to garner some measure of 'Spice proficiency' I have attempted to simulate a rather simple, familiar, 'tried and true' real world circuit -- with disappointing results

Real-world operation:
On power-up the 'real world' circuit's output EMF rises to a ≈ 110% 'overshoot' from which it recovers (within 50ms) to a highly stable, low noise (< 3mV) output -- Said noise being, as it is, characterized by the frequency of the oscillator - and, hence, merely 'ripple' - as opposed to 'regulation artifacts'...

Simulation:
The simulation's output rises to a ≈ 140% overshoot thence, following > 200ms 'recovery' time, 'breaks into' a train of ≈90V(p-p) 'rebound pulses' asymmetrically superimposed on a the DC output (≈ E{selected})

I find it especially curious that (with reference to each 'rebound cycle') the 'correction' comes 'late' (≈ 10V below E{selected}) and with marked rapidity (≈800us)... --- Perhaps I am merely witnessing the analog nature of reality in collision with the digital 'mechanism' of Spice?

Please note: that although LtSpice's rather limited component library compelled my drafting of the simulation with 'ideal' and otherwise 'missapplied' components, I have, following close examination of simulator behaviour, found the simulation of said components to 'jibe' with those applied to the 'real-world' circuit... - moreover, with the possible exception of the op-amp, said substitutions could not produce the erroneous results seen in the simulation (i.e. "undamped hunting")...

For convenience of the readers I have included a screen capture of the simulation as well as the LtSpice schematic file for the circuit in question...

Many, many advance thanks for any insight, assistance or alternate points of view!

Very best regards
HP

PS -- FWIW The semiconductors used in the actual circuit are documented in bold blue text on the .asc file and screen capture...

 

Hi

Can you post a screen capture of the real world circuit output to compare against the simulation?

 

with the possible exception of the op-amp

Therein seems to be the cause of the difference. If you reduce the values of R4 and R5 by a factor of 10 you will see the output stabilise in only ~6mS and the ripple amplitude also changes. This suggests to me (I could be wrong) that the input bias current needed by the opamp plays a big part.

 

Many thanks for your replies!

Hi

Can you post a screen capture of the real world circuit output to compare against the simulation?

While I apologize that such is not practically realizable with my present arrangement - I nonetheless assure you that following 'lock' (in <50ms) the output is 'rock solid' with a vestigial 3mv (p-p), ≈140 khz 'ripple' (which being upshot of imperfect 'filtration' of the full-wave rectified ≈ 70khz oscillator output)...

the ripple amplitude also changes.

Actually the ≈ 13 Hz 'sawtooth' is not truly ripple - but, rather, represents a train of overshoot/rebound cycles owed to an (inexplicably) persistent 'open loop' condition...

FWIW I feel I may be somehow misapplying the simulator inasmuch as simulations of this circuit often 'hang' or abort with a "Time step too small" exception?

Best regards and again, many thanks!
HP

 

simulations of this circuit often 'hang' or abort with a "Time step too small" exception?

That is a common problem; not just with your circuit. Sometimes just changing a component value slightly will fix it.

 

FWIW I feel I may be somehow misapplying the simulator inasmuch as simulations of this circuit often 'hang' or abort with a "Time step too small" exception?

As @Alec_t pointed out, this is actually a common problem in SPICE simulations. I often encounter it in situations like yours, where an op amp has no local DC feedback, just a capacitor, and it is most common with op amps that have extremely high open-loop DC gain, such as the LT1677, and with CMOS op amps such as the LMC6482, and especially with circuits in which the op amp output is followed by additional active elements that create still more gain.

My usual solution is the lazy one: I simply put a resistor, usually between 100 MΩ and 1 GΩ, between the op amp output and its inverting input. This lowers the local DC loop gain enough to allow the simulator to zero in on a solution that satisfies its tolerance limits. (It does alter the simulated circuit behavior slightly, but usually not enough to be a problem.)

 

The problem is an unstable loop, apparently from too much uncompensated loop phase-shift.
The loop is doing a limit cycle oscillation (loop saturates during the oscillation), that can be seen at the output of the op amp.
Likely the difference between the transformer (and possibly other device's) model parameters and your real parts are causing the problem, although with all the phase-shift in the loop from R2 and L5, I'm not sure how the real circuit stabilizes.

After some random (educated guess) parts' changes I got the loop to stabilize:
Used some 5A transistor models for Q1 and Q2 (default models can sometimes give unusual results).
Added an output load R9.
Added resistor R7 in series with M1's source (to reduce the loop gain).
Increased the value of C7 to slow the startup and minimize overshoot.
Changed the value of C10 plus added resistor R10 for some lead-lag feedback for U2.

Have fun.

Edit: Changed R2 back to 10kΩ

 

HP Like you know I DO have attitude abt Spice but this time Ltspice is right and like @crutschow says you’re just lucky real circuit is stable at all! Cuz components of loop are turning phase every which way but loose! So you can fix that by just adding compensation network b4 filter! So that way you just need two more components and can keep same small filter caps so you can save board space. But HP I say you should also use super low leakage zap traps on inverting input cuz compensation network can pass nasty spikes!

So here’s all I changed

◊I added compensation network of R7 and C5 I say time constant of abt 1us will prolly work just fine but you should adjust it for ur exact circuit!

◊Like @OBW0549 said I added big resistor in parallel to opamp fcomp Cap to make simulator happy so it doesn’t bomb but but just so you know simulation is really slow no matter what!

◊I changed fcomp cap to 100n cuz 1nf is totally lame and just weird! HP what were you thinking?

◊I also changed divider to program regulator for 1kv so is easier to study on plot but you need to know that programmed voltage is asymptote in Ltspice cuz of like you say _simulation artifacts_ So it's always approaching from one direction but can never be exactly equal in simulation but real circuit totally captures within 50ms with right network!

HP Now I’m going to tell you something! Like I keep saying you need to look on all feedback control loops as just servomechanisms cuz that’s exactly what they are! So I’m asking since you don’t have problems at all understanding PLL circuits why do you have like you say _mental block_ with just voltage regulators?! So my turn to say you have issues to work through!

HP now I’m asking how does it feel to be schooled by shameless drunken blonde bimbo harlot who aspires to be Pole just so I can find 192 proof vodka close as nearest liquor shop!

 

Aleph(0), note that the added resistive feedback (R9) for the op amp changes the loop such that it no longer has zero steady-state error.
That is generally undesirable.
My simulation shows it simulates and is stable without that resistor so it should be removed.

 

Aleph(0), note that the added resistive feedback (R9) for the op amp changes the loop such that it no longer has zero steady-state error.
That is generally undesirable.
My simulation shows it simulates and is stable without that resistor so it should be removed.

@crutschow Thanks! I put that there to try and _pacify_ Ltspice's quirkiness with high gain opamps but I don't use it in real circuits. Could you plz tell me a way of getting around super slow simulation speed? Is there a way enforce MINIMUM time step interval? TNX!

 

Is there a way enforce MINIMUM time step interval?

Now that would be nice! If there is a way I haven't found it. Tinkering with the tolerances is all very well but .....

 

It's slow because it is simulating a switching circuit and all the ensuing oscillations, so you are limited by your computer processor speed.
All Spice programs exhibit the same issue and LTspice is actually faster than most for simulation of such circuits.

 

First off, many thanks to all respondents!

Thanks to your kind feedback (NPI) I've not merely resolved a 'Spice question' -- But, for the first time, truly benefited from use of spice as a design tool (as opposed to mere 'tinkering with a novelty')

Re: MY modification of the circuit attached to post #8: (Please see the attached image and/or schematic file below)
Inasmuch as I will wish to provide for fine adjustment of E[selected] (A feature which might, IMO, best be realized via placement of a 'rheostat-connected' potentiometer in series with R5 and the sample takeoff [FB])
I've intervened the divider and integrator input with an 'isolation' resistance (R9) such that the compensation network constants are, FAIAP, independent of the division ratio....

Any comments, perspectives and/or monitions will be greatly appreciated! --- FWIW the value of said resistor (R9) was a trade off between 'degree of isolation' and (initial) 'lock' time -- while, as simulated, 220kΩ 'drags it out' for the better part of one second, the real-life circuit attains 'lock' in less than 100ms (owing, perhaps, to differences in simulated vs real-life circuit op-amp input impedances?)

So I’m asking since you don’t have problems at all understanding PLL circuits why do you have like you say _mental block_ with just voltage regulators?!

Yours is a good question but with an embarrassing answer -- My original circuit (attached to post #1 of this thread) was based upon a manufacturer's application example -- I hadn't noticed that instead of an integrator, the literature's circuit featured a digitally implemented 'switching regulator controller' -- thus obviating requirement of analog phase compensation... Hence, the answer to your question: I was both unobservant and, most egregiously, too lazy to so much as cursorily evaluate the 'derived' circuit... No excuses!

I changed fcomp cap to 100n cuz 1nf is totally lame and just weird! HP what were you thinking?

That's one on me! I have no idea how I missed that!

now I’m asking how does it feel to be schooled by shameless drunken blonde bimbo harlot who aspires to be Pole just so I can find 192 proof vodka close as nearest liquor shop!

---Emphasis added---

@Aleph(0) Ya know, dispelling your 'naive numpty' persona really doesn't require redefining yourself as a reprobate! Merely 'cooling it' with the 'Mavis Moulterd' routine oughta do it

Could you plz tell me a way of getting around super slow simulation speed?

Now that would be nice! If there is a way I haven't found it. Tinkering with the tolerances is all very well but .....

It's slow because it is simulating a switching circuit and all the ensuing oscillations, so you are limited by your computer processor speed.
All Spice programs exhibit the same issue and LTspice is actually faster than most for simulation of such circuits.

Odd thing is that simulation of the free running oscillator is very fast -- on the other hand simulation of the controlled circuit quickly becomes excruciatingly slow even running on my dedicated i7 (3.5 GHz) machine

Again! I'm very grateful for your thoughtful responses and quite pleased that Spice actually 'caught' a design error thus 'legitimizing' itself in my eyes as a bona fide tool worthy of serious study to the end of 'acquisition'

Very best regards and many thanks all around!
HP

 

Odd thing is that simulation of the free running oscillator is very fast -- on the other hand simulation of the controlled circuit quickly becomes excruciatingly slow

I think that's because there are a lot more nodes changing voltage with the controlled circuit as compared to the oscillator.
And since each node changing affects all the adjacent nodes, the amount of computations require for the next voltage increment increases greatly.

 

as simulated, 220kΩ 'drags it out' for the better part of one second, the real-life circuit attains 'lock' in less than 100ms (owing, perhaps, to differences in simulated vs real-life circuit op-amp input impedances?)

The op amp input impedance is very high and has absolutely nothing to do with the time the circuit takes to settle.
The settling time is determined by other circuit time-constants in the feedback loop.

Note that the circuit modifications I made in post #7 allowed the circuit to settle in about 15ms.

 

Note that the circuit modifications I made in post #7 allowed the circuit to settle in about 15ms.

Thanks for bringing that to my attention! Thus it seems very short 'lock times' are possible where some overshoot is acceptable -- Moreover, the dramatic stabilizing effect of the 'source degeneration' resistance most interesting as is the 'delayed feedback' arrangement! -- Definitely worthy of further analysis via simulation and 'in vivo', as it were

Very best regards
HP

 

most interesting as is the 'delayed feedback' arrangement!

Are you referring to the added resistor in series with the feedback capacitor?
That actually rather reduces the delay (in the time-domain) since the resistor now determines the high frequency feedback gain above the RC corner frequency.
Thus for a step input you will get a step at the output plus an integration of the step.

 

Are you referring to the added resistor in series with the feedback capacitor?
That actually rather reduces the delay (in the time-domain) since the resistor now determines the high frequency feedback gain above the RC corner frequency.

Indeed, I was referring to the τ=2ms 'phase delay' (perforce the ≈ 80Hz cutoff frequency) Re: the op-amp's feedback signal itself -- as opposed to the resultant system amplitude (i.e. 'group') 'skew'...

Thus for a step input you will get a step at the output plus an integration of the step.

Indeed! - Having explored LtSpice's simulation of a few randomly drafted 'lead-lag' compensation networks - I'm bound to say I'm pleased (and, frankly, surprised) with said simulator's fidelity to the derived transfer functions of same --- Which being more than can be said for ORCAD's simulator (but then I may be doing ORCAD the same injustice formerly done LtSpice -- à la 'it's a poor worker who blames his/her tools!')

Very best regards and many thanks!
HP

 

I've used Spice base simulators for years and find that they seldom give results that are significantly different from the actual circuit, as long as you are operating within the specification limits of the device and you have reasonably good device models.
If there is a problem with the simulation, it's usually apparent by output results that are really strange or physically impossible.
I would never consider building a circuit, even a simple one, without first simulating it. I've caught a lot of design errors that way.
And the ability to readily change component values and to easily look at voltages and currents anywhere in the circuit allows a degree of circuit operation understanding that can be difficult or impossible to achieve with the real circuit, even with a collection of good measurement equipment.
But random circuit configurations that don't respect the component limitations can give strange results (such as an output of 1e27 volts!).
Basically I find that, as is usual in engineering, garbage-in garbage-out.

 

HP Sry to throw ice water on this (which I should be saving for JC anyhow) but however you do phase compensation I say you need lower reference voltage cuz 4.7V isn't convenient for zaptraps made of, like you are thinking, just diode connected jfets! Cuz I say that gives guaranteed margin of 0.4V and developing special rails just for zaptrap returns is totally bogus!

HP protecting opamp input from transients is more than just _good idea_ it's totally necessary! Even if fb is from just single path from output of rectifier filter through divider (which is like in post 7)

So I can't find discrete Zeners with Vz < 1V so I say since opamp input is super high z so also super buffered you can just use higher voltage ZD and resistive divider for reference of like 0.3V