Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » KiCAD
  • » [Kicad-developers] BOM processing (was Re: Default Field names patch) [RSS Feed]

#1 June 15, 2010 02:19:25

Werner A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] BOM processing (was Re: Default Field names patch)




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

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#2 June 15, 2010 12:45:58

Werner A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] BOM processing (was Re: Default Field names patch)


Dick Hollenbeck wrote:
> One idea is to have the BOM generator generate a CSV file that the user
> is to edit.

Heh, I still remember the howl of agony that went through the list
the last time I proposed a (quite simple) text file as a means of
user input (for ERC exceptions) ;-)



It seems that this would still duplicate manufacturer/distributor
data across projects. The model Brian has described, with things
arranged around a CPN, would avoid this. That's also what I know
from industry, although with somewhat questionable MPR.

I feel that things are starting to fall into place. In fact, even
the two scenarios I described in my reply to Brian (1 "CPN and
parameters a la carte" and 2 "user-provided CPN") would converge
and complement each other, since they both use the same base
information.

>> This would also allow the BOM generator to be developed apart
>> from the main KiCad codebase, which is probably a good thing in
>> the long run. (And it might give me a chance to play, too :-)
>
> Yes, but this means duplicating all the schematic file loading code.

Not at all. The existing BOM output would be largely sufficient
for scenario 2. The only thing I can think of at the moment that
would make things even better is if also the symbol name was
available. That way, one could use it as a key for all the
part/parametric tables.

That would be very similar to the model Digi-Key's database uses:
you first select a category (in our case, the symbol), then you
further refine your selection by picking parameters from a table.

What Digi-Key doesn't let you do is order by price when you've
run out of ideas for further narrowing down your search.

With symbols defining category, we'd have a coarser granularity
than Digi-Key for "birdseed" (R, C, etc.), but much finer
granularity than Digi-Key's catalog for ICs, which seems like an
improvement to me.

> I entered that *one time* into the *schematic* symbol property editor
> for a user defined field called "Manufacturer" for *any one (1)* part
> matching C1.

So two components would "match" if they both have the same set of
fields, and fields with the same name/position would have the
same value ?

"Choose alike" sounds like a convenient concept to me. In scenario
1, this could be modeled in the parametric search by showing the
parts most similar to earlier queries, a bit like the "History list"
you get in eeschema when placing new components.

In general, "choose alike" should result more or less automatically
once you have the full set of parameters and all that's left is to
pick among equal parts. I'm sure there are exceptions where you're
doing everything right and still a part you hate keeps on popping
up, but then you'd have the CPN to override that too.

> You thinking we should make Kicad into a spreadsheet?

... and one Excel to rule them all ;-) It looks more like a RDMBS
type of scenario to me at the moment, luckily with nice enough
properties that a few CSV files should do until someone needs
record-wise exclusive access for joint editing.

> What about passing stuff through
> the clipboard, this is also easier than CSV files on the user, and
> easier on us developers.

Hmm, would that mean to use the primary clipboard as an IPC
mechanism ? In this case, I wonder if users wouldn't complain if
we override their copy and paste buffer all the time.

If you're thinking of using another clipboard, how would users
be able to access it (outside the KiCad world, where programs
would know about it) ?

I could see a place for the clipboard when picking things off the
"menu" (scenario 1), so that the parametric search wouldn't have
to live inside eeschema.

The interaction would then be something like this:

eeschema: asks for a parametric search
eeschema -> psearch: symbol name, perhaps any fields already set
psearch: user does some searching, finds, and accepts
eeschema <- psearch: list of values, possibly including CPN

Do we have an IPC mechanism that could be used to announce that
we've put something into the clipboard, so that users don't have
to first tell one side to send, then the other to receive ?

- Werner

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#3 June 15, 2010 15:15:06

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] BOM processing (was Re: Default Field names patch)


I would like some time to study the existing code before I comment any
more. That will be another week or so.

Integration with Kicad is nice, but C++ would not be my first choice of
language for elaborate BOM generation. Exporting a table and running
with it externally has some advantage, and EESCHEMA could be told to
chain load an external executable for post processing.

Let's all sleep on it, and feel free to study what is there now as I
do. I don't share your concerns about the clipboard. I've passed
complete tables through the clipboard before.


Dick

BTW, Excel had not crossed my mind when I used the word spreadsheet.
I'm sure supporting it would be harder, that's just the way things are
with its vendor.



_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

  • Root
  • » KiCAD
  • » [Kicad-developers] BOM processing (was Re: Default Field names patch) [RSS Feed]

Board footer

Moderator control

Enjoy the 20th of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support