← Back to team overview

kicad-developers team mailing list archive

Re: Plot and drill file generation via scripts



I've already done the SWIG magic to hook up FILE * to Python file like
objects.  It was about 5 lines in the SWIG files.  It works, today,
using my patch and drill.py.  This did not involve mmap, or rewriting
anything to think of files as strings.  I do not understand why you
think this would require changes to Kicad.  Can you explain your
reasoning behind that more?


Thank you.  I personally don't care if there is logic in the dialogs.
My opening email for this said, "If people want the logic out of the
dialogs, I volunteer to move it; if they want it to stay there, I
volunteer to watch this interface and keep the scripts working."  This
is almost one of those "guy dancing in the stairwell" moments.  If we
want to take the guy and teach him how to behave on the shop floor,
I'll show him the ropes and make sure he still behaves, but if we want
to keep him in the stairwell, I'll keep an eye on him and make sure he
doesn't escape.

Adam Wolf
Wayne and Layne, LLC

On Fri, May 3, 2013 at 1:35 PM, Lorenzo Marcantonio
<l.marcantonio@xxxxxxxxxxxx> wrote:
> On Fri, May 03, 2013 at 05:31:48PM +0200, Miguel Angel Ajo wrote:
>> I like your idea Adam, specially because you can change file for a stringio, and it could work..
>>     Lorenzo, what do you think?,
>>     do you like Adam refactor idea for the plot controller?
>>    I think it's important that we have similar interfaces at both sides, and also that we have a drill controller (hehe, my implicit meaning was more for Adam that for you) but if it's good if anyone gets it done.
> I suppose the stringio is something like a strstream... as I explained
> in the previous message it's not so trivial. To have a better idea of
> the issue behind this look at GERBER_PLOTTER::EndPlot,
> PDF_PLOTTER::EndPlot and PDF_PLOTTER::closePdfStream. In fact the PDF
> writer keeps open *two* files during plotting.
> As I already said you *could* rework everything to use something else
> instead of FILE* (like a wxMemoryOutputStream), but you'd need to wait
> anyway for the end of the plot. So just use a temporary file and slurp
> it (or mmap it, if possible) at the end. I think that the performance
> improvement is not worth the lot of work needed (also I don't know how
> to use wx streams:D). Maybe it's because I worked on mainframes but
> I like temporary files... You're free to do it if you want, it could be an
> interesting project (for someone else than me:P)
> As for the drill controller: there are more or less four phases:
> - Acquiring and sorting all the drills (no I/O, lot of data structures
>   working)
> - Outputting the actual drill file(s)
> - Outputting the drill map(s) (this would be done using the plotters)
> - Outputting the drill report
> The tricky thing is handling NPTH and blind/buried; I don't know is
> everything is already implemented (at a cursory look it seems so)
> because I never used blind or buried vias. Anyway the output should
> consist of (both of these both as excellon and drill map):
> - NPTH holes (the last drilling/milling pass)
> - THT holes (usual holes for 2 side boards)
> - Blind holes from top to each layer
> - Blind holes from bottom to each layer
> - Buried vias between adjacent layers
> I don't know if a function to customize each of these name would be
> useful; I'd vote no if asked (blind and burieds usually need a human
> operator on the fabrication side *and* you'll have to decide with him
> beforehand the board stacking).
> A somewhat useful function would be merging the NPTH and THT in one
> single drill tape (like pcbnew did before NPTH holes), since some
> fabricator require it (they then split the tape depending on the copper
> beneath).
> --
> Lorenzo Marcantonio
> Logos Srl
> _______________________________________________
> 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

Follow ups