kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/14/2012 08:11 AM, Martijn Kuipers (Private) wrote:
> 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


1) Footprints inside a BOARD.

2) Footprints inside a library.

3) Footprints exported.




1)-> they can be on F.Cu or B.Cu layers either.


2)-> Should always be represented in a "normalized" form.  a) no rotation, b) (at 0 0), c)....


3)-> Only the source code knows for sure, but it would be nice to have this one equal 2)
so you could simply copy the file into an s-expression (i.e. KICAD PLUGIN) library path.


Could still be discrepancies between the above theory and source code, call them bugs if
you want.






>
>
> 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
>
> _______________________________________________
> 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
>