| ID: | 138 |
| From: | ge...@igor2.repo.hu |
| Date: | Sun, 13 Nov 2016 05:53:02 +0100 (CET) |
| Subject: | Re: [pcb-rnd] parametric footprints |
| in-reply-to: | 136 from John Griessen <jo...@cibolo.com> |
| replies: | 141 from John Griessen <jo...@cibolo.com> |
On Sat, 12 Nov 2016, John Griessen wrote: > On 11/12/2016 01:42 PM, John Griessen wrote: >> 4. rows of square pads with paste are generated on top of the center pad, >> with specification for >> being sized from 1mm across to 2mm across with a pitch of 2mm. >> >> Here is some guideline info on qfns: >> >> http://ecosensory.com/geda/qfn_guidelines.png > > Beyond making qf.awk ready to use minimally, looking at this shows > how attributes-per-object of layout can go farther. > > If you created a new layer solderpaste that would allow fully following > guidelines for qfn. > Another way is add attributes per pad about what paste shrink or bloat is and > generate > past as a post processing layer of rs274-x pcb-rnd (and mainline) has a real bad layer support code. Copper layers are explicit: you can create, name and group them. But anything beyond that is an ugly hack: - the outline layer is really a copper layer and the code decides it's for the router by looking at the name(!) of the layer - there are always exactly two silk layers, they are always indexed as +1 and +2 after the last copper layer; this gets ugly when you change the number of copper layers; it's also impossible to have multiple silk layers on the same side (different colors) or remove silk layer (e.g. single sided board; the workaround is to delete some gerber files manually...) - the solder mask layer doesn't really exist at all; the mask is calculated on the fly; many output plugins are aware of the solder "layer", but it's always a hack - paste layer is even worse, it doesn't exist either, but only a few output plugins even care about paste - any extra, user defined layer is a hack: comment layers, layers for metadata (e.g. automated testing) are all copper layers for pcb-rnd - there's no way to tell the code it's not copper; this interferes when you accidentally connect two vias with a comment... I started a long term cleanup of this situation, because maintaining these hardwired hacks in the code is a nightmare and there's some user pull on editable solder mask layer. Some of the code already use the new layer API that doesn't make assumptions, but most of the code is not switched over yet. > > I like the idea of generating both soldermask and solderpaste from pads, vias > with attributes on them. > Seems better than having to learn to think of separately editing those layers. In some situations generating them is good, in other situations it's bad. If you generate layers and you need something done differently, you need to step back and change things indirectly. This often feels like a workaround. If you have explicit layers, you often need to draw (or generate) e.g. when creating a new footprint. Then if you want to make a global change on how these things are generated, it's harder if you already have a snapshot. I don't think either of the above two would be a clear winner. I am considering a setup where you simply have multiple solder mask layers: - one that is generated from the pads automatically - but this still would be an explicilty layer - one or two where you can manually draw openings or fillings (draw and erase) To produce a final output these layers would be merged. I'd probably do the same with paste. This method would keep the advantage of auto-generated pad masks/paste but would allow the user to randomly override it without any indirection. Like you figure you want your power line thicker with some extra solder, you could just draw a few lines over it on the "remove mask" layer. Or you do your first production run and turns out only one of the 6 qfn()s need more paste because of some via sucks away too much: you could go there and draw a drop of paste on the "add paste" layer, without having to change the footprint. > I don't seen any lihata name=vlaue pairs in the .pcb file yet. Is that coming > soon? pcb != lihata. We have support for distinct file formats, they don't mix. You either save in the gEDA/pcb format, and it will have 0 lihata in it, or you wave in the lihata board format. The attribute-for-every-object feature is available only in the lihata board format. There's no plan to extend the gEDA/pcb format in any way - we will track reasonable mainline changes, but we won't change that format from pcb-rnd. Regards, Igor2
Reply subtree:
138 Re: [pcb-rnd] parametric footprints from ge...@igor2.repo.hu
141 Re: [pcb-rnd] parametric footprints from John Griessen <jo...@cibolo.com>
142 Re: [pcb-rnd] parametric footprints from ge...@igor2.repo.hu