Installing and using LTspice IV (now including LTXVII), From beginner to advanced

Administrator
Joined 2007
Paid Member
My method is try to first dazzle them with brilliance. If that fails, try to baffle them with BS. One or the other most times works :cool:

Jan

:) Oh yes, one or the other is always a get out of jail card to hold in reserve.

Another small contribution I found which may be useful:

How to Use a Chip Vendor Op-Amp Model in LTSpice

Jan

Thanks for that Jan.

I found (and still find) that so much knowledge is assumed when dealing with LT. What should be fairly simple operations can be absolutely baffling at first... and my problem is that I just don't use a lot of the functions often enough to remember how it was done. Lol, like adding a 3rd party model.

I stumbled through adding a Pspice opamp model here (post #146) but if you asked me to do it now then I would have to refer back to the tutorial. Such is life though :D

Adding a Pspice 3rd party model
 
If you jump in the time machine you can find all sorts of interesting things. Front lines of the simulator wars in 2005:

SuperSpice and new component | Electronics Forums

Both the LTspice and Superspice creators participate. I remember there was another thread somewhere that they were going back and forth about simulator design problems, and it was not all agreement. I can't find that thread though.

Here is the LTSpice announcement:

Google Groups
 
AX tech editor
Joined 2002
Paid Member
:) Oh yes, one or the other is always a get out of jail card to hold in reserve.



Thanks for that Jan.

I found (and still find) that so much knowledge is assumed when dealing with LT. What should be fairly simple operations can be absolutely baffling at first... and my problem is that I just don't use a lot of the functions often enough to remember how it was done. Lol, like adding a 3rd party model.

I stumbled through adding a Pspice opamp model here (post #146) but if you asked me to do it now then I would have to refer back to the tutorial. Such is life though :D

Adding a Pspice 3rd party model

Yes. Only so many hours in a day.
Right now I am trying to figure out if there is something like a .trace or .plot command where I can enter a function or equation that is then automagically plotted.
I don't think there is though.

Jan
 
AX tech editor
Joined 2002
Paid Member
Ahhhhh, here it is:

Google Groups

Mike's decisions make more sense IMO. And while he does sometimes sound like a braggart, you have to take into consideration that he's telling the truth. If it were anyone but him, it would just be taken as a statement.

That thread sounds like a Blowtorch thread for simulators :mad:

Jan
 
Ahhhhh, here it is:

This made me laugh (I doubt comprehensive benchmarks exist). The roots in the original Berkeley SPICE (like the virtual punch card SPICE deck interface) are there.

Mike Engelhardt, Author of the World's fastest SPICE: SwCADIII/LTspice

I disagree on the case in point floating nodes are problematic especially if you use ideal sources anywhere. Asking the user to check their circuit and intervene if needed is the right thing to do.

Right now I am trying to figure out if there is something like a .trace or .plot command where I can enter a function or equation that is then automagically plotted.

Punting the SPICE deck model and using a command line interface with macros makes it easy to add a Matlab-like set of commands mixing in user defines variables with waveforms.
 
Last edited:
AX tech editor
Joined 2002
Paid Member
This made me laugh (I doubt comprehensive benchmarks exist). The roots in the original Berkeley SPICE (like the virtual punch card SPICE deck interface) are there.



I disagree on the case in point floating nodes are problematic especially if you use ideal sources anywhere. Asking the user to check their circuit and intervene if needed is the right thing to do.

For me the most user-friendly way to approach this would be both a warning and a solution:

- this node is floating and will give you issues when you build it that way;

- but here's your .ac solution.

Best of both worlds.

Jan
 
For me the most user-friendly way to approach this would be both a warning and a solution:

- this node is floating and will give you issues when you build it that way;

- but here's your .ac solution.

Best of both worlds.

Jan

I understand the point, in fact I went to our guys 30yr. ago and asked them to add a complete save/restore command of all node voltages and currents so I didn't have to wait 10min for a DC convergence every time I tuned a capacitor in the compensation network. They didn't realize that changing reactances can't effect the DC values.

Floating nodes will break some sim eventually why not fix it?
 
IIRC LTspice does warn the user, if you look in the error log.

Also changing reactances can and does affect the DC solution found by the simulator, because those time constants must often be taken into account in order to arrive at the correct operating point.

LTspice does have a savebias feature where you can save the operating point and use it in the next simulation.
 
Last edited:
Syntax: .savebias <filename> [internal]
+ [temp=<value>] [time=<value> [repeat]] [step=<value>]
+ [DC1=<value>] [DC2=<value>] [DC3=<value>]

This command writes a text file to disk that is reloaded with a .loadbias command in a subsequent simulation. If you have a circuit that has a difficult-to-solve DC operating point, you can save that solution to disk so that the next analysis can save time finding the DC solution before proceeding to the rest of the simulation.
The keyword "internal" can be added to indicate that the internal nodes of some devices should also be kept so that a more complete version of the DC solution is kept.
If you want to save a particular DC operating point from a .tran analysis, you can give specify a time. The first solved time point after the stipulated time will be written. The modifier "repeat" will cause the DC solution to be written after every period specified by this time. The file will contain only the most recently solved DC point. DC1, DC2, and DC3 can be given to extract a single operating point from .dc sweep analysis.
The savebias command writes a text file in the form of a .nodeset command. Note that nodeset statements are only recommendations of the solution. That is, the solver will start iterating the solution with the node voltages given in the nodeset statements, but will continue iterating until it's satisfied that the solution is valid. If you want to restart a .tran solution from the DC operating point, you can edit the file from a .nodeset to a .ic to try to coercive the solver to start from this DC state.
Since the integration state of all the circuit reactances isn't saved in the .savebias file, success with this technique varies.

I do find it strange that LTSpice wants to recompute the operating point for every step in a simulation where only a capacitor is changed. It's a conservative decision I suppose in case the capacitor actually does change the operating point, but it causes simulations to take much longer than they need to.

One problem with saving the operating point is that if you create or delete any nodes it becomes useless. So it's not necessarily something you want to be using constantly.

Some of the options here might be useful in tuning the DC solution behavior:

DC Operating Point
Find the DC Operating Point

Perform a dc operating point solution with capacitances open circuited and inductances short circuited. Usually a dc solution is performed as part of another analysis in order to find the operating point of the circuit. Use .op if you wish only this operating point to be found. The results will appear in a dialog box. After a .op simulation, when you point at a node or current the .op solution will appear on the status bar.

Syntax: .op
There is no guarantee that the operating point of a general nonlinear circuit can be found with successive linear approximations as is done in Newton-Raphson iteration. Should direct Newton iteration fail, LTspice tries a number of other methods to find an operating point. Below is a table of the methods used and the options settings required to disable a particular method.

Method Directive to Disable
Direct Newton Iteration .opt NoOpIter
Adaptive Gmin Stepping .opt GminSteps=0
Adaptive Source Stepping .opt SrcSteps=0
Pseudo Transient .opt pTranTau=0
 
Last edited:
AX tech editor
Joined 2002
Paid Member
I understand the point, in fact I went to our guys 30yr. ago and asked them to add a complete save/restore command of all node voltages and currents so I didn't have to wait 10min for a DC convergence every time I tuned a capacitor in the compensation network. They didn't realize that changing reactances can't effect the DC values.

Floating nodes will break some sim eventually why not fix it?

Yeah that's probably the more sensible way. You need to fix it sometimes might as well do it right now.
 
Also changing reactances can and does affect the DC solution found by the simulator, because those time constants must often be taken into account in order to arrive at the correct operating point.

Not tuning a few pF at a time or if you run DC convergence to full resolution which was the case here. In fact It worked like a charm always and became a permanent feature. Remember this was 30+ years ago and Berkeley SPICE still used the original setting of nodes by hand as a sort of guessing game to speed convergence. It seemed obvious to me considering memory concerns were no longer necessary.

EDIT - There might be unnecessary discussion here, what we had to work with was fairly primitive (multi-user VAX) many of the simulation modes you might assume were available were not. Trimming capacitors involved editing the deck and restarting it from the beginning.
 
Last edited:
IIRC LTspice does warn the user, if you look in the error log.

Also changing reactances can and does affect the DC solution found by the simulator, because those time constants must often be taken into account in order to arrive at the correct operating point.

LTspice does have a savebias feature where you can save the operating point and use it in the next simulation.

Is this a solution when using big caps into a supply to measure ripple supression of amp?. Because that way I have to set a big value and costs a lot of time, if this is just once and save it
for the next time it is nice.