kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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 is
> probably ok.
>  * Overloaded PLOT_CONTROLLER::OpenPlotfile so it will take a file extension.
> 
> 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 polish
> 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?


Adam,

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.

Dick