Setting or Freezing Plot Scales
First let me congratulate the author(s) and those that support this
software. It is really useful and easy to use. My daughter, who is
an engineeing sophmore, has even started to use LTSpice for some
labs.
I am looking for a way to either pass plot scales from a dot
statement (.PLOT or .VIEW kind of thing) or at least to freeze the
plot scales from run to run. It would be helpful when trying to
visually compare the the results between runs if the the plot did
not automatically rescale. It would also be nice to be able to have
an alias type statement to save reentering things like V(out)/V(in)
or V(N003, N006)/I(R7).
Again, thank you for the software and thanks to Linear Tech for
their part in this.
|
Re: resistance values that depend on simulation time
Thanks for the quick reply. I figured there had to be a way to do
this. I will give it a whirl.
--Brent
toggle quoted message
Show quoted text
--- In LTspice@..., Panama Mike <panamatex@y...> wrote: ...But I need to model the time dependence of these
devices as the temperature is ramped. Is there any
way to specify a resistor value that is dependent
on the simulation time. There's an undocumented means to do this. You might
have convergence trouble with it, especially if you
put it inside a feedback loop. Here's a resistance
that varies as the sine of time:
|
Re: New Feature Released & Opamp Modeling
toggle quoted message
Show quoted text
-----Original Message-----
From: Panama Mike [mailto:panamatex@...]
Sent: 24 maart, 2003 23:59
To: LTspice@...
Subject: Re: [LTspice] New Feature Released & Opamp Modeling
I put up a version of LTspice today with a
new feature. There's a new symbol attribute
called ModelFile. This lets you specify a
file to include as a library file whenever
this symbol is included. However, the symbol
is still edit-able. This let's you enter
parameters to pass to the subcircuit.
There's two example symbols of the use of
these feature included, 1pole.asy and
2pole.asy in the opamp directory. These
are somewhat ideal opamps with allow the
following parameters to be entered to
model a specific opamp:
Avol open loop DC gain.
GBW open loop gain-bandwidth product
Slew slew rate
Ilimit output current limit
rail how close output can get to the rail
Vos input offset voltage
en equiv. input voltage noise
enk equiv. input voltage noise corner freq
in equiv. input current noise
ink equiv. input current noise corner freq
The model draws all current from the voltage
supplies and has a signal internal node.
Output stage emitter followers are set to 100
Ohms, but you can change that if you need a
more ideal opamp.
The 2pole version has two internal nodes and
an additional parameter, phimargin, which
specifies the 2nd pole in terms of the (approx
-imate) phase margin in degrees.
Input bias, input common mode range and PSRR
are not modeled.
Let me know if you find these things useful.
--Mike
Thanks Mike,
The opamp model is just what I needed.
In the unlikely event that you have nothing to do, please think about a few
thinks:
- display of node numbers in the schematic: no need to remember or label if
you want to make an expression using node voltages.
- a quick way to probe voltages across components. Perhaps alt + left mouse
button?
- a way to store multiple analysis commands. If I use .tran and .ac
commands, only the parameters of the last one is saved, the other gets lost
on exit of the program.
Thanks for you great software and support.
Reinier Gerritsen
The Netherlands
|
Re: New Feature Released & Opamp Modeling
On Mon, 24 Mar 2003 15:43:54 -0800, you wrote: On Mon, 24 Mar 2003 14:59:23 -0800 (PST), you wrote:
I put up a version of LTspice today with a
new feature. There's a new symbol attribute
called ModelFile. This lets you specify a
file to include as a library file whenever
this symbol is included. However, the symbol
is still edit-able. This let's you enter
parameters to pass to the subcircuit.
<snip>
Let me know if you find these things useful. Yes! I'll be using it immediately. Thanks!
Jon Okay, tried it and like it. Originally, when I started using LT Spice, I wanted to add a new symbol for the PUJT type of device. You gave me an example of this which went a very long way in teaching me about using spice (I was, and still largely am a neophyte in nearly every sense of that.) This new feature you've added allowed me to create a PUJT.LIB file and link it to the symbol (.asy) which you made for me back in January. Now LT Spice naturally finds the model without me having to specifically write a .include for it. Thanks. In the above case, it would be nice if LT Spice would put a "Select Subcircuit" button on the dialog box which comes up when I right-click on the symbol (if the .ASY symbol is an X type) and provide me a list of .SUBCKT entries it found in the specified library file. In that case, the PUJT.LIB case, this means it would pop up 2N6027 and 2N6028, for example, and offer those as options. I haven't used spice enough to apprehend the implications of doing that, but it's a suggestion which pops into my mind given my limited use, to date. Anyway, thanks much! Jon
|
Re: resistance values that depend on simulation time
...But I need to model the time dependence of these
devices as the temperature is ramped. Is there any
way to specify a resistor value that is dependent
on the simulation time. There's an undocumented means to do this. You might have convergence trouble with it, especially if you put it inside a feedback loop. Here's a resistance that varies as the sine of time: * arbitrary resistor -- even goes negative R1 1 0 1K R=sin(time) ; the 1K is a dummy value I1 0 1 1m .tran 10 .end The 1K "value" of the Resistor is there to bypass the error message that the resistance must not be zero. This value is not used when you use R=<expression> syntax(I never thought of this condition when I added the message so I'll get rid of this error message when an expression is used.) One other caveat I would like to bring up is that there are no time step size checks caused by this resistance expression, so you may have to stipulate a max time step when you use this construction. Good luck with that critter. I thought it might be useful when I wrote it but never really had any use for it myself. Let me know if you find something that needs fixing regarding this. --Mike __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
|
resistance values that depend on simulation time
I just started using LTSPice a few weeks ago to model semi-insulating
electro-optic devices as RC-mesh/networks. It works great... But I
need to model the time dependence of theses devices as the
temperature is ramped. Is there any way to specify a resistor value
that is dependent on the simulation time. I know you can specify a
voltage that is dependent on simulation time by using the PULSE
command, or an behavioral voltage source using a mathmatical
expression with the variable "time". Can you specify a resistor
value that is a fuction of simulation time in a similar manner? If
not, is there any other way to accomplish this?
|
Re: New Feature Released & Opamp Modeling
On Mon, 24 Mar 2003 14:59:23 -0800 (PST), you wrote: I put up a version of LTspice today with a
new feature. There's a new symbol attribute
called ModelFile. This lets you specify a
file to include as a library file whenever
this symbol is included. However, the symbol
is still edit-able. This let's you enter
parameters to pass to the subcircuit.
<snip>
Let me know if you find these things useful. Yes! I'll be using it immediately. Thanks! Jon
|
Re: New Feature Released & Opamp Modeling
I put up a version of LTspice today with a
new feature. There's a new symbol attribute
called ModelFile. This lets you specify a
file to include as a library file whenever
this symbol is included. However, the symbol
is still edit-able. This let's you enter
parameters to pass to the subcircuit.
There's two example symbols of the use of
these feature included, 1pole.asy and
2pole.asy in the opamp directory. These
are somewhat ideal opamps with allow the
following parameters to be entered to
model a specific opamp:
Avol open loop DC gain.
GBW open loop gain-bandwidth product
Slew slew rate
Ilimit output current limit
rail how close output can get to the rail
Vos input offset voltage
en equiv. input voltage noise
enk equiv. input voltage noise corner freq
in equiv. input current noise
ink equiv. input current noise corner freq
The model draws all current from the voltage
supplies and has a signal internal node.
Output stage emitter followers are set to 100
Ohms, but you can change that if you need a
more ideal opamp.
The 2pole version has two internal nodes and
an additional parameter, phimargin, which
specifies the 2nd pole in terms of the (approx
-imate) phase margin in degrees.
Input bias, input common mode range and PSRR
are not modeled.
Let me know if you find these things useful.
--Mike
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
|
Re: limiting saved simulation data & selectively exporting plot data
--- In LTspice@..., "john_oztek" <joconnor@o...> wrote: Also, is there a way to selectively export plot data? It would be
really nice to be able to bring particular traces into Mathcad, for
example, for more detailed analysis. It would also be very
beneficial to be able to e-mail data to plot a few traces.
Hello John, you can use the program "ltsputil.exe" program to export selectively nodes of your circuit. The output is in a tabular form which can be used directly with hopefully all of the math and graphic programs. It is in the download area of this group. Path: Files->Util Best Regards Helmut
|
Re: limiting saved simulation data & selectively exporting plot data
Use the .save command to list those nodes and voltages
that you wish... --Mike
Mike, Thanks for the quick response! I'll give that a try. - John
|
Re: limiting saved simulation data & selectively exporting plot data
Use the .SAVE command option, also in the tools control panel the compression option can be set to ASCII data file which can parse by Mathcad with a lot of effort. --- In LTspice@..., "john_oztek" <joconnor@o...> wrote: Is there any way to limit the number of voltages and currents that
are saved during a transient analysis? Over the weekend I ran a
simulation of a poly-phase voltage regulator. The resulting data
file was nearly 5G! It took about 20 minutes this morning just to
load up 7 or 8 traces to view. I've noticed that the time to load a trace grows with the number of nodes, not just the simulation period, so I'm thinking that I could save a lot of time if I could be
selective about what data I save.
Also, is there a way to selectively export plot data? It would be
really nice to be able to bring particular traces into Mathcad, for
example, for more detailed analysis. It would also be very
beneficial to be able to e-mail data to plot a few traces.
Thanks,
John
|
Re: limiting saved simulation data & selectively exporting plot data
Is there any way to limit the number of voltages and
currents that are saved during a transient analysis?
[...] Use the .save command to list those nodes and voltages that you wish. If there is no .save command, then it saves the defaults, which you can set in Tools=>Control Panel=>Save Defaults.(That's where you tell it to save subcircuit nodes and device currents if you wish). Also of interest might be the special .save keyword of "dialogbox". For example, the syntax ".save V(in) V(out) dialogbox" will throw up a dialog box at the start of simulation of nodes and currents to save. V(in) and V(out) will be selected and you can select other quantities by clicking on the nodes/devices in the schematic. --Mike __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
|
limiting saved simulation data & selectively exporting plot data
Is there any way to limit the number of voltages and currents that
are saved during a transient analysis? Over the weekend I ran a
simulation of a poly-phase voltage regulator. The resulting data
file was nearly 5G! It took about 20 minutes this morning just to
load up 7 or 8 traces to view. I've noticed that the time to load a
trace grows with the number of nodes, not just the simulation period,
so I'm thinking that I could save a lot of time if I could be
selective about what data I save.
Also, is there a way to selectively export plot data? It would be
really nice to be able to bring particular traces into Mathcad, for
example, for more detailed analysis. It would also be very
beneficial to be able to e-mail data to plot a few traces.
Thanks,
John
|
New Opamp Modeling Method (Re: More on Burr Brown Models)
--- In LTspice@..., Panama Mike <panamatex@y...> wrote: Dale wrote:
Mike, this sounds like something I'd like to
dissuade you from. Helmult wrote:
I fully agree with you. The biggest advantage
of all the opamp models
[...]
The provided SPICE models should be also optimized
for good convergence in the simulation. If a model
doesn't provide some features like noise modeling
(.AC), it should behave more like an ideal
component in such a type of simulation. The problem is that the PSpice models often don't
converge very well and don't model noise correctly.
That has nothing to do with Linear's opamp models,
it's common to most Boyle style models.
Hello Mike, I have never said here that it is specific for LT models. My statement has been a general one for all vendor's models. If it is true that the Boyle model is so weak, why not starting with another SPICE model? I am shure that LT has the right people(you for example) to make excellent models. They don't
converge well in PSpice either. It's just a really
lame modeling methodology. Sometimes I honestly
get the impression that SPICE macromodeling
engineers tweak a model until it doesn't run anymore
and pronounce it done at that point, blaming any
convergence problems are due to the simulator. I have experimented with my own generic opamp model and indeed it converges very different depending on the choosen circuit. LTSPICE has been greatly improved over the last year regarding convergence problems. Most of the problems seem to be history. Of course the advantage of being able to run
them in PSpice is important. There are even more SPICE simulators around. Some of them are specific SPICE simulators like ICAP and others are part of PCB-CAD packages. All these users need/want SPICE models of LT opamps. Finally I hope that LT always provide opamp models for the whole SPICE "family" too. Best Regards Helmut
|
Re: New Opamp Modeling Method (Re: More on Burr Brown Models)
Dale wrote:
Mike, this sounds like something I'd like to
dissuade you from. Helmult wrote:
I fully agree with you. The biggest advantage
of all the opamp models
[...]
The provided SPICE models should be also optimized
for good convergence in the simulation. If a model
doesn't provide some features like noise modeling
(.AC), it should behave more like an ideal
component in such a type of simulation. The problem is that the PSpice models often don't converge very well and don't model noise correctly. That has nothing to do with Linear's opamp models, it's common to most Boyle style models. They don't converge well in PSpice either. It's just a really lame modeling methodology. Sometimes I honestly get the impression that SPICE macromodeling engineers tweak a model until it doesn't run anymore and pronounce it done at that point, blaming any convergence problems are due to the simulator. Essentially all customer-reported SwCADIII convergence problems reported deal with using these opamp models. But inside the mixed-mode simulator in LTspice is the ability to model an opamp model like I described. Few convergence problems, one or two internal nodes, good noise modeling and almost no load on the simulation run time. The technology already exists in LTspice and is used in the SMPS products' error amps. Another problem I have is there's some newer Linear opamps that don't have any SPICE models. If I go to this new method, then I can make a model in less than an hour that will be more accurate than the former PSpice models. It's much cheaper and it's hard to justify these expensive PSpice models that don't work well. Of course the advantage of being able to run them in PSpice is important. --Mike __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
|
New Opamp Modeling Method (Re: More on Burr Brown Models)
--- In LTspice@..., "Dale" <dchishol@c...> wrote: --- In LTspice@..., Message 141, Panama Mike
<panamatex@y...> wrote:
< snip >
BTW, I'm thinking of introducing opamp models that
use a different modeling methodology, similar to
that used for LTspice's SMPS products. The result
would be computationally extremely lightweight and
robust models that model noise too(these PSpice-
style opamp models almost never get the noise
modeled). However, the opamps models would not
run in other SPICE simulators and non-LT opamp
models wouldn't be available. Would you folks be
interested in something like that?
--Mike
Mike, this sounds like something I'd like to dissuade you from.
Part of the strength of the SPICE methodology is that the models are
transmitted as "open source", simple text files. The most significant advantage is that we Mere Mortals can easily extend, improve, correct, or modify models as needed.
Hello Dale, I fully agree with you. The biggest advantage of all the opamp models from different vendors is that they follow the general accepted SPICE syntax. This standard has been the base for the success of SPICE over the last thirty years. This is at least true for most of the analog parts like diodes, transistors, passive components and the opamps. It may be different for SMPS, because they are much more mixed signal devices. Here we have a lack of standard for digital parts and also a missing standard for behavioral language syntax. One more reason is the needed compuational speed of SMPS models for effective usage. I believe it is ok to have special models for the SMPS, because they are developed independently of the other anaolg/digital circuits of a design. Hello Mike, I recommend to keep the "easier" parts like opamps compatible with standard (P)SPICE, because many of LT customers use other SPICE simulators for different reasons. The provided SPICE models should be also optimized for good convergence in the simulation. If a model doesn't provide some features like noise modeling (.AC), it should behave more like an ideal component in such a type of simulation. Best Rgeards Helmut
|
New Opamp Modeling Method (Re: More on Burr Brown Models)
--- In LTspice@..., Message 141, Panama Mike <panamatex@y...> wrote: < snip >
BTW, I'm thinking of introducing opamp models that
use a different modeling methodology, similar to
that used for LTspice's SMPS products. The result
would be computationally extremely lightweight and
robust models that model noise too(these PSpice-
style opamp models almost never get the noise
modeled). However, the opamps models would not
run in other SPICE simulators and non-LT opamp
models wouldn't be available. Would you folks be
interested in something like that?
--Mike
Mike, this sounds like something I'd like to dissuade you from. Part of the strength of the SPICE methodology is that the models are transmitted as "open source", simple text files. The most significant advantage is that we Mere Mortals can easily extend, improve, correct, or modify models as needed. The parent thread for this posting is a good example. Because almost everything about the model was in plain view, several minds were independently analyzing the problem and solving it. I cannot imagine the problem being resolved nearly as quickly if the model's topology and parameter values had been locked-up in a proprietary format readable only by a few people. The SPICE methodology permits individuals to customize models as needed. If, for instance, noise is a critical performance characteristic the necessary elements can be readily included to model it. Otherwise they may be omitted. Similarly, a small-signal stage where output limiting is not a concern can get by with a simplified output circuit in the model. Along the same line it is relatively easy to adjust model parameters to fit particular situations. The model can be customized to reflect the device's behavior at, say, a temperature extreme. Or an engineer can investigate the implications of using a device whose performance parameters (like offset voltage or slew rate) are near the data sheet limits. Likewise the need for parts specially selected for certain characteristics (such as low offset current) can be evaluated. Finally the current SPICE modeling methodology allows engineers to quickly create workable models for new or alternative components. I hope that whatever modeling methodology you choose will retain these features. Dale
|
OT: You Have My Admiration (Re: LTspice +)
Quite apart from LTSpice, please accept a moral and ethical
commendation. By living in another culture & learning its language
you are promoting international understanding and respect for all
persons. This is unusual even among educated professionals. When I
was rushed to Mexico City after the earthquake, I learned that one of
my co-workers believed ANYBODY could understand English if only it was
spoken loudly and clearly enough.
An old joke asks, "If somebody who speaks 3 languages is trilingual
and somebody who speaks 2 languages is bilingual, what term describes
somebody who speaks but one language?" The answer, of course, is
"American". This situation is a symptom of a larger arrogance and
self-centeredness which we never intended to cultivate and are
certainly not proud of, but which often limits our ability to accept
others as truly human and our equals. (Yes, I include myself in that
indictment: with the minimal Spanish I learned in High School I could
bumble through ordering from a menu, and possibly even ask for
directions, but writing a coherent paragraph, reading a newspaper or
even normal conversation are beyond me. )
Again, thanks for doing your part. I hope nobody recognizes that I
carry a Scottish name and expects me to reply in Gaelic . . .
toggle quoted message
Show quoted text
--- In LTspice@..., Panama Mike <panamatex@y...> wrote: Arnold,
thanks for finding and solving the +problem.
My (LTspice-) World doesn't seem to collapse
in the near future any more. Das freut mich. (English: Glad to hear it.)
Mr. Engelhardt, are you German? your Name is. Nee, ich bin Amerikaner. Aber ich wohnte ein
Jahr in Mainz. Nicht bei der Army aber auf
der Uni. Das war in 1978. Man versteht meine
deutsch Errantnisse ist in der Zwichenseit
auseinander gefallen. Normaleweise versuche
ich nie auf deutsch zu schreiben.
(English: Nope, I'm American. But I lived
a year in Mainz, Germany. Not with the Army
but at the university. That was in 1978
and my German knowledge has fallen to pieces
in the meanwhile. Normally I avoid writing
in German Language.)
--Mike
|
--- In LTspice@..., Arnold Esper <arnold.esper@n...> wrote: Hallo Helmut and Mike Engelhardt,
thanks for finding and solving the +problem. My (LTspice-)World doesn't seem to collapse in the near future any more.
Hello Arnold and all LTSPICE users. I have uploaded an example how your netlist based circuit can be converted to a LTSPICE schematic and model file. It is hopefully all explained in the comments in this schematic. All the necessary files are in the files area of this group. Files->Examples->Educational->From netlist to schematic Have fun with it. Thanks to Mike too for the correction of the '+' problem in the PWL syntax. Best Regards Helmut
|
Arnold, thanks for finding and solving the +problem.
My (LTspice-) World doesn't seem to collapse
in the near future any more. Das freut mich. (English: Glad to hear it.) Mr. Engelhardt, are you German? your Name is. Nee, ich bin Amerikaner. Aber ich wohnte ein Jahr in Mainz. Nicht bei der Army aber auf der Uni. Das war in 1978. Man versteht meine deutsch Errantnisse ist in der Zwichenseit auseinander gefallen. Normaleweise versuche ich nie auf deutsch zu schreiben. (English: Nope, I'm American. But I lived a year in Mainz, Germany. Not with the Army but at the university. That was in 1978 and my German knowledge has fallen to pieces in the meanwhile. Normally I avoid writing in German Language.) --Mike __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
|
Mike Engelhardt