kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/14/2012 12:10 AM, Chris Giorgi wrote:
>
>
> On Tue, Nov 13, 2012 at 7:57 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> 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.