[CrowdLaborFunding] PCB CAD tool idea

[blueskull]

It may be a stupid idea, and I know there will be KiCAD fans and gEDA fans jumping out. Just to give (myself) a heads up.

I'm thinking if we (active EEVBlog users collectively) can work on a low cost, cross platform CAD tool with VERY BASIC features but very good expandability.
There are tons of threads complaining commercial CAD tool price, OSS CAD tool hard-to-use, and the BS MSFT does to Windows thus the willing to move away.

Based on my understanding, most OSS tools are designed to be new. They are mostly coded by university kids and researchers, looking for publications.
Thus, instead of polishing simple features, they prefer advanced features.

What I'm thinking is can we work on a PCB CAD tool that is very simple, with no new tech nor innovations, but very easy to use and migrate from existing CAD tool.
To be exact, an Altium Designer clone with same graphics, look'n'feel, and keyboard binding, without any advanced features.

I'm looking for the following feature set:

1. Schematic editing -- no ERC, no simulation, no back-annotation. Just one-way netlisting and BOM generation.
2. PCB editing -- no glossing, no hugging/walkover, just hugging, no SI/PI/PDN, no simulation, no DDR routing, no ridig-flex, no autorouting. Just basic editing, length matching and exporting.
3. Librarian -- no multiple footprint, no online database, no supplier mgmt, no nothing. Just a simple SCH and PCB primitive editor and linking between them.
4. Expansion -- all interface of internal modules should be accessible through DLL interface for expanding. This allows advanced features to be developed and maintained separately.

Due to the cross platform nature, I believe C++/wxWidgets is the best combination.
C#/WinForms looks too archaic on non-Windows platforms. C#/gtk or C#/wx.NET is hard to install for non geek users on macOS and Linux.
Python is equally hard to install when wxWidgets comes to the play. Python/Tk looks older than me.

I don't want to waste too much time on this. 10k LoC is what I can tolerate at most. Therefore, no C. I don't want to waste my life on writing linked lists.
Java was never in the picture. If I mess with Java, I would better off using WinForms.

Again, no EDA, just CAD. KISS. The goal is a cloned version of Protel 99 SE that runs on any OS.

A permissive GPL open source license will be chosen. I want the ecosystem to be self-sustaining by attracting people to write paid modules dynamically linked to the main program.

Code gurus here, what are your opinions on this topic?

[awallin]

random thoughts:

• this is a tough project to get off the ground - need a capable programmer to hack together a working prototype as a weekend (or two) effort..
• what examples of working crowd-funding open source (gpl) are out there? in reality you probably need 100-200 hours from one or two very capable c++ programmers to get it off the ground..
• git is a good idea for symbol/footprint libs - some of the problems kicad currently has could be improved
• execution is key - there are probably a dozen of these gEDA/kicad clones which are just in the planning stage forever..

good luck 

[nctnico]

This has been done a lot of times before already. IMHO you better put your effort into KiCad or Geda (more specific: PCB-rnd). Both do exactly what you describe. I sense the problem is more likely that you don't want to learn how to use these tools and want to invent your own. Chances are very high that you end up with a new kind of KiCad which also has a learning curve for most people.

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

[ataradov]

This is an excellent idea, and I'm actually working on something like this in the background. I have some very good ideas on hoe to drastically improve manual routing process. But that's a long term project going on the background of everything else.

I doubt that 10k LoC is realistic. I would estimate 5-10x that amount at the minimum.

But the main reason I'm not doing this in the open and try to attract other people is this:

To be exact, an Altium Designer clone with same graphics, look'n'feel, and keyboard binding, without any advanced features.

I hate Altium UI. I know it is a matter of a personal preference, but that's a big problem for a collaboration like that. For me personally Eagle is the closest to idea UI. It has some things that I don't like, but the general direction is there for me.

There are some other workflow choices that I want to see in a tool like this, but they will likely to be disliked by others.

[radioactive]

This project seems to be off to a nice clean start:  https://librepcb.org/

It doesn't appear to be ready for anything very complex yet, but something to keep an eye on... or maybe work on?

[Lukas]

As the main developer of http://github.com/carrotIndustries/horizon/ (see also https://www.eevblog.com/forum/eda/new-work-in-progress-eda-package!/) I think I'm qualified to comment on this topic.

I don't want to waste too much time on this. 10k LoC is what I can tolerate at most

Won't cut it. Horizon had more than double that 1.5 years ago.

Based on my understanding, most OSS tools are designed to be new. They are mostly coded by university kids and researchers, looking for publications.

My motivation for starting something new has been the fact that no existing OSS EDA tools met my requirements for an EDA tool of the 21st century, in particular regarding parts management.

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work.

My thoughts. Horizon tries to do that well.

To any naysayers that that project won't go anywhere: I did the moderately complex board for my master thesis entirely in horizon EDA: https://github.com/carrotIndustries/x-band-tx

[awallin]

wow this is turning into a good list of KiCad/gEDA alternatives 

[Kasper]

If you have length matching, you'll be more advanced than circuit studio

I think there are a lot of people that would like a simple, easy to use and low cost CAD and making it similar to altium would be helpful for anyone who aspires to work for a company that uses altium.

I don't have much to offer aside from feature requests:
1: gerber import.

2: panelize with ability to route into the panel rails for this:
EEVblog #552 - DFM Automated PCB Panel Testing

Those are also features that circuit studio is lacking.

[krish2487]

Well,
I am not qualified to speak about this in any manner.


but here is my 2 cents,
Looking at the replies to the thread, I see different objective requirements for different people, different subjective preferences for different users.
This alone will drag the project in multiple different directions at the same time.
That is precisely what happened with kicad, before CERN took over.
Many users felt their requirements were not taken care of, the developers felt that the users did not know how to use their tool or have the correct workflow.


I am not trying to rain on anyones parade here, but instead of starting a new project wouldnt it be better to stick with a known devil  like kicad or altium?

[apurvdate]

i'm just someone who uses kicad for hobby projects ( like 555 astable ) and absolutely i've no idea hows the kicad internals work..
but here are my thoughts.. you want a bare minimum cad.. why not create a stripped down version of kicad itself? compatible with kicad symbols & footprints.. with ui modifications you desire..

[ataradov]

why not create a stripped down version of kicad itself? compatible with kicad symbols & footprints.. with ui modifications you desire..

Its code base is huge, even setting up the environment to build it from the source code takes considerable amount of time. This is typical for a big project, but it is hard to take that and strip it down.

Part of the problem is all the dependencies that start to come in as you implement more features. Want Eagle export - include an XML parser, want board outline import from CADs - include a DXF reader. You can implement some of that stuff in a lean targeted way, but at some point things will start getting out of hand.

So the key to a small EDA is to keep features low, which may not be something everyone wants. I personally prefer small code base, which is easy to maintain and modify, even if some features are lacking.

[SiliconWizard]

why not create a stripped down version of kicad itself? compatible with kicad symbols & footprints.. with ui modifications you desire..

Lukas' Horizon actually uses KiCad's router AFAIK (which is only a small chunk of KiCad's source code).

Modifying KiCad's UI is awfully difficult, just look at how KiCad developers have been fighting with this for years. It's not just because they don't want to.

Developing a CAD tool is incredibly difficult, often underestimated and the probability of having approximately one opinion by user is very high. Three of the reasons why many such projects have started and died.

I'm impressed by Lukas' work here, even though I don't quite agree with all of his choices (but see right above...)

Designing such a CAD sofware so that the UI is completely separate (and thus easily modified) from the core functionalities sounds like a great idea. Unfortunately, CAD tools' functionalities are often so intricate with their UIs that it's very, very difficult to design them this way. Many developers starting such projects tend to concentrate on the UI first (mostly because this is often what they have the most definite ideas on, and also because it's a more immediate reward), which is a mistake IMO. So for those still willing to try, my advice would be to work on the architecture and modularity and get that right before writing a single line of UI code.

[ataradov]

So for those still willing to try, my advice would be to work on the architecture and modularity and get that right before writing a single line of UI code.

I was trying to think along those lines, but it is hard. Once you've got basics defined, you need to see things work to proceed with further design decisions. And the GUI is a natural way to provide inputs to such back end. So even if it is not a final GUI, you are forced to do something. And in that case you might as well stay close to the final ideas.

I doubt it is possible to define CAD backend in abstraction of the UI.

[nctnico]

Probably you have to write 3 CAD programs from scratch. The first 2 will be rubbish and the third one will be useful because by then you understand what workflow works.

[langwadt]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

yes, something like Orcad CIS

[janoc]

I doubt it is possible to define CAD backend in abstraction of the UI.

It certainly is - e.g. OpenCASCADE (originally by Matra, then open sourced CAD kernel used by e.g. FreeCAD among others) or OpenSCAD. CAD works with geometric entities - lines, points, surfaces, solids, etc. The way you enter those doesn't matter, the backend/kernel really doesn't care whether they were loaded from a file or someone has entered them using a mouse.

However, I fully agree with what SiliconWizard said above. Writing a CAD program (any type of CAD) is incredibly difficult. UI is probably the easiest part, in fact. The "fun" starts once you get into the geometry, whether it is length-matching traces on a PCB or solving complicated constraint systems in a contemporary mechanical CAD.

Heck, even something as "pedestrian" as rendering good looking fonts is heck of a job - you need to deal with Unicode, with vector fonts (TrueType is not very useful for exporting Gerbers, for ex. - that's why the CAD tools use those funny looking fonts), various language and locale specific things, special symbols ... It becomes a nightmare pretty quick and you can't just offload it to a library (such as Harfbuzz) easily.

Focusing on the UI is also a sure fire way to doom the project early - you will have as many "UI designers" as you will have project contributors and unless there is one person who can put their foot down and have a final say how things are going to work, the result will be an inconsistent mess. And if there is such person, expect flamewars, fights, temper tantrums and people leaving the project in anger. The realities of any open source project beyond a certain size (> ~2-3 contributors). Just look at projects such as Gnome where a small clique decided to redesign the UI in a certain way or to push a certain design philosophy years ago. The fights and personal animosities are going on to this day, even though the software in question is long dead. Or the infamous systemd that works like a red rag for a bull for many people.

Are you prepared to deal with that?

Also unless you are a superhuman with infinite time and money (so no need for a "real" job, etc.), don't expect that you will be able to pull a project like this off alone. You will only burn yourself out in a few months while the competition with larger teams (whether OSS and certainly the commercial ones too) will be running circles around you.

I would strongly suggest to anyone who wants to work on something like this to not fragment the manpower available even more and to join one of the existing projects instead. It is better to bite the bullet and accept that not everything can be as you would like to have it but have at least one working and (semi-)usable tool than to have 20 dead one-man projects all over Github where the authors abandoned them as soon as they discovered that CAD is much more than making sure the menus and toolbars are arranged in their preferred way. Or that in order to be usable, they would have to write a lot of rather "unsexy" code that they aren't interested in - e.g. library management or data import/export.

[BrianHG]

Seriously, just take KiCad's source code engine and just re-do the entire GUI.  I'm sure if the rendering does something you don't visually like, you can also manipulate that easily as well.  For the cad graphics engine, they already done most of the work.  If you want actual Protel compatibility, just save your Protel PCBs and schematics in ASCII mode and decode that format.  I've done this in the past and made a Protel library component generator (it took a .pdf data sheet's pinout screen capture and made the IC's pins with names and IO directions automatically (this save so much time as multiple 240/480/and larger ICs became rampant in my designs, cut out errors too)) as the ASCII format for components took only around a day to figure out.  Same for PCB and Schematics.  They have so few objects in there with so few setting, always saved in order, you can even make your own Protel translator from an ASCII save to an alternate format if you like.

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)


I also know the frustration of trying to learn how to even function or flow in a new cad environment.  Trying to understand an learn how the programmers intended their tool to be used instead of how I am used to working in my old tools.  It can drive me up a wall as I yell WHY the hell did they do it like that???  And not understanding that the cad did the same function I wanted in a completely different way as it takes me 10x longer to force that tool to operate the Protel way, only to discover over a year later all the bloody time, all I had to do was press 'CTL-Left Click' instead of 'Shift-Space'....

[langwadt]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

[nctnico]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

I don't really see the point either. Most ground and power planes will need cut-outs anyway (at the power entry plug for example).

[mrpackethead]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

Because you can see through them.

[BrianHG]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

Because you can see through them.

Pic#1 = Poly Fill.
Pic#2 & Pic#3 = True Ground Plane.
See first 2 images in post...
https://www.eevblog.com/forum/eda/you-get-more-copper-between-padsvias-using-a-true-power-plane-instead-polyfill/msg1524124/#msg1524124

[nctnico]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

Because you can see through them.

You can use semi-transparent layers and/or disable the layers you are not interested in.

@BrianHG: that old story about a bug / user error again 

[klmbk]

I've pondered this too, just for fun. But I'm mostly OK with the interface and most of the concepts in KiCad 5, at least for my quite basic stuff. But I've only ever used KiCad and OrCAD.
What would make sense to me is to have KiCad's workflow for layout organized more around a design rules engine at its core, like, as I understand in Altium design rules are pretty central, also in OrCAD.

How I'd go about it is to take a release version of KiCad (probably because I mostly only know KiCad) and take the geometric, routing, export, and maybe even drawing engine of it and wrap it with a logic and database system. SWI Prolog is probably a good example for such system. A design rule engine built upon that, in conjunction with a new GUI, would drive the KiCad core.  I guess I'd also prefer a single integrated application, like Altium, no separate apps for schematic and layout, so the GUI could be similar to Altium's.  I'd rather not code the GUI in C++. In principle something like Common Lisp would be cool where you can live code, i.e. redefine code of your running program while it's running, to be able to iterate faster.

[Doctorandus_P]

Opening this thread with stating that you have a stupid idea has dicouraged me from reading past the first sentence of this thread.

[ataradov]

Yet you felt compelled to post something without reading. Keep us informed.

[Warhawk]

I understand him. There is not anything better than discouraging the reader from reading with the very first sentence.
..
..
..
Anyway, I wish this could happen but it won't. It is just another "let's make a new EDA" thread which will fail right after the first key programmer starts the family or gets a serious job. We have had some examples before (remember infamous AutoTrax or the DipTrace team incapable of fixing specific bugs which have been there for years?).

People, who have clear idea how the EDA software should look like, know typically NILL about the SW development. And there are hobby (and skilled) programmers who want to have fun and don't know much about the PCB design on the other side.

I admit, that there are few exceptions. E.g. Horizon looks incredibly cool for the one-man show. However, I don't predict it any future. If I am not mistaken, the guy has just graduated...

If you want to have a reasonable EDA package, just invest your time (if you know SW programming) or money (if you're just an EE) in current projects. This LibrePCB looks quite nice.

You can motivate people only with fear, hunger or money. Chose wisely.
 

[free_electron]

The 1 thing I don't like about KiCad, though I am not an expert, is the lack of negative power planes.  (The feature may be hidden in layer setup and I just missed it...)

apart from being easier to do with tape which hasn't mattered in decades, why do you want negative planes?

because you can see through them ... ( when you have multiple layers turned on.)

[Doctorandus_P]

Somehow this thread has re-captured my attention, and today I probably was in a different mood and did read through at least half of it.

I am a KiCad user and I like KiCad very much.
Especially the interactive push and shove router has made it almost trivial to route some things that I previously thought to be almos impossible. It changes the way you route PCB traces significantly.

Creating a new schematics entry / PCB package is a significant undertaking and I do not understand what will be the advantage of this.
A few years ago, when I started with KiCad I got through the "getting started with KiCad" tutorial in a single afternoon, and I had a routed PCB at supper.

If you don't want ERC checking you can simply ignore the ERC check button. You also do not have to compile KiCad if your're just a user. and who cares about a few GB of HDD storage nowaday's? These are all such non issues.

Because of significant improvements of KiCad almost yearly some of the tutorials get misaligned after some time, but I would rather re-learn the changes than stick with the old version.

About a year ago I stumbled into another PCB package which was presented as some new simple but yet advanced thing. It looked very similar to KiCad. It probably was that librepcb thing mentioned in #4. To me it looks just like a tremendous waste of effort to duplicate all this effort to re-invent the same wheel. Writing such a program is not a trivial task:

I doubt that 10k LoC is realistic. I would estimate 5-10x that amount at the minimum.

If the effort to re-invent that same old wheel was invested instead in improving the existing ones then KiCad already would have been easier to get started with, and it is not that difficult to get started with anyway. It just takes some time to get used to.

If you want something "simpler" than KiCad, then stick to somthing like fritzing, but to me it looks like it's so limiting and incomplete that it is not even worth considering.

I have some very good ideas on hoe to drastically improve manual routing process. But that's a long term project going on the background of everything else.

I very much doubt that you can come up with something that works better than the interactive router already built into KiCad.
https://www.youtube.com/results?search_query=kicad+push+and+shove+routing
If you watch some of the video's from above you get some idea of it's capabilities, but to really appreciate it you have to try it for yourself on a non-trivial design.
This router alone is such an enourmous time saving killer feature for me that I'm very happy to look through all the small ideosyncracies that KiCad still has and are mostly legacy from long ago and getting less with each revision.

The (few) negative things I read about KiCad seem to be mostly from people who have not taken the effort to work with KiCad for more than a week, or are comparing it with some other PCB program and are complaining just because it does not work in the same way that that other PCB program works.

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

What makes you say such a thing?
Just edit the properties of any symbol you like and click on the big fat plus. You can add as many Fields with custom information to any of the schematic symbols as you like. All of KiCad's file formats are nicely documented and easily parsable text files. With KiCad 5 and it's new and improved library management it has been improved significantly compared to KiCad V4. Symbol and library management was one of the buggy parts of KiCad but (at least most) of these bugs have already been ironed out now and it works pretty well. You can also easily create your own custom libraries and use the existing symbols as templates and add your own metadata.

There are also multiple tools available to create BOM's from KiCad. Digikey has jumped on the KiCad wagon both financially and with effort in creating libraries and tutorials:
https://www.digikey.com/en/resources/design-tools/kicad
If you don't like Digikey, one of the BOM extensions has very elaborate spreadsheets and pulls information from multiple vendors and generates overviews.
There are a lot of extensions and projects around KiCad to expand it's capabilities in different ways. You want your own metadata custom tool? Take one of the BOM generators and modify them to your liking, or use a bit of Python to extract and organize data in the way you want it.

The list below has 15+ free / or OpenSource projects and 50 or so other projects.
https://www.eevblog.com/forum/eda/pcbeda-software-list/
Is yet another wheel on this hub really going to improve something?

The controversy in this thread has also already started. Some want something "small and managable" others want to add "advanced features". How small a niche do you think you can fill with yet another PCB program?

[nctnico]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

What makes you say such a thing?
Just edit the properties of any symbol you like and click on the big fat plus. You can add as many Fields with custom information to any of the schematic symbols as you like. All of KiCad's file formats are nicely documented and easily parsable text files. With KiCad 5 and it's new and improved library management it has been improved significantly compared to KiCad V4. Symbol and library management was one of the buggy parts of KiCad but (at least most) of these bugs have already been ironed out now and it works pretty well. You can also easily create your own custom libraries and use the existing symbols as templates and add your own metadata.

Look at how Orcad CIS works. In short: you don't add properties to symbols in a schematic. That is wrong because you'll need to add the properties to each individual component. The same goes for libraries. Creating a different library part for each value just clutters your library. Say you want to change the footprint for a specific set of components? Or re-use a symbol for different components? Or the order number needs to be changed? It is an error prone nightmare! In short: you don't want to have the component information in the schematic. It sucks.

The answer is to have an external database which links a symbol to a footprint and ordering information. For example:  I recently switched from Orcad Layout to Orcad PCB Designer (aka Alllegro). Getting the parts database sorted was a matter of adding a column with the Allegro footprints and doing some text search & replace to make the new footprint names. I could have used database queries if necessary. The key is that each component in the database has a unique number. This number is what the schematic is referring to in order to get information about the part. If I need to change the order number (this happens often due to parts migrating to newer versions) I update this in the database and when I create a bill-of-materials Orcad will read the new order number from the database and put that into the bill-of-materials. And this goes for everything including the symbol and footprint. I don't have to go through the schematic manually for any of these changes.

I looked at the Digikey lib files and they contain exactly what I feared: part information combined with a symbol. I don't want to work with a CAD package from the 80's.

If someone wants to take KiCAD a step up: implement a system like Orcad CIS in KiCAD. Every professional PCB package uses a seperate component database. I actually contemplated using the money I spend on buying Orcad PCB designer to hire someone to modify KiCAD but I found the risk that the modifications would be rejected too big. Unfortunately the necessity of having a component database isn't obvious to everyone.

[Doctorandus_P]

@nctnico #12.
I do not realy understand your problem. I also do not have "Orcad Cis".
If you want to maintain an external database with additonal info, then there is noboby to stop you, and the BOM tools in KiCad help with data extraction.
Having to keep track of things both in your schematic and in your "external database" only seems to add to the amount of work and possibility for errors to creep in.

In the last few years most of the focus in improving KiCad has been with PcbNew, and that's working pretty good now. At the moment the focus is switching more to improving Eeschema, which has fallen a bit behind.

With: Eeschema / Tools / Edit symbol fields
you have an overview in spreadsheet format of all components and their attributes, and you can sort by columns and easily copy data (such as  value, or footprint tags) between components.
If you click on the reference field (first column) in the spreadsheet, the corresponding symbol in EEschema is automatically selected. Does this look usable to you?
This spreadsheet is cleary not finished, and still has a very limited functionality at the moment. I expect there are plans for expanding it into a replacement for CvPcb, a full BOM tool and maybe even more.
If you have components which are the same (Value & Footprint) they are grouped together.

I'm now experiming a bit with it and have just changed a whole lot of 5mm leds into 3mm leds by changing a single "5" to "3" in the symbol fields spreadsheet.

Waauw:
I just discovered that you can select how the groups are formed in this spreadsheet.
For example you make a group of all the resistors which are currently in 0805 format (which includes for example current resistor shunts) and then change the footprints of all those resistors to 0603 by editing a single line in the footprints column.

Groups can be made by any column or combination of columns.
You can make a group of all 4k7 resistors and change their values to 6k8. (or change footprint, etc).
This works pretty darn good in my book.

[nctnico]

@nctnico #12.
I do not realy understand your problem. I also do not have "Orcad Cis".
If you want to maintain an external database with additonal info, then there is noboby to stop you, and the BOM tools in KiCad help with data extraction.
Having to keep track of things both in your schematic and in your "external database" only seems to add to the amount of work and possibility for errors to creep in.

No, it is the other way around: you don't keep track of anything in the schematic when you use a component database! The schematic only has 'item number xyz' from the database. All the information resides in the database. Change something in the database and all your past and future schematics are automatically updated with the latest information when you create a new BOM. I have been using Orcad CIS for about 20 years already. Go on youtube and look for a video which explains component management in Altium or Orcad.

Groups can be made by any column or combination of columns.
You can make a group of all 4k7 resistors and change their values to 6k8. (or change footprint, etc).
This works pretty darn good in my book.

Orcad Capture can do this for over 20 years so it really is nothing new. But again, this is not how you want to manage components in a professional environment. Logistics is a big part of getting electronics produced and this starts with a component database.

[Lukas]

@nctnico #12.
I do not realy understand your problem. I also do not have "Orcad Cis".
If you want to maintain an external database with additonal info, then there is noboby to stop you, and the BOM tools in KiCad help with data extraction.
Having to keep track of things both in your schematic and in your "external database" only seems to add to the amount of work and possibility for errors to creep in.

No, it is the other way around: you don't keep track of anything in the schematic when you use a component database! The schematic only has 'item number xyz' from the database. All the information resides in the database. Change something in the database and all your past and future schematics are automatically updated with the latest information when you create a new BOM. I have been using Orcad CIS for about 20 years already. Go on youtube and look for a video which explains component management in Altium or Orcad.

I looked at the Digikey lib files and they contain exactly what I feared: part information combined with a symbol. I don't want to work with a CAD package from the 80's.

My words. Exactly this is one of the reasons I ditched Kicad and went on developing my own EDA package. In horzion, the logical definition of a package (pin names and directions), symbol, package and actual orderable part are separate items that reference each other as needed. See https://github.com/carrotIndustries/horizon/blob/master/doc/pool.pdf

People have complained in the past, that they can't change the value of a capactior in the schematic just by typing in a new value, but that's by design. You can't go to digikey and order a 8.2p, 0603 capacitor, but they'll happily sell you a C0603C829D5GACTU by Kemet.

Horizon recently gained parametric search (see screenshot) below to simplify picking passives.

[ataradov]

This thread is a clear indication why "one EDA for all" is not possible.

I personally don't care about the databases. And my capacitors come from whatever random source I can find at the moment of ordering. Maybe if I was doing some space-level electronics with the absolute need for tractability, I would need that. But I don't, so tools like just get in my way.

I understand that others have different workflows, but those database based tools will not work with mine.

[langwadt]

This thread is a clear indication why "one EDA for all" is not possible.

I personally don't care about the databases. And my capacitors come from whatever random source I can find at the moment of ordering. Maybe if I was doing some space-level electronics with the absolute need for tractability, I would need that. But I don't, so tools like just get in my way.

I understand that others have different workflows, but those database based tools will not work with mine.

one of the powerful things with the database is that you can pick from stock, no need to add a 10k pullup resistor if the database shows you that you don't have 10k resistors but you have 10000 9k resistors etc.

[ataradov]

one of the powerful things with the database is that you can pick from stock, no need to add a 10k pullup resistor if the database shows you that you don't have 10k resistors but you have 10000 9k resistors etc.

Sure. But this implies that there is accurate tracking of the stock. And realistically I personally have a number of values that I always stock (1K, 10K, 100K, plus a few others). And other values will have to be ordered anyway if used in a quantity of more than 10.

For a huge production it is an advantage, but at the same time, the price of Altuim is not that expensive for a large production.

So as usual, the discussion of a simple basic tool turned into a wish list for a fully capable, but somehow free EDA.

[Doctorandus_P]

So I watched some Orcad Cis vid's.

Having an extensive database with preferred parts and combined with inventory management in an production environment is an advantage, I can see that. Ideally you design a PCB once, and then you buy parts for years to come and stuff changes in the meantime. Sometimes you find better parts, somtimes you find cheaper alternatives.

Philips has it's "12NC" system, where each part, whether electronic or mechanical (screws, housings and maybe even packaging material) has a 12 digit part number.
HP and other companies also have their separate identification numbers.

As I just mentioned, such an parts (and ordering?) management system / database ideally has "everything" in it to make a product, and ideally it should also work in reverse direction. If you have a part in your hands, the database should know in which products that part is used, and how many of them.

I do not understand why you would want such a system in a PCB program.
KiCad library magement has long been ... sub optimal  In KiCad 5 a very small, almost trivial change was made to the library system: The name of the library a schematic symbol comes from has been added in the schematic, and now ensures that each schematic symbol has an unique identifier.

Extracting components from the pretty extensive parts databases in KiCad (or any other decent PCB program) and putting them in a library of "preferred parts" together with a unique identification number for each part is trivial.

[Doctorandus_P]

People have complained in the past, that they can't change the value of a capactior in the schematic just by typing in a new value, but that's by design. You can't go to digikey and order a 8.2p, 0603 capacitor, but they'll happily sell you a C0603C829D5GACTU by Kemet.

And rightly so.
You are making a grave error by combining 2 separate things.
The design phase of an electronic product is a creative process, and that creative process needs all your brain capacity and attention to design a product that works.
During this creative process components change often, and even radically. Half the schematic can get erased because it does not work, or works to good, but is too complex.

In extreme cases your system leads to having to search through a database with weird and unintuitive part numbers just to change the value of a resistor in a spice simulation. This is a big distraction and can completely kill the productivity of the designer.
Or even not being able to run a spice simulation with some resistor value because that value is not in the "prefered parts" database. This is horrible.
Stuff like that will lead to engineers using DaveCad to test their ideas and draw schematics.

Making a product ripe for production should only happen after most of the creative process has been done. It is a separate process and an engingeer should not be bothered with it for every nitty gritty change during the design process.

[nctnico]

People have complained in the past, that they can't change the value of a capactior in the schematic just by typing in a new value, but that's by design. You can't go to digikey and order a 8.2p, 0603 capacitor, but they'll happily sell you a C0603C829D5GACTU by Kemet.

And rightly so.
You are making a grave error by combining 2 separate things.
The design phase of an electronic product is a creative process, and that creative process needs all your brain capacity and attention to design a product that works.
During this creative process components change often, and even radically. Half the schematic can get erased because it does not work, or works to good, but is too complex.

A database doesn't get in the way of the creative process. You select parts just like you would from a database-less parts library. Also the creative process should happen before drawing the final schematic (on paper or simulation). I can't imagine you end up with a nice & readable schematic if it has been turned upside down ten times (exaggerated a little bit).

@Ataradov: you don't have to use a database but your way of working means having to look for a specific part on a supplier's website over & over again. When using a database the BOM is a shopping list you can copy into the supplier's website. Many have Excel or CSV imports for this specific purpose. For me this is a huge time saver.

Anyway, IMHO it would be nice if someone would spend time on KiCAD to add a component database to it instead of creating a new CAD package. The biggest hurdle will probably be to make the core team see why this is necessary for KiCAD to be considered an alternative for Orcad or Altium.

[Bassman59]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

For the nth time.

Kicad has supported what is called "atomic parts" for a few years now.

This is where the symbol in a library has its footprint field already populated and it has a populated part number field. Some of the Kicad official libraries already have this. All of my libraries are like this, too. (I use "house" part numbers, which I use with a Python script and a master parts list to generate a BOM from which I can order parts. Others have chosen to put the orderable part numbers into the symbol itself. Either way works.)

Export a BOM from the schematic using one of the standard scripts and voila, it's got everything, including part numbers.

Export a netlist from the schematic to the layout, and voila, all of the footprints are there.

If you're going to make comments about something, at least try to see whether your complaint has already been addressed.

[Bassman59]

People have complained in the past, that they can't change the value of a capactior in the schematic just by typing in a new value, but that's by design. You can't go to digikey and order a 8.2p, 0603 capacitor, but they'll happily sell you a C0603C829D5GACTU by Kemet.

My guess is that DigiKey, as a catalog distributor, does not want to start substituting parts for customer orders. Imagine the finger-pointing that can occur.

Whether a part is a substitute or not is something that must be managed by the customer, as every customer's requirements are different.

And that's why even small businesses will use a system to manage parts, including what substitutions are acceptable. And that's also why for even small businesses the buyer is a full-time job.

For the hobbyist, none of this matters.

[nctnico]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

For the nth time.

Kicad has supported what is called "atomic parts" for a few years now.

This is where the symbol in a library has its footprint field already populated and it has a populated part number field. Some of the Kicad official libraries already have this.

If you're going to make comments about something, at least try to see whether your complaint has already been addressed.

And it hasn't! An atomic part is exactly what you don't want because then you can no longer share the symbol between multiple components. Please understand how professional packages deal with parts. They all use a database for a very good reason!

Look at the KiCAD fora: everyone is using seperate tools for what the professional packages can do in one go while using a components database.

[Bassman59]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

For the nth time.

Kicad has supported what is called "atomic parts" for a few years now.

This is where the symbol in a library has its footprint field already populated and it has a populated part number field. Some of the Kicad official libraries already have this.

If you're going to make comments about something, at least try to see whether your complaint has already been addressed.

And it hasn't! An atomic part is exactly what you don't want because then you can no longer share the symbol between multiple components. Please understand how professional packages deal with parts. They all use a database for a very good reason!

Look at the KiCAD fora: everyone is using seperate tools for what the professional packages can do in one go while using a components database.

Uhh, we use an Altium integrated library here at the day job, and I suppose that meets most definitions of "professional packages." The whole idea of "sharing the symbol" is interesting for things like discrete transistors and op-amps, but really, so what? How many op-amps do you have in your library, really? And how much space is taken up in your library by your op-amps?

[Bud]

Export a BOM from the schematic using one of the standard scripts and voila, it's got everything, including part numbers.

That is fine if ordering parts tomorrow after tinishing the schematic. Try this a year from now and some/many of the parts become obsolete and/or not stocked. What do you do, go and change the scematic each time? Really?

[free_electron]

BTW what it missing from your list is to have a component database which links a symbol, footprint, value and order number together into a component. This allows to create bills of materials automatically which saves a lot of error prone manual work. AFAIK KiCad still doesn't have that but it is what turns a hobby tool into something which is suitable for professional use. I can do without differentail pair routing but I can't do with a component database.

For the nth time.

Kicad has supported what is called "atomic parts" for a few years now.

This is where the symbol in a library has its footprint field already populated and it has a populated part number field. Some of the Kicad official libraries already have this.

If you're going to make comments about something, at least try to see whether your complaint has already been addressed.

And it hasn't! An atomic part is exactly what you don't want because then you can no longer share the symbol between multiple components. Please understand how professional packages deal with parts. They all use a database for a very good reason!

Look at the KiCAD fora: everyone is using seperate tools for what the professional packages can do in one go while using a components database.

Uhh, we use an Altium integrated library here at the day job, and I suppose that meets most definitions of "professional packages." The whole idea of "sharing the symbol" is interesting for things like discrete transistors and op-amps, but really, so what? How many op-amps do you have in your library, really? And how much space is taken up in your library by your op-amps?

that may be true for symbols. what about footprints. What if you restyle or fix a footprint that is in use on many compoentns.
let's say you are going to alter your 0603 footprtin from nominal to least. ...

that is whay the professional packages use a database.
footprints, symbols and parts. parts link to footprints and symbols and other data.
Cadence goes a step further. they have approved pad stacks. change a pad stack and all associated footprints update ! which causes all associated components to update and triggers board reviews on all affected projects ... ( something the altium vault can do as well.

proper design datamanagement is the most critical aspect of product design. screw up your library and even the best designed schematic and board will be useless if the parts don;t fit ...

[Doctorandus_P]

And it hasn't! An atomic part is exactly what you don't want because then you can no longer share the symbol between multiple components. Please understand how professional packages deal with parts. They all use a database for a very good reason!

Look at the KiCAD fora: everyone is using seperate tools for what the professional packages can do in one go while using a components database.

that may be true for symbols. what about footprints. What if you restyle or fix a footprint that is in use on many compoentns.
let's say you are going to alter your 0603 footprtin from nominal to least. ...

It seems that everybody here is hanging on to their own ideas, and I am no exception to that.
For a part there seem to be misunderstandings about this "database" concept.
Having "atomic parts" is not a bad Idea, and is separate from the "database" concept.
I can only look at this through my KiCad glasses, because It is the only recent PCB design package I am familiar with.
I am an un-trusting and suspicious person by nature. For KiCad this translates to, using, but not trusting components footprints etc. from the library databases which come with KiCad. Every part of the libraryies gets scrutinized and modified to my personal liking and added to my own database / library of approved parts, and those are the only ones I trust.

A KiCad library is a database. There is no distinction between those 2.
Having "atomic" parts in KiCad does not mean they are unchangable and static, just that they are uniquely identifiable. If you have a custom database/library of approved parts, and your KiCad schematic or PCB has a reference to those, then changing the library/database will automatically update footprints when new gerbers are generated. If you don't want that, then make local copies in your project of certain "special" parts.
But what exactly is an "atomic part"? Over the years I've been ridiculed by asking such basic questions, but time upon time, if people dare to elaborate, it often leads to discovery of different people making different assumptions that are not compatible, and as long as these misconceptions live there is no hope of reaching consensus.

There also always has to be a limit somewhere. You can't put the whole world into a single database. It won't fit. From what I know Sap tried this, but it's more expensive to maintain than what KiCad cost me  So, where do you want to lay the line?
Do you want screws, washers and wiring in your database?
Do you want cabinets and packaging materials in your database?
Do you want ordernumbers and timestamps in your database? Those could be an important source of information, for example for product recalls when a batch of faulty components slipped through, which start failing after 3 years in the field.

Those are all valid things to have in your database, but are not part of a PCB design program.
When viewed through my KiCad glasses: All it's file formats are open , well documented, human readable and have a simple structure. And they have tools and utilities to write modify them. Generating (and maintaining) KiCad libraries from such an allmighty database would be a trivial extension of such a database.

[nctnico]

What you can do with Orcad CIS -for example- is share a table from a database which is part of your administration / logistics system. By adding columns for a symbol, footprint and value you can pick parts directly from the logistics system. If you create a BOM then the people in the procurement department can order the right parts for production right away. But this is a rather sophisticated scenario. Personally I use the database to detach component information from a symbol. This makes a component is universally re-usable and not stuck to a particular schematic. There are some parallels to using a standard library when writing software. Having a seperate 'universal' library for each project is going to suck at some point because in the end you never know which project has the latest version and changes/additions/bug fixes aren't forwarded to other projects which need the same fixes (or could use the enchancements).

[Bassman59]

Export a BOM from the schematic using one of the standard scripts and voila, it's got everything, including part numbers.

That is fine if ordering parts tomorrow after tinishing the schematic. Try this a year from now and some/many of the parts become obsolete and/or not stocked. What do you do, go and change the scematic each time? Really?

No -- that's one of the reasons to use a "house" part number. The schematic remains the same, the BOM exported from it remains the same. You just update your master parts list with the replacement part for the one which went obsolete and re-run the script that creates the orderable BOM.

Or if you are using a more-comprehensive parts-management system, multiple real parts can be attached to the house part number, so purchasing can buy whatever is cheapest, or whatever is immediately available, or the like.

Of course it's always on engineering to approve whatever parts the buyer might wish to substitute.

[Bassman59]

that may be true for symbols. what about footprints. What if you restyle or fix a footprint that is in use on many compoentns.
let's say you are going to alter your 0603 footprtin from nominal to least. ...

that is whay the professional packages use a database.
footprints, symbols and parts. parts link to footprints and symbols and other data.
Cadence goes a step further. they have approved pad stacks. change a pad stack and all associated footprints update ! which causes all associated components to update and triggers board reviews on all affected projects ... ( something the altium vault can do as well.

proper design datamanagement is the most critical aspect of product design. screw up your library and even the best designed schematic and board will be useless if the parts don;t fit ...

Yes, everyone who does this for a living is well aware that a fucked-up library results in fucked-up boards and money wasted. Not only in the physical design with footprints and such, but also in what purchasing orders and what gets soldered to the boards.

But in your reply, you mentioned two expensive CAD packages, Altium and Cadence, both published by large companies with a lot of programmers on staff, and you're comparing their features to an open-source package with a dozen core developers.

I have no doubt that the Kicad developers would not say no to anyone offering to spec out and implement a full-up library system underpinned by a proper relational database. Nobody is arguing that the database system is a bad idea. I agree that it's the way to go.

But ... has anyone stepped up to offer to do all of that work? No. The silence is deafening.

It's the old saying, everyone talks about the weather but nobody does anything about it.

[awallin]

FWIW FOSDEM talks ongoing now:
https://fosdem.org/2019/schedule/track/cad_and_open_hardware/
IIRC it takes a while (weeks?!) for the live video to be available online for later viewing, so try to catch it now live!?
https://fosdem.org/2019/schedule/streaming/

[nctnico]

Export a BOM from the schematic using one of the standard scripts and voila, it's got everything, including part numbers.

That is fine if ordering parts tomorrow after tinishing the schematic. Try this a year from now and some/many of the parts become obsolete and/or not stocked. What do you do, go and change the scematic each time? Really?

No -- that's one of the reasons to use a "house" part number. The schematic remains the same, the BOM exported from it remains the same. You just update your master parts list with the replacement part for the one which went obsolete and re-run the script that creates the orderable BOM.

With a database that master parts list IS the BOM and there is no need for any extra error prone (manual) processes.

Mistakes can become very expensive. In one of my past projects someone designed a complex board with an ARM SoC on it. IIRC he used Geda and PCB to create the board. When we tested the board we couldn't get the standby current low enough. After spending many hours the hardware designer decided to check (measure) each part on the board against the values in the schematic. It turned out one of the pull-up resistors was 100 Ohm instead of 100k Ohm. He made an error while creating the BOM manually. Needless to say this was a costly mistake. Both in hours and customer confidence in our design.

I have no doubt that the Kicad developers would not say no to anyone offering to spec out and implement a full-up library system underpinned by a proper relational database. Nobody is arguing that the database system is a bad idea. I agree that it's the way to go.

But ... has anyone stepped up to offer to do all of that work? No. The silence is deafening.

Well I did consider paying someone to add a database based component management system to KiCAD. However I very much feared that the creators of KiCAD wouldn't even understand the benefits of having a database (or just ignore it) and I would be left with a fork of KiCAD which would get outdated quickly. Given the lack of understanding on why having a component database is the way forward shown in this thread it seems I made the right choice by bringing my money to Cadence. Also my experience trying to contribute to open source projects is that it is very hard to have your changes accepted by the creators. The only exception so far has been OpenOCD.

[Bassman59]

I have no doubt that the Kicad developers would not say no to anyone offering to spec out and implement a full-up library system underpinned by a proper relational database. Nobody is arguing that the database system is a bad idea. I agree that it's the way to go.

But ... has anyone stepped up to offer to do all of that work? No. The silence is deafening.

Well I did consider paying someone to add a database based component management system to KiCAD. However I very much feared that the creators of KiCAD wouldn't even understand the benefits of having a database (or just ignore it) and I would be left with a fork of KiCAD which would get outdated quickly. Given the lack of understanding on why having a component database is the way forward shown in this thread it seems I made the right choice by bringing my money to Cadence. Also my experience trying to contribute to open source projects is that it is very hard to have your changes accepted by the creators. The only exception so far has been OpenOCD.

Have you approached the Kicad developers in any manner? Are you subscribed to the developers' email listserv? Do you know the state of Kicad development? Did you write a proposal for implementing this feature? Did you identify any developers with the skills necessary to implement them?

I think the answer to all of those questions is "No."

And since it's a lot easier to complain about something on an internet forum than it is to actually get involved, you took the typical way out.

[nctnico]

I have no doubt that the Kicad developers would not say no to anyone offering to spec out and implement a full-up library system underpinned by a proper relational database. Nobody is arguing that the database system is a bad idea. I agree that it's the way to go.

But ... has anyone stepped up to offer to do all of that work? No. The silence is deafening.

Well I did consider paying someone to add a database based component management system to KiCAD. However I very much feared that the creators of KiCAD wouldn't even understand the benefits of having a database (or just ignore it) and I would be left with a fork of KiCAD which would get outdated quickly. Given the lack of understanding on why having a component database is the way forward shown in this thread it seems I made the right choice by bringing my money to Cadence. Also my experience trying to contribute to open source projects is that it is very hard to have your changes accepted by the creators. The only exception so far has been OpenOCD.

Have you approached the Kicad developers in any manner? Are you subscribed to the developers' email listserv? Do you know the state of Kicad development? Did you write a proposal for implementing this feature? Did you identify any developers with the skills necessary to implement them?

I think the answer to all of those questions is "No."

I actually did some investigations in how feasible it would be including finding developers and chances on getting the work into the mainstream. This turned out negative. Remember I'd be paying this out of my own pocket with a limited budget so I had to minimise the risk to end up with a half baked solution. One risk for example: if none of the KiCAD developers would deem a component database a useful feature (or important enough) it could end up being abandoned. Especially with the changes to the schematics part of KiCAD in mind which have been announced a long time ago.

But no, I have not contacted any of the KiCAD developers. And that is on purpose; when you announce you want to contribute to an opensource project the developers usually say 'great, any help is welcome' but when push comes to shove you have to jump through all kinds of hoops to get changes committed / merged. It is (almost) never simple like writing an addition and supplying patches. I've based my decission on experience of other people trying to get changes made to KiCAD (see this forum message for example: https://www.eevblog.com/forum/kicad/one-annoyance-of-kicad-solved-f4-drag/msg933579/#msg933579 ). Some even ended up forking KiCAD which I really didn't want.

[free_electron]

that may be true for symbols. what about footprints. What if you restyle or fix a footprint that is in use on many compoentns.
let's say you are going to alter your 0603 footprtin from nominal to least. ...

that is whay the professional packages use a database.
footprints, symbols and parts. parts link to footprints and symbols and other data.
Cadence goes a step further. they have approved pad stacks. change a pad stack and all associated footprints update ! which causes all associated components to update and triggers board reviews on all affected projects ... ( something the altium vault can do as well.

proper design datamanagement is the most critical aspect of product design. screw up your library and even the best designed schematic and board will be useless if the parts don;t fit ...

Yes, everyone who does this for a living is well aware that a fucked-up library results in fucked-up boards and money wasted. Not only in the physical design with footprints and such, but also in what purchasing orders and what gets soldered to the boards.

But in your reply, you mentioned two expensive CAD packages, Altium and Cadence, both published by large companies with a lot of programmers on staff, and you're comparing their features to an open-source package with a dozen core developers.

I have no doubt that the Kicad developers would not say no to anyone offering to spec out and implement a full-up library system underpinned by a proper relational database. Nobody is arguing that the database system is a bad idea. I agree that it's the way to go.

But ... has anyone stepped up to offer to do all of that work? No. The silence is deafening.

It's the old saying, everyone talks about the weather but nobody does anything about it.

as is so common in the open source world : they are either
- all focussed on the eye candy. (example : 32 different desktop managers)
- stuck in their holy wars between VI and Emacs
- glued to their command line

as opposed to first understanding the problem.

The foundation of a cad system is data management. And that begins by a library system. Not by creating an glitzy user interface to draw lines form point a to point b.

I can spec out a system , but i am not a programmer. Don't look at me to write code. And the kicad programmers are clearly not PCB designers.
And THAT is the problem with all these open source things. The people who have to write the code have never gone through the pain of doing a 'real' pcb layout ( i'm not talking a double sided arduino style board where nothing matters ... but a real board taken fomr concept all the way to production hand-off including all documentation, life cycle , feedback management cradle to grave ...

The spec for a working system is not that hard
- have a way to edit and store symbols
- have a way to edit and store footprint
- have a component management system that allows you to tie one or more symbols to one or more footprints and add 'meta' data to create a 'component'. Meta data is textual data , files ( datasheets for example ). Meta data can also be links to external databases (through SQL , or through simple CSV files for example.) Meta data can contain anything you want and must allow for 'forking' of fields. for example the field 'Manufacturer' and Manufacturer part number' can have multiple entries
Same for field 'supplier'. I buy yageo form digikey and mouer and vishay from future electronics. so my meta data must allow for that. When bom production comes it must properly present that data.
Reason for multiple symbols per component : placement of pins. microcontrollers for example. have same part but with different pinplacements. Different footprints : least,nominal,largest)

- all of the above version controlled and journalled so i can roll/unroll and inspect revisions. the entire history needs to be maintained. Disk space is cheap. If a textual storage system (xml, json) is used it can be heavily compressed.
- all of it managed though a GUI, drag'n'drop copy paste.
- if you edit a symbol or footprint : notification of what is impacted where and push forward so parts update.
- symbols footprint and components have lifecycle levels : new, prototype, approved , eol , replaced. new parts can not be used in a design. they are being built. parts flagged as prototype cannot go in release builds. only approved parts can go to production. eol parts should no longer be placed. if a part has a replacement assigned : when trying to place such a part you get the replacement instead.

This master database should be stored in a concurrent multi-user format ( multiple people accessing the data pool at once without contention risk ) and using user permissions ( who can modify what) , Preferably without requiring a 'server' (a custom machine with dedicated application. should be able to run on a LAMP or WAMP setup) . It would be nice if all that stuff can be done through a SOAP connection and reside on a web server somewhere. Ideal from a collaboration perspective. you can have your own running on your own box, on a company box or on cloud space for the entire community

capability of connecting to more than one such source simultaneously and possibility to transfer data easily between systems so i can import or share between data pools easily.

The Cad editors pull from the component management system.
whenever a project is opened : rescan all instances of parts against the master database and approve/reject import changes. check for new,prototype, eol and replacements and provide detailed reports with approve/reject for each category.

That is your component front end. This can be completely split off from the cad system and even be a separate runtime, but there should be links. if i right click on a part in my schematic editor it should be able to show me all data , or open the correct editor directly

Next would be a similar setup but for projects. That would manage the files , output datasets etcetera. Same concept : manage revisions , manage output creation ( that really should be a one click thing... you set up a template once and forget about it. the tool should be smart enough to know what layers , and what all is needed )

[nctnico]

@free_electron: you forgot about BOM variants where one design can have multiple different BOMs... 

[SiliconWizard]

Indeed. There are actually many different use cases and workflows...

As the list grows, you'll quickly find out that what you really are after in the end is a full-fledged ERP. Anyone having worked on ERP systems knows how much work that means, and that beyond the base software, there is a lot of customization required for each customer's needs. Is your EDA software going to be customizable enough to fit everyone's needs? If so, you'll still be developing it in a few years.

My advice would be to keep it simple and make the database system interoperable with external systems, rather than trying to develop something that would end up being a monster.

One thing that comes to mind regarding the fact that each part of a design would be linked to a database entry. You absolutely need a revision system in your software if you want to do that. The fact that any modification of the database would impact ALL of your exisiting designs without any control would be very risky. It's a no-no when dealing with validated designs. It must be revision-controlled at the design AND database levels. Any modification of an exisiting design should be explicitely accepted, and not blindly automatic. So if any part modification in the database can impact any of your existing designs, the software should give you means of accepting or declining the changes for each specific design. If you decline, it would use the older revision of the part.

[nctnico]

One thing that comes to mind regarding the fact that each part of a design would be linked to a database entry. You absolutely need a revision system in your software if you want to do that. The fact that any modification of the database would impact ALL of your exisiting designs without any control would be very risky. It's a no-no when dealing with validated designs. It must be revision-controlled at the design AND database levels. Any modification of an exisiting design should be explicitely accepted, and not blindly automatic. So if any part modification in the database can impact any of your existing designs, the software should give you means of accepting or declining the changes for each specific design. If you decline, it would use the older revision of the part.

True. In Orcad Capture CIS you can choose to update the design with any changed components (in the database) and you can accept or deny a change for each part.

[free_electron]

@free_electron: you forgot about BOM variants where one design can have multiple different BOMs... 

That is in the output and project modules. the parts information database does not handle that.
I was mainly focused on the parts information database.

[donotdespisethesnake]

There are really two things here, which get conflated
(1) providing support in KiCad for an external database system
(2) creating and maintaining a database of parts which can be shared

I agree that proposing component database for KiCad (whatever that entails) is unlikely to get much traction with KiCad developers. Their focus is on a lot of other stuff, maybe in future they will come round to it. There is a related item on the KiCad "wishlist" https://bugs.launchpad.net/kicad/+bug/1750180. I don't recall seeing any roadmap items that relate to component databases.

In software, with a large chunk of legacy code, it's really hard changing the underlying data structures because your whole code relies on it. Changing to an "atomic" part system is a huge change for KiCad, so it's not going to happen quickly.

In the meantime, the only real options are
a) develop code outside of KiCad which provides similar features
b) fork KiCad
c) use something else, eg, Horizon

With a), you might be able to identify some minimal features that could be implemented in KiCad. For example, when searching for a part, there just needs to be an API that KiCad calls to get a list of parts matching a search query. KiCad does not need know anything about the database structure, or be bundled with a specific database engine.

I did actually try creating part databases by scraping DigiKey web site, but ran into scalability issues with KiCad. When there are a lot of parts in a library (e.g. 5,000) KiCad hangs then crashes.

So the way I see it working is that the main database holds as many parts as you like, and a subset of those is extracted to work with a specific KiCad project or set of projects. It's a two step process which is not ideal, but maybe better than nothing.

The real big issue with (2), and the reason I think it will never happen, is the sheer amount of labor required creating and maintaining a database. Vendors have people full time doing it, and their web sites are riddled with errors. Crowd sourced sites like kicadcloud.com (now defunct) had such poor data it was not worth going there.

I think any effort to create a component database system must be closely focused on the minimum change to interwork with kiCad, and to minimise the amount of labor required maintaining the data. While everyone talks about the need for component data, very few people are willing to pay for it. Those that do, probably go to one of the commercial suppliers.

[nick_d]

I have been planning to do something like this for a while, though it is not possible for me at the moment due to other commitments.

Currently I use KiCAD PCB to generate simple layouts with a textual annotation which I convert to G-Code using a custom Python script and then use to control a Mazak milling machine. And while KiCAD is up to the task it is definitely the weakest link, editing a layout takes ages and I am often dropping out to an editor to manually change things like coordinates, line thicknesses or radii. I tried using Inkscape but Inkscape is problematic for technical drawings for various reasons.

As an experienced developer who usually creates my own tools, my golden rule is this: create a framework that can someday accommodate all wanted features, BUT only implement the features that I immediately need now. That way I can get up and running fast. Many of my creations have been developed substantially from very simple and humble beginnings, the G-Code generator being a case in point.

In terms of the development tools, I have done fairly comprehensive experiments with wxWidgets and although I initially found it promising I have lost the enthusiasm slightly. C++ is also a very problematic language for a number of reaaons (I interviewed for a C++ job the other day and was horrified at the sample code given to me in a coding test).

The only way to use C++ well is to use it VERY sparingly, never use a template where a class will do, never use a class where a function or a variable will do, and so on. Use things like templates only for obvious cases such as std::vector. Luckily wxWidgets is written in a fairly economical style (it uses an early dialect of C++ before templates), but nevertheless. If you plan on a collaborative project it will quickly get gummed up by people who write C++ all day and never realize they are writing 100 lines of code in several files where 5  lines placed directly inline will do!

As a constraint programming researcher I must say I used C++ a lot, as the code was solving combinatorial problems so had to be fast to run through exponential solution spaces quickly. However, my research group produced truly horrible C++ code exemplifying everything you should not do and why you should not.

Instead I would do it in Python 3 with GTK 3, or perhaps I mean Gnome 3. Anyway, the latest GObject system is quite amazingly powerful for interfacing with high level languages, though it is far too clunky to try to code to the native C API as Gnome developers do. I agree that creating the pre packaged Windows and OSX installers is quite challenging by this route, however, it can be done.

cheers, Nick

[nick_d]

@freeelectron you have described a "dream CAD" system, which I suspect may be similar to a commercial system like Cadence, although I would not know as I have not used commercial PCB tools since MacCAD and Protel for DOS.

However, I must say that I would not need or want those advanced features. As a professional software developer who relies heavily on tools like Git, I can understand the importance of proper tooling, and intellectually I can kind of see why you would want all those advanced features if you are designing PCBs daily and maintaining the designs over a product lifecycle, but as a practical matter it seems to me that all those things would get in the way and create much added complexity and extra problems where there weren't problems before. I much prefer minimalism!

Having said that, everyone has their own way of working and feature set that is important to them. That is why I usually create my own tools and develop my own processes (complex sequences of scripts with small manual steps here and there), in an ad-hoc way. I feel this is more effective than the approach you describe which sounds sort of like the "Microsoft Word" of CAD packages where it attempts to anticipate the needs of some mythical advanced user and ends up featureful but clunky.

cheers, Nick

[Doctorandus_P]

Component databases in KiCad got mentioned on the KiCad forum recently:
https://forum.kicad.info/t/for-those-fans-of-atomic-part-libraries/15212
https://github.com/Projektanker/kicad-db-lib

I have no personal interest in the database thing for KiCad, but I find the list of 50+ external tools on
https://github.com/xesscorp/kicad-3rd-party-tools
very interesting.
It's a common side effect of open source projects. When they become popular side projects tend to sprout up, made by people with a personal interest in some extension, and sometimes they gain enough traction and a group forms around such an extention, or they just stay personal pet projects in various states of usefullness or decomposition.

[Bassman59]

I am a professional software engineer that has worked on projects at the embedded level and enterprise level. At my job, in the past couple of years, I have had more responsibility to be a systems integrator designing electronics. I have also worked extensively with embedded electronics through the years designing circuits and writing embedded firmware. Anyhow, I have done my fair share of research on the current state of EDA, and after the industry has lived for almost 40 years, I can say in 2019 I am appalled at the state of the tools.

Anyhow.. long story short, I think that a fresh start is needed for EDA with a focus directly on usability and the big problems with current EDA tools. Don't just run off and start a project without consulting the professional community, because 100 people will have 100 different ideas. If I tried to do that at my job, I would be destroyed, which is why I must consult first. I think what the OP has suggested to start with is good, and after using some of the tools and doing 'a lot' of research, I have some ideas of my own, which I would like to share. Additionally, I am contemplating starting development on this project (after approval of course, because if there is one thing you will find out about me, is I HATE doing useless work - there is no point to such a project if it is not used by others)

Payment scheme
Free - enough said. I am sick and tired of having to deal with a billion EDA tools that cost something for such a basic need. The tool would be open source as well.

Lastly, I would like to state that I found AutoTrax Dex recently, and after looking at the videos, it seemed like this tool would be a godsend for all the features I want to see in an EDA tool. However! I happened upon the long and exhaustive threads on this forum from the developer and.. yeah.. I won't use that software out of principle even though I think it is godly. I want to have a really great EDA tool like Dex that is free and without the risk of some jack charging for it.

So, lemme get this straight ...

You want the sun, the moon and the stars, but you are unwilling to pay for the creation of those celestial bodies.

Got it.

NB: I use Altium for the day job and Kicad for other work.

I will state that in order to produce a result in most of these tools, it is counter intuitive and users coming from a windows world especially expect easy point and click (including myself).

That right there is part of your problem: PCB design and layout for anything but the most trivial of designs is not 'easy point and click.'

You might wish to browse the Kicad developers' email archives. (I use Kicad as an example, because it's the most popular open-source PCB CAD tool out there and the developer discussions are easily accessed.) There is a lot of considered discussion about the user interface, hot keys, approaches to activating tools, all of that. It turns out that everyone has a different opinion and a different idea of how these things should work. What works well for me might drive you crazy. That's the nature of the beast, I suppose.

Finally:

The biggest issue with these tools is usability from the lay person's point of view.

There's the rub, eh? Seems to me that trying to design tools that work for both the casual lay person (a "maker" or hobbyist) and for the professional users is, uh, quite the challenge. The professional needs comprehensive design rules, net classes, hooks for proper BOMs, you name it, and those things might baffle the hobbyist.

-------------
I haven't even mentioned libraries ...

[pointhi]

I want to be able to select and highlight a part just with a single left click.. but instead I have to drag a selection rectangle around it, which is a huge hassle, especially if multiple things end up behind each other, and I want to delete one: this has happened to me at least 10 times since a few days ago because of the way KiCad movement semantics work. Again, maybe I have not found the right switches in KiCad to make it work how I expect.

When you try KiCad nightly you will see this behaviour is fixed with the new tool set .

You need to keep in mind there are technical restrictions which limit the possibility what type of UI developer can create in reasonable time. The Legacy Canvas + Tool system was such a restriction for a long time in KiCad. wxWidgets is another one. Their development speed is pretty slow, and many features planned for wx 3.2 are highly desired. Like proper high DPI support and dockable notebook pages.

In my point of view the best way to get a better ECAD is to improve it part by part.

[Bassman59]

I want to be able to select and highlight a part just with a single left click.. but instead I have to drag a selection rectangle around it, which is a huge hassle, especially if multiple things end up behind each other, and I want to delete one: this has happened to me at least 10 times since a few days ago because of the way KiCad movement semantics work. Again, maybe I have not found the right switches in KiCad to make it work how I expect.

When you try KiCad nightly you will see this behaviour is fixed with the new tool set .

You need to keep in mind there are technical restrictions which limit the possibility what type of UI developer can create in reasonable time. The Legacy Canvas + Tool system was such a restriction for a long time in KiCad. wxWidgets is another one. Their development speed is pretty slow, and many features planned for wx 3.2 are highly desired. Like proper high DPI support and dockable notebook pages.

In my point of view the best way to get a better ECAD is to improve it part by part.

I use the nightlies, and the advances made since even 5.0 was pushed out are great!

Improving part by part makes sure that a release doesn't break everything their users are doing.

Part of the reason for the "slow" development is that they try to ensure that things like the newest wxWidgets is available on all supported platforms. Python scripting is like that, too, with all of the various pieces all on different versions. It's crazy.

[Bassman59]

For all are interested in this thread: I had ditched this idea as I renewed my Altium subscription for another 2 years, and I learned KiCAD as a second plan.

There's a lot to be said for no longer tilting at windmills and instead just getting the tools you need to do you job.

[nctnico]

Bah.. I wanted an admin to change my username before I posted again, because.. I don't like my email as the username (made this account awhile ago and mistakenly used my email as the username). I sent an email to eevblog official to fix the issue.. but I don't think I will be taken care of in a timely fashion... so...... I digress

Multi components
Components with multiple sections - still thinking about the best way to do this

Look at how Orcad and Altium have implemented this. See below.

Integrated toolset
Schematic and layout are coupled in the same program. Same usability exists between schematic and layout (point and click features)

Not even remotely important in a professional tool. In Orcad I draw schematics in Windows and do PCB layout in Linux (this is a >$5k package without the very advanced options).

"Plotting"
PDFs are completely standard in my group.

PDFs are useless as output because you'll need at least Gerbers and ODB++.

One of the things you forget is that creating a board layout is all about logistics. Schematics and PCB layout are just two steps in the entire process. Managing parts and producing production data are even more important. The big error freeware and low cost CAD package often make is not thinking about the logistics first.

[free_electron]

Not even remotely important in a professional tool. In Orcad I draw schematics in Windows and do PCB layout in Linux (this is a >$5k package without the very advanced options).

You must not be doing a lot of crossprobing then .... ( click in pcb and have schematic zoom to part and vice versa ... )

It is VERY important to have the schematic and pcb talk to each other in realtime. only transferring netlists and pushing back eco's using simple files went away 20 years ago... There is not enough data in the file exchanges.
Protel 95 could already crossprobe.

I use that heavily.

[nctnico]

Look at how Orcad and Altium have implemented this. See below.

My first inclination is to just outright say to you: "NO". Because that statement reeks of: "They have been doing it this way for decades, so you do the same!"

Well, they have not been doing it this way forever. The part management in Orcad and Altium (and probably other high-end packages) has been born out of necessity (and went through many improvement cycles). Not because it is something they have thought about long and hard when they begun writing their software. My statement is all about not making the same mistake again.

In my experience people often want to create new software because they don't want to learn how an existing software package works and/or think they can come up with something better. But in reality those people often underestimate or don't understand the complexity. At one of my former employers the R&D manager wanted to have a project management tool. These are a dime an dozen but he insisted we should develop one ourselves because he didn't like (=understood) the existing packages. So we ended up with a very clever intern (no bad word about this person!) who wrote a web-application. When it was nearly finished it turned out all kind of features where missing so the intern got hired to finish it. In the end we got a project management tool which was just as complicated to use as an off-the-shelve solution but only paid more  Meanwhile we could have used the time the intern spend on the project  management on product development.

The moral: be really sure you can improve a 'perfect wheel' before creating something which already exists.

[nctnico]

Not even remotely important in a professional tool. In Orcad I draw schematics in Windows and do PCB layout in Linux (this is a >$5k package without the very advanced options).

You must not be doing a lot of crossprobing then .... ( click in pcb and have schematic zoom to part and vice versa ... )

It is VERY important to have the schematic and pcb talk to each other in realtime. only transferring netlists and pushing back eco's using simple files went away 20 years ago... There is not enough data in the file exchanges.
Protel 95 could already crossprobe.

I use that heavily.

I don't use cross probing at all. However when PCB editor and Capture both run on Windows Orcad can do it as well.