markh-de / KiVar

PCB Assembly Variants for KiCad
MIT License
33 stars 1 forks source link

control text variables from KiVar #23

Open honzakutil opened 9 months ago

honzakutil commented 9 months ago

Is there any way, how to affect text variables by KiVar? It would be handy, if KiVar could somehow tell, which assembly variant is actually selected. Right now, I am using KiBot to automatically generate gerbers and assembly data from project. It could read text variables stored in project and use them as filenames for the outputs. I am used to name bom and pick-and-place data according to selected assembly variant. If KiVar could do this automatically, I would not need to set them manually, thus less work and less chance for my error.

markh-de commented 9 months ago

Again, I think you already read my comments in the source code. I would like such a feature very much. But it depends on a feature in the KiCad API, which is currently not yet implemented.

For the time being, we can use this ticket to discuss possible features to be implemented when the API is ready.

Step 1: Basic choice state variables

As a very basic feature, applying a set of choices should lead to a bunch of variables being created: ${KIVAR.CHOICE.<ASPECT>} = <CHOICE>. With this you could build a text item*, which carries the choices for each aspect you are interested in.

Step 2: Abbreviated codes

However, to cover the abbreviated variant naming feature that you wrote about in your e-mail, it would be very neat if each choice could be abbreviated with a code. These codes could be noted in a similar way as values applied to choices, e.g. ASPECT CHOICE1(c1) CHOICE2(c2) would output either c1 or c2 depending on the actual choice selection for that aspect. The resulting aspect codes would then be assigned to extra variables*.

* Currently, KiCad/pcbnew does not resolve text variables referenced by other text variables. So you could not use the resulting codes to assemble another text variable which you could use in different places of your PCB. Instead you would have to create text items that assemble the string themselves, by referencing each choice code.

For this second step, we would need to discuss where to place these abbreviation rules (in text variables, I would say). Also, compared to the first step, this feature is more complicated, so let's start with step 1 and see where we get.

A word about "choice states"

KiVar itself does not maintain information about the currently selected choices (which is part of the "stateless" concept). Instead, it computes the current state by analyzing and choice-matching each component.

So when KiVar would/will assign text variables after applying choices, you would/will start introducing some state information (even if only for the user). If the user later fiddles around with values and/or attributes, the actual state of the components may not match the choices displayed in the text variables anymore. Users must be aware of this.