These tools are not only supporting Kicad, some of them are supporting
multiple CAD packages, they just look at what information that they know
is available and use that. Not really bothering with what information
"can" be there if only.
There is also the collaboration issue, where if you would use components
from other people, they can have different names for the MFPN, the MPN,
or the ManufPart or PartNo or whatever I have seen many. If I ask a
classroom full of students to fill in the manufacturer part number for
their projects, I usually have to explain where and how to fill that
number very thoroughly. This is such a trivial thing that almost every
EE uses in some way.
I really dont want to get into this discussion about why again. Rather
make it about how can we implement it without breaking everything for
those who dont want to use it. There is some serious power in sane
default configurations.
With JP custom field I am refering to the settings tab in eeschema
called Template Field Names.
Ok, good. So no hardcoding then, although that could have the benefit of
adding things such as "Search digikey/mouser/google for ...". The same
way we have with datasheets etc etc.
Wayne Stambaugh wrote:
Maybe we should add a "FieldNames" entry to the default project file
(.pro) that
gets copied to the project folder when a new project is created. That
can be read and merged with the user's custom fields defined in the
eeschema config file. This seems like a better solution. This way if a
user just doesn't like the default, they can just modify their default
project file accordingly. There may be other potential solutions but
this is the best I can think of at the moment."
This seems like a good idea! Not breaking anything already there, but
providing help for new stuff!
On 06/06/2017 07:42 PM, Wayne Stambaugh wrote:
I feel the same way. My guess is that some of this is new users coming
from other EDA apps that provide default fields which we do not provide.
I personally would rather let users configure fields in the way that
works best for them rather than the KiCad project forcing defaults upon
them.
On 6/6/2017 1:25 PM, Bernhard Stegmaier wrote:
And why shouldn’t just make all those external tools the field names they look
for make configurable on their end?
Instead of trying to satisfy them all with one field defined on KiCad side?
I guess someone who wants to setup a serious BOM workflow should be able to
configure field names on both sides to match…
Just my 2 cents…
Regards,
Bernhard
On 6. Jun 2017, at 18:51, Kristoffer Ödmark <[email protected]>
wrote:
The main reason for the discussion ( From what i gather ) is that external
tools then have a field they know will be there and can all gather around,
since they know what it is called.
I dont really think it needs to be hardcoded as such, it could just be a default preference to the
"JP custom field" table, but then at least there would be some solid ground to parse or
create scripts around, IE anyone can expect that the field "Manufacturer Part Number" (
for example!) is going to be there by default. If it has been renamed or removed, so be it. But it
can reasonably be expected to be there.
The only thing people agreed upon in this long discussion was that there should
be some field that one can expect to hold a Manufacturer part number. The only
way I see this happening (or not) at this point is that someone takes an
executive decision here, and I believe that Wayne should be the one saying yay
or nay, and decide upon a name. Adding it is probably not very hard. I could
take that upon myself, in whatever form it takes.
I also dont think that anyone should have problems creating a script or tool
that parses a field with a spaces in it, if they do have problems with that, I
do not expect that script to be any good anyway :)
Regarding the UPN, I think it was just a compromise about the people wanting a
house part number and the ones who wanted a manufacturer part number.
- Kristoffer
On 2017-06-06 17:48, Fabrizio Tappero wrote:
talking about complains... back on the wild KiCad forum (I did not know existed), people
are kind of "destroying" Kaspar's initiative to make KiCad a better tool.
Kaspar, I personally support your effort but I do not know how since I do not
have any special need in the BOM department. I am happy with JP's custom table.
One the other hand... I would find schematic variants a way more interesting
matter. But that is an other episode of the KiCad series.
cheers
Fabrizio
On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh <[email protected]
<mailto:[email protected]>> wrote:
Are the KiCad library developers planning on providing atomic symbol
libraries? I'm guessing that is the end goal for reserving a name for
an optional field. I cannot think of any other reason to do this.
On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
> Hi!
>
> I will bump this issue again, but to avoid bikesheeding I will ask for a
> decision from leader Wayne. Should there be a default field in kicad for
> part number and if, what should it be named?
It doesn't matter what I decide. Since these are optional fields, users
can choose to ignore, change, or delete them. In my own projects I use
the obvious field name "Manufacturer Part Number".
>
> From what i gather, a field for a part number is the only thing everyone
> agrees on, after that everyone has some different standard and wishes
> for default fields ( Tolerances, fitting, vendors, manufacturer,
> housepart etc etc ).
>
> The name for a part number seem field to most favoured to be MPN or
> ManufacturerPart (differs between github and the user forum), although
> UPN for universal part number was suggested and not flamed.
"MPN" it's not very descriptive (human readable). "ManufacturerPart" is
more descriptive but I'm not thrilled about the camel case name although
I could stomach it. Field names are not programming language syntax.
They can have spaces in them for readability. I'm guessing that someone
is using an application where spaces in the field name causes issues but
I'm not sure that should be a concern for KiCad. I don't much care for
"UPN". Are manufacturer's even talking about a universal part numbering
system? I would be very surprised given that manufacturers do their
best to differentiate there products even if they are functionally
equivalent.
I don't have a strong opinion on this but if I had to pick one of the
choices you have given me, I would pick "ManufacturerPart". Let the
complaining commence. ;)
I hope this helps!
Cheers,
Wayne
>
> Pros:
> Easier with a standard for external tools.
> Every component has one, not every component has values, many
have both.
> Is optional to use, so will not break anything for anyone not
wanting to
> use it
>
> Cons:
> Some are worried the fields will be impossible to keep updated in the
> standard libs
> Some people are using House numbers instead
> Some think this data should not be in the schematic but handled
by other
> tools
>
> Links to discussions I you want to read it:
>
https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28
<https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28>
>
> https://github.com/KiCad/kicad-library/issues/808
<https://github.com/KiCad/kicad-library/issues/808>
>
https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3
<https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3>
>
>
>
> On 2017-01-12 20:12, Kaspar Emanuel wrote:
>> I have put up a proposal for a "community standard" on the forum:
>>
https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1
<https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1>
>>
>> On 12 January 2017 at 18:33, Kaspar Emanuel
<[email protected] <mailto:[email protected]>
>> <mailto:[email protected]
<mailto:[email protected]>>> wrote:
>>
>>
>> On 12 January 2017 at 16:44, Kaspar Emanuel
>> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
>>
>>
>> Is there actually any issue, internally to KiCAD, with
creating
>> multiple fields with the same name? It seems to let me
create
>> two fields called MPN and save and re-open without a
problem.
>>
>>
>> Actually, just tested again and it doesn't like fields with
the same
>> name, it simply overwrites them once you press ok, not sure
what I
>> was doing before. That's a shame.
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
>> Post to : [email protected]
<mailto:[email protected]>
>> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
>> More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> Post to : [email protected]
<mailto:[email protected]>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to : [email protected]
<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
--
-Kristoffer
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
