There was a similar problem recently. The reason was that LibraryLink is for a footprint but for some reason it’s not applied to its pads. You have to use for example A.Parent == ‘REF**’ (but use a better refdes, of course).
That’s what I wanted to avoid. I’d prefer to create templates with rules specifying correct clearances for the footprints. Then one just has to place a mounting hole, that’s it. With A.Parent == … one has to manually rename each reference designator. It works, sure. But it’s not as elegant. More manual work and more options to screw things up.
Yes. The reason is: I asked two questions in the thread you linked to and I didn’t quite get an answer to the 2nd one. You suggestion worked, but I didn’t tell me what the issue with the rule is, which I want to know. So I thought it’s best to start a new thread about why the rule fails because the thread title didn’t really match the 2nd question. So here we are now.
@JeffYoung can comment on technical details. We have had discussions about this before. I’m not competent to talk about the implementation, but at least one problem is that the custom rules must be very efficient to run and they must work on the fly fast and without glitches. Therefore adding features and possibilities isn’t always feasible even when it would look simple.
It would help the end users if an item could reach its parent’s properties, like A.Parent.Library_link==… or A.Footprint.Library_link==… but this proposition wasn’t accepted at least right away.
But if you are willing to try more workarounds, there are some (else than grouping footprints in the board).
You can group pads in footprints and name the group. That name can be used in custom rules. This is different than using groups in board because you can create and modify the footprint in your personal library. When you use the footprint it automatically has the group in it and the same rule works automatically in all projects where the footprint is used. You can even have several different footprints which have their own groups with the same name, and the same rule is applied to all of them without using || condition.
You can also play with pad number (A.Pad_Number) which can have letters, or, if you use a corresponding symbol, pin number or pin name. One multipurpose ugly hack is to use “magic numbers”, i.e. change the pad’s size to something unique like 1.001 or 0.999 mm which isn’t used elsewhere.
If your only requirement is to write once and copy, one of these should be enough.
As eelik said, it’s not a bug, it’s a feature request. I’m not saying your use case is invalid, just want to frame it the right way.
In the rule system, when you type A.<something>, that <something> only will have an effect if it’s a valid property for the object type of A. This check happens at the time the rules are evaluated, because it is a check that happens per object being checked. This means you can write a perfectly valid rule (i.e. it passes the “check for errors” button, etc) that doesn’t match what you want it to match, because you are mixing up properties from two different objects.
In this case, the property Library_link is only valid when A is a footprint, because it’s a property of a footprint. But footprints have no copper clearance (they are just a container for other objects which might have copper) so the rule does nothing.
As eelik said, what you are asking about is a way to “reach in” to the object’s parent, when the object is a pad, and check if its parent has a certain property. This is a new feature that is not trivial to add. It would be helpful to add, but I want to frame it this way to set your expectations accurately – this isn’t a bug that can just be patched.
Thank you for the explanation. I now have a better understanding of why that rule fails.
Since I specified a copper clearance for an object not having copper clearance, KiCAD could theoretically flag is as invalid. But that’s another request and nothing I want to dive into right now.
Is there already a bug report / feature request for that? If there isn’t, I can create one and the devs can close the report I created previously (#16662) because –given your explanation– the request is ill-framed for that feature because it doesn’t cover the essence of the change.
No, I mean editing the library footprint in the footprint editor, not selecting pads from a board. You can test this by opening the footprint in the fp editor from a board by selecting a footprint → context menu → Open in Footprint Editor. Group pads there. Saving saves only that one instance in the board. For doing this universally you have to edit the library footprint and afterwards update the corresponding footprints in the board.
I don’t think there is one for this particular case right now. I would suggest editing your open issue rather than closing and re-opening a different one.
Are you sure your workaround in the issue (memberOfFootprint('library-id')) works? I think I tried it earlier with v8 RC1 and now I’m trying on another machine with a bit older 7.99 and don’t get it to work. I’m downloading RC1 here, too, and will try again soon.
Post script: ahh right will be fixedin RC3. sorry.
Hi Jeff. running rc2 . couldnt make it work. I think it just returns FALSE.
Is ‘library link’ (for the component in question) the same as ‘footprint id’ (in the doco) ?