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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
