Frequently Asked Questions

Changes to Library handling in Version 12 Back


Version 12 has of necessity introduced some major changes in the way the libraries work. These are a consequence of introducing the ability to use multiple library paths. This document details those changes, and the impact they may have on the way you use the libraries.

You should take particular note of the 'warning' below about a possible issue with the (now redundant) DemoLib library.


Firstly, the search conditions have changed. Previously component libraries were searched in the order in which they appeared on the disk. For those who remember DOS, it's the order that would have resulted from a 'DIR' command. The only way of modifying this was by using a file in the library folder called 'Libnames.txt'. Now, the libraries are searched in folder order, beginning at the top of the folder list. Within each folder they are searched in strict alphabetical order, so to promote a library within a folder, it's necessary to rename it. 'Libnames.txt' is now redundant.

Secondly, (and this has the greater impact), components no longer have a hard link to the symbols they use. Previously, every component contained a record of the symbols it used, and the exact library where those symbols could be found. This worked well, but created a phenomenal amount of work for anyone attempting to rationalise their libraries. Now, because it is no longer possible to guarantee that the relevant symbol library will be in the same folder, or even that there won't be two symbol libraries using the same name in different folders, this hard link has had to be abandoned. In it's place is a search algorithm which is exactly the same as that used to identify components, but this time used for symbols. Components still record a symbol's originating library as well as its name but it is purely for reference and is never used to located the symbol.

The major impact of this is that it is no longer possible to use two symbols with the same name, but in different locations. The reason is that regardless of the component initiating the search, the same search pattern will be followed in every case, so the same symbol will be found in all cases, and any other copies of the symbol will effectively be redundant. So, where a conflict such as this exists, clearly it's necessary to know which symbol will be used. Fortunately there's now an easy way to determine this. From the library manager, on the relevant symbol tab, use the [Find] function. In the results list, only the first copy found will be shown bold. All the redundant copies will be greyed, but their location can still be seen.

Finding and resolving duplicates

So, how to resolve this situation? If the affected symbols are identical, then no problem exists. If, however, they are not, then one or the other will need to be renamed. First though you need to find whether there are any duplicates in your libraries, which you can do using the 'Report' button on each of the Library Manager dialog pages.

Having found duplicates, resolving them is usually quite easy. To do this, simply use the Rename button on the just open in the symbol editor, and save with the new name. Before saving, it's a good idea to use the 'Find' function to check that the new name really is unique. The original can then be deleted. Assuming that you know which component will be incorrect, you should also open that in the component editor. Once open, right click on the incorrect symbol, select 'Properties', then browse for the renamed replacement. Save the corrected component back to the library.


In version 12 the standard libraries have been rationalised so that they are completely self-consistent without duplication. The entire 'Demolib' library has been removed as all components were copies of others. However a problem has arisen. This will not affect a completely new installation, but where an existing installation has been overwritten, you should delete any old copies of Demolib. The reason is that it has been discovered that the SOT23 footprint in Demolib.psl has a non-standard pinout. As this is near the beginning of the alphabet, it is highly likely to be used as the default, causing all devices with a SOT23 footprint to be incorrect. This will NOT affect existing designs unless you use update component, but it WILL affect all new designs, and designs which have not previously used a SOT23 footprint. If you discover any similar instances, please inform Number One Systems as soon as possible.

Redundant Libraries

A similar issue exists with several other 'old' libraries. The following libraries have been merged into other library files or renamed, and are thus no longer required:

  • AN3.cml
  • Analogue.cml
  • Bipolar1.cml
  • Conn_std.cml
  • Fet1.cml
  • Fet2.cml
  • Layan.cml
  • Opamp1.cml
  • Pulsar.cml
  • Trnsistr.cml

Although the presence of these libraries will not cause the same mismatch effect as Demolib, the presence of the old library files will only serve to slow down the scanning for library items.

Assuming you have not added your own library items to any of these libraries, you should therefore delete them from your system.

Back | Contents KB020032 / 02-Apr-2010 / Keywords: library setup duplicate redundant