Fixed selection columns for variants.

[mdeweerd]

It would be usefull to preload some columns with fixed selection values based on variants.

There is already --variants-whitelist and --variants-blacklist but these do not create columns, and they are not regex.

Context:

I use KiCAD with KiCost to manage variants.

KiCost allows use to specify a regex that helps filter all the variants. The dnp and variant fields determine together which components are ultimately present.

The contents of most other fields (description, value, ...) can also be changed through the variant expression.

So when I add --variant '^(screen3v|button3)$' , the screen3v and button3 variants are selected.

Proposal

My proposal is that InteractiveHtmlBom also understand a variant option that is based on regex and allows the generation of named columns with tickboxes.

Example:

Repeat the same option multiple times

generate_interactive_bom.py --variant '3btn3Vscreen=^(screen3v|button3)$' --variant '2btn5Vscreen=^(screen5v)$' <otheroptions>

or

to be similar to the existing variant options, using space as a separator:

generate_interactive_bom.py --variant-regex '3btn3Vscreen=^(screen3v|button3)$ '2btn5Vscreen=^(screen5v)$' <otheroptions>

(when the equal sign is missing, this could be considered as a nameless field or only as a regex selector complementing the variants whitelist and blacklist options).

Regex is useful with buttons for example, use button.* to select all buttons.

The suggested examples would add two columns '3btn3Vscreen' and '2btn5Vscreen' to the HTML file much like the default Sourced and Placed columns. They may be modifiable, but the modfications may/(should) be suppressed on reload (which could be an option).

Applying the other impacts of the variant selection (component value) would be nice, but only applicable when only one variant is added (simpliest case because this value is the only one in the HTML file) or selected (more complex case because this adds logic to the HTML file).

[qu1ck]

If I understand correctly you want to create a boolean derived extra field that will be true when value matches a regex. That has nothing to do with variants really. Variants feature is there to select what gets included in the bom or not.

I don't think this is useful functionality to have in ibom, you can do this by adding another custom field in eeschema and use excel or anything else to do your preprocessing. Ibom can't and shouldn't try to do any processing on your fields, it will never have flexibility of software designed to do data processing.

Going back to variants, I can see some value in having regex support in variant whitelist but I'm curious to hear of any practical example where you have so many variants that it's not just as easy to tick a few in the whitelist.

[mdeweerd]

Well, here are some real variant expressions, coping with MCU memory size, input connectors variants, analog circuit variants, voltage variants, input and output options, resistor dividor allowing to read the board variant, an option to choose one or the other rectifier:

VARIANT="^(64k|inp1bnc|inp1|inp1tripAOP|ana5V|inp2bnc|inp2|inp2tripAOP|vnegnc|mot1|5vreg|bridgesldb1|inp1support|inp2support|noF1|vnegnc)$"
VARIANT="^(board_type_duo|inp1bnc|inp1|inp1tripAOP|ana5V|inp2bnc|inp2|inp2tripAOP|ana5V|lvl1|lvl2|flw|flw240v|mot1|mot2|mot2pro|snubber|5vreg|screen5v|bridgesldb1|64k|vneg)"
VARIANT="^(board_type_pe|inp1screw|inp1|inp1tripAOP|ana5V|inp2screw|inp2|inp2tripAOP|ana5V|lvl1|lvl2|flw|flw240v|mot1|mot2|mot2pro|snubber|5vreg|screen5v|bridgesldb1|64k|vneg)$"
VARIANT="^(board_type_pro|inp1screw|inp1|inp1tripAOP|ana5V|inp2screw|inp2|inp2tripAOP|ana5V|bornier_lvl12_flw_clm|flw240v|mot1|mot2|mot2pro|snubber|1wireOnConn2|5vreg|screen5v|bridgesldb1|connextscl|oc_out|extheader|64k|vneg)$"
VARIANT="^(inp1bnc|inp1|inp1tripAOP|ana5V|mot1|noF1|board_type_star|button3|screen5v|bridgesldb1|64k|notvneg)$"
VARIANT="^(inp1bnc|inp1|inp1tripAOP|ana5V|mot2|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$"
VARIANT="^(inp1bnc|inp1|inp1tripAOP|ana5V|mot2|mot2pro|snubber|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$"
VARIANT="^(inp1screw|inp1|inp1tripAOP|ana5V|mot2|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$"
VARIANT="^(inp1screw|inp1|inp1tripAOP|ana5V|mot2|mot2pro|snubber|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$"
VARIANT="^(inp1|ana5V|5vjack|connexti2cwtb|connextscl_3v3|connextscl_5v|connscl|connscl_3v3|connscl_5Vnr|connspi|connspi_3v3|connspi_5Vnr|eeprom|esp32|extheader|extsigheader|inp1screw|inp2|inp2bnc|inp2screw|lvl1|lvl2|mcu.xtal32|mot1|mot800mA|mot8A|notvneg|rf|rtc|rtc.smallcap|rtc.supercap|smaconn|vneg|vrefzener|extrapowercap|clm|bornier_lvl12_flw_clm|screen5v|.*)$"
VARIANT="^(mot1|1wireOnConn2|connextscl|rtc|rtc.supercap|board_type_tp|button3|screen5v|bridgesldb1|64k|notvneg)$"

Another one for a display board coping with different types of LCD_16x02 display modules, some having connector on the side, some on the top, within those some with negative backlight drive others with GND backlight drive, I2C or parallel screen interface, internal negative voltage or external negative voltage, different possibilities of connectors:

--variant "^(parallScreen|screenSRow|K_neg|veeOut|proto)$"
--variant "^(i2cScreen|screenSRow|K_neg|veeOut|connRightSMD)$"
--variant "^(parallScreen|screenSRow|connUpSMD)$"
--variant "^(parallScreen|screenSide|conn2x03_1_27)$"
--variant "^(i2cScreen|screenSide|K_neg|conn2x03_2_54)$"
--variant "^(i2cScreen|screenRow|conn1x06_2_54)$"

I understand that currently the "variant" fields selects what gets included in the interactive BOM, but another way of doing things is to include everything and have columns indicate what is selected for the BOM. This way all components are in the interactive BOM.
There could even be a column for the DNP's (the opposite of what was selected by the variants).
Wheter all component should be in the interactive BOM or not could be determined with an options such as '--include-dnp'.
That way it's possible to mark all the locations that are not supposed to have a component and visually compare with the board.

[qu1ck]

Your examples are perfectly doable with variant whitelist as a list. Except the resulting BOM will not include components that are not on the list. That's the point of the BOM to not include things that are not on the board.

Again, what you are asking for is derived fields, I don't think this should be in ibom. Add whatever fields you want with whatever logic in eeschema.

That said, once template support is added you will be able to write a custom template with functionality to add derived fields dynamically in html.

[mdeweerd]

As you think that this should not be in ibom, I suppose that if I add it to the code, it will never get in the official distribution either?

If so, you can close this.

[qu1ck]

Not in the current form. I will accept it as a custom template in the future. You can follow #234 for when that gets implemented.

[set-soft]

Hi @mdeweerd !

KiBot can apply KiCost style variants to ibom. You can use KiBoM, IBoM or KiCost variants for all the supported tools.
And the KiBot filters allow a rich variety of filtering mechanisms.

[mdeweerd]

@set-soft Thanks for the heads-up. I'll have a look into KiBot. Only, the tool chain for adding interactivebom is a few MB, and the toolchain for KiBOT is close to 10GB. I checked out 'kicost-tools" the other day ;-).

The idea is not only adding KiCost style variants, but have all variants in a single HTML (with all the placements). It would be a single file to manage (not one file per variant) and help understand differences between variants, etc.

[set-soft]

why 10 GB @mdeweerd ? I guess you are counting a full Linux distro. In this case I could say you need 0 MB because you can run it on GitHub/GitLab CI/CD without even installing ;-)

[qu1ck]

Also wsl is a thing.

[mdeweerd]

Not really belongs ehre, but @set-soft I am trying kicad_auto now - managed to run it on windows and even get a ui. 3D models were excluded and probably not ubuntu, so only 771MB . That's find and I can probably link to the 3D Models on the native system. We'll see - in the respective projects.

[set-soft]

That's find and I can probably link to the 3D Models on the native system.

@mdeweerd note that usual usage is to:

1. Have a copy of the 3D models (also symbols and footprints are recommended) in the project. This ensures you'll get the same results even if KiCad changes something (which is too often for my taste).
2. Just let KiBot download the models from the KiCad's repo. Not a big problem for a fast internet connection and much more efficient for CI/CD environments.
   Of course you can use the KiCad models, but the above options are usually better.

[mdeweerd]

@set-soft

1. You are right about the models and that's what I try to do - at the same time I wonder about compatibility with the model's licenses. Maybe another job for KiBot: verify that all the models are in the project - copy them in and adjust the project if not?
2. Ok, but I'm not currenty using CI/CD for KiCad projects, and I "hate" having multiple copies of the same (big sized) data, and even more downloading it "often". Limiting ressource usage is a (small) gesture for the planet as well.

[set-soft]

Hi @mdeweerd !

1. You are right about the models and that's what I try to do - at the same time I wonder about compatibility with the model's licenses. Maybe another job for KiBot: verify that all the models are in the project - copy them in and adjust the project if not?

This is the feature I mentioned in INTI-CMNB/KiBot#279 ;-)