Flag for Component not assembled or not mounted on PCB


#1

Sometimes, when you create a circuit and a pcb, you may want to have options for certain components, pins or connections. For example you have two Serial Ports on a Mikrocontroller, but you are not sure, which one you are able to use. In this case, you could use Zero-Ohm Resistors to assemble either way,
It would be great, of there is a way to mark the resistors you not want to be assembled as “NOT ASSEMBLED”. N.A. (Not Assembled) Components can be gray in the schematics then, that its clearly shown. In the PCB, the component footprint will be there, but the component itself is grayed out as well. The same in the Netlist. It can be marked as n.a.

This would be a great feature to add!!


#2

This is a good idea. If you want this implemented as a feature within KiCad then it is best to raise an issue where the developers will see it.

Here’s what I would do (and would have done already if I didn’t have 100 other things to do…)

Fitted or not fitted is a good start, but what you really want is assembly variants / configurations. Imagine some hypothetical board which you have to build for three customers, as well as have an in-house build with extra parts for debugging or test points or whatever.

Some part (let’s call it U31) is fitted for Customers1, but not 2 or 3.

R17 is missing for Customer2 but loaded for all others.
C99 is ONLY fitted for debug

See how it now becomes more complicated than just DNF?

So, you have the concept of a board configuration - there can be multiple configurations for a given board. In the schematic editor you can edit the configurations, add descriptions, etc. Then, each item in the schematic gets a ‘configuration’ field, where you can specify which configurations correspond to each symbol.

e.g.

U31.configuration = -customer3
R17.configuration = -customer2 -customer3
C99.configuration = +debug

Where:

  1. -xxx removes the part from configuration xxx
  2. +yyy specifies that the part is only fitted for configuration yyy
  3. You can chain multiple explicit configurations e.g. +xxx -yyy -zzz
  4. Unless defined otherwise given the points above, a part is assumed to be fitted.

Once this is implemented, then you can select the ‘active’ configuration within KiCad.

  • Any part that is not fitted in the selected configuration will be greyed-out in the schematic.
  • When it comes time to generate the BOM only active parts are exported
  • 3D models can be hidden in the 3D viewer for DNF parts

I have implemented most of the functionality above into my BOM generation tool which allows you to specify (at BOM creation time) which configuration to use. It requires that you add a specifically named field to the components you are interested in not fitting.

This works pretty well!

However I think that it would be great to implement this within the KiCad source code as described above.


#3

Each footprint has “Attributes” - “Normal”, “Normal +Insert” & “Virtual”. The last does not appear in the BOM


#4

Wow. yeahh that would be even better !

As a very first step for simple use, I could imagine to implementing it
KiCad could be something like this:

A predefined Field in the Edit Window of the selected component could
show “Fitted on PCB” or “Not Fitted on PCB” with the Option “Grey Out”.
This would show the component gray, which gives a very nice readable
Schematics, showing clearly that this component is just for debugging
purposes as an option. In the PCB it will be grayed out as well then.
The BOM should show the n.f. Flag or the variant.

Similar to this, I can imagine it could be a field where more variations
can be selected.

I am always happy of I can contribute some ideas :-). I can also raise
it as an issue for the developers.


#5

I suspect KiCad is a long way from implementing variants (configurations). Until then, I’ve found that virtual attribute works really well. Especially if you have your design under Git as you can use branches as a variant (configurations) selector.


#6

I simply use different Bills-Of_Materials for each different build. In the BOM I mark the component as Do Not Install. My assembly houses do not seem to have an issue with this approach. I assume they make a separate assembly file for each version of the board.


#7

The issue, I think, is how can you start with one schematic and from that, automatically generate those different bills of materials.

One idea, which we use at the day job (we use Altium but our concept predated Altium’s implementation of variants) is to add a custom field (or fields) to the symbols. The field is called CONF-1 (or CONF-2 and so on) and holds either an alternate part number or “not installed.” It’s important to note that each symbol in our library has a custom Part Number field which is always populated.

An Excel or CSV BOM is exported from Altium and a small utility program is run. It pulls orderable part data from the ERP database based on each symbol’s Part Number, and is smart enough to know how to deal with “not installed.” When the program is run, you tell it which configuration you want to use.

The idea, of course, is that BOMs are never hand edited — they are always generated automatically. If the schematic changes then new BOMs must be regenerated.

When you have a complicated design where you don’t want to stuff a lot of things for a certain configuration this can become tedious. (One design was like that and Altium variants and a channelized hierarchical design helped!) so I think that yes, Kicad does need some kind of variants capability but I suppose it won’t get implemented unless someone steps up with a robust concept.


#8

The schematic would have to told how many variants of the board that there are.

In my design I have bus addresses for chips so that the design can communicate between different boards.I think one of the chips can have 9 different addresses, based upon the address resistors that are populated.

My design only needs three though.

If KiCad could create a BOM in an Excel format for these three differently addressed boards, that would probably be a step to make many users happy.


#9

KiCost can handle variants and creates an XLSX spreadsheet based upon whatever variant(s) you activate. While mainly intended for estimating part costs, the initial portion of the spreadsheet is usable as a BOM for assembly.

This is the relevant documentation:


There are cases where a schematic needs to be priced differently depending upon the context. For example, the price of the end-user circuit board might be needed, but then the price for the board plus additional parts for test also has to be calculated.

KiCost supports this using a variant field for parts in the schematic in conjunction with the --variant command-line option. Suppose a circuit has a connector, J1, that’s only inserted for certain units. If a field called variant is added to J1 and given the value V1, then KiCost will ignore it during a normal cost calculation. But J1 will be included in the cost calculation spreadsheet if you run KiCost like so:

kicost -i schematic.xml --variant V1

In more complicated situations, you may have several circuit variants, some of which are used in combination. The --variant option will accept a regular expression as its argument so, for example, you could get the cost of a board that includes circuitry for both variants V1 and V2 with:

kicost -i schematic.xml --variant "(V1|V2)"

A part can be a member of more than one variant by loading its variant field with a list such as “V1, V2”. (The allowed delimiters for the list are comma (,), semicolon (;), slash (/), and space ( ).) The part will be included in the cost calculation spreadsheet if any of its variants matches the --variant argument.