Parent page: Working with Managed Components
Altium Designer, in conjunction with your managed content server, provides a streamlined and highly automated process to quickly migrate your existing libraries to that server. The interface to this process – the Library Migrator – presents a one-click solution that automatically analyses the selected libraries and migrates them to the managed content server to which you are actively signed in.
Catering for all types of libraries, relating to older component management methodologies (SCHLIB, PCBLIB, INTLIB, DBLIB, SVNDBLIB), the Library Migrator is a dedicated solution for quickly building your company's set of managed components so you can benefit from their many advantages – high-integrity, lifecycle management, centralized storage and management, where-used functionality, manufacturer part choices and ease of design reuse.
The Library Migrator offers a minimalist Simple interface mode where the selected file-based component libraries are migrated to managed server components through a single step, while the migrator automatically takes care of type classification, the target source folder, parameter inclusion and value type, and the transfer of all relevant data. The interface is also available in an Advanced mode that provides a full preview of the proposed library migration, and access to its related data and settings. And while the migration is a single-click process by default, the migrator also offers advanced configuration options through the Properties panel for enhanced control over exactly how that migration is performed.
All information that is present in an original source library is migrated to the server-based managed components, including all referenced domain models (schematic symbols, PCB footprints, Simulation Models), parametric information, assigned part choices, datasheet files, etc. Component Templates are also created where necessary, and may then be refined and used for subsequent library migrations.
If your original components have multiple PCB footprints defined, the Library Migrator will bring those models across and keep the current default footprint. And if you only work with PCB libraries – your only concern is PCB layout – then the Library Migrator supports migration of just those libraries, or it can be switched to a models-only migration mode where specified models types are migrated from Integrated or Database libraries. Libraries that include multiple component types (monolithic libraries) are automatically detected and processed as well.
While library migration process needs to deal with file-based library sources that may use a range of formatting standards, its automated analysis processes detect the types of components in the source library (resistor, capacitor, etc) and also the parameters names and their value types (Volts, Ohms, etc). The system conducts and handles a number of validations, for example to ensure no duplicate IDs for the resulting managed components, or to ensure no duplicate models or component templates are created, and that such entities are reused across (linked to) components where needed. And if issues do arise, the system flags them, with suggestions on how to resolve those issues, aiming to get the migration back on track as quickly, and as smoothly as possible.
Library types that can be migrated are:
The Library Migrator is available when you are signed in to an Altium server. To access the migrator in its Simple (easy) mode:
To directly access the Library Migrator in its Advanced interface mode, along with its associated Properties panel, select File » Library Migrator from the main menu.
The Library Migrator's Simple mode preselects all aspects of the migration process based on its analysis of the source library and the connected server. The dialog then presents a summary of the migration structure, including a total number count for each item type. The library migration is performed as a single step from the command.
This Simple interface mode will suit most common source library formats, which tend to contain common component types (resistors, capacitors, integrated circuits, etc) and standardized parameter values. During the initial analysis process the system deduces the type of components within the library based on Designator or parameter key words (
LED, etc) and then locates a corresponding Component Template in the target server (LED). This Template is applied to the migration of those components, which then specifies the migration settings such as target folder (
Components/LED), parameter mapping, parameter value units, and so on – suitable templates are available in the server if the Install sample data option was selected during installation.
The results of the library migration, as newly created managed components, can be seen in both the Explorer and Components panels. Migrated components include all models, parameters as interpreted by the applied Component Template(s), Part Choices derived from Supplier Link source data, and any reference links or files.
Notable points regarding the library migration process are:
Components/Uncategorizedserver folder. Before the migration is run, this can be resolved by applying Designator Mapping or Parameter Grouping in the Advanced (full UI) mode. Alternatively, you can proceed with the migration and then modify the component's settings and folder at a later time, through the Explorer panel.
The Library Migrator's full GUI is presented when in Advanced mode, which offers detailed control over the management of libraries, component types and component parameters. When combined with the Properties panel, the migration of component libraries to the server can be configured to your specific needs. Note that the migrator's settings can be saved and restored by exporting/importing configuration files.
Advanced mode is enabled when the Library Migrator is opened from the File » Library Migrator command, or when the button is selected while in Simple mode. Libraries are added to the migrator's SOURCE LIBRARIES section (if not already populated) from the button, or by dragging and dropping a library file onto the area. Use the right-click option to exclude a selected library or extracted sub library from the migration.
The MIGRATION PREVIEW section lists component type groups identified from the source libraries – as Component Types () or the proposed Folder Structure () – and includes a parameter-based grid view of those components (Components). Parameter values in the grid can be edited on-the-fly, which avoids the need to open and edit the source library. The lower Details area includes additional information sourced from the currently selected component – Part Choices, Models and Datasheets.
Regardless of the detailed options and data presented in the interface, the migrator's Advanced view can be used in the same manner as the Simple view – just click the button to invoke the migration process, without intervention. As in the Simple view process, the migrator has analyzed the library, deduced the type of components it contains, and applied the correct Component Template. In turn, the template determines the server target folder, the applied Naming Schemes and Lifecycle Definitions, and parameter mapping/interpretation.
Source libraries that contain multiple component types are detected by the migrator's analysis routines and segregated into sub-library groups, where they can be processed as individual type libraries. The component type detection is based on the source component Designators (
C?, etc) and also key words (
Res, etc) contained in the other main component parameters (Description, ID, etc).
In the example shown below, the source library (
ProjectABC.IntLib) has been 'split' automatically according to the detected component types (Capacitors, Resistors, etc), which can be selected in the Component Types column to preview their constituent component entries in the Components grid.
Note that the presentation of the Components listing may be changed in several ways:
In the monolithic library shown above, one library sub-group entry is named
Uncategorized (and listed as
Uncategorized under Component Types), which indicates that the migrator could not detect and assign a type to that group of components – the Component Type is effectively set to
None. In this example case, the undetected components (Inverter logic ICs) use an unrecognized Designator prefix (
U?) and their parameters do not contain detected key words such as
This issue can be addressed by manually mapping the designators used for those components to the desired component type in the Library Splitting dialog, which is accessed from the button – available when the source library (
ProjectABC.IntLib) is selected.
With the dialog's Custom Designator Mapping option selected, click the button to create a new mapping entry, choose the designator string option that applies to the uncategorized components from the Designator drop-down list (all available designators are included), and then the desired component type option from the Component Type drop-down menu. Confirm the completed type-designator mapping (
U? designators to the
Logic component type) with the button. Note that if needed, multiple comma-separated designator types can be entered manually.
With the component type now specified by the applied mapping, the migrator will use the matching Component Template (
Logic) to configure the library migration as defined by the template settings (folder, naming, etc).
Note that thanks to the flexibility of the Library Migrator settings, a new (uncategorized) type of component library can be migrated with the entire infrastructure required for future migrations of that library type. By choosing a suitable migration configuration – new Component Type, Component Template, target folder, parameter mapping and parameter Value unit types – the only requirement for the next migration of that library type is to select the previously defined Component Type. The selected Component Type will then determine all other aspects of the migration.
Components that will not be migrated to the server correctly, or not at all, are indicated by warning or error tags in the Advanced UI when the Library Migrator is run (), or a migration Validation is performed (). A Fatal error will block the migration.
When attempting to perform the migration, the Messages panel is populated with the detected violation issues, and a dialog will offer the choice of abandoning or proceeding with the current migration configuration. In the latter case, invalid components are not migrated or the migration process will fail.
In the case of a canceled migration or when the manual Validation is run, any components that fail the migration checks are then associated with error/warning icons plus further information in the lower Details area. Icons in the preview Status column indicate the specific component entries that are in violation of the migration rule checks.
Parameters errors, such as in the example shown here where the component's
Forward Voltage value cannot be interpreted to a valid voltage, can be resolved by:
Text– select the Source Library in the migrator UI, and then change the
Forward VoltageType in the Properties panel Parameter Mapping list (under the General tab).
A missing file error, such as the unlocatable Datasheet file shown here, can be resolved by:
Use the Search field (upper right) if you wish to find particular component entries. The search filters the item listing by matched parameter value(s) for the currently selected component type – select All under Component Types for the search to apply to all components in the available source libraries.
If you encounter a 'model not found' error (such as
Footprint <footprint name> not found in available libraries) when attempting to migrate a schematic library, it means that the Library Migrator cannot locate the models that are linked to components within the SCHLIB.
In Simple Mode such errors will be shown in the HTML-based Migration Report, accessed from the button that is available when the migration has been run. In Advanced Mode, the errors are indicated by Status icons in the main interface () and as entries in the Messages panel – this occurs when performing a validation check () or when attempting to migrate the library ().
The simplest way to resolve (or avoid) this issue is to ensure that the required model library files are available from within Altium Designer. Libraries are installed through the Data Management - File-based Libraries page of the Preferences dialog.
Alternatively, if you do not wish to install multiple model libraries, you will need to locate them in the software's default library path (or edit the path), and check that the model source library is specified for the Schematic Library components:
The Library Migrator also includes mechanisms to avoid duplicate components being created in the target server. This is achieved during validation by comparing the source library's component identifier parameters and Part Choices with those of components in the target server.
With the migrator's default settings, a Validation step () will flag a Warning message when the same component
Part Choices entry (indicating a potential component duplicate) is detected in the target server. The displayed warning/error message includes the type of duplication violation (parameter or Part Choice), the violating library component name and the server component (by ID) it is in violation with.
The parameter name-value pair used to detect duplicate violations is specified in the Duplicates Detection region of Properties panel, under the Advanced tab. Use the Unique Field drop-down menu (set to
Name by default) to select from the Parameters available in the source library. This selection is particularly useful for company library configurations that use a proprietary identifier field that ties into the broader enterprise system.
A different type of status flag can be set for the duplication violations by selecting an alternative Report Mode in the Migration Checks region under the General tab of the Properties panel.
Automated duplicate detection also is used to process source libraries that use a common symbol model for all components. Such libraries tend to be composed of a single component type with differing styles and values, such as resistors of a particular package format, where the symbol for each is a standard model graphic.
This single, common model condition is detected by the Library Migrator, which then configures the migration to transfer one symbol model that applies to all migrated components – rather than a corresponding, individually named symbol for each component. The symbol to be migrated adopts a generic
Symbol name, and all component parameters remain unchanged.
The migrated library symbol (which has the name
Symbol and a blank Description field) can be edited to suit your needs. In the Explorer panel, use the right-click Edit option to invoke the action. During the process, select the Update items related to <symbol ID> option in the Create Revisions for Item dialog to ensure that the migrated components use the new symbol revision.
The range of Component Types registered with the system – or in practice, in the connected server – can be viewed and managed in the Data Management – Component Types page of the Preferences dialog. Types are listed with their associated component Template and server Folder, and will include any new types created when the Library Migrator has migrated library files to the server.
The creation of multiple new Component Types might typically occur when a Library Migration configuration has used Parameter Grouping (a nominated component parameter value) to determine the Type for each migrated component. For example, the
Categories parameter might be
Resistor-0608 for one collection of migrated components and
Resistor-0402 for another, and so on. Here, all would be best grouped under the single
Resistors Component Type for future use.
Rather than manually changing all the Component Types in these circumstances, the Component Types page in Preferences allows selected Type entries to be merged into a specified single entry. To do so, select all Type entries to be merged, including the target Type, right-click on the highlighted entries and choose the Merge option from the context menu. In the following Merging dialog, select the target Component Type from the Merge to drop-down menu and click the dialog's button to confirm. The below image illustrates this for a range of migrated Resistor component types.
The process changes the Component Type for components of the merged type (such as
Resistor-0603, etc) to that of the merge target Type –
Resistors in this example. One of the practical outcomes is that all components of a particular type will now be available when that type is selected under Categories in the Components panel. Note that the component entries are not affected in any other way. They remain in their existing folders, which are associated with the Component Template created during migration, and the templates themselves remain available.
Following the merge, the Data Management – Component Types page now indicates that the
Resistors component type is the default for multiple Templates – namely, the
Resistors Template and all those associated with the newly merged component types (the
Resistor_0402 Template, and so on). The Folder entry for the
Resistors component type corresponds to the target folders of those multiple templates.
The result of such a merge is that when
Resistors is chosen as the migrated component type in the Library Migrator, it will be applied if you select any of the merged Templates (
Resistor_0402 etc) as an alternative. When a new component is being created (File » New » Component), those Templates are offered as sub entries for the
Resistors Component Type in the Create new Component dialog.
The Edit Templates dialog, accessed from the button, allows you to update the Template to Component Type mapping from that indicated in the Data Management – Component Types page. The mapping, as shown in the dialog's column entries, represents which Component Type be will applied when the associated Template is used – or conversely, which Template is used when a Component Type is chosen (such as when creating a new component).
For a selected Template entry in the dialog, the association is changed by choosing an alternative Component Type from the entry's drop-down menu. When the dialog and page are then closed, the template's
ComponentType parameter value and its
Default Folder setting will be changed to correspond with the newly specified type. This is equivalent to editing the Template manually.
The result of the updated template-type mapping is shown in the Data Management – Components Types page, which has a Name orientated listing – where Name represents Component Type. This indicates that a number of different templates (
Resistor_0603, etc) are associated with and will apply the
Resistor_LibMigrate Component Type.
The Library Migrator may be switched to a special Models Only migration mode that detects and processes the available component models in a source library. To change to this migrator mode, check the
LibraryMigrator.ModelsOnlyMode option in the Advanced Setting dialog, available from the System – General page of the Preferences dialog.
In the Models Only mode, the migrator's analysis process will detect all Symbol, Footprint and Simulation models that are available in a source library (
PcbLib, etc), then migrate those models to the server using the system's default locations, naming schemes and lifecycle definitions.
When the Library Migrator is switched to its Advanced mode () or opened in its Advanced mode (File » Library Migrator), full details of the proposed model migration are available. The Migration Preview area shows the Folder Structure that will be used in the target server, which may be modified from the default settings in the Folder field for each model type in the Properties panel. The applied naming schemes and Lifecycle definition for each model can be selected from the available system types (see Properties panel, below).
Once the Library Migrator is configured, select the button to complete the migration of the listed component models. The results can be reviewed in the migration log file, as offered by the Library Migrator progress dialog (), or by viewing the migrated models in the Explorer panel.
The Library Migrator's associated Properties panel settings provide advanced control over the migration configuration for the selected library (or sub library group). The panel's option settings are defined by the default system settings or those specified by the applied Component Template, which in turn is set by the library's detected component type –
LED in the example shown here. The settings are also user editable, allowing you to tailor the migration process as required, and may be restored with the Reset to Default link (top right).
The panel's General tab sections are as follows:
[Create new]for the automatic creation of a template derived from the source library parameters and the Library Migrator's current settings, or choose [
No Template] to prevent a template from being applied or created.
<Skip>option to not include a parameter. Any parameter that has not automatically been matched to a source library parameter (is set to
<Skip>by the system) can be manually mapped to a suitable Template parameter – for example, the source parameter
ROHSmight be selected to match the
RoHS Compliantparameter defined by the server template. Parameter names can be edited, and Parameter sets can be added, edited and removed. The base component parameters (
Description) may be remapped, but are otherwise read-only.
Supplier Part Number 1) is used for the Part Choices field entries.
Fatal Errorreport mode is selected, it will block the migration process when this violation is detected.
The panel's Advanced tab offers settings for all migrated data object items, as set by the system defaults or the applied Component Template. These include component Models, Datasheet files, and any created Component Templates. With the exception of the Datasheet option (an enable/disable toggle) the settings for each migration object include:
The Library Migrator features the ability to export a detailed text-based file that captures the current configuration setup, which includes all configurable migration settings such as target paths, parameter mapping, naming scheme, lifecycles definitions, target component types, and so on.
The Migration Configuration file is saved from the File » Export » Migration Config command as a
*.lmcfg file type, and may be restored at any time through the File » Import » Migration menu option.
The ability to restore a configuration is particularly useful when the source file-based library has been updated and those changes need to be migrated to the server. If the configuration was exported when the library was first migrated, the restored (imported) configuration will re-establish the exact configuration settings that were used, which guarantees a consistent data transfer scheme for that library (or libraries).