Hello!
I noticed something strange in eeschema, or more specificlly in the symbol lists.
My understanding was that Kicad separates concepts. For example footprint and symbols are
independent, which is a very good thing.
Now could anyone explain me why there are myriads of identical diodes in the symbols?
For example I was looking for a shottky diode, and among the first shottky in the list, I found
1N5711. But there are many others? Why? Why not consider that 1N5711 is the value.
After all, there is no resistor symbol for R47K and so on. I think there should be diode,
shottky, and so on for all the types, but that should be about it. Is there a technical reason
for that?
Thanks!
Thrr is the concept of the fully specified symbol. Such a symbol already connects to the correct footprint within the library. This is explaind in detail as part of this tutorial: Tutorial: How to make a symbol (KiCad v5.1.x)
Hello Rene!
Thanks for you reply.
Ok, I got it, but my question was a bit more like why is it so?
I think it brings complexity (browsing through zillions of types to find the proper symbol where
a few symbols (maybe 10) could make it. There might be advantages, I don’t know, but from
my point of view, it’s just the best way to screw up a good design.
So in short, what are the advantages of doing this?
Thanks,
Pascal
The reason is because this allows assigning the correct footprint. Read the introduction of the tutorial I linked above for more details.
TlDr: There are simply two competing workflows. One is assigning the footprint (and selecting which part to order) at tge end of the design process. The other is to select the correct part directly from the lib and have the footprint (plus possible additional information) already assigned when placing the symbol.
Since always (means 1988) we use the method that symbol precisily defines the element. The same symbol is written on this element’s box (among many others on the wall) so the worker who assembles the PCB, can easily get what is needed and have not to think which one of 10 Shottkys we used during last 10 years he is supposed to take this time.
@roboya, I agree with you, but also it not convenient when come to footprint mapping. So I try to minimize my personal symbol library, and using alias for other part that I found they are compatible. But I wish Kicad alias have more feature, so that I can have completely difference fields values for each alias which will allow me to pre-link to the default footprint, manufacturer, datasheet, where to order info correctly. So I can either use symbol as atomic part other generic part as needed.
Or KiCad need another way to isolate these information so that we don’t end up with 1000 symbols for 1000 part!
To me a physical IC can map to multiple symbols style, and footprint style. In that thinking, I think we will end up with minimal number of symbols, minimal number of footprint, and a customized set of mapping of physical part to symbol + footprint. So doing schematic can be add from generic symbol, or pulling from physical pool that will automatically add all the addition filed values to the symbol on the schematic…
With this way, we then can even have a tool to extract the mapping data from the project and use it for next project.
Rene has described the two workflows supported by the current libraries. I just checked the libraries on my initial v5.0.1 release install (internally labeled as 5.0.1-rc2, I should upgrade this machine to 5.0.1_3 release at some point…) and find that both workflows are supported. As it should be for a set of general all-purpose libraries, thanx to the great effort by the librarian team of volunteers.
(BTW, the _3 in the version just means it was the 3rd try to get the build right with the sources for the 5.0.1 release. It doesn’t describe any changes to the actual source code base.)
In the Device library is the generic schottky symbol:
Note that there are many other schottky generic symbols, basically covering other package pinouts available on the market. Note in the symbol in the above screenshot both the footprint and the datasheet fields are empty (the tilde (~) mark is often used in KiCad libraries meaning NULL).
Now, in the Diode library is where you found your 1N5711, here:
Comparing against the generic symbol shown above, there are several differences.
- This one actually has a specific footprint specified. Nothing is forcing you to use that specific footprint, you may change that in your design if you need to (like change to a vertically mounted orientation). But, it provides a good starting point.
- There is also a datasheet URL attached. As long as microsemi doesn’t change the organization of their website, that gives you a way of viewing the datasheet by right-clicking on the symbol in your schematic and selecting “
Open Documentation”. - Finally, note how the highlighted 1N5711 (and others in the list) are italicized. This means the symbol is actually an alias. Continuing to look down at the information area of the symbol chooser under the bolded symbol name there is a line, also italicized, stating what this part is an alias of. Note that the Value shown is actually the value of the parent part, not the 1N5711 alias. When you place the symbol in your schematic, you will get your chosen value 1N5711 of the alias that you selected.
Quick explanation of what an alias is with respect to KiCad symbols. There are two basic parts of information for any component symbol. The graphical part and the description part. All aliases of a symbol use the graphical part of the parent symbol which includes the footprint if specified. But each alias can have its own description part which consists only of the value (symbol name), description, search keywords, and documentation (datasheet) fields. This alias mechanism allows for what Rene referred to as “fully specified symbol” without having to redraw the graphical part over and over again. This is why there are actually 2 files for the symbol libraries (currently). The .lib file contains the graphical parts of all the symbols. The .dcm file contains the description part of all the symbols and aliases. The reason why the cache library for projects is only a .lib is because the description part of all the symbols in use (what would be the .dcm file) is embedded into the schematic in addition to other information overrides of the library (like footprint), one entry for every reference designator.
It is known that this will change by v6 (when ever that is, probably a couple years) because of a major overhaul of how the symbol library files and schematic files will be handled. I don’t know the specifics of how the v6 libraries will be other than it will be similar to how the footprints are currently handled.
4 Likes
I hope KiCad will support multiple way of pointing to datasheet, so use can locally cached their datasheet, and link the part to both local, and link, Incase the link broken, or not internal access. My personal library reference to local datasheet by default (like 3D image in footprint). And I add an addition “datasheet” filed which will contain the URL link.
AFAIK, the documentation field takes either a web link or a file path (I think it can handle path variables like the library tables can) for a local file. I haven’t tried other URIs like ftp:// or file:// but they may work.
The old 4.x version, allow relative path to the symbol library - which is very very nice if you wan datasheet and symbol stored together in repository. Now it not work, and using ftp or file:// required absolute path which is no long useful at least for my case. I will wait and see the finial before go change all my symbol to use Environment Variables. But I like to see if any new feature still can allow me to just link the symbol and work without other requirement of manually set this environment variable, and that environment variable… It just not work if you come back to the project after 10 years.
You are talking about the atomic part method, which is usually used with private “house” part number systems.
KiCad supports this, but it is your problem to make the libraries, as no two companies use the same numbering.
Yes. In that method you have to have each element you use as separate symbol (can be alias) in your library. I tried to explain why it can be usefull as I understood that @roboya don’t sees any advantage of haveing more than one Shottky in library.
In case I haven’t misunderstood you, a relative path can still be used for 5.x libraries.
This is a sample line from the sym-lib-table:
(lib (name VOM1271T)(type Legacy)(uri $KIPRJMOD/../kicad_lib/schematics_libs/VOM1271T.lib)(options "")(descr ""))Trouble is it is relative to the $KIPRJMOD. But I like to specify my “doc files” relative to where the symbol library file were. Same as 3d file, I like it relative to the path where the footprint file were, not the global/local KISYSMOD, or KISYS3DMOD, or KICAD_SYMBOL_DIR. These environment will break your link if I include multiple libraries from multiple locations/paths.
Relative to the folder where the project file is.
For each project I have symbol, footprint and models3D libraries related to ${KIPRJMOD}.
${KIPRJMOD}/…/libraries/Symbols
${KIPRJMOD}/…/libraries/Footprints.pretty
${KIPRJMOD}/…/libraries/Modules3D
May be I’m not clear!. In your case, what if your “libraries” location have nothing relative to the project?!?!. What if the libraries are in C:\my_personal_global_lib.
And all the datatsheet pdf are in C:\my_personal_global_lib\doc, C:\my_personal_global_lib\3dshape.
Then what if my project also need to link to another set of other library in:
C:\my_friend_lib (which have doc, 3dshape).
And another from github C:\ext\kicad-footprint, C:\ext\kicad-3dpackage, C:\ext\kicad-symbol.
If all the footprint reference to 3d shape using KISYS3DMOD, then it will not work at all. If all the symbol doc reference to KICAD_SYMBOL_DIR, then none of doc file will be able to located correctly by KiCad.
Then I would use other environment variables, like ${KISYSMOD}, ${KISYS3DMOD} or ${KICAD_SYMBOL_DIR}.
Anyway, every folder in the system can be related to the project by ${KIPRJMOD}, only the path from the ${KIPRJMOD} folder will be more complicated.
Or I didn’t understand you correctly. I understood you meant {KPRJMOD} pointed to the symbol library.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.