Location: https://gitlab.com/kicad/libraries/kicad-library-utils
kicad / kicad-library-utils Goto Github PK
View Code? Open in Web Editor NEWSome scripts for helping with library development
License: GNU General Public License v3.0
Some scripts for helping with library development
License: GNU General Public License v3.0
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.
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):
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.
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.
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?
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.
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.
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.
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'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
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
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.
Checking SMD footprint with pcb check corrupt the file. I have a copy of the file if you want it.
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.
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")
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
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.
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
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?
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
The library checker for testing commited files has problems when aliases are defined for the components. (Error 3.8). Please fix.
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.
Footprints can be found in this PR: KiCad/RF_Modules.pretty#1
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.
@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
I created a test library with a few errors that runs cleanly through checklib.py. Here are the known errors:
PART2
).PART1
and PART2
).PART2
).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
It can easily happen when you are copying same parts of symbol.
or
What do you think?
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:
I can do this and give you PR. I just need to know, if you agree with this idea.
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
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.
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.
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:
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.
Just an idea ;-)
JAN
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?).
When a component has alias the respective documentation is not removed from source and it is not placed to destination.
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
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.
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
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.
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.
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)
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.
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)
add extra checking to checklib to verify if aliases have documentation, additionally create a script to populate them.
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.
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
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
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
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):
device.lib
, transistors.lib
, diodes.lib
(already opto.lib
is mixed!)simple-device
as "definite" markerOne 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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.