kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Kaspar!

On 2016-12-21 17:19, Kaspar Emanuel wrote:
> 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.

I would use or maintain neither a datasheet field nor a MPN in KiCads world. I wouldn't mind to remove the "datasheet" field completely when it can be done with a generic key=value. If I need it for documentation purposes with the schematics or assembly data, I would pull them in selectively from my database using my Partname + UID - only on demand to generate a documentation for a customer.


> In any case we are trying to come up with a better, standard way to do it, what's the problem with that?

Simply: Your standard way is completely different than my "standard" way.

Lengthly: Just imagine you have used an ATtiny-861A in your libraries and use it in 14 different projects in 5 different variants spread over the last couple of years and wired "Atmel" into your designs. Now try find and replace "Atmel" with "Microchip" in your designs.

In my case, my designs would only know the Partnames:
IC-ATtiny861A-MU (ID=0) some old default type (Chip revision A)
IC-ATtiny861A-MU (ID=1) is invalid as it had an error in the pinout it automatically maps to an Error: verify your design.
IC-ATtiny861A-PU (ID=0) default type - just a different housing (documentation is the same)
IC-ATtiny861A-MU (ID=2) current default type (Chip revision B)
IC-ATtiny861A-MU (ID=3) current default type (Chip revision B) footprint optimized for wave soldering (long pads)
IC-ATtiny861A-MU (ID=4) current default type (Chip revision B) footprint with rounded rectangles
IC-ATtiny861A-MU (ID=4NA) current default type (Chip revision B) but this is a not assembled IC-ATtiny861A-MU with roundrects - it doesn't need to be ordered/assembled.
IC-SecretChip-AA (ID=0) can also map to IC-ATtiny861A-MU (ID=2) current default type (Chip revision B), but nobody should know what that part is except me and my assembly house. 8-)

You can see the IDs as "versions" and "variants" of a part to be able to automatically migrate old designs to be up to date with new libraries or to migrate a design from one manufacturing process to another one.

There is still no manufacturer of these chips envolved. I am mapping my PN+UID to my assembly house's SAP-No. (like 233400.0300). Then, they map the SAP-No. to one manufacturer (Microchip) and a manufacturer part number as well as to several distributors and a dist. order numbers and prices.
They choose the distributor of their choice (depending on volume, price, availability) and store it for part tracking/QM including datecodes if we want to. We could theoretically use the ID to indicate a "datecode tracked part".


> 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.

That is true. But if you really need to code something, it might be reasonable to spend your time to code something flexible/generic.
Some commercial tools simply use key=value pairs and they can map them using dictionaries when importing/exporting data.


> 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.

Again: I would not embed pre-assigned fields. I would prefer to keep them generic.

> Your alternative system is interesting but/is/ a bit more complicated.

Complicated or just more flexible?

As most people might have noticed is that KiCad is used a lot in the amateur electronics/maker community. But it can compete already with commercial
packages and use cases where the processes (or "standards") are quite different when you need a version management, part tracking, etc.


Regards,

Clemens