Keyboard Shortcuts
ctrl + shift + ? :
Показати всі комбінації клавіш
ctrl + g :
Не доступний для безкоштовних груп.
ctrl + shift + f :
Знайти
ctrl + / :
Сповіщення
esc to dismiss
Лайки
Пошук
Search Paths
|
You can add any text to a schematic, but I
don't think it will work to add a search path as an LTspice
directive. You can .INCLUDE a file, but I don't see how that
would work. Why do you want to list the search path anyway? On 2024-11-14 15:24, Robert Tomlinson
via groups.io wrote:
-- OOO - Own Opinions Only Best Wishes John Woodgate Keep trying |
|
Yes, I think the standard redirections work:
переключити цитоване повідомлення
Показати цитований текст
.\<SomeFileSpec> --> relative to current directory ..\<SomeFileSpec> --> relative to parent directory Did you try anything and find it didn't work? -- Regards,
Tony On 14/11/2024 16:24, Robert Tomlinson
via groups.io wrote:
|
|
On Thu, Nov 14, 2024 at 10:24 AM, Robert Tomlinson wrote:
Yes. People do that all the time. Well, not ALL the time, but quite often. It works fine.
I recommend quotes around the whole path, especially if any part of the path includes a space.
Andy
|
|
But what does putting a search path on a
schematic actually do? Perhaps I misunderstand the original
question. On 2024-11-14 15:57, Tony Casey wrote:
Yes, I think the standard redirections work: -- OOO - Own Opinions Only Best Wishes John Woodgate Keep trying |
|
I could envision a large project with a number of
"sub-projects" where the libraries are in directories so: ProjectTopLevel I wouldn't do it that way, but I could see someone doing it so or some corp requiring such. FWIW, On 11/14/24 13:48, John Woodgate wrote:
|
|
On Thu, Nov 14, 2024 at 01:50 PM, John Woodgate wrote:
Certainly it makes no sense to just add a "search path" to a schematic or netlist for simulation. You are correct in that respect. Search paths can be added to LTspice but only through setup, in the Settings / Control Panel (Sym. & Lib. Search Paths).
However, you can use a path, which can be either absolute or relative, when specifying the location of a file to be included in a simulation. It is not precisely a "search path" in the way that I think of it, because each path specifies only one location, not a handful of locations to be searched or tried.
I interpreted the original question as asking whether relative paths can be used as an alternative to absolute filename paths. I read "Can I create a relative search path" to really mean "Can I create a relative path", without the word "search".
It's my understanding that LTspice hands the path over to the O.S., and then the O.S. deals with it. (With the possible exception that LTspice converts forward slashes into backslashes, for Windows.) If the O.S. can deal with relative paths, then LTspice's calls to include a file can as well.
Andy
|
|
One of the things I have seen used in some simulations, is to include the "relative" path to the current directory, like this:
.include .\mymodel.lib
.lib .\myothermodel.lib
What that does is force LTspice to look only in the current working directory for the file. Otherwise, if you write just the filenams without any path, LTspice uses its normal search path, which means first trying its own program libraries before looking in the current directory. This is a way to override that.
Andy
|
|
Hey Andy, et al, Reason: Whenever we use analysis simulations in a report, we provide those simulations to our customer. We do that by creating a ZIP file. We want the customer to be able to unzip the file anywhere and have it run. Problem: When we have a lot of simulations (multiple circuits on each board and multiple boards, along with system level simulations) and must use a relative folder structure to find the part models (some from third party providers and some developed by us), we place the same models over and over with the schematic. As you might imagine, when simulations use many of the same parts, the zip file gets very large very quickly (even without the raw data files). So, we were trying to find a way to point to the normal LTSpice directories, but also wanted to point to a specific path that is above the schematic folder in a structure. Report / Box Sim //Analysis1 /// Sim1 /// Sim2 ... //Analysis2 /// Sim1 /// Sim2 ... / Board1 // Analysis1 /// Sim1 /// Sim2 // Analysis2 ... / Board2 // Analysis1 ... / Board7 ... / Models // Diodes // Transistors // ICs // Custom ... No, I had not tried the use of ../.. in the .INC command. I will try it to see how it works. As you can hopefully see, it would be nice to be able to point to the Models folder, which is up 1 or 2 levels, then over to a Sibling directory under the Report folder, no matter where the file is Unzipped. If we can point to the top folder, would LT search subdirectories? In other words, is there a /S option on the .INC command, so it would search subdirectories? Of course, if we can point to the model folder, we can just add a single text file to each sim folder that has the correct path. .INCLUDE ../../Report/Models/Diodes .INCLUDE ../../Report/Models/Transistors ... Now that you know more details of the issue, let me know if you have any further thoughts. I will try this and also keep an eye on my email today. Thanks! - Bob Tomlinson Email from Yahoo |
|
On Fri, Nov 15, 2024 at 09:35 AM, Robert Tomlinson wrote:
As we have told you already, you don't need to say "it would be nice if..." and then wonder if it does. If you use relative paths, it works! TRY IT!
No, LTspice does not search down through all subdirectories. If you put a file in directory \X, and point to that file in directory \X, it will find it. If you put it in \X\Y\Z, and point to the file in that directory, it will find it. But if you point only to director \X, it won't recursively search down all paths below \X.
Note, however, that LTspice Beta 24.1 adds some capability for searching down through hierarchy even in user-provided paths. I do not know the extent of this new feature, but I suspect it may apply only to the library search paths that you set in the Settings / Control Panel. In other words, probably not a .INC or .LIB command. That would not make any sense.
No. As I've been explaining, the path you put in the .INC statement is exactly where it looks. It looks there and nowhere else. It looks exactly there. You give it the path to the file, and it finds it.
LTspice uses a short list of actual "search paths" ONLY when you give it just a filename without ANY path. And then its search path is very small. It basically includes the LTspice model libraries, and the current directory, and that's it. The moment you give it any sort of path in your .INC command, LTspice's library search feature is turned off. You are telling it precisely where your file is, and your computer will not look for it anywhere else - not my computer, nor anywhere else.
Please understand, any and every path that you use in a .LIB or .INC command, specifies an exact location of a file. There is no chance for searching subdirectories in that case, because the whole idea is that you have told it EXACTLY where to find the file, period.
Also, just in case there is any misunderstanding about this - you do not use a .LIB or .INC command to tell LTspice about a Folder or Directory. Never. Those commands are used to load a FILE and only a FILE. Not a directory. Whatever comes at the end of the .LIB or .INC command must be a filename and extension. What comes before that can be a path to that file, and that path may be absolute or relative. In your case, I think you only want to use relative paths, unless you require your customers to install your models only in a very precise directory tree starting at the root directory. Usually that is not desirable.
That should work, as long as "Diodes" is a file, and "Transistors" is a file. In other words, the filename had better not be "Diodes.lib" or "Diodes.mod" or "Diodes.txt". LTspice does not assume filename extensions. But if "Diodes" and "Transistors" are directories, then you would have misused the .INCLUDE command. You cannot include a whole directory itself in a simulation. The directory exists for the filesystem only.
Andy
|
|
On Fri, Nov 15, 2024 at 09:35 AM, Robert Tomlinson wrote:
I'm writing this again, just in case it is not clear yet.
Yes, that works, if done right.
Up 1 level, then over to Sibling under Report? Like this: ..\Report\Sibling
Up 2 levels, then over to Sibling under Report? Like this: ..\..\Report\Sibling
Assuming that the whole shebang is unzipped at one time, and if you use relative references only, then it makes no difference where the customer unzipped it. The relative references make it work.
Brush up on your DOS/Windows (or Unix) directory nomenclature. That is exactly what you need to use.
So, to refer to a model file named "MyModel.lib" that is located in Sibling under Report where Report is 2 levels up:
.LIB ..\..\Report\Sibling\MyModels.lib
Remember, .LIB and .INCLUDE must point to a FILE, not to a directory. That file can be on the end of a path to a directory, but the whole thing needs to point to a file, not to a directory.
Andy
|
|
Thanks Andy.
переключити цитоване повідомлення
Показати цитований текст
Yes, I know that inc or lib must point to a file. Hence my question. If there was a way to add a /S to the end of an include and have it look through subdirectories to find that file name. If there isn't that capability today, maybe propose it. Most of the time the part name is the file name, such as, JANS1N6146US.lib. I have done 2 things in the past I have created a single file that has all Diodes in one include statement that points to that file or point to a file for each part separately in multiple include statements. So, I get what you are saying. I am going to contact my colleagues and we will try it. Thanks again! - Bob Tomlinson Email from Yahoo
|
|
When I wrote the email this morning,, I had yet tried it. Sounds like LT is looking at searching subfolders. I can see how it would help in some ways and not in others. Ok, I am good. This is going to help a lot. Thanks! - Bob Tomlinson Email from Yahoo
|
|
On Fri, Nov 15, 2024 at 11:09 AM, Robert Tomlinson wrote:
Hence my question. If there was a way to add a /S to the end of an include and have it look through subdirectories to find that file name. If there isn't that capability today, maybe propose it. I thought I answered that already. Here is the answer: No. No, no, no, and no. Absolutely NO.
The .INC command specifies a filespec. When it includes anything before the filename, a filespec is the address of the location of one file. You are telling SPICE (or LTspice) that you want to include THIS ONE FILE, located in THIS EXACT LOCATION. You are not asking SPICE (or LTspice) to go off on a chase to see if it can find another file by that name in some other location that was not in the filespec, even if it might be in an unspecified subdirectory of it. You are telling it the exact location where that file is. That is what is meant by a filespec. This is DOS/Windows/Unix stuff.
If you .INC with no path at all, just a filename.ext, then and only then LTspice uses a built-in search path. As you can see by reading the docs about it, that search path is this, in order:
There is no "/S" and it makes no sense to have one in a .INC command.
As I alluded to earlier, LTspice Beta 24.1 adds some recursive hierarchy capability to library searches:
I assume (but have not yet verified) that this applies to either or both of the user-provided Sym. and Lib. Search Paths, which are entered in the Control Panel / Settings - in other words, it applies to step #3 above. Previously, you had to enumerate every single user-provided directory because it would not recursively search subdirectories (hierarchy). But note that this applies only to the user-provided directories in #3.
The moment your .INC command's filespec includes any hint of a directory, the above search path is switched off. SPICE, and LTspice, include only that one file pointed to by that filespec. They do not deviate from the filespec. They can't guess what you wanted but didn't enumerate in your filespec.
Andy
|
|
On Fri, Nov 15, 2024 at 12:30 PM, Robert Tomlinson wrote:
I'm not entirely sure what you mean.
If I understand correctly (it's possible I'm wrong):
LTspice already recursively searches subdirectories of its OWN symbol directory, but only there. It does it there because that was how LTspice's own symbol library was designed - with subdirectories for different types of components. Therefore, it had to do that already, on day 1.
Much later, LTspice added the capability for the user to add user-defined Lib. and Sym. Search Paths. When the user adds a user-defined Sym. Search Path to their LTspice (Control Panel), LTspice did not recursively search below the user-specified paths, forcing the user to enumerate every (sub-)directory they wanted to be included. This change in Beta 24.1 apparently alters that strategy. It is probably limited to that one case, and was done to make its behavior similar to that of the system-defined LTspice library.
None of that directly applies to .LIB or .INC commands. Whenever a .LIB or .INC has a filespec that has a hint of a directory, you have pointed to an exact location, and only that one location can be used. There is no means to violate that filespec.
Andy
|
|
Hello Andy, Again just to be clear, the solution that I asked about works. It does exactly what I wanted, to reduce the size of a ZIP file while allowing someone to unZIP the file anywhere and simulate immediately. I had a colleague try it. Note: If using a SharePoint for the schematic and relative file structure, it did not work (We double checked everything) and when we copied everything to a C: Drive it worked. For the other subject: Yes, I had been using the Control Panel pointing to multiple folders in which I have placed models. From what you said about the Beta version, it sounds like I could use one statement in the Control Panel to search all subdirectories of a directory "Models." It wouldn't matter if they were organized by project, by part type, AND by third party. This is exactly what I was thinking about. The downsides could be 1) taking more time to search through all of those subdirectories for a specific model and 2) I am already getting warnings in the output log file about multiple definitions of the same model. If I wanted to do so on my personal computer (I cannot do it on my work computer because I don't have rights), is it possible that I could try a Beta version? FYI the reason that I am thinking about file structure and model access: I had my personal computer custom built to run simulations. My PC has a liquid cooled motherboard with AMD Rizen 9 7950X Threadripper (16 dual core processors) running at 4.5 GHz with 6TB HDD and 2 TB NVMe 4.0 Samsung 980 Pro PCIE 4.0x4 SSD with 128GB DDR5 memory running Windows 11 Pro 64 bit. It is capable of driving 4 monitors with a GPU Quadro T1000 4Gb 4x MiniDisplay port and has the latest WiFi and Bluetooth, though I run GB hardwire Ethernet throughout the house. Unfortunately, the only issue is that there is no Internet provider that has fiber in my area (yet), so my bandwidth is limited to what the wired providers can give me. Anyway, I do appreciate your help and feedback. Thanks. - Bob Tomlinson Email from Yahoo
|
John Woodgate
Tony Casey
Повідомлення
Більше
Додаткові параметри
Більше
to navigate to use esc to dismiss