Neither would I. Creating a large library from scratch takes time (work hours) and it’s valuable intellectual property. Most of the companies aren’t Open Source minded even if they use Open Source. I would love to be proven wrong.
1 Like
As the company I’m working for makes point-of-sale terminals, the parts database would be considered secure information, since it would provide an attacker/hacker insight into the parts used in the product, along with internal company part numbers. There is no way that would ever be shared publicly.
1 Like
I agree.
Also a parts database would expose who the approved vendors are and reveal single sourced suppliers, allowing pricing abuse, so this is very sensitive
1 Like
ince it would provide an attacker/hacker insight into the parts used in the product, along with internal company part numbers.
The classic security by obscurity
The flaw here is liquidation sales and ebay.
I buy our competitor’s products from said sources all the time, even some decently newish stuff 
This is just one brick in a rather large security wall.
It will never be impossible to reverse engineer a product, but we can make it as difficult as possible.
Having a product sample with all the chip numbers lasered off is very different to having that and the company parts database.
Hello,
me and my colleagues at the EDL design lots of different stuff for research purposes like
power electronics, communication, sensors, FPGA, RF, medical, optics, harvesting… and many other
crazy stuff.
Lately we are evaluating KiCAD (6.xx) as a possible CAD to use in parallel with our current workflow
that relies on OrCAD CIS and PADS.
We manage our own libraries for sch/pcb components and we recover the ‘commercial’ information from
a ‘normalization’ database (more than 16000 items) accessed by OrCAD via ODBC.
Our first evaluation showed us that KiCAD has all the features that we need but the capability to
retrieve atomic information from an external DB, so this year we planned to design our own ‘plugin’
to allow that; we were starting but I’ve seen that things are already starting to move in that regard 
I’ve read the technical proposal written by @craftyjon, and i find it very adherent with our current
workflow, and i was asking if we can in some way help to reach the goal, maybe help with coding?
testing stuff?
If i would like to follow the developments reguarding the #7436 issue, is it fine to check
the 6.99 branch?
Is there a developer that we can be in contact with in order to understand how we can be of
assistance?
Thanks, Claudio.
2 Likes
I’m the developer in question. There is no code that is ready to test yet, but if you reach out to me by email, I can let you know when there is.
2 Likes
So I noticed that Issue # 7436, is listed as closed.
Does that mean that this is implemented?? Is there a good place to read about the implementation or do I just need to update the version and try it out?
OK - Thank you for your efforts on this craftyjon!
1 Like
4 Likes
Great progress! IMHO this is a very important feature for KiCad in order to serve as a alternative for professional CAD packages.
I’ve read the documentation and it looks good. I have two comments:
-
is that having a database is not just for larger companies or teams, it is also very usefull for small or single person companies. I have been using Orcad with a component database for >20 years and I never want to go back to the tedious situation where all the information of a part is stored in the parts library or sits ‘hidden’ in the schematic. A database makes it so much easier to ‘share’ components between designs as well. Define once, use many times with 100% assurance all the part information is correct so no nasty surprises after the board has been produced. It also takes so much work away at the logistics side of things.
-
Components are not always in seperate tables (with a table for each kind of component). IMHO it makes very little sense to do so because you easely get a messy mix with different field types which becomes hard to maintain. In the end there has to be a uniform bill of materials with the same columns for each type of component. I’m using a single table (with Orcad CIS) which has a component type field that descibes a tree in which the components are organised. For example: connector\board2board . The root type is connector and the sub-type is board2board. Sorting the component table by this field also groups the similar type components together so having multiple tables to keep an overview of various components isn’t necessary.
2 Likes
- i agree.
- as long as you have a field that can provide a primary key to the table, i think that the implementation is flexible enough to accommodate your use case.
The point of that language is to indicate that our primary focus is on meeting the needs of teams – if we happen to meet the needs of individuals also, that’s great!
It does not matter to KiCad whether or not you put components in separate tables / views, but doing so may improve performance. It all depends on the application
In the end there has to be a uniform bill of materials with the same columns for each type of component.
The columns used in the BOM are (in my experience) a subset of all the columns available. The BOM typically doesn’t report on component parameters such as tolerance, etc which are in my database.
I agree that the BOM is typically a subset but still it helps to maintain the whole setup when the database has a consistent layout.
What I’m wondering is whether KiCad can built a component tree (like Orcad Capture CIS does) using a ‘component type’ field in a single table with different components. This makes it quite easy to configure the system because you don’t have to do a lot of setup for the database part. Just setup a single table, set the database <-> schematic field relations and done.
I do not use Orcad so I don’t know what “component tree” means in this context.
This is a screenshot from the database part selector from Orcad. The tree is build from the ‘Part Type’ field which is also in the screenshot.
I can highly recommend to look for some videos on how Orcad Capture CIS works in order to get some inspiration. I have some Altium experience as well but the way it is implemented in Orcad Capture, is very efficient to use and setup.
1 Like
I don’t think we are going to base KiCad software off of videos of other software in general.
It is not clear from your screenshot what you’re actually asking for KiCad to do here. You want to see parts in a tree view based on a database field? I don’t think we will implement that anytime soon, because KiCad only supports a single-level tree at the moment. However, you can create different views in your database and present those views to KiCad to sort into different libraries.
What Orcad is doing in the part selector is presenting all components from all database sources & component libraries in a single tree view so it is easy to find & select a component.Thus without needing to go through various libraries by yourself hunting for a particular component. I now understand that this will likely be a next step for KiCad to take.
BTW: I don’t want / suggest KiCad to re-implement what Altium, Orcad, etc are doing but it never hurts to look at software that already has similar features. Not re-inventing the wheel and so on but improving it 
2 Likes
We do take into account how other software works, but generally through actually using/experiencing it rather than just watching videos (which can be deceiving sometimes)