SPICE deep yogurt..

To make your subckt list a true subckt list,not a 'comment', right click on the text area and the select "SPICE directive"

Changes the color of the text from blue to black.

Still doesn't run, but it's a start.

To make a 'new' symbol, go up to FILE on the upper left and select New Symbol.

But you don't need one.

There's more, so I'll have to keep looking to find more.

You could also, select oe of the 3-terminal regulators from the library, THEN change to your subckt. too.

Much easier, and faster, and get some really thorough answers, post your schematic to the /temp folder and post your question relating to that schematic to the LTspice group. Helmut will either walk you through, or point you to the step by step directions on a new symbol.

Download this...

from the Simulation Tools & Macros Page of my website.

Go thru all the tutorials. Flailing rarely is a productive learning mechanism.

...Jim Thompson

Thanks, will try all of your suggestions,in order given or until i get it working.

Thanks.

After taking your schematic and changing the subckt from comment to SPICE Directive, it still won't run because couldn't find the .lib files, well duh!

What happened when you did that?

"you" who ?>:-}

Your "Spice directive" should be either a .LIB or a .INC and show the path and filename to the subcircuit declaration.

Or, I think... in LTspice you can do that with "TEXT".

In PSpice I created a "part" called "TextForce" which forces the subcircuit declaration into the .NET file, otherwise it automatically goes into the .CIR file.

The reason I do that is to contain device libraries into subcircuit declarations when I'm creating models for distribution and the end-user doesn't have all my libraries. ...Jim Thompson

That was supposed to go back to Robert Baer, the OP, but with all that snipping who knows.

Nice feature: LTspice lets you put the whole .subckt description, or .model statment on the schmenatic as SPICE Directive text. However, that gets a bit cluttered, but is self contained.

I have 104 folders from various I/C foundries, each of which has at least three 3-4 different processes. Each library (CMOS in particular) can be hundreds of lines long, so .LIB calls are the only rational way to handle them.

PSpice only imports into the simulation whatever devices are used in that simulation, thus saving space. I don't know how LTspice handles them. But I do know .INC (.INCLUDE) sucks in the whole enchilada, thus is terribly wasteful of memory. ...Jim Thompson

How wasteful can it be? My entire SPICE library directory tree is under a gigabyte, i.e. about 2% of the memory installed on my desk machine. I can't imagine a single simulation pulling in more than a few megabytes of library files.

Cheers

Phil Hobbs

Each to his own. Reading in all that excess shit takes time. Do whatever you want. Including symbols and libraries IN the schematic is so... so... juvenile >:-} ...Jim Thompson

How do you suppose that Pspice figures out where in the library file the required models are? That's right, by reading in the whole thing and parsing it. It's not like there's some great directory in the sky that gives it the byte offset of your desired models from the beginning of the file.

I'd be very surprised if Mike kept the rest of the file in memory after that. It isn't very hard to notice when the user edits the file to call out another model--even a really dumb program would only need to re-parse the library when you changed models.

Cheers

Phil Hobbs

You're obviously not Spice literate on what _finally_ gets loaded.

You need to study up on

yourself... and stop throwing sand into the air.

"Surprised" isn't an engineering term. ...Jim Thompson

I'm all for learning things. You keep repeating that (1) LTspice handles .LIB statements as though they were .INC, and (2) that doing so necessarily means that it's grossly inefficient. (See, I've been listening.) ;)

However, given the realities of file handling, the program will have to read in the file until it finds the .MODEL or .SUBCKT it's looking for, and then convert that into some internal representation. It only has to do that when you add a library call, so it's not happening on every run, by a lot, even if it doesn't happen during editing (which it easily could). In any case, it's just a string search, which is really quick.

I appreciate the pointer to your tutorial, which I hadn't seen before. But for present purposes, it's a bit bulky. Where exactly in all that admirable stuff do you explain how LTspice, Pspice et al. handle files at the actual code level? I didn't think you were a programmer, and I'm quite certain you don't have either Cadence's or LT's source code.

If there's some covenant between programmers that forces all Spice flavours to re-parse the whole library on each invocation just because it's invoked with .INC instead of .LIB, I'd sure like to know about it. I have a lot of respect for Mike Engelhardt--given how good he is, it sure seems unlikely that that's the case.

Cheers

Phil Hobbs

I said nothing of the sort/

You clearly have problems understanding how ALL Berkeley-derived Spice handle .LIB versus .INC (.INCLUDE) and I don't understand why you keep dribbling about it. What's your problem? Trouble keeping the narcissism level up ?>:-}

End of this subthread. ...Jim Thompson

If name-calling is all you have left, I guess it is the end. Is "narcissism" an engineering term? ;)

Cheers

Phil Hobbs

I've lots of code writing and I really don't think the sim scans the required files, looking for the start of subs etc each time.

I've noticed with Ltspice when ever you access a folder the first time around it appears to be scanning it. Taking this into account tells me that it could be looking for LIB, subs etc, and then, building an in memory index to subckts and what not, for fast external access, which is very common in database land.

Taking this into account, Ltspice can also keep the creation and modification date in memory so that each time it opens the LIB, it can also check against the current file time with the last file date and re index the LIB if they differ. This would correct for anyone editing a file.

With that kind of handling it's very logical to have a large collection of LIBs and not clog up the system in the process.

It's more than likely that LTspice caches subckts and only does a file date change status since the last sim. That would be the most practical way. Compilers have been using cached libs for years now, they normally stip out the comments etc..

Jamie

Yup. In 1970, you'd probably do that on each iteration, but not in

Maybe. Given that most .LIB files are pretty small, I'd be inclined to do that during editing, when the disc and CPU are twiddling their thumbs.

Yup. I suspect that JT is operating on badly out-of-date info, like 20+ years out of date. However, as he doesn't write his own code, it's sort of hard to avoid that.

Cheers

Phil Hobbs

Please recite the difference between Spice handling of .INC (.INCLUDE) files and .LIB files.

Cut the crap and tell us all the difference. ...Jim Thompson

Subthreads of the living dead, I get it. I feel like that in malls myself. ;)

Given that the library files are generally small, and the required parsing infrequent, I don't think that (in 2014) it's a big performance hit regardless of how stupidly they do it.

Pspice fanboi that you are, you've been beating the .INC vs .LIB drum for years now, but AFAICT you have no idea how actual code implements them. Of course I don't either, but (a) I've implemented that sort of thing in my own simulators, such as POEMS

What exactly do you know about Berkeley SPICE derivatives' file handling? If you have anything definite to contribute on that point, I'd really like to hear it. I've learned a number of things from you, and I have no reluctance to learn more.

Cheers

Phil Hobbs