RFC: Future of footprint wizard and generator

pointhi · September 14, 2018, 3:35pm

I did some new implementation for kicad-python: Building a proposal for an (official) high level python API

Basically, it’s a preliminary implementation which shows how footprint plugins could be handled. I will try to extend it to BOM-scripts, Action Plugins,… in the future as well to have all those things in a similar structure.

What’s different to the already present footprint generator? Well, it now supports CLI scripting which is very important for library management like it’s done in the official library. Actually, this work should replace my footprint generator framework https://github.com/pointhi/kicad-footprint-generator in long-term.

My current idea would be to have a new kicad-scripting repository with some structure like:

- CMakeLists.txt
- scripts
|- footprint_wizard_package_dip.py
|- footprint_wizard_package_sip.py
|- ...
- library
|- Package_DIP
  |- CMakeLists.txt
  |- package_dip.yml
  |- package_dip_handsoldering.yml
|- Package_SIP
  |- CMakeLists.txt
  |- package_sip_sharp.yml
  |- ...
- specs
|- KLC.yaml
|- IPC.yaml

In the scripts repository, all wizard scripts would be located. They can be used in the footprint wizard to give users the possibility to create new KLC compatible footprints from scratch using the GUI.

In the library folder, on the other hand, we have the same directory structure as in the official one. They contain footprint specification files like the ones which are heavily used in my kicad-footprint-generator project. The cmake scripts connect the specification files with the scripts together and would allow us to generate a library from scratch. If possible it should also support generating 3D-Models (I haven’t looked into this yet)

The specs folder would contain some definition files to alter the behaviour of the scripts. Namely naming convention, line width, courtyard distance,… I didn’t implement this yet, especially because I’m still not sure how those files should look like in the end. https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/tools/global_config_files shows how this stuff is currently handled in some scripts. Ideally, those definitions would change the default parameters of the wizard to avoid boilerplate code.

You can find the current wizard example in my kicad-python repo. You notice many TODO statements which should make it clear it is not ready for production yet. But it is able to execute and returns a footprint with ref and value.

github.com

pointhi/kicad-python/blob/master/examples/footprint_wizard/simple_footprint_wizard.py

#!/usr/bin/env python

from kicad.scripting import FootprintWizard, register_footprint_wizard


class ExampleWizard(FootprintWizard):
    def __init__(self):
        super(ExampleWizard, self).__init__()  # TODO: simpler design without super on current classname?

        self.name = 'Example Wizard'
        self.description = 'Example Wizard description'
        self.value = 'some_value'  # TODO: should be set in build_footprint

    def generate_parameter_list(self, params):
        params.add_parameter("Basic", "name", str, "Example_Footprint")  # TODO: float -> distance in mm
        params.add_parameter("Package", "width", float, 1)  # TODO: float -> distance in mm
        params.add_parameter("Package", "height", float, 2, designator='D')
        params.add_parameter("Package", "pad_width", float, 0.5)
        params.add_parameter("Package", "pad_height", float, 1)
        params.add_parameter("Package", "pad_spacing", float, 0.25, minValue=0.2)

This file has been truncated. show original

I would like to know what you think about this proposal. Furthermore, I would like to discuss some ideas how the python and yaml files should look like in the future. That’s the reason why the current stuff is so hacky. I would like to create some nice specification first and then do the real implementation.

Rene_Poschl · September 14, 2018, 4:14pm

For dimensions i would ensure the new toleranced dimension class is supported. (For now it lives in the ipc pad size calculator file found in the tools menu. We might want to move it someplace more central.) It has yaml parsing implemented (supports both my old way of adding dimensions and the new hierarchical one. For examples how they are defined look at the gullwing generator and its size definition files. The ssop yaml shows the new way of defining stuff in action.)

The problem i face in most cases is that rewriting any yaml file is a lot of effort. (and is error prone) This is why a lot of my stuff has backwards compatibility build in.

pointhi · September 14, 2018, 4:32pm

@Rene_Poschl, For dimensions, I would introduce a new Datatypes which simplifies things quite a bit. It would support ranges as well as units in a compact way:

body_size_x: 5.3
body_size_x: 5.3mm
body_size_x: 5.3mil
body_size_x: 5-5.6
body_size_x: 5-5.6mm
body_size_x: 5.3+-0.3
body_size_x: 5.3+-0.3mm

Rewriting could be automated as well. Simply read the parameters and output them in the new format. I would like to have a clean cut without legacy stuff in the new scripts.

Rene_Poschl · September 14, 2018, 4:40pm

would this also support entering something like min=5.2, max=5.4? A lot of datasheets give dimensions as min/max (plus optional nominal, if given it should be included as some IPC stuff uses nominal and some of it uses min/max. Especially important for non symmetrical tolerance ranges) so i would not rely on calculating the nominal plus tolerance by hand (very error prone. This was the reason why my original 0603 resistors where completely wrong)

pointhi · September 14, 2018, 4:42pm

such a custom type could support something like the following as well. It’s basically only a parser of the value field:

body_size_x:
- min: 5
  max: 5.6

SchrodingersGat · September 15, 2018, 2:00am

@pointhi I really like this idea - for a long time I have thought that there is a lot of duplication of effort between the footprint generators and the great work you have done with your scripts.

If you can get buy-in from the devs that’d be great. A high-level API would be very useful indeed.

pointhi · September 15, 2018, 9:22am

@Rene_Poschl, I wrote an initial proposal for the specification file:

layers:
- silkscreen:
  - layer: 'F.SilkS'
    line_width: 0.15
    line_length_min: 0.4
    text_size: [1, 1]
    text_thickness: 0.12
    pad_clearance: 0.2
    fabrication_offset: 0.11

- outline:
  - layer: 'F.Fab'
    line_width: 0.1
    text_size: [1, 1]
    text_thickness: 0.12
    pin1_marker_length: 1

- courtyard:
  - layer: 'F.CrtYd'
    offset: 0.25  # TODO: dependent on type of component
    grid: 0.01
    line_width: 0.05

- drawing:
  - layer: 'Dwgs.User'
    line_width: 0.12

- board_edge:
  - layer: 'Edge.Cuts'
    line_width: 0.12

references:
- layer: 'F.SilkS'
  position: 'top'  # top | inside | bottom
  text_size: [1,1]
  text_thickness: 0.15
- layer: 'F.Fab'
  position: 'inside'  # top | inside | bottom
  size:
  - min: [0.25, 0.25]
    max: [1, 1]

values:
- layer: 'F.Fab'
  position: 'bottom'  # top | inside | bottom
  text_size: [1, 1]
  fontwidth: 0.15

I’m still not sure how to specify rules depending on the footprint type (for example bga package, …) and how we should overwrite naming conventions. I think the easiest way would be to specify a (hierarchical) class like “package.bga” and set overwrites for them (courtyard, name as a format string, …):

overwrites:
- "connector":
    - courtyard:
      - offset: 0.5
- "package":
    - courtyard:
      - offset: 0.5
- "package.bga":
    - value: "BGA-{colums*rows}_{width}x{height}mm_Layout{rows}x{colums}"
      courtyard:
      - offset: 1

Another thing to think about is how to handle the rules in a way the programmer does not have to worry about them very much (boilerplate code). Default line width,… is easy to implement. But what about text position, courtyard distance,…?

Rene_Poschl · September 15, 2018, 1:24pm

The courtyard offset would come from the ipc specifier. (It not only depends on package class but also on density level. It might even be desirable to have larger courtyard for handsoldering variants. For the later maybe even different depending on direction.)

pointhi · September 15, 2018, 2:39pm

well, I try to solve all those possibilities with the specification file definition. We would then have IPC specification files for every density level, one KLC specification file for the KiCad library and people can write their own ones if required.

Rene_Poschl · September 15, 2018, 7:24pm

To be honest i would use command line options to select some of these things. For example the density level could very well be such an option (that is set to the middle density by default)

tolot27 · November 28, 2018, 7:48pm

That looks like a good starting point for me as a newbie.

system · February 26, 2019, 7:48pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.