kicad-developers team mailing list archive

[Kevin Bortis <kevin@xxxxxxxxx>]

Hi Kaspar

On Wed, Dec 21, 2016 at 5:19 PM, Kaspar Emanuel
<kaspar.emanuel@xxxxxxxxx> wrote:
> Thank you Clemens and Kevin for your responses.
>
> Clemens, you raise that you are not happy with hard-coding fields at all
> because there is no standard way to do it. But KiCad’s symbols already come
> with a datasheet field for instance. To me, the datasheet field is way less
> useful than an MPN field. In any case we are trying to come up with a
> better, standard way to do it, what's the problem with that?
>
> You then go on to describe your method and say you have no use case for it.
> That’s fair enough but I think its clean that I and a few other people do
> have a use case. Furthermore, the proposal, if implemented, shouldn’t affect
> your way of working at all.
>
> Kevin, you say that this would not work for generic components like
> resistors and capacitors. I don’t think I was clear enough: the proposal is
> to add a standard MPN field to schematic symbols to be populated when they
> are part of a schematic, i.e. their values (and tolerances etc) have been
> assigned. Really we are talking about the schematic format.

Thanks for clarifying that. I see then no problem with your proposal.
I really understand that other people have different requirements and
workflow and I am the last person who wants to break anything. Because
you intend to define it as an OPTIONAL property in the S-expression
format I see no problem. As long as KiCad not automatically adds
useless and undefined parameters I am good with that.

You proposed in your original E-Mail something like the following:

(property "MPN" "NXP" "i.MX6")

As Clements also noted, these values change very fast nowadays. At my
workplace I have a library of around 4000 pysical components that I
"try" to manage. As an example, I have a sensor chip which changed 3
times, in the last 2 years the value of the Manufacturer field,
because of mergers. It is even common that the orderable part number
change in such a process. In the example above, Motorola split away
the semiconductor business in to the spin offs ON Semiconductor and
Freescale. The later got acquired by NXP last year and next year it
will already be absorbed into Qualcomm. The second problem is, that
the info i.MX6 or NE555 is almost useless. Almost all modern
semiconductors are available in different packages and packaging
options. If you go to the page
http://www.ti.com/product/NE555/samplebuy everyone see what I mean.
Even when the footprint is defined it is not clear what kind of
temperature range etc. you intend to use. So the field should look
more something like

(property "MPN" "Texas Instruments" "NE555PSR")

This way you really know what you will get and it can be used for
automatic BOM creation. I see that for some projects that are only
produced once or that have a very low production count and lifetime,
the basic info is enough, but if someone tries to manage multiple
designs with a component count over 500 per board and a production
lifespan of over 10 years, which is quiet common for industrial
electronics, you will simply be lost.

In the last 4 years KiCad made real progress to the point where you
can use it for real work. The only thing that is missing at the moment
to make it enterprise ready is a good and solid library management. So
my proposal is that we should come up with a file format spec, that
allows different workflows to exist. Even if this means that someone
wants to define (property "MPN" "Texas Instruments" "NE555") for his
hobby projects or if somebody needs other fields for external part
management as long it will not be enforced to users.

>
> Your alternative system is interesting but is a bit more complicated.
> Standardizing on an MPN field is something existing tooling could make use
> of very quickly but with yours they would have to change their way of
> working quite substantively. I think further discussion of your proposal is
> a separate point and should continue in another thread.

There you are right.

>
> All the best,
>
> Kaspar
>
>