search

markh-de / KiVar

PCB Assembly Variants for KiCad
MIT License
30 stars 0 forks source link

Allthough identical rules are formulated, one Component does not react as the others #51

Closed PerennialNovice closed 6 months ago

PerennialNovice commented 6 months ago

Describe the bug I have a board where several components are populated or not according to several rules. One of those components does not get unpopulated allthough the rules are identical for all components (copy-paste)

To Reproduce I could not reproduce it with a new KiCad-project. I use KiVar on several existing projects, but this is the only one with a problem

Desktop (please complete the following information):

Additional context I can confidentially share the project in question

markh-de commented 6 months ago

Please e-mail your project data (or a stripped down version that shows the problem) to: dev at markh dot de. I'll look into it.

markh-de commented 6 months ago

You have two reference designators "U6" in your design: One is the component that carries the rule string, the other one is your company logo.

Older versions (incl. 0.1.2, still being the latest stable release) only used the ref. des. internally to identify footprints. If you would have assigned rules to both U6 footprints, KiVar would have warned you that there are multiple footprints with same ref. des. and conflicting rules.

But in your case, KiVar reads rules for (some) U6, then calculates rules internally and finally assigns values and attributes to the other U6 (only having "U6" as a reference, and relying on the pcbnew API wrapper to find the right footprint instance). Unfortunately, pcbnew returns your company logo as the (first?) match. This is the moment where the computed values and attributes are assigned to the wrong footprint.

Hint: You can click the messages in the "Changes" section of the dialog. This focuses the selected part. In case of U6 this is your company logo. This is how I identified the problem very quickly (after being puzzled for a moment, I have to admit :smile:).

Knowing that there is nothing stopping users from assigning the same ref. des. to different footprints, I already changed this behavior a while back to use the footprints' UUIDs instead. The upcoming release 0.2.0 would have handled your situation gracefully.

PerennialNovice commented 6 months ago

oh dear ... sorry for bothering you

while I admit that using the UUID seems like the better way to go, I think it is the project creators task to not assign the same refs to two different things ...

Thank you for finding out so quickly (and thanks as well for KiVar, been using it only for a few days but I do already like it a lot)