kicad-developers team mailing list archive

[Francesco Del Degan <f.deldegan@xxxxxxxxxxx>]

On Sun, Apr 27, 2014 at 8:01 PM, jp charras <jp.charras@xxxxxxxxxx> wrote:

> Le 27/04/2014 10:11, Lorenzo Marcantonio a écrit :
> > On Sun, Apr 27, 2014 at 09:57:26AM +0200, Francesco Del Degan wrote:
> >
> >> After using kicad for some months, i decided to start to implement
> >> an IPC-7351 compliant footprint wizard that will cover several packages,
> >> listed in standard itself.
> >
> > Another one that bought the standard? nice:D
> > I did an explanation document a while ago if you need more informations
> > on the computation itself.
> >
> >> 1. implement the entire wizards and dialogs in C++, adding a starting
> >> button (New IPC Footprint wizard) in module editor.
> >
> > Noooo... foolish, we have python *and* a launchpoint for footprint
> > creation.
> >
> >> 2. Extend the python scripting footprint wizard, allowing choices-based
> >> (radio-buttons, dropdowns menus, etc) fields, dynamic parameters, and
> >> wxPython dialogs.
> >
> > That's the way to do it.
> >
> >> Consider that the dialogs would also display some help images (with
> >> standard reference quoting) and a small preview window that will change
> as
> >> soon as you change parameters or choices into the dialog itself.
> >
> > I.e. exactly all the others IPC wizards...
> >
> > Just a thing: it would be nice to use the JEDEC symbols instead of the
> > old IPC ones. The C revision is due to publish since something like june
> > of last year, and they seem to have adopted them too.
> >
>
> I confirm we have already a footprint wizard mechanism inside the
> footprint editor, which works fine.
> (you just need to use option -DKICAD_SCRIPTING=ON to compile Kicad)Ye
>

Yes, i already enabled all three scripting options (WX related also), and
digged the code a bit. I use daily builds compiled from source
code since several months.



> Wizard themselves (entirely written in Python) are outside the Kicad
> code and are plugins, called by the footprint editor.
> Few days ago, a contributor added wizards for DIP, QFP and BGA
> footprints, and some utilities to help writing wizards.
>

Yes, I will try to reuse the helper classes that was committed few days ago,
and fix some issues with it. (I just discovered that actual BGA footprint
uses all
26 letters, but only ABCDEFGHJKLMNPRTUVWY should be allowed) .



> Therefore:
> First, tell us more about the footprint types you want to add?

(IPC-7351 compliant footprint wizard has no meaning for me)
>

 Chip Resistor, Capacitor and Inductor
 Aluminum Electrolytic Capacitors
 Tantalum Capacitor
 Molded Inductor
 Wire Wound Inductor
 Molded Resistor, Diode
 TO Packages
 Oscillators and Chip Array’s
 QFN
 SOJ
 PLCC
 SOT
 MELF
 LCC
 CFP
 CQFP
 BGA
 QFP
 SQFP
 TQFP
 SOIC
 SOP
 TSOP
TSSOP

For naming a few, all with with A,B,C density levels (with  heel, toe  and
side fillet dimensions),
and the two zero orientation levels (A and B) like C revision of standard.
For some packages will be also the possibility to add local fiducial
points, and for BGA, also support
thermal, staggered and custom removal of pads (for custom pad patterns).

As Lorenzo suggested, i will try to use JEDEC dimension naming, and the
wizard will
suggest the footprint name like those suggested by standard.

Second, have a look at these wizards, and try to use the existing framework.
> (see pcbnew\scripting\plugins in Kicad sources)
> They are powerful (without radio-buttons, dropdowns menus), etc, and do
> not use wxPython.
>

Be careful with wxPython when it is used in Pcbnew: today we have some
> troubles with it:
> - It does not work on Windows (at least for me)
> - It has serious issues (crashes) (not yet fixed) on Linux.
> (I do not know the status on OSX)
>

I will look into it, i embedded (into C) and extended python since 8 years
now, so i will try
to do my best to look also at those issues.

I studied the entire work done by Miguel, in his original intent it was the
possibility
to add Action and File plugins also.

I'm also very interested, at the end, to bring python support more deeply
(and stable) into kicad itself

Thanks for the hints,
  Francesco