kicad-developers team mailing list archive

[Werner Almesberger <werner@xxxxxxxxxxxx>]

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) ;-)

[ Iterative BOM process. ]

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