Skip to content
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.

Discrepency between S4.6 check and KCL S4.6 rules #285

Closed
JacobEFO opened this issue Jan 25, 2019 · 7 comments
Closed

Discrepency between S4.6 check and KCL S4.6 rules #285

JacobEFO opened this issue Jan 25, 2019 · 7 comments

Comments

@JacobEFO
Copy link
Contributor

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:
image

To me this seems like the script just checks all NC pins for visibility. But maybe this rule is a little ambiguous.

@poeschlr
Copy link
Collaborator

poeschlr commented Jan 25, 2019

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.

@JacobEFO
Copy link
Contributor Author

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?

@poeschlr
Copy link
Collaborator

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.

@JacobEFO
Copy link
Contributor Author

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?

@poeschlr
Copy link
Collaborator

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)

@poeschlr
Copy link
Collaborator

@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.

@JacobEFO
Copy link
Contributor Author

Everything is good here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants