gEDA-user: PCB paste layer, revisited.

[Dave N6NZ <n6nz@xxxxxxxx>]

To recap: I have been experimenting with making solder paste stencils 
from laser cut drafting mylar.  The current implementation of paste 
layers is not very flexible.  The paste stencils that result from my 
current workflow apply way too much solder (for various reasons).

So.... I've been noodling for some weeks about a better solution. 
Thoughts and questions below.

It seems to me that the simplest way forward that provides adequate 
flexibility is to add a "paste" directive to the footprint definition. 
It would be syntactically identical to the current "pad" directive that 
defines surface mount pads.  In the absence of *any* "paste" directive, 
*all* "pad" directives would create default "paste" information of 
identical dimensions.  If *any* "paste" directive is present, then *no* 
default "paste" information is created from "pad" directives.

Note that:
1) This is upward compatible with current footprints, with no surprises, 
since the current paste layer is simply a copy of the pad information.
2) Footprints with "paste" information can be script-o-matically down 
graded for backward compatibility by a simple 
sed/awk/perl/your-tool-here script that yanks out the "paste" directives.
3) The user has complete control over solder placement and volume, 
although there will be considerable interaction between the user's 
process and the dimensions in the paste directive.  What works for my 
el-cheapo laser cut 5 mil mylar may not be what you want to send to a 
fab house that uses a YIG laser to cut stencils in 3 mil stainless. 
Especially when you compare hand-squeegeed solder to robot-applied 
solder. Oh well.  I don't see an elegant solution, so I bias toward a 
simple solution.

Now my questions. I've spent a few minutes studying some slightly old 
sources, but I'm guessing that there are few architectural differences 
in the current release.

Adding the "paste" directive to the flex/bison parser seems simple and 
straight forward.  The question becomes what to do with it.  It appears 
to me that there is no paste information stored anywhere in the data 
structures, and that the current paste layer is simply a copy of the pad 
layer, and is produced at print-time.  Is this correct?

Assuming the above is correct, then it would seem that cloning the 
memory allocation, data structures, and support routines for pads would 
be straight-forward, perhaps tedious, but at least would present few 
architectural "gotcha's".    The idea being that we simply add paste 
information to every element in a way that parallels the current pad 
information.  Comments?

Other than carrying the paste information along, there isn't really much 
that needs to happen to it other than tweaking the print routines to now 
use the actual paste information instead of reading the pad information. 
  Correct?

I'm happy to work on a patch to add this functionality, but not having 
mucked around in the code, I would need some coaching, and would welcome 
help from someone who is familiar with the data structures and back end. 
  I can see my way clear to doing the flex and bison parts quite easily 
--  where I need help is how to tuck all the information away.

-dave


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user