Hi Kaspar On Wed, Dec 21, 2016 at 5:19 PM, Kaspar Emanuel <kaspar.eman...@gmail.com> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp