kicad-developers team mailing list archive

[Werner Almesberger <werner@xxxxxxxxxxxx>]

[ Belatedly changed the subject, to look better in that thread
  hijacking trial. ]

Thanks for your description. Now I understand better where those
"heavy symbols" come from. Okay, not crazy. Not at all. But still
flawed ;-)

I agree that CPNs make things a lot easier, but managing them also
has a cost. I don't quite agree that doing everything manually is
very nice for casual users. Granted, the damage a mistake can
cause is small, but I think we should be able to do better than
this, without creating too much of an administrative burden.

Now to the main issue, the "heavy symbols." It seems that there
are two ways to get the CPN into a symbol: 1) put it already in
the library, or 2) add it in the schematics. 1) has the benefit
that you can also populate the fields for all other parameters.

1) has the big drawback that your library contains lots of
duplicate information. 2) avoids this problem, but has a high
risk of the visible information in the schematics and the
invisible CPN diverging.

To help with 1), one could separate the CPN-specific field values
from the symbol and have a table of field values for each symbol.
E.g., you'd put, say, your R, and then you could pop up a
parametric search over a table with entries like
CPN12345 R=100k TOL=5% FP=0402 V=50V
CPN12346 R=100k TOL=1% FP=0402 V=50V
etc. In many cases, that table could even be auto-generated from
the CPN/OPN tuples from the MPR and a universal table that maps
OPNs to parameters. Quite often, the latter can be
machine-generated as well.

To help with 2), the MPR could use the same kind of information
to check if things really do match.

The system I've written in actually quite similar to 2), only
that it doesn't make the CPN explicit.

Am I making sense so far ?

Particularly 1) has the issue that the same CPN can be associated
with multiple sets of parameters. E.g., the CPN12345 from above
would also be compatible with a specification of only R=100k
FP=0402. Now, do you

a) include all CPNs that are compatible with the requested
   parameters (leave it to the MPR to pick one it likes),

b) oblige the user to specify more parameters until only one CPN
   is left, or

c) introduce a separate CPN if the list of parameters isn't
   identical, e.g.,
   CPN12345 R=100k TOL=5% FP=0402 V=50V
   CPN23456 R=100k FP=0402

?

By the way, for narrowing down under-specified parameters, the
price is often a useful guide. Common parts tend to be cheap,

> A BOM generator in KiCad should really not be over complicated.

For case 2) with an implicit CPN, very little would be needed in
eeschema. The existing BOM format is already good enough. All
other information can live outside of eeschema.

1) would be much nicer, because it also eliminates all sorts of
data entry mistakes (or at least moves them away from the process
of making the schematics), but it would be more invasive for
eeschema, because you'd need the parametric search dialog.

By the way, regarding use cases, let's not forget collaborative
projects, where a design is shared with a large audience that
may have wildly different preferences for manufacturers and
distributors. Case 2) with an implicit CPN would be ideal here.

- Werner