Discrepency between S4.6 check and KCL S4.6 rules
JacobEFO opened this issue · comments
I've come across a peculiar issue when running checklib on Converter_DCDC.lib. More specifically TC7662AxPA.
Its pin 6 (NC, electrical type: passive, non-visible) generates an error on S4.6.
However according to http://kicad-pcb.org/libraries/klc/S4.6/ NC pins can be set to invisible, but doesn't necessarily have to. However S4.6 rules from library-utils find pins named NC to be required to be invisible and electrical type: not connected, in order not to generate an issue.
When I resolved the issue I did like this:
To me this seems like the script just checks all NC pins for visibility. But maybe this rule is a little ambiguous.
Pins that are not intended to be connected must be set to invisible (and of course have the electrical type "not connected" assigned)
There is an exception for when datasheets suggest NC pins to be connected to ground or some other potential. Such exceptions can not be checked properly with the script. It will always require humans to say that in this case it is ok to violate the rule. It is expected that the contributor gives a detailed reason why they think a specific rule does not apply to their contribution.
Another problem is that the pin name NC can also mean something else than non connected. Again something where our script will always be limited.
And yes the wording of the rule should really change. (The person writing it wanted to sound polite. See: KiCad/kicad-website#289)
I will update that rule shortly to use much stronger wording.
Aha of course, this makes sense.
Your doc PR seems to clarify it quite well.
Isn't it hard to distinguish with the checklib script which symbols generating errors which are excepted from this rule?
This is why i also updated the template for new pull requests.
It now states the following:
Give a reason behind any intentional library convention rule violation.
Some things simply can not be done automatically. Luckily we humans have a powerful brain that can be used to make decisions in a flexible manner.
When things like this are able to be automated then we humans have successfully replaced ourselves. Not sure if i would want to live in a world where we humans have no place any more.
Naturally.
But running checklib.py on all the libraries with hundred of these exceptions, how do you keep control of which has an expection and which don't?
We generally do not run the script over libs just because we are funny. We use them to ensure that new additions are as good as they can be.
(Sorry for the late answer i was a bit absent for a few months and seem to have missed your followup question)
@JacobEFO i would assume this is resolved as well as it can reasonably be. If not re open it and clarify what you think can still be done.
Everything is good here.