Hi list, I have never designed more than double sided PCBs with KiCad, so I have never run into this. What happens to the layers of a footprint if I place a component on the bottom-side ? Are all the layers reversed, i.e., fronts means back and vice versa?
/Martijn On Nov 14, 2012, at 1:57 PM, Dick Hollenbeck <d...@softplc.com> wrote: > On 11/14/2012 12:10 AM, Chris Giorgi wrote: >> >> >> On Tue, Nov 13, 2012 at 7:57 PM, Dick Hollenbeck <d...@softplc.com >> <mailto:d...@softplc.com>> wrote: >> >> On 11/13/2012 05:33 PM, Chris Giorgi wrote: >>> Good afternoon, >>> >>> I've been glancing at this thread on&off for a while and have and have an >>> observation >>> and suggestion. >>> >>> A board has a distinct set of lamination layers: >>> Front >>> Inner 1 >>> : >>> Inner n >>> Back >>> >>> Each lamination may have one or more physical materials or operations: >>> Substrate, Copper, Adhesive, Solder Paste, Solder Mask, Silk Screen, >>> Drill, Place >>> Parts, Probe, etc... >> >> A real board does, yes. But in the software each of the above is a >> "layer", so the >> paradigm you are proposing does not match, nor does it help in the >> reduction of dope >> associated with pads, measured in total text length. >> >> In this thread, mostly we are trimming pad descriptions down with this, >> since we do not >> have padstack support. This *.kicad_pcb and *.kicad_mod effort now is >> merely a file >> format conversion, to improved readability. There is no change being >> made at this >> time to >> internal BOARD data structures as a result of this current work. >> >> >> Dick, >> I was suggesting only a consistent naming scheme for the (logical) layers >> based on the >> physical layering and materials. Internal representations would not need to >> change at >> all, and the resultant names are similar, if not identical to those >> suggested by Wayne >> in most cases. For conciseness and clarity, I would suggest types labeled >> "Cu", "Adh", >> "Paste", "Silk", "Mask", "Draw", "Cmnt", and "Edge". Symbolic layer >> positions include >> "F" or "Front" for the first defined (0), "B" or "Back" for the last defined >> (N), "I" or >> "Inner" followed by a number for 1 - (N-1), and "G" or "Global" for items >> not residing >> on a specific physical layer. >> >> "Front" -> "0.Cu" = "F.Cu" = "Front.Cu" >> "Inner1" -> "1.Cu" = "I1.Cu" = "Inner1.Cu" >> "Inner{n}" -> "{n}.Cu" = "I{n}.Cu" = "Inner{n}.Cu" >> "Inner14" -> "14.Cu" = "I14.Cu" = "Inner14.Cu" >> "Back" -> "15.Cu" = "B.Cu" = "Back.Cu" >> "Adhes_Back" -> "B.Adh" >> "Adhes_Front" -> "F.Adh" >> "SoldP_Back" -> "B.Paste" >> "SoldP_Front" -> "F.Paste" >> "SilkS_Back" -> "B.Silk" >> "SilkS_Front" -> "F.Silk" >> "Mask_Back" -> "B.Mask" >> "Mask_Front" -> "F.Mask" >> "Drawings" -> "G.Draw" >> "Comments" -> "G.Cmnt" >> "Eco1" -> "G.Eco1" >> "Eco2" -> "G.Eco2" >> "PCB_Edges" "G.Edge" >> >> Parsing would be very straightforward and the format I proposed would allow >> for very >> concise representations of more complex pad structures, such as a thermal >> via connected >> to the front, back, and 2nd and 4th inner copper ground layers in an 8 layer >> board -- >> eg. 0+I2+Inner4+Back.Cu . >> >> Parsing (wild stab): >> - Split at "." as L, T ( L="0+I2+Inner4+Back", T="Cu") >> - Handle wildcards in L, T. ("*" -> Array containing all defined values, >> skip tokenizer) >> - Tokenize L by replacing symbolic names with numeric identifiers ( >> L'="0+2+4+7" ) >> (First letter and number is unique) >> - If we have ranges, replace with included values (i.e. "0-2+4" -> >> "0+1+2+4"). >> - Dump into an array L'' = [0,1,2,4] >> - Treat T similarly (T' = "Cu") (i.e. "Eco1-3" -> "Eco1+Eco2+Eco3", >> "Mask1+2+Paste" -> >> "Mask1+Mask2+Paste"). >> - Lookup indices for T and dump into an array T'' = [5] >> - Iterate L'' and T'', marking each layer as a bit in a field, or however >> it's >> represented internally. >> (pseudocode: for (l in L'') { for (t in T'') { layers.setbit(layer[l][t]]) } >> ) >> >> In my opinion, the results would be concise, while remaining readable and >> possibly >> allowing for forward compatibility. Looking back at the above, I wonder if >> it might make >> more sense to reverse the order -- {Type}({Idx.})(.{LayerPosition}) -- >> giving us "Cu.F", >> "Adh.B", "Silk.Front", "Cu.3", "Eco1", "Cu.In2", and "Draw", which I find >> slightly more >> readable. > > > I finished my implementation last night. > > Really, the main win was simply *.Cu in through hole pads. > > The rest is just noise mostly, and what is not in the noise category is in > the arm waving > category. > > Submit a patch if you want it considered. I am back onto the layer manager > now. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp