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
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
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
On Wed, 14 Nov 2012 08:25:04 -0600
Dick Hollenbeck d...@softplc.com 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
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
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.
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
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
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
Good afternoon,
I've been glancing at this thread onoff 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:
On 11/13/2012 05:33 PM, Chris Giorgi wrote:
Good afternoon,
I've been glancing at this thread onoff 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
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
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
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
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
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.
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
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
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
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
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
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
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 :
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
24 matches
Mail list logo
