Our Take on Concord Pro / NEXUS / Vault
Note: For this article's purpose, the term Concord Pro will be used. However, the same concepts can be applied to Nexus and Vault. The term container will be used as the location in which the files are stored. Regardless of what one calls this product, it is a container.
We at Nine Dot Connects have had the opportunity to watch the vault evolve over the past 8 years. Indeed, it has evolved in many ways, not just in the name. There has been a good deal of streamlining to the various processes that make Concord Pro what it is - a document storage container. Its purpose is to store all PCB design data - libraries, templates, and projects. It does a great job storing documents with an excellent graphical representation that combines revision control with life cycle management. When a project has been formally released, that revision of the project is locked forever. The user is assured the information assigned to that particular revision is original and unadulterated. Copies can be made of the project, but another revision must be declared if changes need to be made. The same is also true for components and templates as well.
There are two methods to introduce components into Concord Pro. The first is by importing existing libraries through the library migration tool. The library migration tool can also be used to update components en masse.
Note: In prior versions of Concord Pro, the user pushed the component into the container through the component library editor (.cmplib). This is not a library but rather a staging ground to move the component into the container. This was eventually replaced with the library migration tool.
The second method is to create a component within the library editors provided within Concord Pro. The intent is to manage to create the Concord Pro component, eliminating the need to import the component thereafter. The component editor tool handles all aspects of the component development, including the symbol, footprint, simulation, and parametric data.
Like a database configuration, a Concord Pro component consists of a symbol file, a footprint file, and a component file containing the parametric data and links to the symbol and footprint files. Other library-related files can be associated with the component file, such as a SPICE simulation file and a 3D model for the footprint file. (No need to embed a 3D graphic into each footprint in Concord Pro.)
Concord Pro provides pre-defined folders for its directory structure. These folders not only store specific file types, but they can also assign formatted IDs to each file introduced to the directory, provide information and previews based on the directory type, and assist with the creation and editing of files specific to that directory.
If one is looking for a well-defined library system with revision control, Concord Pro is certainly capable.
With that being said, caution is given. Concord Pro requires a full-time librarian. It is straightforward to use the wrong naming ID or to forget to add something into the component parameters before checking into Concord Pro. A change to a component's symbol or footprint will result in the need to bump the component's revision. This is a minor issue when performing these edits on a single component; however, if a revised symbol file happens to be associated with 1000 components, those 1000 components will also need to be revised. Granted, the tools are there to facilitate it; however, this takes time.
Deletion of any file can be very tricky. The ease or difficulty depends on whether the file has already been used in a design and any other file dependency. For example, the Concord Pro will not allow one to delete a symbol if it is associated with any components.
The introduction of the component through the library migration tool can also be tricky. The file structure needs to be well established within Concord Pro, and the naming IDs need to be predefined to ensure proper consistency. More so, a successful import leans heavily on how the library is structured before importing the library. The library migration tool is fully capable of importing any Altium supported library. The results will be different depending on the library type. For example, a classic symbol-centric library (consisting of .schlib and .pcblib files) will create a symbol file for each component established in Concord Pro. That may be fine for ICs, but does one want 1000 resistor symbols, one for each resistor component being imported? This creates a ton of files and makes the management very difficult. But an Excel spreadsheet as a temporary database library allows just one symbol file to be reused for 1000s of resistors. This also takes time to prep.
Lastly, those who have outside contractors will need to 'straightjacket' the creation of components. If the contractor's components do not match the components' look and feel in Concord Pro, each component will need to be heavily edited before being imported. It is far more difficult to revise a component within Concord Pro than prep the component before importation.
Unfortunately, we must conclude that though Concord Pro is a powerful way to create and maintain components, the overhead in setting up and continual maintenance of Concord Pro erases any efficiency that may be gained from it. The entry point is the biggest issue, which requires a great deal of forethought to get it right, but still requires a good deal of manual entry, especially for parametric data.
We will also point out that Concord Pro can live in harmony with an external database. In this arrangement, Concord Pro contains the graphical representation while the database contains the parametric information. The component in Concord Pro needs to have a unique ID associated with the component in the database. When the component is placed on the schematic, the DbLink file can pull parametric data into the component. We have called this the Tesla Motor Method (TMM) to give them credit for this idea they suggested on the Altium forum.
