Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

> I am back onto the layer manager now.

oops, footprint library table.

Pay no attention to anything I say, instead listen to what I mean.



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Martijn Kuipers]

On Wed, 14 Nov 2012 08:25:04 -0600
Dick Hollenbeck  wrote:

> >
> > 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)
> 
> oops,
> always on F.Cu for 2)
> 
> >
> >
> > 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.
> >
> >
> 
> 

Dick, thanks for the clarification and your efforts on KiCad.

/Martijn

___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

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

oops,
always on F.Cu for 2)

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


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Martijn Kuipers (Private)]

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  wrote:

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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Chris Giorgi]

On Tue, Nov 13, 2012 at 7:57 PM, Dick Hollenbeck  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.

~~~Chris Giorgi~~~
___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

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.




___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Chris Giorgi]

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

Each lamination may have optional engineering and documentation data:
Drawings, Comments, ECOs, Test Parameters, Thermal Profiles, and
whatnot.

Following the style proposed by Wayne, I suggest the following naming
scheme:

{Layer}.{Type}

Where:
  Layer is a symbolic name (such as Front, Inner1, Inner2, Inner{n}, Back),
a symbolic abbreviation (F, I1, I2, I{n}, B), or corresponding numeric
layer number (0 - {n}).
  Type is a concise symbolic identifier for a material or documentation
type: Sub, Cu, Adh, Paste, Mask, Silk, Drill, Part, Probe, ..., Draw, Cmnt,
Eco, etc.

An optional form of {Layer}.{Type}{n} would allow for multiple ECO, Silk
Screen, or other types on a given layer where it may be appropriate, while
still following the style.

Group selections take the form:
{Layer}.*  - All materials and documentation on a given
layer ( Front.* for the entire front layer in the stack)
{Layer}+{Layer}.*  - All materials and documentation on given layers
(F+B.* for everything on the front and back)
{Layer}-{Layer}.*   - All materials and documentation on range of
layers (0-6.* for the front and top 6 inner layers)


*.{Type}   - Given type on all layers (*.Cu for all copper
layers)
*.{Type}{n}   - Given specific type with index on all layers
 (*.Part3 for parts in 3rd stuffing procedure)
*.{Type}{n}+{n} - Given specific types with given indices on all
layers   (*.Eco1+4 for ECOs 1&4)
*.{Type}{n}-{n}  - Given range of specific types on all layers (
*.Silk1-3 for White, Red, and Yellow silk screens)

and all reasonable linear combinations of the above, subject to
existing internal restrictions, such as
{Layer}.{Type}{n}-{n}   - Given range of types on specific layer (
B.Eco1-5 for the first 5 ECOs on the back layer)

...just my thoughts, take them with a grain of salt.

   ~~~Chris Giorgi~~~


On Tue, Nov 13, 2012 at 9:36 AM, Wayne Stambaugh wrote:

> On 11/13/2012 10:16 AM, Dick Hollenbeck wrote:
>
>> The open issue of changing the non-copper names is best settled if we had
>>> a complete
>>>
>> list of proposed names to change to, and to make the determination if
>> this is worth the
>> disruption.
>>
>>
>> Aw oh.   I slept on it and woke up thinking about this as my first
>> conscious waking
>> thoughts this morning.  (Don't say it, I know I need to get a life, I've
>> been working on
>> that, for a lng time.)
>>
>>
>> As I attempt to show, I think there are some improvements in conciseness
>> possible
>> (conciseness = ratio of clarity to size), even in the copper layer naming.
>>
>>
>> I like the wildcard notion and wanted to be able to use it in a few other
>> places.  I also
>> noticed that "Inner3" does not explicitly say it is a copper layer.
>>
>>
>> Of course the value of the combos is the reduction in Pcbnew data file
>> size, and increased
>> speed of parsing.  (Would put the [combo] mask into the hashtable instead
>> of the layer index.)
>>
>>
>> Attached is my proposal and recommendation.
>>
>> I would say that the combos can be used even in *.kicad_pcb files where
>> they can.  Custom
>> layer names pertain to cu layers, and to tracks more than pads.  Here are
>> the heuristics:
>>
>>
>> a) if a combo can be recognized in a layerMask when Format()ing, then it
>> should be used,
>> in either BOARDs or MODULEs.
>>
>> b) otherwise, if saving a BOARD, then use the translated layer names.
>>
>> c) otherwise, if saving a MODULE, then use the untranslated english layer
>> names.
>>
>
> Your proposal makes sense to me.  I like the use of the wildcard search
> pattern to indicate multiple layers.  You might consider renaming *.SoldP
> to *.Paste for the solder paste layer if your going to use *.Mask for the
> solder mask layer.  It's a bit more consistent and solder is also implied
> in the case of *.Paste.
>
> Wayne
>
>
>
>>
>>
>>
>> __**_
>> 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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Wayne Stambaugh]

On 11/13/2012 10:16 AM, Dick Hollenbeck wrote:

The open issue of changing the non-copper names is best settled if we had a 
complete

list of proposed names to change to, and to make the determination if this is 
worth the
disruption.


Aw oh.   I slept on it and woke up thinking about this as my first conscious 
waking
thoughts this morning.  (Don't say it, I know I need to get a life, I've been 
working on
that, for a lng time.)


As I attempt to show, I think there are some improvements in conciseness 
possible
(conciseness = ratio of clarity to size), even in the copper layer naming.


I like the wildcard notion and wanted to be able to use it in a few other 
places.  I also
noticed that "Inner3" does not explicitly say it is a copper layer.


Of course the value of the combos is the reduction in Pcbnew data file size, 
and increased
speed of parsing.  (Would put the [combo] mask into the hashtable instead of 
the layer index.)


Attached is my proposal and recommendation.

I would say that the combos can be used even in *.kicad_pcb files where they 
can.  Custom
layer names pertain to cu layers, and to tracks more than pads.  Here are the 
heuristics:


a) if a combo can be recognized in a layerMask when Format()ing, then it should 
be used,
in either BOARDs or MODULEs.

b) otherwise, if saving a BOARD, then use the translated layer names.

c) otherwise, if saving a MODULE, then use the untranslated english layer names.


Your proposal makes sense to me.  I like the use of the wildcard search 
pattern to indicate multiple layers.  You might consider renaming 
*.SoldP to *.Paste for the solder paste layer if your going to use 
*.Mask for the solder mask layer.  It's a bit more consistent and solder 
is also implied in the case of *.Paste.


Wayne






___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Wayne Stambaugh]

On 11/12/2012 4:38 PM, Dick Hollenbeck wrote:

On 11/12/2012 12:19 PM, Wayne Stambaugh wrote:

On 11/11/2012 9:46 AM, Dick Hollenbeck wrote:

On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:

On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:

*Observations:*


a) Layernames should be in English always (in a footprint, not a board).


Once we go down this path, we can never change the English default layer names 
without
maintaining support for the current spelling of the ones you see now.

I knew this had the potential to be an issue when I designed the new
file format.  I am not opposed to going back to a hexadecimal bit mask
for layer definition.  Now would be the time to do it before we make the
new file format the default.  We would be trading human readability and
potentially unlimited layers (I'm not sure that is important) for a
smaller file size, faster layer parsing, and easier maintenance.  There
are sound arguments for both designs.  Internally Pcbnew layers are
still bit masks so the number of layers are limited to the integer size.
Any move to a layer stack would require major changes.  It does seem
that a hexadecimal bit mask is more appropriate given our current
design.  We can always move from a 32 bit to a 64 bit layer mask when
users start requesting more copper layers.

Wayne


The layering *order* in pcbnew is questionable, and something I've been arguing 
to change
for 4 years.  Therefore the hexadecimal numbering scheme is more likely to 
become obsolete
than is a well thought out English layer name.

I also don't think you have a speed problem parsing layer names.  We can get an
improvement using std::string in stead of wxString for the hashtable.   There's 
not a lot
of point in converting to wxString before doing compares or hash functions.   
But this is
MINOR.

When I load a *.kicad_pcb file now, it loads at about the same speed as a 
legacy load on
the same *large* board.

We do not have a problem.  I am in favor of staying with the current game plan, 
although
would be open to another look at English layer name *spellings*, NOW.   
Personally the
spellings seem clear, but I am not certain about conciseness, but don't take 
that as an
objection to current conciseness.   Practically, we may already be past the 
point where
they can be changed without disruption.

It shouldn't be a problem for legacy board files.  Only the copper layer
names are saved in the legacy format which are about as concise as you
can make them without abbreviating.  There shouldn't be too many sexpr
files around other than a few developers so if we are going to change
the English names, then now is the time.  I could see dropping the
underscores from the camel case names and drop the "PCB_" from
"PCB_Edges" since PCB is implied.  Another option is to drop the vowels
from the layer names so "SilkS_Back" becomes "SlkScrnBck".  In some
cases the name will not be any fewer characters but would be more
readable.  I'm assuming that by concise that you mean as short as
possible without any loss in readability.



Yes, "as short as possible without any loss in readability", is a concise 
definition of
concise.


Agree that copper names are now already optimal.


Extending your suggesting further, what about using a leading or trailing 'B' 
(=Back) or
'F' (=Front), rather than the suffix of Bck?

BSlkScrn
FSlkScrn
etc.

(These non-cu name changes, although improvements that I would enjoy, still 
leave me less
than 100% comfortable this late in the game.  I am concerned about how this 
propagates
into the layer manager user interface, where the user sets up his board names.  
Are you OK
with these names there too?  Don't remember if we have layer specific tool tips 
there, but
that would help.)


I also coded last night some support to compress the "all copper stack" found 
in through
hole pads into "*.cu", that is *.cu.
This 4 character sequence is about as concise as you can get there too.  This 
will have a
tremendous impact on reducing the size of through hole pads, and leaves the 
door open to
more copper layers down the road.  This simply means all cu layers.


The layer manager does have tool tips to describe each layer but I don't 
know how they are mapped to the actual BOARD layer.  If they are mapped 
by bit mask, then there should be no problem.  If they are mapped by the 
layer name (default or otherwise), then there could be issues.




Last night I also trimmed out the tstamps where not needed, but have not 
committed yet.

The open issue of changing the non-copper names is best settled if we had a 
complete list
of proposed names to change to, and to make the determination if this is worth 
the disruption.


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[jp charras]

Le 13/11/2012 16:16, Dick Hollenbeck a écrit :

The open issue of changing the non-copper names is best settled if we had a 
complete

list of proposed names to change to, and to make the determination if this is 
worth the
disruption.


Aw oh.   I slept on it and woke up thinking about this as my first conscious 
waking
thoughts this morning.  (Don't say it, I know I need to get a life, I've been 
working on
that, for a lng time.)


As I attempt to show, I think there are some improvements in conciseness 
possible
(conciseness = ratio of clarity to size), even in the copper layer naming.


I like the wildcard notion and wanted to be able to use it in a few other 
places.  I also
noticed that "Inner3" does not explicitly say it is a copper layer.


Of course the value of the combos is the reduction in Pcbnew data file size, 
and increased
speed of parsing.  (Would put the [combo] mask into the hashtable instead of 
the layer index.)


Attached is my proposal and recommendation.

I would say that the combos can be used even in *.kicad_pcb files where they 
can.  Custom
layer names pertain to cu layers, and to tracks more than pads.  Here are the 
heuristics:


a) if a combo can be recognized in a layerMask when Format()ing, then it should 
be used,
in either BOARDs or MODULEs.

b) otherwise, if saving a BOARD, then use the translated layer names.

c) otherwise, if saving a MODULE, then use the untranslated english layer names.


Sounds very good for me, and I like it.
Inner1.Cu seems better than 1.Cu (more explicit.).

The prefix gives an idea of the type of layers.

Therefore ( just to be more explicit, and usually there is not a lot of 
items on these layers):
Drawings, Comments, Eco1, Eco2 are something like user layers, and could 
be called something like:
usr.Drwgs (or u.Drwgs), usr.Cmts, usr.Ecox (x = 1, 2 and perhaps more in 
the future)

and, for consistency:  PCB_Edges  brd.Edges

Thanks.

--
Jean-Pierre CHARRAS


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

> The open issue of changing the non-copper names is best settled if we had a 
> complete
list of proposed names to change to, and to make the determination if this is 
worth the
disruption.


Aw oh.   I slept on it and woke up thinking about this as my first conscious 
waking
thoughts this morning.  (Don't say it, I know I need to get a life, I've been 
working on
that, for a lng time.)


As I attempt to show, I think there are some improvements in conciseness 
possible
(conciseness = ratio of clarity to size), even in the copper layer naming.


I like the wildcard notion and wanted to be able to use it in a few other 
places.  I also
noticed that "Inner3" does not explicitly say it is a copper layer.


Of course the value of the combos is the reduction in Pcbnew data file size, 
and increased
speed of parsing.  (Would put the [combo] mask into the hashtable instead of 
the layer index.)


Attached is my proposal and recommendation.

I would say that the combos can be used even in *.kicad_pcb files where they 
can.  Custom
layer names pertain to cu layers, and to tracks more than pads.  Here are the 
heuristics:


a) if a combo can be recognized in a layerMask when Format()ing, then it should 
be used,
in either BOARDs or MODULEs.

b) otherwise, if saving a BOARD, then use the translated layer names.

c) otherwise, if saving a MODULE, then use the untranslated english layer names.


Proposed default English layer name changes

The impetus of these changes is twofold:

1) lay the foundation of the combo abbreviations
2) bring clarity and conciseness


Old New Alternate
=   =   =
Front   F.Cu
Inner1  Inner1.Cu   1.Cu
Inner2  Inner2.Cu   2.Cu
Inner3  Innere.Cu   3.Cu
Inner4  Inner4.Cu   :
Inner5  Inner5.Cu
Inner6  Inner6.Cu
Inner7  Inner7.Cu
Inner8  Inner8.Cu
Inner9  Inner9.Cu
Inner10 Inner10.Cu
Inner11 Inner11.Cu
Inner12 Inner12.Cu
Inner13 Inner13.Cu
Inner14 Inner14.Cu
BackB.Cu
Adhes_Back  B.Adhes
Adhes_Front F.Adhes
SoldP_Back  B.SoldP
SoldP_Front F.SoldP
SilkS_Back  B.SilkS
SilkS_Front F.SilkS
Mask_Back   B.Mask
Mask_Front  F.Mask
DrawingsDrwgs
CommentsCmts
Eco11.Eco
Eco22.Eco
PCB_Edges   Edges


Laying the above building blocks, then paves the way for the following combos.
Special reserved names which indicate combos:

New Meaning

*.Cuall cu layers, used frequently in thru hole pads
F&B.Cu  front and back cu, sometimes needed in double 
sided SMD pads
*.Adhes front and back adhesive, used on double sided 
SMD pads
*.Mask  front and back solder mask, used most on all 
pads
*.SoldP front and back solder paste, used on most all 
pads

Of course the value of the combos is the reduction in Pcbnew data file size, 
and increased speed of parsing.

___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

On 11/12/2012 03:38 PM, Dick Hollenbeck wrote:
> On 11/12/2012 12:19 PM, Wayne Stambaugh wrote:
>> On 11/11/2012 9:46 AM, Dick Hollenbeck wrote:
>>> On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:
 On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:
> *Observations:*
>
>> a) Layernames should be in English always (in a footprint, not a board).
> Once we go down this path, we can never change the English default layer 
> names without
> maintaining support for the current spelling of the ones you see now.
 I knew this had the potential to be an issue when I designed the new
 file format.  I am not opposed to going back to a hexadecimal bit mask
 for layer definition.  Now would be the time to do it before we make the
 new file format the default.  We would be trading human readability and
 potentially unlimited layers (I'm not sure that is important) for a
 smaller file size, faster layer parsing, and easier maintenance.  There
 are sound arguments for both designs.  Internally Pcbnew layers are
 still bit masks so the number of layers are limited to the integer size.
Any move to a layer stack would require major changes.  It does seem
 that a hexadecimal bit mask is more appropriate given our current
 design.  We can always move from a 32 bit to a 64 bit layer mask when
 users start requesting more copper layers.

 Wayne
>>> The layering *order* in pcbnew is questionable, and something I've been 
>>> arguing to change
>>> for 4 years.  Therefore the hexadecimal numbering scheme is more likely to 
>>> become obsolete
>>> than is a well thought out English layer name.
>>>
>>> I also don't think you have a speed problem parsing layer names.  We can 
>>> get an
>>> improvement using std::string in stead of wxString for the hashtable.   
>>> There's not a lot
>>> of point in converting to wxString before doing compares or hash functions. 
>>>   But this is
>>> MINOR.
>>>
>>> When I load a *.kicad_pcb file now, it loads at about the same speed as a 
>>> legacy load on
>>> the same *large* board.
>>>
>>> We do not have a problem.  I am in favor of staying with the current game 
>>> plan, although
>>> would be open to another look at English layer name *spellings*, NOW.   
>>> Personally the
>>> spellings seem clear, but I am not certain about conciseness, but don't 
>>> take that as an
>>> objection to current conciseness.   Practically, we may already be past the 
>>> point where
>>> they can be changed without disruption.
>> It shouldn't be a problem for legacy board files.  Only the copper layer 
>> names are saved in the legacy format which are about as concise as you 
>> can make them without abbreviating.  There shouldn't be too many sexpr 
>> files around other than a few developers so if we are going to change 
>> the English names, then now is the time.  I could see dropping the 
>> underscores from the camel case names and drop the "PCB_" from 
>> "PCB_Edges" since PCB is implied.  Another option is to drop the vowels 
>> from the layer names so "SilkS_Back" becomes "SlkScrnBck".  In some 
>> cases the name will not be any fewer characters but would be more 
>> readable.  I'm assuming that by concise that you mean as short as 
>> possible without any loss in readability.
>
> Yes, "as short as possible without any loss in readability", is a concise 
> definition of
> concise.
>
>
> Agree that copper names are now already optimal. 
>
>
> Extending your suggesting further, what about using a leading or trailing 

oops, no "or trailing"

> 'B' (=Back) or
> 'F' (=Front), rather than the suffix of Bck?
>
> BSlkScrn
> FSlkScrn
> etc.
>
> (These non-cu name changes, although improvements that I would enjoy, still 
> leave me less
> than 100% comfortable this late in the game.  I am concerned about how this 
> propagates
> into the layer manager user interface, where the user sets up his board 
> names.  Are you OK
> with these names there too?  Don't remember if we have layer specific tool 
> tips there, but
> that would help.)
>
>
> I also coded last night some support to compress the "all copper stack" found 
> in through
> hole pads into "*.cu", that is *.cu.
> This 4 character sequence is about as concise as you can get there too.  This 
> will have a
> tremendous impact on reducing the size of through hole pads, and leaves the 
> door open to
> more copper layers down the road.  This simply means all cu layers.
>
> Last night I also trimmed out the tstamps where not needed, but have not 
> committed yet.
>
> The open issue of changing the non-copper names is best settled if we had a 
> complete list
> of proposed names to change to, and to make the determination if this is 
> worth the disruption.
>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https:/

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

On 11/12/2012 12:19 PM, Wayne Stambaugh wrote:
> On 11/11/2012 9:46 AM, Dick Hollenbeck wrote:
>> On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:
>>> On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:
 *Observations:*

> a) Layernames should be in English always (in a footprint, not a board).

 Once we go down this path, we can never change the English default layer 
 names without
 maintaining support for the current spelling of the ones you see now.
>>> I knew this had the potential to be an issue when I designed the new
>>> file format.  I am not opposed to going back to a hexadecimal bit mask
>>> for layer definition.  Now would be the time to do it before we make the
>>> new file format the default.  We would be trading human readability and
>>> potentially unlimited layers (I'm not sure that is important) for a
>>> smaller file size, faster layer parsing, and easier maintenance.  There
>>> are sound arguments for both designs.  Internally Pcbnew layers are
>>> still bit masks so the number of layers are limited to the integer size.
>>>Any move to a layer stack would require major changes.  It does seem
>>> that a hexadecimal bit mask is more appropriate given our current
>>> design.  We can always move from a 32 bit to a 64 bit layer mask when
>>> users start requesting more copper layers.
>>>
>>> Wayne
>>
>> The layering *order* in pcbnew is questionable, and something I've been 
>> arguing to change
>> for 4 years.  Therefore the hexadecimal numbering scheme is more likely to 
>> become obsolete
>> than is a well thought out English layer name.
>>
>> I also don't think you have a speed problem parsing layer names.  We can get 
>> an
>> improvement using std::string in stead of wxString for the hashtable.   
>> There's not a lot
>> of point in converting to wxString before doing compares or hash functions.  
>>  But this is
>> MINOR.
>>
>> When I load a *.kicad_pcb file now, it loads at about the same speed as a 
>> legacy load on
>> the same *large* board.
>>
>> We do not have a problem.  I am in favor of staying with the current game 
>> plan, although
>> would be open to another look at English layer name *spellings*, NOW.   
>> Personally the
>> spellings seem clear, but I am not certain about conciseness, but don't take 
>> that as an
>> objection to current conciseness.   Practically, we may already be past the 
>> point where
>> they can be changed without disruption.
> It shouldn't be a problem for legacy board files.  Only the copper layer 
> names are saved in the legacy format which are about as concise as you 
> can make them without abbreviating.  There shouldn't be too many sexpr 
> files around other than a few developers so if we are going to change 
> the English names, then now is the time.  I could see dropping the 
> underscores from the camel case names and drop the "PCB_" from 
> "PCB_Edges" since PCB is implied.  Another option is to drop the vowels 
> from the layer names so "SilkS_Back" becomes "SlkScrnBck".  In some 
> cases the name will not be any fewer characters but would be more 
> readable.  I'm assuming that by concise that you mean as short as 
> possible without any loss in readability.


Yes, "as short as possible without any loss in readability", is a concise 
definition of
concise.


Agree that copper names are now already optimal. 


Extending your suggesting further, what about using a leading or trailing 'B' 
(=Back) or
'F' (=Front), rather than the suffix of Bck?

BSlkScrn
FSlkScrn
etc.

(These non-cu name changes, although improvements that I would enjoy, still 
leave me less
than 100% comfortable this late in the game.  I am concerned about how this 
propagates
into the layer manager user interface, where the user sets up his board names.  
Are you OK
with these names there too?  Don't remember if we have layer specific tool tips 
there, but
that would help.)


I also coded last night some support to compress the "all copper stack" found 
in through
hole pads into "*.cu", that is *.cu.
This 4 character sequence is about as concise as you can get there too.  This 
will have a
tremendous impact on reducing the size of through hole pads, and leaves the 
door open to
more copper layers down the road.  This simply means all cu layers.

Last night I also trimmed out the tstamps where not needed, but have not 
committed yet.

The open issue of changing the non-copper names is best settled if we had a 
complete list
of proposed names to change to, and to make the determination if this is worth 
the disruption.


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Wayne Stambaugh]

On 11/11/2012 9:46 AM, Dick Hollenbeck wrote:

On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:

On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:


*Observations:*


a) Layernames should be in English always (in a footprint, not a board).



Once we go down this path, we can never change the English default layer names 
without
maintaining support for the current spelling of the ones you see now.

I knew this had the potential to be an issue when I designed the new
file format.  I am not opposed to going back to a hexadecimal bit mask
for layer definition.  Now would be the time to do it before we make the
new file format the default.  We would be trading human readability and
potentially unlimited layers (I'm not sure that is important) for a
smaller file size, faster layer parsing, and easier maintenance.  There
are sound arguments for both designs.  Internally Pcbnew layers are
still bit masks so the number of layers are limited to the integer size.
   Any move to a layer stack would require major changes.  It does seem
that a hexadecimal bit mask is more appropriate given our current
design.  We can always move from a 32 bit to a 64 bit layer mask when
users start requesting more copper layers.

Wayne



The layering *order* in pcbnew is questionable, and something I've been arguing 
to change
for 4 years.  Therefore the hexadecimal numbering scheme is more likely to 
become obsolete
than is a well thought out English layer name.

I also don't think you have a speed problem parsing layer names.  We can get an
improvement using std::string in stead of wxString for the hashtable.   There's 
not a lot
of point in converting to wxString before doing compares or hash functions.   
But this is
MINOR.

When I load a *.kicad_pcb file now, it loads at about the same speed as a 
legacy load on
the same *large* board.

We do not have a problem.  I am in favor of staying with the current game plan, 
although
would be open to another look at English layer name *spellings*, NOW.   
Personally the
spellings seem clear, but I am not certain about conciseness, but don't take 
that as an
objection to current conciseness.   Practically, we may already be past the 
point where
they can be changed without disruption.


It shouldn't be a problem for legacy board files.  Only the copper layer 
names are saved in the legacy format which are about as concise as you 
can make them without abbreviating.  There shouldn't be too many sexpr 
files around other than a few developers so if we are going to change 
the English names, then now is the time.  I could see dropping the 
underscores from the camel case names and drop the "PCB_" from 
"PCB_Edges" since PCB is implied.  Another option is to drop the vowels 
from the layer names so "SilkS_Back" becomes "SlkScrnBck".  In some 
cases the name will not be any fewer characters but would be more 
readable.  I'm assuming that by concise that you mean as short as 
possible without any loss in readability.


Wayne




Dick



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[jp.charras (Wanadoo)]

Le 11/11/2012 15:39, Dick Hollenbeck a écrit :

On 11/11/2012 07:43 AM, Wayne Stambaugh wrote:

On 11/10/2012 11:09 PM, Dick Hollenbeck wrote:

OK, I got a footprint library to convert from legacy to kicad format using the 
attached
command line python script.
It ran nicely, and quickly, without a fuss once I get it setup correctly.


Procedure I used, which is perhaps not optimal, but is one that worked:
(I'm open to suggestions on improvement.)


1) Build target _pcbnew after enabling scripting in cmake.
$ make _pcbnew


2) Changed dir to pcbnew
$ cd pcbnew
$ pwd
build/pcbnew



3) Entered following command line, script takes to arguments: oldLibPath & 
newLibPath
$ PYTHONPATH=. ../lib_convert.py /usr/local/share/kicad/modules/smd_dil.mod 
/tmp/smd_dil


4) inspect one footprint found in new librarypath /tmp/smd_dil
$ less /tmp/smd_dil/msoic-10.kicad_mod


Attached is one of the converted footprints, *.kicad_mod
Observations:

a) Layernames should be in English always (in a footprint, not a board).

b) The old footprint was deci-mils, the new one is mm.


c) The next thing I notice is the ugyly timestamps on the fp_lines.

Wayne or JP, do we need those time stamps on mere lines?

Dick,

I believe there are some BOARD objects that require time stamps so I was
being conservative and kept them in objects if I wasn't sure if they
were required.  I'm guessing fp_lines do not need a time stamp.  JP will
know if they are needed or not.  There may also be some other BOARD
objects in the board file that have time stamps that are not required as
well.  I'll take a look at it when I get a chance.

Wayne


Thanks, but I don't need help changing the code, I just was asking for a need 
assessment.

Now I'd like to extend my original question, to the footprint itself, why do we 
need a
time stamp on a footprint that resides in a library?
For the footprint itself ( i.e. when inside a library, not inside a 
board), the time stamp is not used.
It is actually used only when loaded on a board, and it is modified when 
reading a netlist.
Therefore the time stamp of the footprint itself, if exists, will be 
replaced the first time a netlist is read.



--
Jean-Pierre CHARRAS


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:
> On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:
>>
>> *Observations:*
>>
>>> a) Layernames should be in English always (in a footprint, not a board).
>>
>>
>> Once we go down this path, we can never change the English default layer 
>> names without
>> maintaining support for the current spelling of the ones you see now.
> I knew this had the potential to be an issue when I designed the new 
> file format.  I am not opposed to going back to a hexadecimal bit mask 
> for layer definition.  Now would be the time to do it before we make the 
> new file format the default.  We would be trading human readability and 
> potentially unlimited layers (I'm not sure that is important) for a 
> smaller file size, faster layer parsing, and easier maintenance.  There 
> are sound arguments for both designs.  Internally Pcbnew layers are 
> still bit masks so the number of layers are limited to the integer size. 
>   Any move to a layer stack would require major changes.  It does seem 
> that a hexadecimal bit mask is more appropriate given our current 
> design.  We can always move from a 32 bit to a 64 bit layer mask when 
> users start requesting more copper layers.
>
> Wayne


The layering *order* in pcbnew is questionable, and something I've been arguing 
to change
for 4 years.  Therefore the hexadecimal numbering scheme is more likely to 
become obsolete
than is a well thought out English layer name.

I also don't think you have a speed problem parsing layer names.  We can get an
improvement using std::string in stead of wxString for the hashtable.   There's 
not a lot
of point in converting to wxString before doing compares or hash functions.   
But this is
MINOR.

When I load a *.kicad_pcb file now, it loads at about the same speed as a 
legacy load on
the same *large* board.

We do not have a problem.  I am in favor of staying with the current game plan, 
although
would be open to another look at English layer name *spellings*, NOW.   
Personally the
spellings seem clear, but I am not certain about conciseness, but don't take 
that as an
objection to current conciseness.   Practically, we may already be past the 
point where
they can be changed without disruption.


Dick



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

On 11/11/2012 07:43 AM, Wayne Stambaugh wrote:
> On 11/10/2012 11:09 PM, Dick Hollenbeck wrote:
>> OK, I got a footprint library to convert from legacy to kicad format using 
>> the attached
>> command line python script.
>> It ran nicely, and quickly, without a fuss once I get it setup correctly.
>>
>>
>> Procedure I used, which is perhaps not optimal, but is one that worked:
>> (I'm open to suggestions on improvement.)
>>
>>
>> 1) Build target _pcbnew after enabling scripting in cmake.
>> $ make _pcbnew
>>
>>
>> 2) Changed dir to pcbnew
>> $ cd pcbnew
>> $ pwd
>> build/pcbnew
>>
>>
>>
>> 3) Entered following command line, script takes to arguments: oldLibPath & 
>> newLibPath
>> $ PYTHONPATH=. ../lib_convert.py /usr/local/share/kicad/modules/smd_dil.mod 
>> /tmp/smd_dil
>>
>>
>> 4) inspect one footprint found in new librarypath /tmp/smd_dil
>> $ less /tmp/smd_dil/msoic-10.kicad_mod
>>
>>
>> Attached is one of the converted footprints, *.kicad_mod
>> Observations:
>>
>> a) Layernames should be in English always (in a footprint, not a board).
>>
>> b) The old footprint was deci-mils, the new one is mm.
>>
>>
>> c) The next thing I notice is the ugyly timestamps on the fp_lines.
>>
>> Wayne or JP, do we need those time stamps on mere lines?
> Dick,
>
> I believe there are some BOARD objects that require time stamps so I was 
> being conservative and kept them in objects if I wasn't sure if they 
> were required.  I'm guessing fp_lines do not need a time stamp.  JP will 
> know if they are needed or not.  There may also be some other BOARD 
> objects in the board file that have time stamps that are not required as 
> well.  I'll take a look at it when I get a chance.
>
> Wayne


Thanks, but I don't need help changing the code, I just was asking for a need 
assessment.

Now I'd like to extend my original question, to the footprint itself, why do we 
need a
time stamp on a footprint that resides in a library?



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Wayne Stambaugh]

On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:



*Observations:*


a) Layernames should be in English always (in a footprint, not a board).




Once we go down this path, we can never change the English default layer names 
without
maintaining support for the current spelling of the ones you see now.


I knew this had the potential to be an issue when I designed the new 
file format.  I am not opposed to going back to a hexadecimal bit mask 
for layer definition.  Now would be the time to do it before we make the 
new file format the default.  We would be trading human readability and 
potentially unlimited layers (I'm not sure that is important) for a 
smaller file size, faster layer parsing, and easier maintenance.  There 
are sound arguments for both designs.  Internally Pcbnew layers are 
still bit masks so the number of layers are limited to the integer size. 
 Any move to a layer stack would require major changes.  It does seem 
that a hexadecimal bit mask is more appropriate given our current 
design.  We can always move from a 32 bit to a 64 bit layer mask when 
users start requesting more copper layers.


Wayne







b) The old footprint was deci-mils, the new one is mm.


c) The next thing I notice is the ugyly timestamps on the fp_lines.

Wayne or JP, do we need those time stamps on mere lines?




___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Wayne Stambaugh]

On 11/10/2012 11:09 PM, Dick Hollenbeck wrote:

OK, I got a footprint library to convert from legacy to kicad format using the 
attached
command line python script.
It ran nicely, and quickly, without a fuss once I get it setup correctly.


Procedure I used, which is perhaps not optimal, but is one that worked:
(I'm open to suggestions on improvement.)


1) Build target _pcbnew after enabling scripting in cmake.
$ make _pcbnew


2) Changed dir to pcbnew
$ cd pcbnew
$ pwd
build/pcbnew



3) Entered following command line, script takes to arguments: oldLibPath & 
newLibPath
$ PYTHONPATH=. ../lib_convert.py /usr/local/share/kicad/modules/smd_dil.mod 
/tmp/smd_dil


4) inspect one footprint found in new librarypath /tmp/smd_dil
$ less /tmp/smd_dil/msoic-10.kicad_mod


Attached is one of the converted footprints, *.kicad_mod
Observations:

a) Layernames should be in English always (in a footprint, not a board).

b) The old footprint was deci-mils, the new one is mm.


c) The next thing I notice is the ugyly timestamps on the fp_lines.

Wayne or JP, do we need those time stamps on mere lines?


Dick,

I believe there are some BOARD objects that require time stamps so I was 
being conservative and kept them in objects if I wasn't sure if they 
were required.  I'm guessing fp_lines do not need a time stamp.  JP will 
know if they are needed or not.  There may also be some other BOARD 
objects in the board file that have time stamps that are not required as 
well.  I'll take a look at it when I get a chance.


Wayne







___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

*Observations:*

> a) Layernames should be in English always (in a footprint, not a board).



Once we go down this path, we can never change the English default layer names 
without
maintaining support for the current spelling of the ones you see now.



>
> b) The old footprint was deci-mils, the new one is mm.
>
>
> c) The next thing I notice is the ugyly timestamps on the fp_lines.
>
> Wayne or JP, do we need those time stamps on mere lines?



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

OK, I got a footprint library to convert from legacy to kicad format using the 
attached
command line python script.
It ran nicely, and quickly, without a fuss once I get it setup correctly.


Procedure I used, which is perhaps not optimal, but is one that worked:
(I'm open to suggestions on improvement.)


1) Build target _pcbnew after enabling scripting in cmake.
$ make _pcbnew


2) Changed dir to pcbnew
$ cd pcbnew
$ pwd
build/pcbnew



3) Entered following command line, script takes to arguments: oldLibPath & 
newLibPath
$ PYTHONPATH=. ../lib_convert.py /usr/local/share/kicad/modules/smd_dil.mod 
/tmp/smd_dil


4) inspect one footprint found in new librarypath /tmp/smd_dil
$ less /tmp/smd_dil/msoic-10.kicad_mod


Attached is one of the converted footprints, *.kicad_mod
Observations:

a) Layernames should be in English always (in a footprint, not a board).

b) The old footprint was deci-mils, the new one is mm.


c) The next thing I notice is the ugyly timestamps on the fp_lines.

Wayne or JP, do we need those time stamps on mere lines?



#!/usr/bin/python

from __future__ import print_function
from pcbnew import *
import sys

if len( sys.argv ) < 3 :
print( "usage: script oldLibraryPath newLibraryPat" )
sys.exit(1)

# 2 libraryPaths.  One is a file, one is a new directory, but that difference
# is abstracted into the notion of a "library path", so you can forget that you
# now know that secret.

old = sys.argv[1]
new = sys.argv[2]

legacy = IO_MGR.PluginFind( IO_MGR.LEGACY )
kicad  = IO_MGR.PluginFind( IO_MGR.KICAD )

try:
kicad.FootprintLibDelete( new )
except:
None# ignore, new may not exist if first run

kicad.FootprintLibCreate( new )

list_of_parts = legacy.FootprintEnumerate( old )

for part_id in list_of_parts:
module = FootprintLoad( old, part_id )
kicad.FootprintSave( new, module )

(module msoic-10 (layer Front) (tedit 49EA0D66) (tstamp 0)
  (at 0 0)
  (descr MSOIC-10)
  (fp_text reference MSOIC-10 (at 0 -0.29972) (layer SilkS_Front)
(effects (font (size 0.24892 0.24892) (thickness 0.06096)))
  )
  (fp_text value U*** (at 0 0.29972) (layer SilkS_Front)
(effects (font (size 0.24892 0.24892) (thickness 0.0508)))
  )
  (fp_line (start -1.016 -2.413) (end -1.016 -1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21A7))
  (fp_line (start -0.508 -2.413) (end -0.508 -1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21A8))
  (fp_line (start 0 -2.413) (end 0 -1.524) (layer SilkS_Front) (width 0.127) 
(tstamp 509F21A9))
  (fp_line (start 0.4826 -2.413) (end 0.4826 -1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21AA))
  (fp_line (start 1.016 -2.413) (end 1.016 -1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21AB))
  (fp_line (start 1.016 2.413) (end 1.016 1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21AC))
  (fp_line (start 0.508 2.413) (end 0.508 1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21AD))
  (fp_line (start 0 2.413) (end 0 1.524) (layer SilkS_Front) (width 0.127) 
(tstamp 509F21AE))
  (fp_line (start -0.508 2.413) (end -0.508 1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21AF))
  (fp_line (start -0.9906 2.413) (end -0.9906 1.524) (layer SilkS_Front) (width 
0.127) (tstamp 509F21B0))
  (fp_circle (center -0.89916 0.9017) (end -1.09982 1.09982) (layer 
SilkS_Front) (width 0.127) (tstamp 509F21B1))
  (fp_line (start 1.50114 -1.50114) (end -1.50114 -1.50114) (layer SilkS_Front) 
(width 0.127) (tstamp 509F21B2))
  (fp_line (start -1.50114 -1.50114) (end -1.50114 1.50114) (layer SilkS_Front) 
(width 0.127) (tstamp 509F21B3))
  (fp_line (start -1.50114 1.50114) (end 1.50114 1.50114) (layer SilkS_Front) 
(width 0.127) (tstamp 509F21B4))
  (fp_line (start 1.50114 1.50114) (end 1.50114 -1.50114) (layer SilkS_Front) 
(width 0.127) (tstamp 509F21B5))
  (pad 1 smd rect (at -1.00076 2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 2 smd rect (at -0.50038 2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 3 smd rect (at 0 2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 4 smd rect (at 0.50038 2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 5 smd rect (at 1.00076 2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 6 smd rect (at 1.00076 -2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 7 smd rect (at 0.50038 -2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 8 smd rect (at 0 -2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 9 smd rect (at -0.50038 -2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (pad 10 smd rect (at -1.00076 -2.30124) (size 0.29972 1.02108)
(layers Front SoldP_Front Mask_Front)
  )
  (model smd/smd_dil/msoic-10.wrl
(at (xyz 0 0 0))
(scale (xyz 1 1 1))
(rotate (xyz 0 0 0))
  )
)
_

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Miguel Angel Ajo Pelayo]

Exactly, what you're proposing must work, may be cleaner if you use "
GetPluginForPath(lpath) " twice (at start) to hide the IO_MGR calls :-) and
then you can convert from any format to any other without changes to your
script :D

Yes, the IO_MGR architecture is quite well designed , good design uses to
pay back fast :-)



2012/10/19 Dick Hollenbeck 

> On 10/19/2012 02:24 PM, Miguel Angel Ajo Pelayo wrote:
> > Of course, I will be very happy to help on that, if you point me to the
> "lib table" branch.
>
> This new branch should not be needed, since the lib table is not needed
> for this script.
> The plugin types are supplied explicitly in the script as you have done.
>
> I was not certain you were honoring the plugin type, but now see that you
> are with the
> call to IO_MGR.PluginFind( plugin_Type ).
>
>
> Can the efficiency of your loop be improved if we keep the two plugins
> instantiated?
>
> See below
>
>
>
> >
> > The needed functions are here:
> >
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/module.i
> > <
> http://bazaar.launchpad.net/%7Ekicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/module.i
> >
> >
> > def GetPluginForPath(lpath):
> > return IO_MGR.PluginFind(IO_MGR.LEGACY)
> >
> > def FootprintEnumerate(lpath):
> > plug = GetPluginForPath(lpath)
> > return plug.FootprintEnumerate(lpath)
> >
> > def FootprintLoad(lpath,name):
> > plug = GetPluginForPath(lpath)
> > return plug.FootprintLoad(lpath,name)
> >
> > def FootprintSave(lpath,module):
> >   plug = GetPluginForPath(lpath)
> > return plug.FootprintSave(lpath,module)
> >
> > def FootprintDelete(lpath,name):
> > plug = GetPluginForPath(lpath)
> > plug.FootprintDelete(lpath,name)
> >
> > def FootprintLibCreate(lpath):
> > plug = GetPluginForPath(lpath)
> > plug.FootprintLibCreate(lpath)
> >
> > def FootprintLibDelete(lpath):
> > plug = GetPluginForPath(lpath)
> > plug.FootprintLibDelete(lpath)
> >
> > def FootprintIsWritable(lpath):
> > plug = GetPluginForPath(lpath)
> > plug.FootprintLibIsWritable(lpath)
> >
> >
> > and they should be available from pcbnew.* :
> >
> > it must be something like (totally untested):
> >
> > import pcbnew
>
> old = argv[1](my python knowledge is rusty)
> new = argv[2]
>
> legacy = IO_MGR.PluginFind(IO_MGR.LEGACY)
>
> kicad = IO_MGR.PluginFind(IO_MGR.KICAD)
>
>
> >
> > list_of_parts = pcbnew.FootprintEnumerate("file.mod")
> >
> > for part_id in list_of_parts:
> > module = FootprintLoad("file.mod",part_id)
> > FootprintSave("new_path",part_id)
>
> list_of_parts = legacy.FootprintEnumerate("file.mod")
>
> for part_id in list_of_parts:
>   module = legacy.FootprintLoad( old, part_id )
>  kicad.FootprintSave( new, module )
>
>
>
> >
> >
> > problems will arise, and bugs will need to be hunted :-)
> >
> > Greetings :-)
> >
> >
> > 2012/10/19 Dick Hollenbeck mailto:d...@softplc.com>>
> >
> > Hi Miguel,
> >
> > I would like to be able to instantiate to PLUGINs simultaneously in
> a script, one of
> > type
> > LEGACY, and the second of type KICAD.
> >
> > Then I would like to copy all the footprints from one plugin to the
> other, thereby
> > doing a
> > conversion of the entire library behind the LEGACY plugin into the
> library behind the
> > KICAD plugin.
> >
> > Is this kind of script fu something you could help us with?
> >
> > Maybe it could take two "library paths" on the command line, old and
> new.
> >
> > FYI, a "library path" in the context of the new KICAD format is now
> a directory,
> > whereas a
> > "library path" in the context of the LEGACY plugin is an actual
> *.mod file, but I think
> > the API hides this abstractly.
> >
> >
> > Thanks for any help you can offer,
> >
> > Dick
> >
> >
> > P.S. Wayne and I are currently collaborating on the branch which is
> being used to
> > add the
> > "lib table" support.  So the time at which this script could be very
> useful is
> > approaching.  I envision running it one time on all the package
> supplied footprint
> > libraries, and that may be the end of its utility for the most part.
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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
> >
> >
> >
> >
> > --
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 636 52 25 69
> > skype: ajoajoajo
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
__

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

This would be an 8 line long conversion program with powerful ramifications.

Where else do you get something like this?

This is software architecture, starting to shine.



___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Dick Hollenbeck]

On 10/19/2012 02:24 PM, Miguel Angel Ajo Pelayo wrote:
> Of course, I will be very happy to help on that, if you point me to the "lib 
> table" branch.

This new branch should not be needed, since the lib table is not needed for 
this script. 
The plugin types are supplied explicitly in the script as you have done.

I was not certain you were honoring the plugin type, but now see that you are 
with the
call to IO_MGR.PluginFind( plugin_Type ).


Can the efficiency of your loop be improved if we keep the two plugins 
instantiated?

See below



>
> The needed functions are here: 
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/module.i
> 
>  
>
> def GetPluginForPath(lpath):
> return IO_MGR.PluginFind(IO_MGR.LEGACY)
>   
> def FootprintEnumerate(lpath):
> plug = GetPluginForPath(lpath)
> return plug.FootprintEnumerate(lpath)
>   
> def FootprintLoad(lpath,name):
> plug = GetPluginForPath(lpath)
> return plug.FootprintLoad(lpath,name)
>   
> def FootprintSave(lpath,module):
>   plug = GetPluginForPath(lpath)
> return plug.FootprintSave(lpath,module)
>   
> def FootprintDelete(lpath,name):
> plug = GetPluginForPath(lpath)
> plug.FootprintDelete(lpath,name)
>   
> def FootprintLibCreate(lpath):
> plug = GetPluginForPath(lpath)
> plug.FootprintLibCreate(lpath)
>   
> def FootprintLibDelete(lpath):
> plug = GetPluginForPath(lpath)
> plug.FootprintLibDelete(lpath)
>   
> def FootprintIsWritable(lpath):
> plug = GetPluginForPath(lpath)
> plug.FootprintLibIsWritable(lpath)
>   
> 
> and they should be available from pcbnew.* :
>
> it must be something like (totally untested):
>
> import pcbnew

old = argv[1](my python knowledge is rusty)
new = argv[2]

legacy = IO_MGR.PluginFind(IO_MGR.LEGACY)

kicad = IO_MGR.PluginFind(IO_MGR.KICAD)


>
> list_of_parts = pcbnew.FootprintEnumerate("file.mod") 
>
> for part_id in list_of_parts:
> module = FootprintLoad("file.mod",part_id)
> FootprintSave("new_path",part_id)

list_of_parts = legacy.FootprintEnumerate("file.mod")

for part_id in list_of_parts:
  module = legacy.FootprintLoad( old, part_id )
 kicad.FootprintSave( new, module )



>
>
> problems will arise, and bugs will need to be hunted :-)
>
> Greetings :-)
>
>
> 2012/10/19 Dick Hollenbeck mailto:d...@softplc.com>>
>
> Hi Miguel,
>
> I would like to be able to instantiate to PLUGINs simultaneously in a 
> script, one of
> type
> LEGACY, and the second of type KICAD.
>
> Then I would like to copy all the footprints from one plugin to the 
> other, thereby
> doing a
> conversion of the entire library behind the LEGACY plugin into the 
> library behind the
> KICAD plugin.
>
> Is this kind of script fu something you could help us with?
>
> Maybe it could take two "library paths" on the command line, old and new.
>
> FYI, a "library path" in the context of the new KICAD format is now a 
> directory,
> whereas a
> "library path" in the context of the LEGACY plugin is an actual *.mod 
> file, but I think
> the API hides this abstractly.
>
>
> Thanks for any help you can offer,
>
> Dick
>
>
> P.S. Wayne and I are currently collaborating on the branch which is being 
> used to
> add the
> "lib table" support.  So the time at which this script could be very 
> useful is
> approaching.  I envision running it one time on all the package supplied 
> footprint
> libraries, and that may be the end of its utility for the most part.
>
>
>
>
>
>
>
> ___
> 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
>
>
>
>
> -- 
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo


___
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

Re: [Kicad-developers] PLUGIN::Footprint*() from python

[Miguel Angel Ajo Pelayo]

Of course, I will be very happy to help on that, if you point me to the
"lib table" branch.

The needed functions are here:
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/module.i


def GetPluginForPath(lpath):
return IO_MGR.PluginFind(IO_MGR.LEGACY)
def FootprintEnumerate(lpath):
plug = GetPluginForPath(lpath)
return plug.FootprintEnumerate(lpath)
def FootprintLoad(lpath,name):
plug = GetPluginForPath(lpath)
return plug.FootprintLoad(lpath,name)
def FootprintSave(lpath,module):
plug = GetPluginForPath(lpath)
return plug.FootprintSave(lpath,module)
def FootprintDelete(lpath,name):
plug = GetPluginForPath(lpath)
plug.FootprintDelete(lpath,name)
def FootprintLibCreate(lpath):
plug = GetPluginForPath(lpath)
plug.FootprintLibCreate(lpath)
def FootprintLibDelete(lpath):
plug = GetPluginForPath(lpath)
plug.FootprintLibDelete(lpath)
def FootprintIsWritable(lpath):
plug = GetPluginForPath(lpath)
plug.FootprintLibIsWritable(lpath)

and they should be available from pcbnew.* :

it must be something like (totally untested):

import pcbnew

list_of_parts = pcbnew.FootprintEnumerate("file.mod")

for part_id in list_of_parts:
module = FootprintLoad("file.mod",part_id)
FootprintSave("new_path",part_id)


problems will arise, and bugs will need to be hunted :-)

Greetings :-)


2012/10/19 Dick Hollenbeck 

> Hi Miguel,
>
> I would like to be able to instantiate to PLUGINs simultaneously in a
> script, one of type
> LEGACY, and the second of type KICAD.
>
> Then I would like to copy all the footprints from one plugin to the other,
> thereby doing a
> conversion of the entire library behind the LEGACY plugin into the library
> behind the
> KICAD plugin.
>
> Is this kind of script fu something you could help us with?
>
> Maybe it could take two "library paths" on the command line, old and new.
>
> FYI, a "library path" in the context of the new KICAD format is now a
> directory, whereas a
> "library path" in the context of the LEGACY plugin is an actual *.mod
> file, but I think
> the API hides this abstractly.
>
>
> Thanks for any help you can offer,
>
> Dick
>
>
> P.S. Wayne and I are currently collaborating on the branch which is being
> used to add the
> "lib table" support.  So the time at which this script could be very
> useful is
> approaching.  I envision running it one time on all the package supplied
> footprint
> libraries, and that may be the end of its utility for the most part.
>
>
>
>
>
>
>
> ___
> 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
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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