Home

Introduction

This repository is about a proof of concept in matching schema components in KiCad with a PartKeepr database. The proof of concept is realized in a few XML scripts. These scripts can be executed from within a single executable developed by me.

The reason why I've chosen this platform is mostly because I liked the challenge. Also all of the logic is within scripts and therefore customizable and expandable.

Interpreting schemacomponents specifications and stockcomponent specifications and matching both is heavily depended on how information is structured. This proof of concept is about precise matching, with very little data entry burden.

Component specifications

Different components can have different requirements that must be matched. For example:

• a resistor has a resistance value, a minimal power rating, a footprint.
• a capacitor has a capacitance value, a minimal voltage rating, a footprint.

These differences are implemented by the following specification classes:

• Resistors
• Capacitors
• Inductors
• Zener diodes
• Connectors
• Generic components

Within classes it is possible to have different component kinds, like unipolar and bipolar capacitors.

Collecting schema component specifications

The component class of a component is mostly determined by its library identifier (Device:R for example). Resistance, capacitance, inductance, zenervoltage values are parsed from the value field. Different notations are possible, values are stored and matched by scaled integer values. This means it doesn't matter how values are formatted. Parameters can also originate from default values, like a 250mW powerrating of normal resistors. These values can be overruled by adding them as extra fields.

Collecting stock component specifications from PartKeepr

The component class of a component in PartKeepr is mostly determined by a the category it has been assigned to. This information must be added to the description of such a category (or one of its ancestors). For example

[Resistor]
ComponentKind=Resistor
Footprint=THT

Or a subcategory resistor

[Resistor]
PowerRating=250mW
Technology=metal film
Tolerance=2%

Resistance, capacitance, inductance, zenervoltage values are parsed from the component name. Different notations are possible, values are stored and matched by scaled integer values. This means it doesn't matter how values initially where formatted when matching them. Requirements can also originate from category values, like a 250mW powerrating of normal resistors . These values can be overruled by adding them as extra Part Parameters. Text parameters and numeric parameters are both supported. From a numeric parameter the nominal value, the prefix and the unit are used to create a text value, which is processed the standard way.

Schema component and stock component matching

Schema components and stock components both are handled in a similar way. For each component it’s specification class is determined by reading the data into a specification object of such a class and the asking the object if it’s valid or not. More special specification classes are tried before the more generic. (In this way available data can be treated differently in each class, without outside knowledge on how.) The first valid specification object of the schema or stock component is added to the list belonging to it’s specification class (so resistors are seperated from capacitors). These components don’t have specification data, only “instance data” such as a designator or a stock location.

The next step is bundle identical specifications, this is done by first sorting the list and then walking trough it. If a specification object is the same as the previous one, the components are moved and the identical specification object is removed.

At this point schema specifications and stock specifications are still in seperate but very similar lists. This is required because when matching schema specifications to stock specifications they don’t need to be identical. For some specification requirements better values are allowed. (Better tolerances, poweratings etc.).

The next step is to match each schema specification with each stock specification of the same specification class. If they match than add (but not move) the stock component to the schema specification. (Stock components might match multiple times with schema specifications). Requirements that must match exactly can be indexed to speed up the process.

After these steps we end up with categorized and bundled specifications which contain schema components and their matching stock components.