LT Spice .PARAM

In an analog circuit, everything happens at the same time. A computer compiles and executes sequentially, and sometimes that matters. I've seen digital sims do strange things in LT Spice, too, which might be dependant on execution order.

.PARAM does resolve netlist forward references properly. Maybe it runs the entire .PARAM set multiple times until things settle out.

.PARAM barfs if you do two assignments to one variable. It does handle forward references properly.

PARAM's are NOT executed in order... even if one parameter is a function of another... irrespective of what any "expert" may be claiming.

RFTM, "PARAMS:" in a subcircuit declaration/instantiation are handled differently than .PARAM declarations that are in-line.

There are also "functions" (.FUNC) if you want to play >:-} ...Jim Thompson

We were discussing parameters depending on other parameters, so that you can have an order dependence.

Plus I'm down on compilers because I've been fighting a _really_stupid_ compiler bug in Visual Studio 2010--assigning a variable to another one of the same type doesn't yield equal values. I can see it happening as I single step with the debugger.

Cheers

Phil Hobbs

On Fri, 26 Jun 2015 16:25:19 +0100, Martin Brown Gave us:

No.. It will error at runtime, because they are treated like a variable definition, and you cannot have two variables with the same name and it will NOT make any presumptions or cast out the first in favor of the last.

Not in Spice... any order works.

I leave all my programming needs to son Aaron. The only hassles we have are I insist on a human-friendly GUI... he responds by adding to his code comments like, "added because Jim Thompson is too lazy..." ;-) ...Jim Thompson

An example of me simulating a bunch of PVT corners in one pass...

...Jim Thompson

Are you referring to crashing? ;)

Just to be clear, I'm not suggesting that changing the order of the .param's would have any effect on the _values_ output by the simulation, but at least in LTSPICE - I have no experience of any other variants - it clearly affects the way the results are displayed.

There are undoubtedly better ways of controlling the output that hacking the .asc in a text editor. I'm slowly working my way through this

which is the closest I've seen to a printed manual for LTSPICE. Anybody have any other recommended reading?

On 2015-06-30 09:05, RBlack wrote: [Snip!]

Google for 'scad3.pdf'.

Jeroen Belleman

I dunno--I routinely hack .asc files, e.g. when I ship them to customers. T o make them easy to use, I put all needed models into the .asc, but there's no way to mke them stay hidden on load, so they take up all the screen spa ce and reduce the actual schematic to a postage stamp.

As a workaround, I usually hack the .asc to make all the lines of the model s display on top of each other. The resulting black stripe can be puzzling, but enclosing it in a small rectangle and adding a comment is a reasonable solution.

Cheers

Phil "my editor rocks" Hobbs

That explains some things!

I like separate include files, all zipped with my .asc. Keeps things cleaner.

I use Crimson, but there are fans of EDIT++ around here.

It does if you're always careful to unzip it into an empty directory, but otherwise it makes a mess and can break other things.

I suppose I could mane a custom library, i.e. fancyTIA.asc would load fancyTIA.lib, but that's much more work to keep up.

Cheers

Phil Hobbs

I've collected a whole series of tutorials and help files in "LTspiceTutorials.zip " on the Simulation Tools & Macros Page of my website. ...Jim Thompson