Standard LTSpice having a scarce selection of IGBT models (& if anything, only a single rudimentary one), has got me looking for a library of choices. So I was glad that Bordodynov's library of of models & examples also included IGBTs. But, I was disappointed that there seems to be glitches in importing them.

What I would do is create the .asc schematic file in the same directory as the model .asy symbol files, so I can select them in the Select Component Symbol dialog box. After selecting an IGBT model, I would place it & run it.

I like IRF power transistors, so I started on them (lib\sym\ZZZ\IGBT\IRF):

Although, when I run them:



I get this:


Placing ".lib lib\$partname.spi" does nothing to remove this dialog prompt.

Then I try Fairchild models (C:\Users\raini\Documents\elec\lib\sym\ZZZ\IGBT\FAIRCHILD_IGBT):


On run, I get this:



I try APT:



I get this:


Do notice that my directory specification typically is "lib\directory_name", whereas the dialog box's is "..\sym\zzz\IGBT\$manufacturer\lib$partname", meaning the lack of inclusion is somewhere else. I wish I could do more prodding, but, for all of them, this is what I get on a right click:

 

Can anybody help me get these models working for me?

 

Can anybody help me get these models working for me?

Yes, I can help you
There are several strategies that you can employ to fix the problem

1. You can replicate the folder structure as it exists on @Bordodynov's computer in MInsk.
2. You can edit the symbol to make it compatible with an alternate structure.
3. You can copy the subcircuit into your schematic as spice directive text and edit the symbol to have no path to the subcircuit file.
4. You can revise everything to suit your own folder structure.

I have employed method#1 above on my computer but it has the disadvantage that I cannot share simulations as a package because other people do not share that same folder structure. The reason I chose method #1 is that I update my copy of @Bordodynov's library about every 2 weeks or so because he is constantly changing and improving it.

As for the symbols you cannot edit, that happens because of the following which is documented in the LTspice Help file

Super Expert Mode ​

The attributes SpiceModel, Value, Value2, SpiceLine, and SpiceLine2 are all part of the overall value of the component. In terms of the way the component is netlisted for SPICE, the component will generate a line of SPICE that looks like this:​

​

<name> node1 node2 [...] <SpiceModel>
+ <Value> <Value2> <SpiceLine> <SpiceLine2>​

​

The prefix attribute character is prefixed to the reference designator if different than the first character of the reference designator. The Prefix character and InstName will be separated with a '§' character in this case. For example, if you have a Prefix attribute of "M" and an InstName attribute of "Q1", the name in the netlist will be M§Q1. This allows you use reference designators with a leading character different than SPICE uses to identify the type of device.​

​

There are three exceptions to the above rule. There is one special symbol, jumper, that does not translate into a circuit element, but is a directive to the netlist generator that there are two different names for the same electrically identical node. Another exception is a symbol defined to have a prefix of 'X' and both a Value and Value2 attributes defined. Such a component netlists as two lines of SPICE:​

​

.lib <SpiceModel>
<name> node1 node2 [...] <Value2>​

​

This allows symbols to be defined that automatically include the library that contains the definition of the subcircuit called by the component. The netlist compiler removes duplicate .lib statements. Note that such components are not editable on the schematic. The third exception is a symbol that has other exception is a symbol defined to have a prefix of 'X' and a ModelFile attribute defined. Such a component also netlists as two lines of SPICE:​

​

.lib <ModelFile>
<name> node1 node2 [...] <SpiceModel> <Value> <Value2> <SpiceLine> <SpiceLine2>​

​

Use this method when you want to automatically include a library file yet still want to have an instance of this symbol editable. If the symbol attribute SpiceModel exists and is the name of a subcircuit in the file specified as <ModelFile> then a drop list of all subcircuits names will be available when an instance of the symbol is edited on a schematic.​

​

Good luck finding a method that works for you.

 

Standard LTSpice having a scarce selection of IGBT models (& if anything, only a single rudimentary one), has got me looking for a library of choices. So I was glad that Bordodynov's library of of models & examples also included IGBTs. But, I was disappointed that there seems to be glitches in importing them.

What I would do is create the .asc schematic file in the same directory as the model .asy symbol files, so I can select them in the Select Component Symbol dialog box. After selecting an IGBT model, I would place it & run it.

I like IRF power transistors, so I started on them (lib\sym\ZZZ\IGBT\IRF):

Although, when I run them:
View attachment 272703


I get this:
View attachment 272700

Placing ".lib lib\$partname.spi" does nothing to remove this dialog prompt.

Then I try Fairchild models (C:\Users\raini\Documents\elec\lib\sym\ZZZ\IGBT\FAIRCHILD_IGBT):
View attachment 272704

On run, I get this:
View attachment 272705


I try APT:
View attachment 272706


I get this:
View attachment 272707

Do notice that my directory specification typically is "lib\directory_name", whereas the dialog box's is "..\sym\zzz\IGBT\$manufacturer\lib$partname", meaning the lack of inclusion is somewhere else. I wish I could do more prodding, but, for all of them, this is what I get on a right click:
View attachment 272708

Hi

The problem is related to the subckt folder path specified in the symbol's SpiceModel attribute.
For some reason, the path specified is "..\sym\ZZZ\IGBT\IRF\LIB\irgb4061dpbf.spi" which is odd.
Normally, a ".sub" file, or any subckt files, are stored in a folder below sub/ so that it can be found by specifying a relative path below sub/ folder using the ".lib" directive on the schematic. This looks to be a problem with a large number of symbol files in Bordodynovs library, so there won't be a easy fix.

A quick fix for a symbol or two is:
1. Copy each symbol file and its subcircuit file to the schematic folder.
2. Delete the "Spicemodel" attribute value in each symbol.
3. Use the ".inc" directive on the schematic to specify the location of the subcircuit file.
Like this:
.inc modelfile.sub <----filename.ext of model file without path.

 

Here is the first part modified to run out of the folder that contains the schematic, the symbol, and the subcircuit file. I parameterized the gate signal and the simulation command so you could try various DC_offsets, AC_amplitudes, and frequencies and number of cycles to plot.

 

The second device was more difficult because it was located inside a library named "Sborka.lib" which is part of @Bordodynov's collection. I have broken it out for you and made the symbol editable.

 

And here is the last one. Alex is very good at what he does, but his methods can be obscure. It took me some time to work out the details but I am glad to have made the effort.

 

Hi

The problem is related to the subckt folder path specified in the symbol's SpiceModel attribute.
For some reason, the path specified is "..\sym\ZZZ\IGBT\IRF\LIB\irgb4061dpbf.spi" which is odd.
Normally, a ".sub" file, or any subckt files, are stored in a folder below sub/ so that it can be found by specifying a relative path below sub/ folder using the ".lib" directive on the schematic. This looks to be a problem with a large number of symbol files in Bordodynovs library, so there won't be a easy fix.

A quick fix for a symbol or two is:
1. Copy each symbol file and its subcircuit file to the schematic folder.
2. Delete the "Spicemodel" attribute value in each symbol.
3. Use the ".inc" directive on the schematic to specify the location of the subcircuit file.
Like this:
.inc modelfile.sub <----filename.ext of model file without path.

What Alex (or the original author) was doing with that particular path specification in the symbol was pointing to a subcircuit that was located in a subfolder called "LIB" below the folder where the symbol was located instead of having LTspice look for it in the "...\sub" folder. The complete path would look like:

C:\Users\<username>\Documents\LTspiceXVII\lib\sym\ZZZ\IGBT\APT\LIB\40GT60BR.lib​

where <username> will be different for each Windows system. Maybe there was a purpose to this and maybe it was just an experiment.
Perhaps it was not Alex who came up with this particular method and he has just passed it on without comment or modification.

...\ZZZ\ is the place where all of Alex's stuff resides on his machine. See the screenshot below
...\TZZZ\ is where all of the stuff I have developed resides. Imitation is a sincere form of flattery.

 

What Alex (or the original author) was doing with that particular path specification in the symbol was pointing to a subcircuit that was located in a subfolder called "LIB" below the folder where the symbol was located instead of having LTspice look for it in the "...\sub" folder. The complete path would look like:

C:\Users\<username>\Documents\LTspiceXVII\lib\sym\ZZZ\IGBT\APT\LIB\40GT60BR.lib​

where <username> will be different for each Windows system. Maybe there was a purpose to this and maybe it was just an experiment.
Perhaps it was not Alex who came up with this particular method and he has just passed it on without comment or modification.

...\ZZZ\ is the place where all of Alex's stuff resides on his machine. See the screenshot below
...\TZZZ\ is where all of the stuff I have developed resides. Imitation is a sincere form of flattery.
View attachment 272723

Hi

Yes...I'm aware. Alex B. is an expert spice modeler. But I really don't like the way Alex's library is structured. It's too easy to break.
I use my own structure that is easier to manage, retains the original LTspice library structure, and utilizes LTspice options intended for this purpose.

 

Hi

Yes...I'm aware. Alex B. is an expert spice modeler. But I really don't like the way Alex's library is structured. It's too easy to break.
I use my own structure that is easier to manage, retains the original LTspice library structure, and utilizes LTspice options intended for this purpose.

I know that you are as well, and I have no problem with that. I'm also not sure Alex created that structure originally or not. I was trying to demystify some of the errors being experienced by the TS by way of explanation. Sometimes I succeed and sometimes I fail. C'est la vie.

 

I know that you are as well, and I have no problem with that. I'm also not sure Alex created that structure originally or not. I was trying to demystify some of the errors being experienced by the TS by way of explanation. Sometimes I succeed and sometimes I fail. C'est la vie.

No problem here PB
There's always more than one solution to a problem.

 

No problem here PB
There's always more than one solution to a problem.

I the late 1960's I had a mad friend who was known to opine that: "There is something about every system that sucks". He was specifically talking about operating systems, but I have come to understand that his sentiment may have been more general.