Hi,
I am looking for folks who want to work out some CAD oriented library work.
For many years I have been messing with “Reverse Index Searching” for electronic components and PCB footprints. I just started looking at KiCAD so I decided to run the 13K footprints through the indexer (Indexing by processed descriptions) and it did not work so hot. It works ok for my 3500 footprints but I have very consistent descriptions built with keywords. Work fairly well on my descriptions but not KiCAD footprints. I could tweak but I want a “Light Year” jump in performance.
I went a bought a book on library science and it was a real eye opener. It turns out folks started building “Card Catalogs” (clay tablets) back in 2000BC. Holy cow, libraries on many CAD systems are often after thoughts and they are not much better that the lists built back in 2000BC. During my school days (mid 1970s) I loved the card catalog systems and the library staff who made the whole thing work.
After some reading I now think some means are required to manage a part library without requiring a full time staff to keep things organized. The footprint are the easy part as for components there are orders of magnitude more parts.
Modern libraries use “Abstracts” to form Surrogate Records which are indexed by several means. Subject, Author, Language, Location and so on. The creation of Abstracts and the subsequent indexing needs to be automated. While I like what KiCAD did with Global and Personal libraries a Global library doesn’t belon on every desktop instance, at least I think not. We need APIs (Web or or RPC or COM or something) as to decouple fomr the KiCAD C++ code, I think.
If anyone is interested in this subject please let me know. Bob at partsync dot com
Thanks, Bob, for making the video. There seems to be an interesting idea here, I just don’t know what it is. So i’ll ask some more questions.
Is this a problem that is solved just by putting better descriptions on part symbols and footprints? You show some categorization hierarchies, but how do those get reflected back into the decal descriptions you showed in the list in the window of your video?
Part and footprint selection occurs when using KiCad, but you talked of possibly building your librarian system as a web service. So the librarian sounds like it’s doing something other than searching through descriptions. Is it compiling descriptions and entering them into the KiCad symbol and footprint libraries and then KiCad searches for them as it does now? Or what?
Most software tools exist to allow more complex systems to be built faster and with less effort while reducing the probability of making errors. How does your librarian fit into that? It seems you already have a version that works with PADS. How does it work when entering a schematic? When doing layout?
just by putting better descriptions on part symbols and footprints?
Better descriptions help, absolutely. However we don’t typically search on just one word we often have several. Some words, or word combinations are more important and there are weights that need to be applied. The searching happens when things are put into the library and again when a user looks for things. The logic for each of these phases is a little different. There is additional logic required for how to display results.
Part and footprint selection occurs when using KiCad
Correct but that is for a user search. In a library we start with a catalog to find books that are on a shelf but who setup the catalog or who keeps the shelves organized. Key words and phases need to be defined, weighted and changed at time. I used a lot on “Generic” parts in my OrCAD libs. I had a single resistor symbol. Once the schematic was finished I formed BOM line items and annotated each line item to a Component. That annotation brought in database Footprint data. New components would be setup in the database with references to either existing or new footprints.
3.Most software tools exist to allow more complex systems
There are several inputs to software tools. Language, runtime, 3rd party components and programmer experience. The 3rd party components and programmer experience are most important. I use Delphi which I compile to Win 32/64 or Javascript for web apps. I can also compile to Linux, Android and Mac but have seldom used those. I have various sets or 3rd party tools I use, without them I would never get anything complete. The current code has ZERO to do with PADs. I write footprint for PADs and Altium now (both use .d files) and I am adding output of KiCAD footprint. But footprint and component librarians are needed in any case.
The “Downside” of my Delphi and 3rd party tools is cost, plan on $7K or so. A drop in the bucket compared to programmer salaries but very far from chump change for a DIY kind of guy. But the productivity in Delphi is huge. I know, all the C, C++, C# and HTML folks will hunt me down with torches but I have been doing this for years. I am right.
With a good API who cares what the source code is written with. We have no idea what is on the other end of a browser. And COM objects in Windows can be written in about any language and then used by code from any language. Whatever get the job done fast and best. And with RPC or Web we don’t even care about where the code executes, do we?
How about the https://www.snapeda.com/ ?
Combine it with the digikey might solve most of the available parts.
If you can find a way contribute to the snapeda by uploading your thousands parts information, that can help lots of people.
They are more of a marketing company and not a librarian that can help KiCAD users manage their own libraries. They have tons of very nice data but all us users need to organize the data we use.
The local copy should not contain more information than the hash of the index of the online database. For search request, always redirect it to the online database, if the result is already used before, then directly point to it, or else, download a new copy.
The local copy can have extra fields like extra user note, project info etc.
What you mention sounds very nice but it is a fraction of what engineers need when designing PCBs.
PCBs have hundreds of parts and these change during the design phase. Doing as you suggest for every part multiple times would be ridiculous. Some type of automated system is required with part caching during design.
Final part selection is often most efficient when it is done for complete line items once the schematic is finished. This process requires a little software support.
3 You ignore the huge difference between Parts, Packages and PCB Footprints. The associations between these are very much a task for local database logic.
Further searching Digikey for keywords returns multiple responses that must be manually sorted and the reported footprints are not related to existing footprints in local KiCAD libraries.
When you throw out ideas please go into a little more details. I have many pages of details up on my partsync dot com site. Take a look, Send me some written descriptions with more detail than single sentence statements. I would love to compare notes.