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

[Steve Conklin]

FWIW, This is easy in KiCAD. It allows libraries for symbols and for
footprints, and you can load them globally or per-project. My
recommendation would be to create a separate kicad library git repository
that's used across all ORI projects using KiCAD. We'll need further
discussion about processes, like whether we also tag a library 'release'
when tagging release of a dependent project.



On Tue, Jul 28, 2020 at 1:24 PM Keith Wheeler via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> 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/20200730/1f27aed8/attachment.html>