Is it possible to include the component class assigned to a component (using a rule area with a directive label attached) as a field when generating a BOM? I would like to keep track of which subsystem each component belongs to within the BOM. Drawing a rule area around a part of a circuit seems like a perfect way of “tagging” related components together. As new components are added, copied in, or removed, they will automatically be grouped together so long as they are inside the rule area.
I think what you’re trying to do might be difficult/impossible. A component might have multiple netclasses (one per pin).
If you want tagging of certain blocks on your design, it’s probably easier to separate them into hierarchical sheets and then you can refer to the sheet number within each component with the variable ${#}. If you want to give a name to the block you can use one of the Comment fields (for example Comment 3) in Page Settings and then refer to it with the variable: ${COMMENT3}.
If you give a different name to each page this way, your components would be associated with it.
To quickly add this property to all symbols, go to Edit Symbol Fields..., Add a new field name and then add the variable ${COMMENT3} on all components.
2 Likes
The OP is talking about component class, a newer feature.
But I think the answer is no. A symbol can be part of several component classes. A logical solution would be to have a text variable ${COMPONENT_CLASSES} which would give a comma separated list. Maybe a reason for a feature request…
BTW, I don’t even find a way to see a symbol’s component classes except going through Fields and trying to detect rule areas visually. IMO that’s not enough in difficult cases, for example in case the rule areas are badly drawn or a directive label isn’t attached properly.
Component classes are quite expensive to compute, as we have to look in every hierarchical sheet to see if there is another multi-part component (e.g. I might have U1A on one sheet, and U1B on another). The component classes are then assembled as the set of all associated component classes across units. That’s why they’re only computed when exporting the netlist to the PCB editor. Also in v9.99 component classes can be dynamically allocated in the PCB editor, so the schematic list of classes isn’t always going to be the final set.
We could consider some ‘tell me this component class in the schematic context’ function, but this would naturally sit in the properties inspector, and we’d be back to potential performance issues. Unless we cached it (which we could do…). I’ll have a think.
Just create new field in component properties or database, for example “Group”. Set Group value.
In BOM dialogue set checked field Group, and group checkbox
now in BOM you can see grouped parts by your group settings
I think the solution suggested by @tiagogala will work very nicely for my needs. It is only slightly less flexible than what I was trying to do, but it may actually force me to have better organized schematics. It didn’t occur to me that there are multiple COMMENT variables associated with each sheet.
And now I know for sure that there is not currently a way to use the component classes in the way I wanted (and to some extent the reasons why not).
Thank you everyone for your responses!