That makes perfect sense but (from the schematic) when I edit say Unit A of a R4N network and I then inspect Unit B it has not changed to match A. So I assume I have to change the rest (i.e. B,C,D to match) which is very tedious and quite logically makes no sense other than I don’t understand the tool to do otherwise.
Do I need to rebuild the NETLIST (or something else) following the change to one of the Units to get them to resync as the display shows they are not?
doing the annotation shows me that they belong to each other
going into the properties of either one of them will change the fields for both of them
I admit, placing multi unit symbols/parts is a bit tricky and doesn’t do a lot of hand-holding/guiding (which would be severely needed - or I didn’t see it yet), but once you got past that obstacle it’s bearable.
IMHO I would expect that it drops all sub parts of the multipart… but then how do you deal with hierarchical sheets… or I’d like an option when I select a mutli part that I can tell the tool to drop all subparts in one go.
Or when you want to drop another part there should be a list of sub parts that are able to be dropped, separate from the History selection… something like a multi-part waiting to be placed stack.
It’s definitely error prone because of that manual handling of getting the sub-units placed.
I change the Item # from _24B to _24BBB hit save; Unit A changes and selecting B in the pull down says B has also changed. However if I go back to the schematic, mouse over the B unit and hit E and it is still at the original _24B not the edited _24BBB.
;
I go to the B Unit and select the A pulldown and it is as it was originally unchanged at _24B. There is a syncing problem making appear that there are multiple definitions.
Now sure if this works; I edited the Unit A symbol in the Symbol editor and then saved to a new library. It created the two files attached(drop box link).
That’s what it looks like in the sch file once dropped:
…
$Comp
L LED_Dual_LSGT676_PLCC4 D101
U 1 1 56FE0703
P 9550 5475
F 0 “D101” V 9450 5475 50 0000 C CNN
F 1 “LED_Dual_LSGT676_PLCC4” V 9735 5475 50 0000 C CNN
F 2 “LEDs:PLCC-4” H 9550 5475 10 0001 C CNN
F 3 “E:\Datasheets\Electronics\Optoelectronics\LED\Osram_MultiTopled_LSG_T676_Pb_free.pdf” H 9550 5475 10 0001 C CNN
F 4 “Q65110A4186” H 9550 5475 10 0001 C CNN “Manf#”
F 5 “test” H 9550 5475 10 0001 C CNN “Manf”
1 9550 5475
1 0 0 -1
$EndComp
$Comp
L LED_Dual_LSGT676_PLCC4 D101
U 2 1 56FE07B4
P 9950 5475
F 0 “D101” V 9850 5475 50 0000 C CNN
F 1 “LED_Dual_LSGT676_PLCC4” V 10135 5475 50 0000 C CNN
F 2 “LEDs:PLCC-4” H 9950 5475 10 0001 C CNN
F 3 “E:\Datasheets\Electronics\Optoelectronics\LED\Osram_MultiTopled_LSG_T676_Pb_free.pdf” H 9950 5475 10 0001 C CNN
F 4 “Q65110A4186” H 9950 5475 10 0001 C CNN “Manf#”
F 5 “Osram” H 9950 5475 10 0001 C CNN “Manf”
2 9950 5475
1 0 0 -1
$EndComp
…
Each one of them got their own set of fields - independent of each other.
See how I changed the Manf field?
Using the drop down selector in EEschema to select units doesn’t actually bring you to the other sub unit of that multipart, but instead let’s you change/select the sub unit of the part you’re editing.
I can make a red led (unit A) out of the green led (unit B) by changing this drop down value.
So even when I placed a unit A and a unit B, I can change them afterwards?!
That’s definitely wrong.
Anyone who does this on a regular basis care to shed some light into this?
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