[Ground-station] How are we set for layout tools?

[Keith Wheeler]

Completely agree John.  In Altium we could create a symbol and footprint
from everything used in the project; that was often used just to archive a
project. Otherwise we used our standard libraries and that was critical.

I spent a lot of my career at a contract design house, and the unified
"source of truth" library was very important to us. I wouldn't suggest this
for our purposes, but we went so far as having our libraries refer to our
part numbers. An engineer didn't place a generic 0.1uf cap, they placed a
PARNUM-123 0.1uF 50V cap. If the schematic is the source of truth in a
hardware design, then it should carry all of the information necessary to
build that design -- which means footprint (gerbers and board build) and
BOM (purchasing). In our case some of that would be overkill, but there is
some really nice consistency as you say to having the same 0805 footprint
for all 0805 caps, another for 0805 resistors. With small production run
boards that may have a lot of debug/modification/development work on them,
these little details really add up.

Another bit of project management that this "official" library allows is
part life cycle. A footprint for a complex part requiring a center heatsink
pad that's never been used in production is very different -- from a
project management point of view -- from the footprint that has been
verified in production. Sometimes there are differences that the casual
board layout person may not notice; like how the solder stencil is formed
for that large heatsink pad. That little detail can mean a huge difference
in board yield. I've chased this a few times and the more complex and
higher pin count the part the more likely issues there are. Having an
official library, where there is some indicator of a part's life cycle --
new, proven, obsolete -- can be important.

-Keith

On Tue, Jul 28, 2020 at 10:47 AM John Ackermann N8UR via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> KiCad does have the concept of a project, and I am pretty sure it
> maintains a local cache of all the footprints used.
>
> What I was suggesting was a little more than that -- collect up and
> share all the symbols and footprints used across all group projects in a
> set of (moderately) organized libraries that become *the* source
> libraries for future work.
>
> That way you avoid recreating the wheel, and also get consistency -- if
> you have make available one tested footprint for an 0805 passive, you
> don't end up with people using all the slight variants that are
> available in the universe of libraries.
>
> (And to be clear -- I'm not being KiCad specific about this; I think
> it's a good time investment no matter what tools you use.)
>
> 73,
> John
> ----
>
> On 7/28/20 1:39 PM, Keith Wheeler via Ground-Station wrote:
> > Paul,
> >
> > Honestly I personally wouldn't have separate repos for the outputs and
> > source. I'd tend towards a single repo, with outputs being generated for
> > each tagged release. I mentioned separate repos because many prefer to
> > model hardware repos on software ones where build artifacts are pushed
> > to a different channel. The complaint, as I understand it, is that at
> > any point in development other than tagging a release, there is likely
> > to be a mismatch between the source schematic document output documents.
> > Seems to me the best way to resolve this is a well written readme; I
> > think CI/CD is still a radical concept for board design, at least once
> > you get away from multik$ tools which have scripting support for
> > automated output generation.
> >
> > One thing I'd change in the trans-ionospheric repo is the "outputs"
> > directory. The gerbers, drc, BOM, etc are all there. Perhaps a directory
> > structure for these would be in order, and one would be the pdf's of the
> > source docs. Netlists would be a useful output.
> >
> > John,
> >
> > I completely agree with your comment about creating a project library.
> > Some tools make that easy; the top tier Altium does, I don't know about
> > the "Circuit Studio" I use or Kicad. While "source" a project library
> > should be at a minimum updated with every tagged release. Other than the
> > tool the project space should contain every source file someone would
> > need to recreate and modify the gerbers, BOM, etc, with no surprise
> > library dependencies. It also prevents issues with name collisions --
> > I've seen tools just default to using the first "SOT23" footprint it
> > finds, and if there are different footprints that differ in pin
> > ordering, bad things happen.
> >
> > On Tue, Jul 28, 2020 at 9:36 AM Paul Williamson via Ground-Station
> > <ground-station at lists.openresearch.institute> wrote:
> >
> >>     On Jul 28, 2020, at 7:53 AM, Keith Wheeler wrote:
> >>     This also opens the question of do we have a repo for source and
> >>     another for tagged released outputs.
> >
> >     I’m curious as to why it might be a good idea to have separate repos
> >     for work and outputs. At first glance it would seem to me that this
> >     is just asking for version skew confusion and extra work.
> >>
> >>     1.
> >>
> >>         Not all parties interested in the schematic and layout source
> >>         files will desire access to the tool. We should publish these
> >>         in a more common format (pdf?), perhaps at every tagged release.
> >>
> >     Yes, we absolutely should. Even people who do have access to the
> >     tools may find it quicker and easier to open a PDF for reference.
> >     The semantics of the special source file formats can have
> >     dependencies on library files that could become separated (or
> >     version skewed) from the design, or on features of specific tool
> >     versions. A stable, widely recognized, print-oriented format like
> >     PDF gives a valuable point of reference for what the thing is
> >     supposed to look like. Ancillary text-based outputs like netlists
> >     can also be helpful for people working with the hardware.
> >
> >        -Paul KB5MU
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20200728/4cbd9dcd/attachment-0001.html>