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

[Michelle Thompson]

I've started work on a paper that synthesizes all of this excellent
discussion.

The goal of the paper is to produce an ORI PCBA tools policy and list of
action items needed to accomplish that policy.

-Michelle W5NYV



On Thu, Jul 30, 2020 at 6:49 AM Steve Conklin via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> 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/20200811/96495d54/attachment.html>