kicad / kicad-library-utils Goto Github PK

It can easily happen when you are copying same parts of symbol.

• SIMPLE - check for g. elements with same points

or

• COMPLEX - find all overlapping lines no matter of what are they part of (polyline, rectangle), no matter of their length

What do you think?

Hi!

it seems the new scripts ahve some problems with pins that are unnamed (and therefore their names are set to ~). For these an EC01 error is reported.

Best,
JAN

Latest KLC rule 4.5.ii treats Vss as a negative power pin which, like ground pins, should be at the bottom of the symbol. The module rule4_5.py treats Vss as a positive power pin.

    def checkPowerPins(self):
        PWR = ['^[ad]*v(aa|cc|dd|ss|bat|in)$']
    
        first = True
        
        for pin in self.component.pins:
            name = str(pin['name'].lower())
            for pwr in PWR:
                if re.search(pwr, name, flags=re.IGNORECASE) is not None:
                    # Pin orientation should be "down"
                    if not pin['direction'] == 'D':
                        if first:
                            first = False
                            self.warning("Power pins should be placed at top of symbol")
                        self.warningExtra(pinString(pin))

I can work on a PR to move Vss to checkGroundPins() if that helps?

EDIT

Also, the script does not check for "V+" or "V-" which are mentioned in 4.5.i and 4.5.ii.

KiCad/kicad-library#774

it seems like the check_kicad_mod.py has a little bug with the orientation of square pads, because it throws an invalid error for some of my footprints, where no 6.5 violation is visible.

Furthermore, when using --fix it delets silkscreen, which would be overlapping the pad, when the pad would be orientated 90 degrees inclined, but not how I have inclined it in the footprint.

Footprint before --fix (purporsed violation of rule 6.5)

Footprint after --fix

Footprints can be found in this PR: KiCad/RF_Modules.pretty#1

I liked that option. May I ask the reason to remove it from both sch and pcb scripts? I can find where it was added around the middle of last year but I don't see any discussion or PRs about why it was removed.

When moving parts with script move_part.py symbol and documentation of main symbol is moved. Unfortunately documentation of all aliases remain in source dcm file.

Once this is fixed, checklib.py should be extended to check unused aliases. There could be a lot of them.

My symbol for the LPC1111FHN33-101 in nxp_armmcu.ib which was merged a few weeks ago has what I now realise is an invalid footprint filter (invalid because it includes the number of pins):

$FPLIST
 *QFN*32*
 *HVQFN33*
$ENDFPLIST

The symbol passes checklib.py with no errors or warnings.

The code in rule4_12.py includes this regex:

if re.search('(SOIC|SOIJ|SIP|DIP|SO|SOT-\d+|SOT\d+|QFN|DFN|QFP|SOP|TO-\d+|VSO|PGA|BGA|LLC|LGA)-\d+[W-_\*\?$]+', filter, flags=re.IGNORECASE) is not None:
    self.warning("Footprint filter '{filter}' seems to contain pin-number, but should not!".format(filter=filter))

BTW I will submit a PR to fix the filter.

Just cloned the repo and found two unstaged files in master branch (see below).

If I fork and create a feature branch to submit a PR, can I safely commit these two files, or do they need to be tidied up first?

Thanks.

ray@ray-Inspiron-7537:~/kicad-library-utils$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   schlib/autogen/R_NETWORKS/make_R_NET.py
	modified:   schlib/autogen/make_DIPSwitches/make_sw_dip.py

no changes added to commit (use "git add" and/or "git commit -a")

I'm designing a footprint for a TO-252-5-11 package (see images below). The footprint fails check_kicad_mod.py with a rule 6.4 violation.

Using the --fix option and comparing the resulting file with my original, it looks like the program calculates footprint centre based on the position of the centres of the pads. For this type of package (the tab pad is much wider than the pin pads), this doesn't seem to correctly interpret the KLC rule, assuming that one should treat the tab as a lead:

"Generally [the middle] is the centroid calculated with respect to the device lead ends"

Am I interpreting this correctly, and therefore can ignore this error?

Thanks.

Package

In X direction (red axis) distance from end of pins to end of tab is 9.98mm. Distance from left edge of pin pads to right edge of tab pad is 10.3mm. So I assume that package sits centred within pads with 0.3mm clearance on each side.

Draft footprint

When --fix parameter is used for checklib.py, library files are written in the end of processing. Resulting library is ok, but it has some differences in formatting. There are some whitespace changes but main problem are line order canges.
This behavior makes uneasy to spot real changes in commits.
It could be fixed in schlib.py which generates output.

Until it is fixed, I suggest open and save library in KiCad after --fix parameter usage.

I'll take a look on this.

When a component has alias the respective documentation is not removed from source and it is not placed to destination.

probably it would be a good idea, to throw warnings for possible errors in the footprint. For example, when the Annular ring is to small (which can cause production and solder issues):

http://www.ipc.org/committee/drafts/1-13_d_7251WD1.pdf

I had a multi-unit symbol with pins that were stacked. I accidentally mis-named the pins so they had different names. When I ran checklib.py I got this:

Looking at the rule file I was able to see this was likely because of stacked pins that did not have the same name. And indeed, after aligning the names the error went away.

This check works properly with single-unit symbols in my experience.

The function overpadsBounds() in kicad_mod.py returns incorrect results for many (all?) footprints where one or more of the pads has an integer value for X or Y size.

Fix is to add from __future__ import division to the module. I will raise a PR.

Details

Testing with the SOT-143 footprint from TO_SOT_Packages_SMD, pad 2 has the following attributes:

Position: -1.1, 0.95
Size: 1, 1.4
Orientation: 270

The orientation means that the "X" size relates to the Y direction on the footprint, and vice versa.

The program calculates the coordinates of the pad corners as:

-1.800000, 1.950000
-0.400000, 1.950000
-0.400000, 0.950000
-1.800000, 0.950000

The Y coordinates are +1 and -0 from the pad centre Y coordinate. They should be +0.5 and -0.5 from the centre.

-1.800000, 1.450000
-0.400000, 1.450000
-0.400000, 0.450000
-1.800000, 0.450000

Rule 10.5 says "Reference designator has a height of 2.0mm or smaller if needed and is placed on the fabrication layer."
check_kicad_mod.py reports an error if the reference is on the fabrication layer and reports no error if the reference is on the silk screen layer.
This should be corrected so that no error is reported if the reference designator is on the fabrication layer.

In components where there are two pins with number 1 (e.g. Buttons_Switches_ThroughHole/SW_PUSH_6mm), the script gives an error even if the anchor is on one of the pin 1s

Hey Travis familiar people

over at this PR Travis apparently disagrees with some text thickness
KiCad/Inductors_SMD.pretty#19

according to KLC the fab layer REFDES can have a text thickness down to 0.01 but looking here:
https://github.com/KiCad/kicad-library-utils/blob/master/pcb/rules/klc_constants.py
it looks like Travis only accepts down to 0.025.. should this simply be changed?

This is a very minor bug, but something that I'd like to get fixed at some point.

checklib.py sets up a printer object to print out deleted, added, and updated items. The KLC script sets up a /separate/ printer object to print the KLC violations. Because of this the script output can get jumbled a tiny bit, but nothing that is beyond mildly annoying.

• If there is exactly on FPFilter we should given an error message that the footprint field should be filled
• if FPFilter is empty and footprint field is filled, we should tell the user to give the FPFilter (I think this is already implemeneted)

Just an idea ;-)

JAN

sch.py generates Fields with extra space at the output, for example:

-F 0 "R207" V 7980 5800 50 0000 C CNN
+F 0 "R207" V 7980 5800 50  0000 C CNN

Note the two white space after "50". This does nothing wrong except that eeschema puts only one space there, and all the time I run my script I have a ton of diffs where only the extra whitespace is the difference.

Thanks,
Levente

In 99% cases, there should be no skipped pin numbers. It is problem for pin count filter in KiCad.
If pin is not used, Not connected pin type + invisibility is solution.

This check is so simple, It could be integrated to existing EC. (EC05 #29 ?)

If you agree, I'll create PR (new/integrate?).

At KiCad/LEDs.pretty#39 I submitted/fixed footprints to use a stencil design that is quite different from the pad design. I do not know if this was tried before.

Then at KiCad/Housings_QFP.pretty#19 Jan was quite right to ask if there's a way to reduce the number of KLC violations based on the current scripts from this footprint design.

This method does create a lot of errors but it generates footprints that match the datasheet and known good design practices. The scripts require a mask and paste layer to exist for each pad. This is unreasonable since it doesn't allow custom mask/stencil designs, but it was a reasonable place to start. I think we're at a place where we need to consider how to do it better.

Perhaps a better way would be to have the script accept either of two padstack styles:

1. A copper pad has mask and paste layers. This is the current behavior.
2. A number of pads with the same number, considered as a group, contains elements on copper, mask and paste layers? This would allow for the footprints which currently give us problems, where the stencil design is different than the copper/mask design.

I can still imagine errors with the second method, but they should be in a very small minority of footprints and eliminate the issues I linked above. Other ideas?

This may drive some changes to KLC, depending on what we find (like the stencil pads use the pin number or not), but let's first figure out how to construct and check footprints.

@jkriege2 can you shed some light on this:

checking module: QFN-16-1EP_5x5mm_Pitch0.8mm
  Violating Rule 6.6
    Courtyard line has a width 0.05mm. This line is placed so that its clearance is measured from its
    center to the edges of pads and body, and its position is rounded on a grid of 0.01mm.
      A courtyard clearance in the range 0.2...0.3mm was found, but 0.25mm was expected.
      The recommendet courtyard rectangle would be:
          {'x': -2.95, 'y': -2.95, 'width': 5.9, 'height': 5.9}mm.

The rule recommends corners at 2.95, corners are at 3.00 so the courtyard is at least enough.

Plus, 0.25mm IS in the range 0.2...0.3mm...

What's going on here?

The datasheet field of symbols seems to be no longer checked for emptines (KLC 4.9.iv)

Best,
JAN

The title pretty much sums it up. I don't think I am calling anything wrong. I need this feature to work to get some continuous integration code I am using to work.

Dear all (especially @SchrodingersGat @poeschlr @pointhi ),

I'm opening this issues to discuss a possible extension for the utils:
Currently we get a lot of errors for "simple" devices (R,C,CP,L,D,transistors, diodes, ...) for which we allow deviations from KLC (especially they don't have background-filled 10mil rectangles, pins may lie on 50mil grid ...). We could avoid these, if we can recognize such devices. Here are some ideas for heuristics (I think there is no definite way, unless we can somehow get a flag into the file-format, so heuristics is all we can get):

• 1-3 pins, maybe 4-pins (not sure ... transistors in SO-8 may have stacked pins, so actually counting pin-stacks might be the way)
• small size (say. max. size of a coil- or resistor-symbol x1.5-x2)
• pin-names invisible or besides the pin, not "inside" device-box
• special lib-names: device.lib, transistors.lib, diodes.lib (already opto.lib is mixed!)
• maybe a special tag/keyword simple-device as "definite" marker

One might make a decision on say matching 80% of such heuristic points ...

What do you think? If I get some input, I ight go ahead and try to get some first version coded with which we can experiment.

Best,
JAN

sch/test_sch.sh and pcb/test_kicad_mod.sh have the shebang as #!/usr/bin/bash"
Is there a reason for this? The "normal" path on almost all distros is /bin/bash

When trying to use schlib/checklib.py to check a single component, it fails with a Traceback. Adding the -v verbose flag causes it to behave as expected and give me the DRC errors. This is confusing since the help text for checklib states: -c COMPONENT, --component COMPONENT check only a specific component (implicitly verbose)

Example output without and with -v flag:

kenneth@thor:~/src/kicad-library/library$ ../../kicad-library-utils/schlib/checklib.py -c ATMEGA168A-AU ./atmel.lib 
Traceback (most recent call last):
  File "../../kicad-library-utils/schlib/checklib.py", line 68, in <module>
    if (args.verbose>2):
TypeError: unorderable types: NoneType() > int()

kenneth@thor:~/src/kicad-library/library$ ../../kicad-library-utils/schlib/checklib.py -c ATMEGA168A-AU -v ./atmel.lib 
Checking symbol 'ATMEGA168A-AU':
  Violating Rule 4.1 - Pin placement
    Pins must be placed on regular grid, and be of correct length
    Pins not located on 100mil grid:
     - Pin ADC7 (22), @ (-900, -350)
     - Pin (PCINT8/ADC0)PC0 (23), @ (1000, 250)
     - Pin (PCINT9/ADC1)PC1 (24), @ (1000, 150)
     - Pin (PCINT10/ADC2)PC2 (25), @ (1000, 50)
     - Pin (PCINT11/ADC3)PC3 (26), @ (1000, -50)
     - Pin (PCINT12/SDA/ADC4)PC4 (27), @ (1000, -150)
     - Pin (PCINT13/SCL/ADC5)PC5 (28), @ (1000, -250)
     - Pin ADC6 (19), @ (-900, -250)
     - Pin (PCINT14/~RESET~)PC6 (29), @ (1000, -350)
  Violating Rule 4.5 - Pin orientation
    Wherever possible, pins should be arranged by function
    Ground and negative power pins should be placed at bottom of symbol
    Positive power pins should be placed at top of symbol
  Violating Rule 4.6 - Pin types
    Pin electrical type should match pin function
    Pin types should match pin function
  Violating Rule 4.8 - Field text size
    Field text uses a common size of 50mils.
     - Pin (PCINT19/OC2B/INT1)PD3 (1), text size 40, number size 40
     - Pin (PCINT20/XCK/T0)PD4 (2), text size 40, number size 40
     - Pin GND (3), text size 40, number size 40
     - Pin VCC (4), text size 40, number size 40
     - Pin GND (5), text size 40, number size 40
     - Pin VCC (6), text size 40, number size 40
     - Pin (PCINT6/XTAL1/TOSC1)PB6 (7), text size 40, number size 40
     - Pin (PCINT7/XTAL2/TOSC2)PB7 (8), text size 40, number size 40
     - Pin (PCINT21/OC0B/T1)PD5 (9), text size 40, number size 40
     - Pin (PCINT22/OC0A/AIN0)PD6 (10), text size 40, number size 40
     - Pin AREF (20), text size 40, number size 40
     - Pin (PCINT16/RXD)PD0 (30), text size 40, number size 40
     - Pin (PCINT23/AIN1)PD7 (11), text size 40, number size 40
     - Pin GND (21), text size 40, number size 40
     - Pin (PCINT17/TXD)PD1 (31), text size 40, number size 40
     - Pin (PCINT0/CLKO/ICP1)PB0 (12), text size 40, number size 40
     - Pin ADC7 (22), text size 40, number size 40
     - Pin (PCINT18/INT0)PD2 (32), text size 40, number size 40
     - Pin (PCINT1/OC1A)PB1 (13), text size 40, number size 40
     - Pin (PCINT8/ADC0)PC0 (23), text size 40, number size 40
     - Pin (PCINT2/OC1B/~SS~)PB2 (14), text size 40, number size 40
     - Pin (PCINT9/ADC1)PC1 (24), text size 40, number size 40
     - Pin (PCINT3/OC2A/MOSI)PB3 (15), text size 40, number size 40
     - Pin (PCINT10/ADC2)PC2 (25), text size 40, number size 40
     - Pin (PCINT4/MISO)PB4 (16), text size 40, number size 40
     - Pin (PCINT11/ADC3)PC3 (26), text size 40, number size 40
     - Pin (PCINT5/SCK)PB5 (17), text size 40, number size 40
     - Pin (PCINT12/SDA/ADC4)PC4 (27), text size 40, number size 40
     - Pin AVCC (18), text size 40, number size 40
     - Pin (PCINT13/SCL/ADC5)PC5 (28), text size 40, number size 40
     - Pin ADC6 (19), text size 40, number size 40
     - Pin (PCINT14/~RESET~)PC6 (29), text size 40, number size 40

Hello, i found a curious bug in the rule 6.5 script.

It tells me that two of my silkscreen lines violate the rule even if i move them farther away than others.
Testfiles: (one with only the violating lines on f.silk the other one with all non violating lines.)
Testfiles.pretty.zip

Commit hash with the problem: e72a61a

I don't know is it right place for this issue.
Each module should contain reference in fabrication layer:
text field with name '%R'.
This is need for plotting assembly drawings.
This issue applies for all *.pretty repos

Hi!

in this PR: https://travis-ci.org/KiCad/kicad-library/builds/235958971?utm_source=github_status&utm_medium=notification I get several violation sof KLC 4.10 in Travis, although the data in the DCM is there and everything checks out OK on my local computer ... So I don't really have a clue, where this behaviour comes from ... maybe from the way the check-scripts are called by travis???

Best,
JAN

Checking SMD footprint with pcb check corrupt the file. I have a copy of the file if you want it.

add extra checking to checklib to verify if aliases have documentation, additionally create a script to populate them.

executing check_kicad_mod.py gives me the following error:

Traceback (most recent call last):
  File "./check_kicad_mod.py", line 11, in <module>
    from print_color import *
ImportError: bad magic number in 'print_color': b'\x03\xf3\r\n'

It seems to be a python3 error. python2 works fine. Using an older version of kicad-library-utils also works fine.

I'm on an x64 Antergos System (Arch based distribution)

As also the warning message

   missing datasheet, please provide a datasheet link if it isn't a generic component

suggests, for some general schematic components it's meaningless to provide datasheet, but the checklib.py scripts also sets the test failed if the description, keyword fields are properly set, and only the datasheet is missing. Instead it should print the warning (maybe even without -vv), but passing the test.

I get Violating Rule 9.6 Minimum annular ring error on attached footprint. The error is generated for circular pads with 2.0mm diameter and 1.0mm drill. If diameter is set to 1.99mm or to 2.01mm, no error occurs.

Here is what I get in console:

D:\some_path>python check_kicad_mod.py -v  d:\some_path\Cliff_UT1x_SPDT_ON-ON_Switch.kicad_mod
To print using colors you have to install colorama. Try to install it using: "pip install colorama"
[Continuing using no color mode]

Checking footprint 'Cliff_UT1x_SPDT_ON-ON_Switch':
  Violating Rule 10.4
    3D model reference
    No 3D model provided
  Violating Rule 9.6
    Minimum annular ring
    Pad 2 annular ring (0mm) is below minimum (0.15mm)
    Pad 4 annular ring (0mm) is below minimum (0.15mm)
    Pad 4 annular ring (0mm) is below minimum (0.15mm)

Cliff_UT1x_SPDT_ON-ON_Switch.zip

checklib.py  -vvv  --enable-extra library/device.lib

Traceback (most recent call last):
  File "/home/diggit/dev/kicad-library-utils/schlib/checklib.py", line 131, in <module>
    if ec.check():
  File "/home/diggit/dev/kicad-library-utils/schlib/rules/EC05.py", line 53, in check
    for i in range(1, max(pins.keys()) + 1):
ValueError: max() arg is an empty sequence

on kicad-library PR 742

Also fails for component with non numerical pin numbers like BGAs.

Error log from console:

To print using colors you have to install colorama. Try to install it using: "pip install colorama"
[Continuing using no color mode]

checking module: Connector_Mini-DIN_Female_6Pin_2rows
  Violating Rule 6.6
    Courtyard line has a width 0.05mm. This line is placed so that its clearance is measured from its
    center to the edges of pads and body, and its position is rounded on a grid of 0.01mm.
      A courtyard clearance in the range 0.25...1.0mm was found, but 0.5mm was expected.
      The recommendet courtyard rectangle would be:
          {'y': -5.05, 'x': -9.81, 'height': 14.05, 'width': 17.0}mm.
        REPLACING Courtyard with RECTANGLE with clearance 0.5mm on layer F.CrtYd
Traceback (most recent call last):
  File "check_kicad_mod.py", line 132, in <module>
    module.save()
  File "D:\MyProjects\kicad-library-utils\pcb\kicad_mod.py", line 829, in save
    f = open(filename, 'w', newline='\r\n')
TypeError: 'newline' is an invalid keyword argument for this function

I can fix this issue and create a pull request.

I would love to get the automated testing merged in to master so I don't have to worry about them diverging as much. I'll use this as a starting point to figure out a good way to do this. Feel free to chime in if you feel like something should change

The name of the game is to /only/ check symbols (footprints will come later) that have been changed in a pull request.

Diffs often don't include the full symbol source that has been changed which is annoying, but understandable. So we have to use some other way to figure out exactly which symbols were changed.

The way I have it set up to do this is by running checklib.py on the master, storing the output of that in a file, then running checklib.py on the pull request branch, and lastly I compare the output of the two. As long as no new errors were added I consider it a successful pull request and update the status.

It would be nice if instead it could just detect if a symbol had been changed and mark the pull request as failed if there are any errors on that symbol, whether or not the errors on it are new. It would likely be possible to do this in a similar way to how the errors are done now, where we parse all of the symbols on master and store those, then parse all of the symbols on the pr branch, and then compare. Not sure how much work this would require though.

Minor point: this will likely get moved to a different script called automatedtesting.py so checklib.py doesn't end up super cluttered.

The current setup can be seen on my kicad-library-utils mirror (http://github.com/reportingsjr/kicad-library-utils/)

I created a test library with a few errors that runs cleanly through checklib.py. Here are the known errors:

1. Two symbols with the same name (PART2).
2. A symbol with the same name as an ALIAS (PART1 and PART2).
3. Duplicated ALIAS entries (PART2).
4. An entry in the DCM which has no corresponding symbol (PART3).

Most glaring, when I try to load a library in KiCad I see the following:

This means that there is a error which KiCad is checking for that checklib.py isn't. A user could certainly think their library or updates are good when in fact there is a real problem.

There may be more errors I created which I overlooked, and there almost certainly are other pathological errors along these lines if we think harder.

Here is test.lib:

EESchema-LIBRARY Version 2.3
#encoding utf-8
#
# PART1
#
DEF PART1 U 0 20 Y Y 4 F N
F0 "U" 0 200 50 H V L CNN
F1 "PART1" 0 -200 50 H V L CNN
F2 "" -50 100 50 H I C CNN
F3 "" 50 200 50 H I C CNN
ALIAS PART1 PART2 PART2
$FPLIST
 DIP*W7.62mm*
$ENDFPLIST
DRAW
P 4 0 1 10 -200 200 200 0 -200 -200 -200 200 f
X V+ 4 -100 300 150 D 50 50 0 1 W
X V- 11 -100 -300 150 U 50 50 0 1 W
X ~ 1 300 0 100 L 50 50 1 1 O
X - 2 -300 -100 100 R 50 50 1 1 I
X + 3 -300 100 100 R 50 50 1 1 I
X + 5 -300 100 100 R 50 50 2 1 I
X - 6 -300 -100 100 R 50 50 2 1 I
X ~ 7 300 0 100 L 50 50 2 1 O
X ~ 8 300 0 100 L 50 50 3 1 O
X - 9 -300 -100 100 R 50 50 3 1 I
X + 10 -300 100 100 R 50 50 3 1 I
X + 12 -300 100 100 R 50 50 4 1 I
X - 13 -300 -100 100 R 50 50 4 1 I
X ~ 14 300 0 100 L 50 50 4 1 O
ENDDRAW
ENDDEF
#
# PART2
#
DEF PART2 U 0 20 Y Y 2 F N
F0 "U" 150 150 50 H V C CNN
F1 "PART2" 250 -150 50 H V C CNN
F2 "" 0 0 50 H I C CNN
F3 "" 0 0 50 H I C CNN
ALIAS PART1
$FPLIST
 DIP*W7.62mm*
$ENDFPLIST
DRAW
P 4 0 1 10 -200 200 200 0 -200 -200 -200 200 f
X V- 4 -100 -300 150 U 50 50 0 1 W
X V+ 8 -100 300 150 D 50 50 0 1 W
X ~ 1 300 0 100 L 50 50 1 1 C
X _ 2 -300 -100 100 R 50 50 1 1 I
X + 3 -300 100 100 R 50 50 1 1 I
X + 5 -300 100 100 R 50 50 2 1 I
X _ 6 -300 -100 100 R 50 50 2 1 I
X ~ 7 300 0 100 L 50 50 2 1 C
ENDDRAW
ENDDEF
#
# PART2
#
DEF PART2 U 0 20 Y Y 2 F N
F0 "U" 0 200 50 H V L CNN
F1 "PART2" 0 -200 50 H V L CNN
F2 "" 0 0 50 H I C CNN
F3 "" 0 0 50 H I C CNN
$FPLIST
 DIP*W7.62mm*
$ENDFPLIST
DRAW
P 4 0 1 10 -200 200 200 0 -200 -200 -200 200 f
X V- 4 -100 -300 150 U 50 50 0 1 W
X V+ 8 -100 300 150 D 50 50 0 1 W
X ~ 1 300 0 100 L 50 50 1 1 O
X - 2 -300 -100 100 R 50 50 1 1 I
X + 3 -300 100 100 R 50 50 1 1 I
X + 5 -300 100 100 R 50 50 2 1 I
X - 6 -300 -100 100 R 50 50 2 1 I
X ~ 7 300 0 100 L 50 50 2 1 O
ENDDRAW
ENDDEF
#
#End Library

And here is test.dcm:

EESchema-DOCLIB  Version 2.0
#
$CMP PART1
D 30V Vce, 100mA IC, Double NPN Transistors, Current mirror configuration, SOT-143
K Transistor Double NPN
F http://www.nxp.com/documents/data_sheet/BCV61.pdf
$ENDCMP
#
$CMP PART2
D 30V Vce, 100mA IC, Double PNP Transistors, Current mirror configuration, SOT-143
K Transistor Double PNP
F http://www.nxp.com/documents/data_sheet/BCV62.pdf
$ENDCMP
#
$CMP PART3
D Ferrite Bead
K Ferrite Bead
$ENDCMP
#
#End Doc Library

Why is the schlib/autogen folder in gitignore?
It currently holds symbol generator scripts.
Are the scripts in the wrong directory or is the gitignore file wrong?

The library checker for testing commited files has problems when aliases are defined for the components. (Error 3.8). Please fix.

I'm testing a footprint with check_kicad_mod.py. Using Python 2.7, it reports a courtyard error. Using Python 3.5, it reports no errors.

With which version(s) of Python is check_kicad_mod.py intended to be used?

Thanks

I was browsing sources and noticed, that verbose messages are generated in checklib.py script. This is kind of limiting, because each rule script returns just T/F. All additional info is specific for each rule and checklib.py must handle message for each rule separately.
I suggest:

• add verbose level argument into rule constructor (rule.py)
• add list of messages which will buffer verbose message from rule script (rule.py)
• add method for appending separate verbose messages into message list ^^ (rule.py)
• modify all rule scripts to compose verbose messages using that method^^
• modify checklib.py to pass verbose level to rule scripts and print message buffers after check() (this will be unified for all rules, so there will be no need to modify checklib.py for each rule script)

I can do this and give you PR. I just need to know, if you agree with this idea.

According to KLC 4.3.vi when pin stacking, when pins are output, all of the invisible pins should be identified as passive, while the visible one should be input. However, checklib.py reports this as an error due to there being different types of pins.

As described in this pull request, checklib.py -v -c G5LE-1 library/relays.lib on this commit results in:

Checking symbol 'G5LE-1':
  Violating Rule 4.10 - Part metadata
    Part meta-data is filled in as appropriate
    Component G5LE-1 has metadata errors:

But there is nothing further after the colon. This is not enough information for me to figure out what the error is.

Hi @SchrodingersGat !

Could you please have another look at the new script version and/or Travis-Integration? In some cases it seems to work
KiCad/TO_SOT_Packages_SMD.pretty#41
but here:
https://travis-ci.org/KiCad/kicad-library/builds/218111516
https://travis-ci.org/KiCad/kicad-library/builds/218111557
...
are some strange error messages.

Best,
JAN