I have a folder containing asc, sub, asy files. I wanted to organize sub and asy files into their respective subfolders, but keeping asc files in the parent folder. But when I did that arrangement and opened an asc file, LTSpice not showing subfolder containing the asy files. How do I make the subfolder visible?

 

Hi kao,
Check this image for the asy files path.

Create a File lib/sym and place your asy files there.
Or use the 'AutoGenerated' folder

Using F2 key should make all the asy folder names visible.
E

 

I have a folder containing asc, sub, asy files. I wanted to organize sub and asy files into their respective subfolders, but keeping asc files in the parent folder. But when I did that arrangement and opened an asc file, LTSpice not showing subfolder containing the asy files. How do I make the subfolder visible?

Placing any .asy or .sub into LTspiceXVII folders is not recommended.

1. Create your custom folder structure.
Example:
D:\LTspice\lib\sub\74HC\
D:\LTspice\lib\sub\CD4000\
D:\LTspice\lib\sym\74HC\
D:\LTspice\lib\sym\CD4000\

2. Copy each of your .asy file into the appropriate subfolder below D:\LTspice\lib\sym\

3. Copy each of your .sub file into the appropriate subfolder below D:\LTspice\lib\sub\

This is just one example folder/file management structure. The .asy and .sub files do not have to be in separate folders.

4. Use the "Sym. & Lib. Search Paths" option in the LTspiceXVII Control Panel. Add each of the folder paths to LTspiceXVII so it will know where to find the files.
4.1 Add each new folder path containing .asy files to the "Symbol Search Path" pane.
4.2 Add each new folder path containing .sub files to the "Library Search Path" pane.

Note- be sure to type a <return> at the end of each path so LTspice will recognize it.

5. Use LTspice component selector to browse/pick your symbol.
5.1 press F2
5.2 click "Top Directory" pulldown menu.
5.3 Select the desired folder.
5.4 Select the desired symbol. Then click OK.

 

Placing any .asy or .sub into LTspiceXVII folders is not recommended.

hi eetech,
Could you explain why you don't recommend this action,
It has worked perfectly well for me, and others, for a long time with no problems.

E

 

hi eetech,
Could you explain why you don't recommend this action,
It has worked perfectly well for me, and others, for a long time with no problems.

E

Hello E

Use whatever you think works for you.
In the past, various problems have occured by placing files inside LTspice default folders. Too many to mention here.
I will only recommend what LTspice Group recommends.

 

Hi eeTech,
As it is a LTspice Group recommendation, I will accept that point.

I was interested to know why, a problem example would suffice.

E

 

Hi eeTech,
As it is a LTspice Group recommendation, I will accept that point.

I was interested to know why, a problem example would suffice.

E

Hello again E

The main reason is that the LTspiceXVII installed directories are managed by the LTspice developers, so they're free to manipulate the files and folders therein. This means that any file or folder may be REMOVED or MODIFIED whenever LTspice is updated. This includes the lib/ directory and files and/or folders contained within it. Also, new model files are constantly being added to the lib directory by Analog developers and this creates the potential for conflict of casually managed model and symbol names by non "power" users.

The above mentioned risks can be mitigated by not placing any user created files in the LTspiceXVII directories in the first place by using your own custom library folder structure outside the LTspiceXVII managed folder structure, and using the "Sym. & Lib. Search Paths" option in the LTspiceXVII Control Panel.

Hope that helps.

 

This means that any file or folder may be REMOVED or MODIFIED whenever LTspice is updated.

I've often seen that stated before, but in my several years of using LTspice I've never experienced that happening to any file I've added or modified. The update procedure has always respected any additions I've made (even in the 'standard' component files) and has left them intact. But I suppose there's a chance it could happen.
Under Win10, LTspice XV11 gets installed in two places. I've assumed (perhaps wrongly) that the copy in the Documents path is one intended to allow editing but the other copy is a reference/backup? It seems to be just the one in Documents which is consulted by LTS when running.

 

But I suppose there's a chance it could happen.

Yes.

Under Win10, LTspice XV11 gets installed in two places. I've assumed (perhaps wrongly) that the copy in the Documents path is one intended to allow editing but the other copy is a reference/backup? It seems to be just the one in Documents which is consulted by LTS when running.

The lib located in program flies is created/updated first, followed by the LTspiceXVII in Documents folder.
This is also the case for a "sync release". As with other programs, the files located in Documents will be referenced in the context of the logged on user.

 

Hi eeTech,
I must say, over many years of using LTS, I have never lost any self created files during an update.

Knowing Murphy's Law, it will happen on the next upgrade.
E

 

The other recent controversy involved moving the LTspice contents from the Documents folder to AppData, and people ended up with multiple copies of some very large libraries. @Bordodynov was one of the first to notice the lunacy of this choice as it broke many things that he was doing. They did rescind that change. Besides being a hidden folder there may be other access restrictions in some window environments where they would be inaccessible.

 

Besides being a hidden folder there may be other access restrictions in some window environments where they would be inaccessible.

For the benefit of other users-
This is another good reason to use a custom folder outside Documents. So that a common library can be shared with multiple users of a single machine and won't be touched by automated OS permission changes.

 

The other trend in recent Windows machines is to have an SSD as the C-drive and rotating memory as the D-drive. While there may be a temptation to move either Documents or AppData to the rotating memory with some clever hacks, I'd like to suggest that there might be some risks in doing that. Making a private library repository sounds like a more reasonable way to go.