kicad-developers team mailing list archive
Mailing list archive
Re: KiCad PCB
On 11/30/2012 11:56 AM, Dick Hollenbeck wrote:
Fair enough. Like I said, next year I expect to spend some time really
looking at the code in detail. Just posting the idea to see if there
were any takers or solutions in the works.
On 11/30/2012 12:23 PM, Richard Howlett wrote:
Thanks Dick for taking the time to look at this.
I thought that the "Append Board" might have been a planned way of
dealing with hierarchy that just wasn't fully implemented. Now, I'm
guessing it for stepping multiple boards to export into gerber to
exploit full PCB panels?
I'm poking around KiCad but I can't seem to find anything that
references Board fragment. I think I get what you are saying. In some
ways this approach is how I've dealt with this in the past, but it's
always been kind of a kludge (by hand, and very time consuming). Plus
the Module Editor doesn't deal in traces, just pads. If I could save a
PCB as a Module this might get me part of the way. Then, its like you
say, just adding modules. The only hiccup I see is the naming of the
internal nets, it would seem they would need some type of unique name
(hidden names in a component with no connect declarations so the
netlister assigns the names, oh the list just keeps getting longer...)
*) Points of connections are just pads and traces, I can't think of any
*) So a Module would need some minimum set of verification such as width
and clearance DRCs, but it should be ok for connectivity to have opens
as long as the pads or traces are open for routing (this can be part of
someone's master plan to do this at a higher level, ie GND), thus it
should be a warning and not an error.
*) It seems if the PCB could save schematics artwork as a Module, and
there were a simple path for a Schematic to save as Component (with some
type of link to the original schematic) this would be an acceptable and,
I might add, good solution. I don't know the code well enough to say if
this is easy but I have plans to start really digging into it next
To actually achieve this, one would need a use case description (written spec), then a
software design. After that, in theory, coding it is like cutting a down a few trees
without a chainsaw, only a handsaw. Less thinking, mostly grinding.
But it is definitely a longer term perspective, and tantamount to envisioning a garage
from a pile of lumber. The pile may only look like a garage to a framer.
If I were to spend any more time on it, then I would be funding it. And it is too big a
task without outside funding.