Re: gEDA-user: Light? Heavy? Reuse...

[Bob Paddock <bob.paddock@xxxxxxxxx>]

> Yes. But let's distinguish between the design data (the "source
> files" for the design) and the BOM, which is a report generated from
> these files.

The BOM can contain much more than just the gEDA/PCB based
files.  It may mounting hardware, enclosures, notes, warnings (see below) etc.

> > Also in a project where there is government approvals involved you
> > want  as little detail as possible in the schematic, be generic (MSHA does
> > not even want to see values on the schematic.  Need a way to turn that 'layer' of
> > information off when making one for them).
>
> Never heard of that one, but...

http://www.wearablesmartsensors.com/msha_rules.html :

FAQ:
2.1) What are some common administrative drawing omissions that lead to
discrepancy letters and approval delays?

8
a. Not putting the MSHA warning note "Do not change without approval of
MSHA" on each page of every drawing and each *page* of a parts list or bill
of material for Part 18 approval applications.
...
d. Illegible or partially legible drawings, sometimes due to print quality and
other times due to excessive drawing reduction where nomenclature is too
small to read.

[That one frequently makes me consider XCircuit, but XCircuit is not that great
at producing netlists.]

2.6) I want to maximize my ability to make post-approval design
changes without having to submit them for MSHA approval. How
can I configure my drawings to allow flexibility for future changes?
...
One way to reduce evaluation time is to avoid submitting drawings
containing duplicate or unnecessary information. MSHA investigators
must compare the submitted drawings with a sample unit to ensure the
unit is assembled according to the submitted drawings. The more
unnecessary information that is submitted, the more time must be spent
comparing components on the sample unit to the drawings. An example
where time is wasted is when a detailed electrical parts list and a
schematic are submitted with component values and specifications. A
cross check then has to be made comparing the parts list with the
schematic. Many times discrepancies are found where the component
values don't agree. It is better to either put all of the electrical parts list
information on the schematic diagram or to leave all parts values off of the
schematic and only list them on the electrical parts list.

> It's a one-liner in AWK to hide all value= attributes.

For you or I or most everyone here, yes.  However there may
very well be people that simply want to use the tool to get
a task done, and have zero interest in figuring out what
a attribute is, or where it might be located, or why they should care.

> A trivial automation problem in the gEDA architecture.
> Radical flexibility.

Which can lead to a paralyzing inability to use it.
Anything that does limit flexibility is bad.
That flexibility should not prevent methods
from being built into the tools.


> > The fewer documents that change, the less problems you have with
> > updating your project with "Them", and less expense.  Change *anything* in
> > submitted documents with MSHA and your looking at least $1000 bucks.
>
> That's another reason why, in the gEDA architecture, it makes great
> sense to maintain the information that will generate the BOM in
> project-specific "heavy" symbols.

To a degree.  Say you have a Second-Source alternative that fulfills
"form, fit, function".  You don't really want to have two heavy symbols
in your schematic, so that either can be used.  Also that can again
force a change in your schematic that would be otherwise unnecessary
when a part does go obsolete, but a new "form, fit, function" one
becomes available.

> One customer of mine wants the BOM bound together with a copy of the
> manufacturer's datasheet for every part.

I do that for every project I design for the inevitable day when something
goes obsolete or someone buys out someone else and changes the
part numbers.  I've run into cases when a manufacture obsoletes
a part, they remove the part from their website.  You still need to have
the original data to figure out the replacement.

> Just about every project I do has a software component, too. Given
> that the gEDA formats work well with common version control systems,
> it makes sense to go that route for both hardware design and software.

Yes.  The call to the heavy-mass provider should not make any assumptions
about where the mass is being stored or how.  Send out a request,
get back a response, via an API.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user