Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Option to apply a variant to be used by the preflights #388

Open
jnavila opened this issue Feb 7, 2023 · 3 comments
Open

[FEATURE] Option to apply a variant to be used by the preflights #388

jnavila opened this issue Feb 7, 2023 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@jnavila
Copy link

jnavila commented Feb 7, 2023

Fill as much as you can, remove the rest

Describe the bug
When using variants for alternative population of functions, some output pins of alternative functions are tagged in contention error by ERC , but that would not happen for each variant.

To Reproduce
Create a schematic with 2 op-amps whose output are linked. Create variants which eliminates one of them. Enable erc in Kibot → you get an erc error.

Expected behavior
The erc should be performed for each variant, once each schematic has been processed. Reports of ERC errors should be per-variant.

Environment (please complete the following information):
Where are you running KiBot:

  • Using a docker image? kicad5_auto:1.2.0
  • Using a desktop system? Windows 11 and Linux ubuntu 22.04
@set-soft
Copy link
Member

set-soft commented Feb 7, 2023

Hi @jnavila !
I understand your problem, but is not that simple.
The preflight section, as its name says, is run before the outputs. So no variants are applied.
If you really need to run the ERC after variants I'll suggest doing this:

  1. Apply the variant to the schematic using sch_variant output
  2. In a separated run check the ERC of the generated schematic

You must understand that a config file could contain more than one variant, without a new option is impossible to determine the exact thing you want. To make things worst: changing the behavior is not a good idea.

BTW: I was thinking about some mechanism to create the SCH/PCBs for the variants and then apply the operations, so we don't generate them over and over, but some small details forces to generate them anyways. But could help with this.

@set-soft set-soft added the enhancement New feature or request label Feb 7, 2023
@set-soft set-soft changed the title [BUG] When using variant, the erc_check should be performed per-variant [FEATURE] Option to apply a variant to be used by the preflights Feb 7, 2023
@jnavila
Copy link
Author

jnavila commented Feb 7, 2023

Hi,

My config files contain several variants, that's the pain point, and obviously, my request does not fall into the preflight checks, but more on variant management. I don't think that the behavior needs to be changed, but more that an additional command be created once a variant has been instanciated.

Your last remark is very interesting. I usually generate multiple outputs for a given variant, and the types of outputs are the same across variants. Right now, I managed to prevent copy-paste by using yaml references, but this feels a bit odd because I would expect this feature to be described in the kibot language, not by a the yaml level workaround. Anyway, let me know how the enhancement goes.

Edit: fixed some typos.

@set-soft
Copy link
Member

set-soft commented Feb 7, 2023

Hi @jnavila !
Don't use copy & paste!
Try doing what I told you:

  1. Create one config file with all your variants/filter, preflights and outputs. But just one output for all the variants, lets say: just one BoM output.
  2. Include an sch_variant and pcb_variant, but with the run_by_default disabled.
  3. Run KiBot once for each variant asking to generate the variants.
  4. Run KiBot once for each variant asking to generate the outputs, passing the variant files.

You'll avoid repetition in the config file and get the preflights

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants