I had all the text fields in place and then did the layout having to exchange units in several cases to aid in the layout of the 2 layer board. Then if I decided using layout my Cap network or Resistor network was too big and I swapped over all of the parts to something smaller , resetting all of the fields by cut and paste caused reannotation hassles and undid the parts swapping I did in the layout. Major hassle doing 5 steps backward and it has literally been three days since I made any progress.
This implies that the program is ignoring the field entries for any other units.
Donāt know what happens though, when you donāt place unit A but only unit B+ā¦ uncharted waters.
Bom hell is my only comfort but at least the KiCAD BOM seems to work using Transform. I have been going through the csv file with a fine tooth comb and creating a corresponding Digikey BOM to keep both in sync.
Iām realizing js and xml are modern day batch files but they are still foreign to me. So donāt really have a clue. I can write C/C++ but never did any xml.
Anyway the BOM export seems to be working and with multiple parts so not sure what you are seeing.
You can see from the last sentence in Parg 11.9 that they say that adding fields is normally done in the Schematic rather than the Library. The rest is left to the imagination which I imagine is contributing to my BOMing.
If you then create a new part in the Part Library Editor (symbol editor) and go for the āField Propertiesā (top toolbar, uppercase black āTā depicted) youāll find that besides the (built in) standard fields Ref/Val/FP/PDF you have whatever you set up in EEschema editor settings up there:
And you can deviate from this (new) default any time, just add or delete the custom fields. Canāt do that for the 4 built-in fields though.
I donāt do any editās of those properties once a part is in the schematic. Way to dangerous. The library is the master and only source of this info for me. This way I have atomic parts.
PS: Iād like to have a [Clear Field] button in that dialogā¦ itās cumbersome to take a part, adjust it to another part and replacing the pdf path in there as you canāt select/replace in a simple operation, but instead you have to scroll/select/delete/pasteā¦ not fun.
Thatās how they roll (or rolled) and the difference between doing symbols+footprints (hobbyists) vs parts (professionals).
KiCAD allows both ways and suggests the easier to understand and faster (as less cumbersome library works needs to be done) to the finish line approach.
But anyone working with KiCAD seriously over a couple of months sooner or later arrives at the latter system to stay somewhat sane while creating PCB after PCB. That system needs more legwork upfront to get everything set up right, but will pay off if you do board after board.
I think the best workaround for keeping fields in sync for sub-parts at schematic level is:
Place first sub-part on schematic.
Edit fields if necessary.
Place other sub-parts by āCopy componentsā (C key).
Re-annotate schematic.
Of course point 3 will not work when sub-parts are on different sheets in hierarchy. But you can use āSave Blockā and āPasteā operation instead of simple āCopyā.
Each element consisting of the symbol - graphics/free text item - has its own properties. This is not related to the components fields.
So if you reannotate after each unit (sub-part) copy then it avoids perturbing the other annotations as there is only one unannotated? I would do an R4N by editing the first and copying the rest and then reannotate and it would screw up the pin orders in my layout.
This is basically what was I was doing to start, it was the rework (back filling of modification to network footprints in the layout that was the killer with just a few footprint changes. I started to edit fields to avoid the reannotation pitfalls.And Iām guessing all these mysterious fields really only exist in the program and not the xml files? I changed the one unit in the example above and regenerated the BOM and it made the change even though only one Unit had been changed.
Controlled ācut, paste, reannotateā on a per unit basis is the best option then Iāll do that.
Iām gathering you are talking about having a common/standard Parts Library with joined symbols and footprints which you use to populate your schematics/layouts.
Yes, exactly - just not as elaborate as @Andy_P is doing it.
Iām on amateur level in this regard.
My symbols/parts in the KiCAD libs carry the manufacturer number and thatās it.
I donāt use a lot of parts and my turn over rate of designs is relatively low, Iām also the only one using it. @devbisme, the author of KiCost must be running the āamateurā version as well.
I know Andy is rolling the professional version, probably in a team - instead of a manufacturer part number field heās got an internal house number field that is linked to the real manufacturers part number via a list that is being accessed through an external script/tool.
That way he/they can change components outside of KiCAD (reel vs tray, etcā¦ ) more easily and do some other stuff I donāt have a use for (yet).
Well that really comes as no surprise. Within a couple of hours, I knew that the method promulgated by Rhinegoldheavy was not the right thing to do. I searched around and saw some other tools but nothing that looked like it was DONE.
Trying to use the schematic as a database for all parts related information puts the parts management job into teh schamticand forces you to use KiCAD tools for that where there are probably many more tools much more appropriate Excel to name just one.
Therefore it is clear that KiCAD should have the minimum amount data nessesary to complete the EDA process. It should not be used for parts control or purchasing. Obviously carrying a single PN is minimum, but that still might be the best of all worlds.
I certainly do not want to take on the job of maintaining a giant parts data base and numbering system. In fact to a large extent it is not even nessesary. If you just carry around the Digikey part number you cover 95% of your parts. With an alternate like Mouser you have 98% covered. In fact it would be easy to encode a single part number field into KiCAD like:
D-DigikeyPN
M-MouserPN
N-NewarkPN and then you are down to a single field to parse.
You then manage combine and manage the data in some other tool. Even Excel would be better than what Iām doing now.
You still need the BOM export facility, but dramatically fewer fields that I started with based on the Rheingold approach.
All you then do is strip the leading source prefix and compile the various source lists for the constituent parts of your BOM.
I already started adding additional parameters , like voltage, tolerance and package to the āvalueā field of my parts. This is stuff I want to see on the schematic.
For each PCB I have a BOM line item number and Iām not sure that that could not be the sole entry in KiCAD beyond minimum needed for layout. In the past I have easily managed the BOM in a spreadsheet using the line item number. Striving for even better efficiency I step off the trolley and into a pig pen when I found the Rhinegold blog.
Well it looks like at least I know what not to do next time.
EDIT:
If for example I refer to a Resistor network as BOM item #32 and I change the part from cut tape to real or even 10% to 20% tolerance as long as I donāt have to change the BOM number or footprint there are no KiCAD changes required the rest is in the external tool. That is even lower impact to KiCAD . There is no reason to change the schematic or layout if you have an alternate manufacturer part number and even less with an alternate source part number for a specific line item in the BOM.
You need to keep all this information out of KiCAD.
You donāt want too much data being managed by KiCad because larger companies have already invested plenty of time and money to their ERP systems. Unfortunately most companies setup is unique, a combination of the ānot invented hereā thinking and contractors such as SAP specialists earning billable hours by creating complex customisation
Well that is the irony of the situation; So why then are people trying to build elaborate KiCAD BOM export tools?
The reality is that parts selection is the result of a web search; one of the most convenient I have found is DigiKey parts search facility.
If I search for parts, save a part in a basket why do I need to take this information and enter it into KiCAD so I can turn around and upload it back to DigiKey?
I drew a quick picture of the data flows that are in general required even for a relatively simple PCB design process. From the picture it is clear that a large part of the vendor and part information actually comes from the vendors or their links back to manufacturer data.
There are various activities that have to occur that have really nothing to do with KiCAD. Purchasing, Inventory Order management and shipping receiving. This does not have to be some big SAP tool. You can do it in Excel (which I have) leveraging the vendors on line tools.
The KiCAD libraries come in two forms; The public libraries and the libraries you maintain after you have vetted symbols and footprint you have used in your own design. Because of some of teh limitation that exist in KiCAD such as there multi unit parts you have to be careful about how much information to carry around in KiCAD.
You real central data base of parts should be outside of KiDCAD even for the simple DIY.
Thanks for that explanation. At some point will be cleaning all this extraneous info out of my KiCAD project and putting only the minimum in into a set of Library symbols as you describe. At this point with my discussion above I donāt know what that would be if anything. Iām virtually convinced that Manufacturer part number or vendor part number or any other part number should not be in the Library,schematic or KiCAD at all. I think it only need to be a BOM reference ID number. (1,2,3ā¦55)
Exactly, which is why a ODBC connector is probably the way to go for the future, csv export for now.
ODBC can be a two way process, allowing the database to be queried
