I am using the following part MountingHole_3.2mm_M3_Pad for 4 mounting holes on my boards. Interesting they show up in the BOM and PCBWay is asking for a part# for this. I am commenting back that these are just mounting holes, so they don’t need a part #v5_1
Curious what the right way is to handle this going forward on new orders so they don’t think this is a part to be populated.
Should I omit from BOM? If so, is there a way to designate this so I don’t have to edit the csv file after the BOM generation.
This problem, in one form or another, has been present in every PCB layout program I have worked with. Search this Forum with “DNP” or “Do Not Populate” as the search seed to get background information, and an appreciation for the scope of the problem. It affects not only mounting holes but also things like testpoint pads, wire-attachment pads, traces designed to be fusible links, traces used as RF antennas, etc.
To my knowledge there is no standardized solution, and not even widely accepted practices. From that perspective your best approach is to ask PCBWay how they want to handle the situation . . . . and be prepared to change your procedure if you ever use a different vendor. Several incarnations ago my employer (as I recall) filled the “Manufacturer” field with “PCB Design Feature Only”, and the “Part Number” field with “No Physical Part”. This method works if there is a live, human, person processing the information but is probably unwieldy for automated systems where things are done by machine.
If virtual would sovle the problem then through hole would as well. Both tht and virtual are currently excluded from the position file. The normal bom is not affected by this flag (as it is created by eeschema which does not know about this flag).
PCB fab houses can contour boards - sometimes via Milling, sometimes via Laser cut.
KiCad puts the shape stuff on the Edge_Cuts layer (though you can put them on other layers, too, such as Eco_User…)
Check with your fab house to see what they prefer…
Below shows a shape contour with cutouts - all done on the Edge-Cuts layer.
A BOM will not list them.
The copper looking one shows it loaded into CopperCam for milling…
Recognize the remaining copper inside the hole is graphic only, it’s unattached and gets thrown out…
For most fabs circular holes <6mm are best made by adding some form of non plated hole as this will means they will be drilled which has lower tolerances compared to milling.
I’m slowly adopting KiCad to my needs.
I don’t know Python.
To generate my BOM I copied bom_csv_grouped_by_value_with_fp.py and made there a little modifications to get csv as I need (good people here helped me to make small text manipultions in Python).
Later myself I noticed in that file the line:
“import kicad_netlist_reader”
so I looked into kicad_netlist_redaer.py and found there:
“def getInterestingComponents(self)”
reading that function (even don’t knowing the Python) it is clear that it excludes from element list elements according to many criteria. It uses the text lists exclude_references[], exclude_values[], exclude_footprints[] to exclude elements if its reference, value or footprint is in appropriate list.
This text lists are defined close to the file beginning.
The excluded_footprints contains #‘MOUNTHOLE’. I don’t understand what that # means for Python as in other lists there are only simple texts (without # ).
It looks it is intended to take care exactly of your problem. May be someone will tell how to follow that way, but (don’t understanding that way) I went other way.
Reading further our function there is also:
if c.getField( “Installed” ) == ‘NU’:
exclude = True
I have changed in my_bom.py the line:
grouped = net.groupComponents()
to
grouped = net.groupComponents(net.getInterestingComponents())
and to all my symbols (in my library) to be excluded from BOM I added the field ‘Installed’ with value ‘NU’.
I get the csv without these components and need not to sort them out manually after each BOM generation.
I don’t know why before my modification I get element lists in wrong order (not specially importanat) - like C1,C7,C2,C15,C6. Function groupComponents sorts it (or tries to sort it).
After my modification these references are sorted twice (getInterestingC… also sorts) and I get them in right order.
The sort function is called differently in these functions. I reported it as a bug. I see there are minor changes in sorting in kicad_netlist_reader.py (5.1.5) compared in my older one (probably 5.1.4).
It was enough long ago for me to not remember details but I think I have checked those time that this changes not helped. But as my output is correctly sorted (I don’t care that computer loses some time for two times sorting ) I’m happy with my solution.
) I’m happy with my solution.