Runtime error with this test program ...

kicad_mod = Footprint('foo')
kicad_mod.append(Circle(center=[0, 0], radius=1.5, layer='F.SilkS'))
print(kicad_mod.getRenderTree())

render_strings.append(self.end_pos.render('(end {x} {y})'))
AttributeError: 'dict' object has no attribute 'render'

In Circle.py, end_pos is a dictionary, while center_pos is an instance of Point. Changing end_pos to be Point removes the error, but maybe there are reasons why it was a dict?

    def __init__(self, **kwargs):
        Node.__init__(self)
        self.center_pos = Point(kwargs['center'])
        self.radius = kwargs['radius']

        self.end_pos = {'x': self.center_pos.x+self.radius, 'y': self.center_pos.y}

        self.layer = kwargs.get('layer', 'F.SilkS')
        self.width = kwargs.get('width')

https://www.samtec.com/products/tsm

@evanshultz Bringing it over here from the kicad-footprints issues.

I've slightly modified the existing Harwin script that you found for similar pins.

Note I'm using windows with the bash shell provided by Git.

Here's where I'm at just trying to get it to spit something out

Greg@MEDUSA /d/kicad/kicad-footprint-generator/scripts/Connector/Connector_Samtec (samtec-tsm) $ python conn_samtec_tsm_sh.py
conn_samtec_tsm_sh.py:200: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  configuration = yaml.load(config_stream)
conn_samtec_tsm_sh.py:206: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  configuration.update(yaml.load(config_stream))
Traceback (most recent call last):
  File "conn_samtec_tsm_sh.py", line 210, in <module>
    gen_family(configuration)
  File "conn_samtec_tsm_sh.py", line 190, in gen_family
    gen_footprint(x, mpn.format(pincount=x), configuration)
  File "conn_samtec_tsm_sh.py", line 80, in gen_footprint
    orientation=orientation_str)
KeyError: 'mounting_pad'

See KiCad/kicad-footprints#1087.

Hey you guys.

I stumbled upon a lot of DFN packages looking like this:

In the DFN_QFN library, and I realized they were generated with the scripts here. It seems as if the way the scripts are made now, they generate the silkscreen marking the "highest" pin number instead of pin number 1.

Instead KLC states it should look somewhat like this:

according to http://kicad-pcb.org/libraries/klc/F5.1/

If need be, if have the fix ready for a PR. Although it is reasonably easy to fix (two minor changes).

@jkriege2, @hackscribble, @SchrodingersGat, @poeschlr

We are a small group of people which created most of the script generated parts inside KiCad. First of, thanks for using my stuff ^^.

In contrast to the framwork itself, I'm merging contributions into scripts with almost no review. Simply because most scripts are used mostly a few times by mostly the same people.

This results in some collection of code, where it's hard to use/change existing scripts, as well as the invention of scripts which get better placed into the framework itself (like the KLC definitions).

I would like to start a discussion about how much we can unify our development of scripts, to help new contributors as well as ourself.

The main proposal could be described as separate code and data. This is a main statement when talking about secure coding, but has other reasons as well. Everyone invented his system to get the data into the system. (I invented at least 3 different ones ^^). This means people can not simply use those data for other purposes (like generating 3d-models), and people are required to decrypt the way of data storage to push their own values into the system.

I added ModArgparser.py as my proposed fix for this problem into the framwork. Although no one really uses it right now beside me. This class would allow us to unify the external behaviour of all the scripts, means everyone can push data to it using .csv or .yml files. Furthermore, every script get's the same comandline interface, for interaction.

I would ask about your opinion about those problems, as well as what are you thinking about my proposal. I'm especially thinking about the usage of ModArgparser for 3d-file generation as well. This would allow us to use the same part definitions for both tasks.

Ubuntu 18.04lts, python 2.7.15rc1
manage.sh tests gives me:

FAIL: testChamferedRoundedPad (moduletests.test_kicad5_padshapes.Kicad5PadsTests)

Traceback (most recent call last):
File "/home/anders/Desktop/kicad-footprint-generator/KicadModTree/tests/moduletests/test_kicad5_padshapes.py", line 634, in testChamferedRoundedPad
self.assertEqual(result, RESULT_CHAMFERED_ROUNDED_PAD)
AssertionError: '(module chamfered_pad (layer F.Cu) (tedit 0)\n (descr "A example footprint")\n (tags example)\n (fp_text reference REF** (at 0 0) (layer F.SilkS)\n (effects (font (size 1 1) (thickness 0.15)))\n )\n (fp_text value chamfered_pad (at 0 0) (layer F.Fab)\n (effects (font (size 1 1) (thickness 0.15)))\n )\n (pad 1 smd custom (at 0 0) (size 3.646447 3.646447) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -1.5) (xy -1.5 -2) (xy 1.5 -2) (xy 2 -1.5)\n (xy 2 1.5) (xy 1.5 2) (xy -1.5 2) (xy -2 1.5)) (width 0))\n ))\n (pad 1 smd roundrect (at 0 0) (size 4 4) (layers B.Cu) (roundrect_rratio 0.25))\n (pad 1 smd custom (at 0 5) (size 2.292893 2.292893) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -0.5) (xy -1 -1.5) (xy 1 -1.5) (xy 2 -0.5)\n (xy 2 0.5) (xy 1 1.5) (xy -1 1.5) (xy -2 0.5)) (width 0))\n ))\n (pad 1 smd custom (at 0 5) (size 2.292893 2.292893) (layers B.Cu)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -1.25 0.25) (xy -0.25 -0.75) (xy 0.25 -0.75) (xy 1.25 0.25)\n (xy 1.25 -0.25) (xy 0.25 0.75) (xy -0.25 0.75) (xy -1.25 -0.25)) (width 1.5))\n ))\n (pad 1 smd custom (at 5 0) (size 2.292893 2.292893) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -0.5) (xy -1 -1.5) (xy 2 -1.5) (xy 2 0.5)\n (xy 1 1.5) (xy -2 1.5)) (width 0))\n ))\n (pad 1 smd custom (at 5 0) (size 2.292893 2.292893) (layers B.Cu)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -1.25 0.25) (xy -0.25 -0.75) (xy 1.25 -0.75) (xy 1.25 -0.25)\n (xy 0.25 0.75) (xy -1.25 0.75)) (width 1.5))\n ))\n)' != '(module chamfered_pad (layer F.Cu) (tedit 0)\n (descr "A example footprint")\n (tags example)\n (fp_text reference REF** (at 0 0) (layer F.SilkS)\n (effects (font (size 1 1) (thickness 0.15)))\n )\n (fp_text value chamfered_pad (at 0 0) (layer F.Fab)\n (effects (font (size 1 1) (thickness 0.15)))\n )\n (pad 1 smd custom (at 0 0) (size 3.646447 3.646447) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -1.5) (xy -1.5 -2) (xy 1.5 -2) (xy 2 -1.5)\n (xy 2 1.5) (xy 1.5 2) (xy -1.5 2) (xy -2 1.5)) (width 0))\n ))\n (pad 1 smd roundrect (at 0 0) (size 4 4) (layers B.Cu) (roundrect_rratio 0.25))\n (pad 1 smd custom (at 0 5) (size 2.292893 2.292893) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -0.5) (xy -1 -1.5) (xy 1 -1.5) (xy 2 -0.5)\n (xy 2 0.5) (xy 1 1.5) (xy -1 1.5) (xy -2 0.5)) (width 0))\n ))\n (pad 1 smd custom (at 0 5) (size 2.292893 2.292893) (layers B.Cu)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -1.292893 -0.207107) (xy -0.707107 -0.792893) (xy 0.707107 -0.792893) (xy 1.292893 -0.207107)\n (xy 1.292893 0.207107) (xy 0.707107 0.792893) (xy -0.707107 0.792893) (xy -1.292893 0.207107)) (width 1.414214))\n ))\n (pad 1 smd custom (at 5 0) (size 2.292893 2.292893) (layers F.Cu F.Mask F.Paste)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -2 -0.5) (xy -1 -1.5) (xy 2 -1.5) (xy 2 0.5)\n (xy 1 1.5) (xy -2 1.5)) (width 0))\n ))\n (pad 1 smd custom (at 5 0) (size 2.292893 2.292893) (layers B.Cu)\n (options (clearance outline) (anchor circle))\n (primitives\n (gr_poly (pts\n (xy -1.292893 -0.207107) (xy -0.707107 -0.792893) (xy 1.292893 -0.792893) (xy 1.292893 0.207107)\n (xy 0.707107 0.792893) (xy -1.292893 0.792893)) (width 1.414214))\n ))\n)'

Ran 45 tests in 0.087s

FAILED (failures=1)

Hello @pointhi

First of all just want to say that's a very nice job done here that help so much to create footprints :)

I was wondering why the repository was not part of the KiCad community ? I see several good reasons:

• better visibility for people submitting footprints, they often do not know the existence of this repository
• maintenance by all librarians, @poeschlr particularly is very good at this job. Today I realized that you were mandatory to merge the pull requests

However, maybe you have good reasons to not doing that ?

Cheers,
Joel

Edit: this will also permit to expend the management of labels we have to this repo. See also my propositions on this subject at KiCad/kicad-symbols#1368

There are loads of headers with this general description, dual row in my experience. It seems like a standard part and not manufacturer-specific, since loads of vendors make them.

For clarity about what I'm describing, here is a picture:

Are there footprints for any of these variants in the library? I confess that I don't see it, but I'm so surprised I feel I must be missing it. https://github.com/KiCad/Socket_Strips.pretty has something similar, but no shrouds or latches (just bare breakaway strips). If there are footprints and/or a script, I'd be obliged if someone can point me to it so I can cover all the common varieties. If there's nothing already, I'll start from scratch.

Here is my wish list (not every single combination exists in the market and would be created):

• Mounting: SMT, THT
• Pitch: 1.27mm, 2.00mm, 2.54mm
• Rows: 2
• Pin count (even only): 4-44, 50, 60, 64, 68, 80, 100, 110, 120
• Orientation: Straight, Angled
• Latch: With, without (default and unannotated in footprint name)

One last note: My gut is to generate them all from the script for simplicity and maintainability. Would that be an issue?

@pointhi @SchrodingersGat @poeschlr @jkriege2 @hackscribble

I have a few questions about the IDC header footprints:

1. Is there a script to generate them? An example footprint is IDC-Header_2x13_P2.54mm_Vertical_Lock.
2. The vertical footprints have large THT pads which aren't in the referenced datasheet.
3. The vertical footprints don't show the latch in the open position, which means any required keepout for any tall components or other elements near the PCB can't be easily found. I've seen this shown in silk on every PCB using this type of header I've ever seen.
   
4. The horizontal header is potentially even worse because no components can lay on the PCB (or near the edge if the connector doesn't hang totally off) and the open position of the latches aren't shown.
5. The horizontal is called Lock but it doesn't include latches in the drawing but only the shrouded header that can optionally support latches!
   
6. Latches come in various sizes, so the vertical and horizontal footprints may need a couple different footprints to cover short and long latches. Even if they vary a little bit, certainly a reasonable generic footprint could be created.
7. Using Lock seems like a poor word choice. Locking can be achieved with a ramp or other means for a similar connector, but latches are more specific to this type of lock. In other words, latches seem to me to be a subcategory of locks and we could be more specific in our footprint names.
8. Would it be best to reference a standard for these connectors? DIN 41651, I believe, is the standard for these connectors (but I don't have it to review).

Existing SO package generator includes mask information in 3D path. See KiCad/kicad-footprints#1441

IPC 7351B land patter naming shows three suffix letters to be placed at the end of the footprint name (except for BGAs) to indicate the density. They are:

• M: Most Material Condition (Level A)
• N: Nominal Material Condition (Level B)
• L: Least Material Condition (Level C)

We currently have built all footprints to Level B. I would like to introduce Level C for chips because it's quite useful to get vias closer to the pads, especially in high-dV/dt situations.

This issue is to try and figure out what the footprint names should be so the generator can be updated to suit the decisions here.

My first thought is to keep the existing footprint names and add _L to the end. It may conform best to IPC is the existing footprints end in _N, but IMO that's unnecessary as the nominal density can be considered the default condition and users would normally select it and consider the one with a suffix as some variation. Users who knew about IPC density levels and wanted more dense footprint are probably capable, especially with the improved descriptions we would need for our footprints, to find these footprints and use them.

Thoughts? I wouldn't be surprised if there's a better scheme but keeping some relationship to IPC's recommendation when building footprints to their standard seems prudent to me.

The doc mentioned above is widely available online, for example at http://ohm.bu.edu/~pbohn/__Engineering_Reference/pcb_layout/pcbmatrix/IPC-7x51%20&%20PCBM%20Land%20Pattern%20Naming%20Convention.pdf.

I'm just starting to dig into this repo since I wanted to create a few footprints and I like the idea of spripting it, so please forgive me if it's a silly question.

For a QFN script, which one is recommended ipc_dfn_qfn_generator.py or qfn.py?
Why are there two different ones?

Thanks!

@poeschlr
#385 showed that the script entry had two "minimum" statements and was missing the "maximum" one. The script could handle this gracefully.

Installing from PyPi fails with the following error:

> pip install -U KicadModTree                                                                                       
Collecting KicadModTree
  Downloading https://files.pythonhosted.org/packages/32/bf/03d74cafe091fa62cb7f96134b4ea9b32c3a328727e492fc362e263f2875/KicadModTree-1.0.3.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-Ppptc0/KicadModTree/setup.py", line 11, in <module>
        requirements = map(str.strip, open('requirements.txt').readlines())
    IOError: [Errno 2] No such file or directory: 'requirements.txt'

I'm running Python 2.7.15rc1 on Ubuntu 18.04.

When arguments inside the footprint contain spaces, we need to escape the string with ". this is currently done in a pretty sloppy way, and should be improved.

Probably caused: KiCad/Connectors_Molex.pretty#44

Hi,
i get following exception when i execute the example from the webpage or in the example directory.

I am using anaconda 4.3 (python 3)

Traceback (most recent call last):
File "./simpleFootprint.py", line 39, in
kicad_mod.append(RectLine(start=[-2, -2], end=[5, 2], layer='F.SilkS'))
File "/home/username/workspace/kicad-footprint-generator/KicadModTree/examples/../../KicadModTree/nodes/specialized/RectLine.py", line 84, in init
PolygoneLine.init(self, polygone=polygone_line, layer=kwargs['layer'], width=kwargs['width'])
KeyError: 'width'

Is the problem on my end?

Hi @pointhi

Would you mind if I made a copy of this repo on the /kicad/ github page? That way we can provide an officially maintained set of footprint scripts?

Cheers

I want to contribute the SOT762-1 package (which is despite it's name a QFN)

Note that the pin 1 is not placed in the corner as usual, but instead on the same side as pin 14. Is there a way to script it?

I'm trying to connect the Vishay_PowerPAK_1212-8_Single Drain Pad (custom pad) to one zone, but it never connects.

After to spend some time to understand why it didn't work, decided to edit the footprint and see the definition on "Local Clearance and Settings".
On Connection to Cooper Zones, the Pad connections is None. It only have two options None or Solid.

If go to normal pad without having Custom Shape says "From parent footprint".

How can fix it?

Pad has a keyword argument for solder_paste_margin_ratio, but that information is not propagated to the output file.

Acording to push
6722aac

scripts/Packages/Package_DFN_QFN/ipc_dfn_qfn_generator.py
Was updated

But if you look at
https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Packages

scripts/Packages/Package_DFN_QFN

Is not visible?

I want to do the Diode_SOT-553 from
https://www.diodes.com/assets/Datasheets/AH1806.pdf

with help of
Package_Gullwing__QFP_SOIC_SO\ipc_gullwing_generator.py

But I can not find any way to excluding pins, is it possible at all with this script ?

http://www.ti.com/lit/an/slma004b/slma004b.pdf
For this footprint one would want to repeat the thermal_vias statement.
one set of vias in the un-masked exposed-pad area (small diameter and dense grid)
another set of vias in the masked pad-area (large diameter and large grid)

is this possible currently? (I could not get it to work).
thanks.

I'm trying to make a script to new connector.

Did successful make smd pad and then pad with F.Paste with different sizes.
In the datasheet says "Recommended thickness of solder paste: 120um"
How can add in script?

KiCad v5 adds polygon pads. Will KiCadModTree support them?

The RectFill function produces an approximation, but with many lines and only in rectangular shapes. Even when it works, it's more clunky.

I'm just starting to check out the scripting tools, so forgive me if this is a stupid question.

After seeing my first footprint in KiCad, I noticed the silk layer was turned on. Looking at kicad_mod.py, I see that silk is indeed a layer generated for THT pads:

Is this correct? I would not expect silk to be a desired layer for THT pads.

If this needs to be corrected, I'm happy to submit a PR.

Right now the code climate stuff mainly complains about the testcases. Makes it hard to see where one could invest time to make something more maintainable. My suggestion would therefore be to add the test directory to its ignore list.

Those connectors went missing: https://github.com/KiCad/Connectors_Molex.pretty/blob/master/Molex_KK-41791-02_02x3.96mm_Straight.kicad_mod. Is this intentional? I added them back then. Should I submit them again or should I host them somewhere else? Those connectors are typically used in pinball.

@poeschlr
A few things with https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/SMD_chip_package_rlc-etc/size_definitions/size_default_chip_devices.yaml.

1. The tortai-tech.com link seems broken. I assume that was from IPC-SM-782? Perhaps a comment to indicate the document source, even if we can't find it available online?
2. SMD_0603 matches IPC-SM-782 sizes so I assume that was the reference. But for SMD_0805, the only significant deviation from the IPC doc is in terminator spacing. I suppose we could use the IPC spec for the other two dimensions and then just modify the terminator spacing to suit our needs (we both will recall the huge variation we found and the limits we placed on this parameter based on gathering data from parts in the market).
3. Here is the major issue that I found which caused me to make this issue: I'm concerned the generic SMD_0603, SMD_0805, etc. size definitions aren't specific enough. IPC-SM-782 shows different dimensions for chip resistors (page 72) and chip capacitors (page 76) which are NOT the same for the same body size. So instead of SMD_0603 should we have C_0603 and R_0603, and the same for other body sizes and part types?

If I'm right about the third item, it means that our footprints are using correct IPC calculations for fillet goals, but the body sizes that are an input to the IPC calculations could (should?) be more specific for different part types.

One example application would be a union of multiple polygons for creating courtyard areas. (Would make a lot of our generators easier if one could simply define some overlapping rectangles that are then combined to a polygon outline.)

I think shapely could fit our application.
Example regarding union of polygons: https://stackoverflow.com/questions/40385782/make-a-union-of-polygons-in-python-geopandas-or-shapely-into-a-single-geometr (geopanda the second lib mentioned there uses shapely as its geometric kernel.)

Maybe this can also be used for a better cutout generation but i have not yet looked into that. (Better cutouts could allow creation of top tented vias inside of an exposed pad. Better union could already help even with that application.)

I'm trying to use the generator scripts to produce a footprint for Texas' RGY/R-PVQFN-N20 used here, on page 42:

https://www.ti.com/lit/ds/symlink/tlc59108.pdf

Also note the pin number assignments. Is there a way to do that?

I started creating a generator (based on #236) for the PTDA series from Phoenix Contact.

If I look at scripts/Connector/Connector_PhoenixContact I can see variants of the manufacturer naming like "TerminalBlock_Phoenix", "Phoenix_Contact", "PhoenixContact" or even "Phoenix". Is there a rule or nomenclature for the manufacturers?

In addition, the connectors exist in various pin spacings, like the Altech connectors. Shall I create a separate yaml for the different pin spacings or use arrays for parameters which differ between different pin spacings?

The Hirose_DF63-1P-3.96DSA_1x01_P3.96mm_Horizontal footprint does not include the NPT hole as the connectors with more pins do. This is erroneous. It should include it, as the datasheet (page 3), but also the following picture, show.

Additionally, all the DF63 connectors currently in the library are named Horizontal, although they're actually the vertical parts. (their 'angled' counterparts would be the horizontal ones).

Would a patch be accepted, that adds the NPTH unconditionally (removing this line)?

With DIY-soldering fine pitch BGAs accurate placement can get tricky: you can't see the balls from the top and the only thing you can align against is the silkscreen - if it is even used. AFAIK the tolerances of the silkscreen aren't usually great, which could be an issue aligning a 0.4mm pitch BGA. Many sources suggest putting small dots or arrows onto the copper layer at at least two opposite corners of the packages as an alignment reference. (e.g. point 7 here )

It would probably be easy to extend the BGA script to generate a second version with a, say, "_mark" prefix which would be suitable for hand assembly by adding those marks.

I want to push a part to kicad-symbols which requires the R-PUQFN-N10 package.

As always, TI was creative with this one. If you look at the foorprint, the pins 5, 6, 7 ALL have different widths.

Is this thing scriptable in some way, would you prefer extending the script if not or should I just go ahead and make them manually?

The potentiometer, TO_SOT_THT, and diodes_THT scripts, and probably many others, are dramatically different in style from what I believe is the new/desired format using a YAML file for raw input data and a Python script that sucks in the YAML data and outputs footprints from it.

Examples of the new script style are bga.{py/yml] and ipc_dfn_qfn_generator.py/qfn.py and its associated YAML files.

This issue is simply to capture this and stand in as a place to capture old scripts if/when they're updated. The newer style described above is preferred and desirable, right?

Scripts to convert/rewrite:

• make_Diodes_THT.py
• TO_THT_packages.py / TO_SOT_THT_generate.py
• make_Potentiometer.py

BTW: The SMD potentiometer script doesn't put pin 1 at the top left, either.

I get:
$ python ipc_noLead_generator.py
File "ipc_noLead_generator.py", line 50
SyntaxError: Non-ASCII character '\xe2' in file ipc_noLead_generator.py on line 50, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

seems to be associated with square-root symbols in the source file.
would be nice if this script would work on a standard vanilla ubuntu/python install...

I'd like to contribute to the KiCad libraries and really like the idea of the generators. Even though I'm a longtime programmer, it's hard for me to dive in. I've read the KLC and inspected older and newer generator scripts (based on CSV and YAML). However, I did not find general coding rules and specifications for the generators or objects (symbols/footprints) to create - beside the KLC.

Are there some additional guidelines or are there just the sources? Am I free with the YAML files, as long as I use already used "keywords" or is there a YAML dictionary or specification?

Anyone working on creating a keep out area "module"?

If not, I was thinking of making one, using line intersection algorithm for any type of polygon shape

Mainly a reminder for myself.

Polygon pads in kicad do not support thermal zone connection. The standard option without specifying zone connection is none. For a KLC complaint generation of chamfered pads we would need to add support for the zone connect parameter to pads and select zone connect 2 for chamfered pads.

    def calculateBoundingBox(self):
        min = max = self.getRealPosition(self.nodes[0])

Is this correct, does not min and max become the same object,
and therefroe the min and max functions update "both" objects at the same time

should it not be?

    def calculateBoundingBox(self):
        min = self.getRealPosition(self.nodes[0])
        max = self.getRealPosition(self.nodes[0])

It seems that you can not add a list with attribute required false, that is

parser.add_parameter("size", type=list, required=False)

If size is not present in yml file you get the following error message

parser.run()
  File "C:\Users\stefan\KiCad\NyVersion\kicad-footprint-generator\scripts\Battery\..\..\KicadModTree\ModArgparser.py", line 134, in run
    self._parse_and_execute_yml(filepath)
  File "C:\Users\stefan\KiCad\NyVersion\kicad-footprint-generator\scripts\Battery\..\..\KicadModTree\ModArgparser.py", line 162, in _parse_and_execute_yml
    self._execute_script(**kwargs)  # now we can execute the script
  File "C:\Users\stefan\KiCad\NyVersion\kicad-footprint-generator\scripts\Battery\..\..\KicadModTree\ModArgparser.py", line 253, in _execute_script
    parsed_args[k] = type(v.get('default'))
TypeError: 'NoneType' object is not iterable

@poeschlr
I suspect the file at https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/Packages/Package_DFN_QFN/size_definitions/dnf.yaml should actually be named dfn.yaml.

Hi Thomas,

is there a workflow or a best practice how the develop a new generator module release it (pull request). And how to transfer the new footprints to the github repo?

I'd like to implement a generator for the molex sl connectors.
When my work on my fork is finished what to do?

I think I have to create a pull request for the new generator module.
If the pull request will be accepted then I can create a pull request for the kicad footprint repo (for this request a link to the generator module if required).
But what if my kicad pull request will receive some review comments. Then I have to make the modifications for the generator. Create pull request and so on.

Or do you make the review for the created footprints during the review of the generator module?

Is there a best practice / workflow how the make this changes in an easy way without creating a lot of work for a lot of people?

Thanks,
Richard

When you create a script based foot print with the following lines

f = Footprint(footprint_name)
s = footprint_name.replace('Valve_', 'Valve_Tube_')
f.append(Model(filename="${{KISYS3DMOD}}/Valve.3dshapes/{}.wrl".format(s), at=(0,0,socket_H)))

and socket_H is 11 even according to the foot print file

  (model ${KISYS3DMOD}/Valve.3dshapes/Valve_Tube_Noval_B9A-9_D25.50x11.00_P11.89_A36_RP.wrl
    (at (xyz 0 0 11))
    (scale (xyz 1 1 1))
    (rotate (xyz 0 0 0))

KiCad itself recalculate this into 279,4

Is this a known problem or should it be reported to the coders ?

It took me a few minutes to understand how to launch the scripts.
For reference, I copied the script in the root directory of the repo, and finally copied the KicadModTree/ to site-packages to be able to run any script anywhere.
I was searching for a way to properly install it, as any other module, but can't find anything.
Am I missing something or isn't there any way to correctly install this as a module at the moment ?

KiCad/kicad-footprints#1595 is an example where the latest checks by Travis are causing an error because the silk is mirrored around the X axis so the horizontal silk lines are split into a left and right part in all footprints.

There is a clear reason to split the lines if it will encounter copper, like this:

But there's no reason to split the lines on most of the footprints, for example this one:

This is happening because the points for the silk line are a polygon built up for the right side and then mirrored to the left side.

It should be possible to only do this when required (if the EP size sticks outside the silk line area) and otherwise use a single set of points for both sides. The real advantage is making the footprint files just a bit smaller. And possibly if there's a footprint not worth scripting because of complexity, the silk is a bit easier to manipulate if it's not split. (Making CI not whine is a side benefit and not a real advantage to me.)

I don't have time to look into this more right now but it shouldn't be too tough to implement.

I believe this applies to other generator scripts but I didn't look at them yet.

@poeschlr
KiCad/kicad-footprints#732 (comment)

I've been working on a fairly complicated footprint generator script. Part of this script utilizes the tree shown below.

+ Node
  * Translation [x: -27.25, y: -2.485]
    * Rotation [r: 180]
      * PolygoneLine [[x: -0.5, y: 0.5] ,[x: 0.0, y: 0.0] ,[x: 0.5, y: 0.5]]
        * Line (fp_line (start -0.5 0.5) (end 0 0) (layer F.Fab) (width 0.1))
        * Line (fp_line (start 0 0) (end 0.5 0.5) (layer F.Fab) (width 0.1))

However, attempting to rotate the PolygoneLine object produced an AttributeError:

Traceback (most recent call last):
  File "./QStrip_Vertical.py", line 300, in <module>
    generate_one_footprint(fp_params, config, args.library)
  File "./QStrip_Vertical.py", line 246, in generate_one_footprint
    KicadFileHandler(fp).writeFile(filename)
  File "kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/FileHandler.py", line 54, in writeFile
    output = self.serialize(**kwargs)
  File "kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/KicadFileHandler.py", line 103, in serialize
    sexpr.extend(self._serializeTree())
  File "kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/KicadFileHandler.py", line 143, in _serializeTree
    sexpr.append(self._callSerialize(node))
  File "/home/caleb/GitHub/kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/KicadFileHandler.py", line 161, in _callSerialize
    return getattr(self, method_name)(node)
  File "kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/KicadFileHandler.py", line 220, in _serialize_Line
    sexpr += self._serialize_LinePoints(node)
  File "kicad-footprint-generator/scripts/Connector/Connector_Samtec/../../../KicadModTree/KicadFileHandler.py", line 211, in _serialize_LinePoints
    ['start', start_pos.x, start_pos.y],
AttributeError: 'tuple' object has no attribute 'x'

After looking at the inner workings of KicadFileHandler.py, Translation.py, and Rotation.py, I found the source of the error: Rotation.getRealPosition() always returns a tuple, and many of the serialization methods expect Node.getRealPosition() to return a Vector2D object. However, if a rotation argument is included, getRealPosition() functions generally return a tuple containing the position and an angle in degrees.

For now, I made a minor modification to KicadFileHandler._serialize_LinePoints() that resolves my issue. However, it would probably be a good idea to make all getRealPosition() methods return a single type. I see several ways to do this:

• Change all rotation=None default parameters to rotation=0 and modify all _serialize methods to accept a tuple from getRealPosition().
• Several classes redefine getRealPosition() to return a dict. For instance, Translation includes this definition:

   translation_coordinate = {'x': parsed_coordinate.x + self.offset_x,
                             'y': parsed_coordinate.y + self.offset_y}
  

  Adding an 'r' or 'theta' element to such a dict (even if it is zero) would be inconsequential in cases where only the coordinates are required (Vector2D ignores the extra element), and it should be fairly easy to modify the _serialize functions that require the rotation.

Pad() allows pads with an empty string for the number parameter which gives unnumbered pads. This is used for NPTH pads. However, PadArray() doesn't support this because the initialPin variable must be an integer. It would be nice to support NPTHs with no number as an array.