kicad-developers team mailing list archive

["Martijn Kuipers (Private)" <martijn.kuipers@xxxxxxxxx>]

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 <dick@xxxxxxxxxxx> wrote:

> 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.
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp