开云体育

Well, I have done? a lot of FFTs in the past , and .FOUR, but I've never seen an .IMP file before.

It is indeed an "Impulse response" file, the result of performing an FFT of the FFT's output.? Like regular .fft files, LTspice leaves it around for you to delete if you choose to.? If I'm not mistaken, I think you can also drag and drop it in LTspice if you want to see it again.? Otherwise, it's not of much use to you.

Andy

Have you modified the settings in LTspice so that? temporary files and working files are in a folder on the ramdisk?

This is an impulse response output from LTspice. I think it is the FFT of an FFT done. You can delete it.

开云体育

On 02/07/2023 19:05, John Woodgate wrote:

Isn't the normal way of doing this to create a 'Project' folder that automatically contains folders for each data type (i.e. each .extension) that can all 'see' each other? Like a PCB design project.

The problem with this is it won't contain anything from LTspice's distribution. We know that, over time, devices are added to standard libraries. But also devices are deleted - usually without announcement. If a project uses any of those, it won't be able to find them. This is what has happened to many of LTspice's own example schematics, which are currently being fixed - there are hundreds of them.

开云体育

On 02/07/2023 18:53, John Woodgate wrote:

I just did a simulation of a simple active filter, to look at distortion of the filtered signal, and after LTspice has closed, it has left a file called 'Filter.imp' in the schematic folder. It's 4097 KB, but LTspice won't open it. A web search suggests that it is a Adobe Audition file. I don't want to have to buy Audition! Changelog doesn't give a clue.

Try opening it in a text editor just for a look, or just try dragging it from Explorer into an open LTspice session - it would then be opened by LTspice as a text file. LTspice initially assumes everything is text unless it turns out not to be.

开云体育

On 02/07/2023 18:59, eetech00 via groups.io wrote:

On Sun, Jul 2, 2023 at 09:21 AM, Tony Casey wrote:

Another way that this issue could be solved is an "archive" function, that collects together all the files a project needs and puts them a zip. Ideally, this should be an LTspice function, as it already knows where it got all the files a schematic uses.

Hmm. interestingly, I happen to be working on a powershell script to do just that (although, I'm guessing yours would probably be designed for linux OS).
I imagine, however, that there would have to be options configured by the user to cover the multitude of library management methods.

No, the first very basic mockup was done in a bash script, simply to get an idea how it should work. But anything for the masses has to be multi-platform. I'd not even considered Powershell. I don't know if it is supported in Wine. I don't see why it shouldn't be. DOS cmd scripting works, but after bash, using it is just horrible. Python is inherently multi-platform and can do just about anything. There's also no reason it can't be done in C/C++ and compiled for almost any platform with GCC.

Like I said, though, ideally it should be within LTspice. Other simulators and EDA tools have had this kind of functionality for decades. Vlad and I also talked about this some years ago. Maybe he got further than I did. But I think he was also working in bash at the time, as a fellow Arch Linux user.

If you manage to get something running, I'm sure it would be very well received and appreciated.

开云体育

I have a folder named "Components", where I put the basic sims of individual devices. Each one has a folder with the .asc, .sym and model in it.

When I want to sim a circuit that usees one of these devices, I open the .asc, copy the device and .inc or .sub command into the new file. Then I need to open both the "Components" folder and the folder in which I have created the new circuit for copying the needed .sym and model files.

Wouldn't it be nice if just copying the device would simultaneously copy the other files?

开云体育

Isn't the normal way of doing this to create a 'Project' folder that automatically contains folders for each data type (i.e. each .extension) that can all 'see' each other? Like a PCB design project.

On Sun, Jul 2, 2023 at 09:21 AM, Tony Casey wrote:

Another way that this issue could be solved is an "archive" function, that collects together all the files a project needs and puts them a zip. Ideally, this should be an LTspice function, as it already knows where it got all the files a schematic uses.

Hmm. interestingly, I happen to be working on a powershell script to do just that (although, I'm guessing yours would probably be designed for linux OS).
I imagine, however, that there would have to be options configured by the user to cover the multitude of library management methods.

开云体育

I just did a simulation of a simple active filter, to look at distortion of the filtered signal, and after LTspice has closed, it has left a file called 'Filter.imp' in the schematic folder. It's 4097 KB, but LTspice won't open it. A web search suggests that it is a Adobe Audition file. I don't want to have to buy Audition! Changelog doesn't give a clue.

开云体育

On 02/07/2023 18:03, Jerry Lee Marcel wrote:

Le 02/07/2023 à 17:24, Tony Casey a écrit?:

Maximum portability is afforded by keeping added symbols and models in the same folder as the schematic that uses them.

I fully agree. It's what I do since you have recommanded it years ago.
The only drawback is that one has to copy the necessary model and symbol in a separate operation.

It would be nice if copying a .asc simultaneously copied them.

Actually, many suppliers continue to recommand appending the standard libraries.

Yes, I write and tell them sometimes. But my voice isn't loud enough. Anyone that's been here long enough will remember Helmut saying all this over and over again.

Another way that this issue could be solved is an "archive" function, that collects together all the files a project needs and puts them a zip. Ideally, this should be an LTspice function, as it already knows where it got all the files a schematic uses. From time to time, I mess about with an external utility that would do the same things. It's not massively complicated, but I fear it will remain yet another unfinished project, because we all limp by with an imperfect solution that just works.

开云体育

Against stupidity, the gods themselves contend in vain.

Le 02/07/2023 à 17:24, Tony Casey a écrit?:

Maximum portability is afforded by keeping added symbols and models in the same folder as the schematic that uses them.

I fully agree. It's what I do since you have recommanded it years ago.
The only drawback is that one has to copy the necessary model and symbol in a separate operation.

It would be nice if copying a .asc simultaneously copied them.

Actually, many suppliers continue to recommand appending the standard libraries.

开云体育

Agreed, and doing that doesn't stop you ALSO having personal library files for symbols and models, which avoids having to remember which schematic folder to look into for a given .ASY and/or .MOD or .SUB or several other extensions.

These days, there is no longer a realistic limit on how much storage is devoted to such libraries. All the entries are likely to be not larger than a few kB.

开云体育

On 02/07/2023 14:29, eewiz wrote:

I have found "2n7002.sym" in the following folders.

LTspice\lib\sym\EXTRA\Philips\NMOSFET

LTspice\lib\sym\EXTRA\ZETEX\NMOSFET

If you have those folders, it's because you have added them. They are not in the distribution.

I'm also fairly sure you don't mean 2n7002.sym, because LTspice symbol files are .asy.

I highly recommend you don't mess with the distribution library folders/files, because unless you keep meticulous notes, you won't remember what you've done. Keep your own additions somewhere else, clearly labelled. Maximum portability is afforded by keeping added symbols and models in the same folder as the schematic that uses them.

开云体育

On 01/07/2023 23:44, eewiz wrote:

A time saver.

Presort your standard.bjt, .dio, .jft and .mos files with the EditPad-Lite free text editor.

Then there is no need to click on the Part No. heading.

Personally, that make no sense to me, as normally I select a device on the basis of one of the other parameters, like voltage, Rdson or gate charge. I prefer not to touch the standard libraries in any way, on the basis that most people that people write in with problems haven't either.

On the other hand, there have also been plenty of issues with people that have altered their standard libraries and forgotten they've done so; then being surprised when they upload a schematic that other folk can't run, because they don't have those devices in theirs that were added by the OP.

I've reported it as a bug. Let's hope they do something about the
grid control warning (it is indeed necessary to hide the B-source
text in some way when '+' is not supported)

Properly showing the b-source text in the .log file should be
easy.

-marcel

开云体育

On 02/07/2023 12:53, mhx@... wrote:

The following B source definition (all on one line, it is a mere 600 characters) is no problem in LTspiceIV:
~~~
Bxx    S_junction_1 0  I=V(n1 ) *  9.3993002816     + V(n2 ) * -8.3877049435e+01 + V(n3 ) * 1.0381596463e+02 + V(n4 ) *  7.7568930320e+01 + V(n5 ) * -6.0938454341e+01 +  V(n6 ) * -1.1355133106     + V(n7 ) * -1.5622632040e+01 + V(n8 ) * 4.8948254492e+01 + V(n9 ) * -5.9853970925     + V(n10) * -3.6704588281e+01 + V(n11) *  4.2526090679     + V(n12) * -1.2632025682e+01 + V(n13) * 7.0439969303     + V(n14) *  5.6648248733     + V(n15) *  3.2392479658     +  V(n16) *  4.8449566268e-01 + V(n17) * -2.4475209917e-01 + V(n18) *-3.9824174985     + V(n19) * -7.5842504091     + V(n20) *  1.6805598922     + V(n21) *  1.2729728817     + V(n22) * -3.9681499520e-01
~~~

In ADI LTspice 17.1.8, the line can be entered in the "old-style" editor (ctrl+right-click) just fine. 
AFAIK, the fact that it can be entered means that at least the syntax is correct.
It is possibe to save the *.asc and read it in again, however, when clicking on the B-source 
to check/change it, there is an error "This attribute exceeds the 260 character limit for a 
Windows grid control".  The circuit doesn't run.

If I make a netlist, save it, and pass it to LTspice, it stops with an error and ^L shows 
a few strange characters where the B-source text should be.

I hope I simply made a mistake, because when this is a new limitation, it will make many
of my old LTspiceIV circuits unusable. Or maybe there is a workaround?

I have tried to split the text in multiple lines and use "+" to continue them in the trusted
SPICE fashion, but "+" doesn't work in the ctrl+right-click B-source editor, and it also
appears not to work when entered in an ASCII netlist with a text editor.

You're right, you can't then enter the symbol dialogue, but you can right-click on the displayed string - not the symbol - and directly edit the expression, stretching the dialogue window, if necessary. The problem with long expressions like this is you can't make them invisible without going into the attribute editor, which you can't do when the 260 character limit is exceeded.

My solution to difficulties like this is put the long expressions into a text file. Then wrap then the B-source into a .subckt, in which you can .INClude the text file:

.subckt Fudged_B_source 1 2
Bxx S_junction_1 0 I=
.inc Expression.txt
.ends Fudged_B_source

You can also directly paste the entire B-source netlist into a SPICE directive, placed on the schematic. It still looks just as ugly, and you can't make a directive invisible, either. Good job probably, as you would never find it again!

开云体育