kicad-developers team mailing list archive
Mailing list archive
Re: Plot and drill file generation via scripts
Thanks. Let me know if there's anything I can do to help get this or
similar functionality built-in. Wayne and Layne volunteers to do any
desired refactoring to drill/plotting in order to reduce logic in the
dialogs and create a solid and small API. If this is something you want,
please note I am not an expert at C++, however, so I would greatly
appreciate an outline in order to increase the chances that the branch will
eventually be integrated.
I can't do much more with this functionality until after Maker Faire, so
May 20th or so, but I can answer emails and continue to test the Python
Wayne and Layne, LLC
On May 2, 2013 12:46 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx> wrote:
> On 05/01/2013 09:39 AM, Adam Wolf wrote:
> > Hi folks,
> > One of the tasks I've been doing for Wayne and Layne for Kicad is
> > command line plot and drill generation. Internally, we're going to
> > use it to generate files upon commit to better track progress in the
> > distributed team, but externally, we're working with a friend of ours
> > who runs a PCB order service. He usually takes gerbers and drill
> > files, but through his web interface, you can upload Eagle files and
> > it'll "do the right thing" and show you an automatic preview and
> > everything. We're trying to let him do the same for Kicad.
> > This required a few changes, and we've made what we think is the
> > minimal set of changes in Kicad to do this.
> > The patch is attached, and we believe it matches coding standards.
> > It's based off of r4123 from last night.
> > Quickly highlighting the changes we made:
> > * Added a few files to the scripting interface and a typemap so FILE
> > * in C++ turns into file objects in Python
> > * Moved GetGerberExtension to common_plot_functions.cpp. I tried
> > just exporting the plot file it was in, and had some issues.
> > * I moved the fclose outside of CreateDrillFile in
> > gendrill_Excellon_writer.cpp.
> > This was causing issues in Python. I added an fclose after each time
> > CreateDrillFile was called. You pass in a file handle, so I think this
> > probably ok.
> > * Overloaded PLOT_CONTROLLER::OpenPlotfile so it will take a file
> > Future work:
> > * There is a good amount of logic in the dialogs, for both plotting
> > and drill file generation. Because of this, I had to redo some logic
> > in the Python program. While there is more testing to be done before
> > I hand this off to the PCB order service, I'd like to minimize the
> > logic in python for this--if something changes in Kicad regarding
> > these files, like the recent NPTH/TH two file drill generation, I
> > would prefer the Python script to automatically "do the right thing".
> > However, I'm comfortable maintaining these scripts and watching for
> > regressions with each build--the Wayne and Layne build cluster already
> > does this for the Kicad packages.
> > * The scripts are not complete. Right now, they're mostly untested,
> > but they prove out the concept. Some of the arguments are unintuitive.
> > If you use the scripts provided, and they explode your computer,
> > I told you so. If there isn't serious pushback to the concept, I'll
> > the scripts up over the next few days and release them along with
> > their tests.
> > Please let me know if there's anything I can do to help this along.
> > What do you think folks?
> Thanks for your contributions to KiCad.
> Sorry I have not had time to look at this, but it is something of interest
> to me, just
> need some time.
> There is something about having scripts that, at least in theory, suggest
> being able to
> achieve a certain amount of consistency across runs.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp