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?
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?
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.
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 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.
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
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)
i’ve been testing the database libraries with great satisfaction, expecially the
new search capability in the symbol chooser, it works so much better than in the
system i’m currently using.
i have a couple of questions slightly related to the topic of DB driven design:
afaik, up to now KiCAD could not could not propose different schematic symbols
for the same component. With the intriduction of kicad_dbl has something changed
in that reguard?
Could be possible to have a mechanism similar to the selection of footprints,
with multiple names separated by ‘;’?
This is not a fundamental capability but it happens that me and my colleagues
sometimes have a different preference on graphical rapresentation on schematic.
I usually like a more compact and crammed schematic, some collegues likes more
‘sparse’ rapresentation.
it happens that under ubuntu (20 and 22), the kicad-nightly package is incompatible
with the ‘unixodbc’ package that contains the ‘isql’ command, useful to check the correct
configuration of the datasources. can something be done about that?
Some suggestion of alternative methods to check the datasource configuration?
I know this feature is new and highly undocumented, but I could use a little nudge in the right direction as I’ve been struggling for the past hour to get a mimimal working example library up and running.
I have to admit I am not very familiar with the nomenclature and tools for database work. I’m using a pretty convoluted setup of a local WAMP server running MySQL, and I’ve created my test database with HeidiSQL. I’m sure there are easier ways, but I managed to export my test database as a .sql file.
My main problem (besides a general lack of knowledge and experience in this area ) is that I fail to see where/how the path to the database file is specified in the configuration file. I have tried simply putting my “SymbolsDB.sql” database in the same folder as the “SymbolsDB.kicad_dbl” configuration file, but this was a wrong assumption.
I guess what I am looking for has to do with the DSN and/or connection string, but after consulting Google and reading a bit at e.g. SQL Server connection strings - ConnectionStrings.com , I want to cry under my desk
) is that I fail to see where/how the path to the database file is specified in the configuration file. I have tried simply putting my “SymbolsDB.sql” database in the same folder as the “SymbolsDB.kicad_dbl” configuration file, but this was a wrong assumption.