Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

I agree with all of these points and I am very happy that there now is
a plan! There is one thing I would like clarified for this though. 

Would It be okay to add the suggested template fields as a starting
point for users? Ofcourse without the "silent" adding to symbols and
netlists and boms.

On Tue, 2018-05-29 at 15:55 -0400, Wayne Stambaugh wrote:
> v5 point release:
> 
> Remove the "silent" add template fields behavior from the symbol
> properties dialog.
> 
> Add a button to the symbol properties dialog to add the template
> fields
> to the symbol.
> 
> Add an option in the template field option panel to add the template
> fields to symbols as they are added to the schematic.
> 
> Add a menu command and possibly a toolbar button to add the template
> fields to all symbols in the schematic.
> 
> Any adding of template fields assumes that any duplicate existing
> symbol
> fields will not be overwritten.
> 
> During v6 development, I would like to see the storage of the
> template
> fields moved from the Eeschema config file to the default project
> file.
> This would allow users to define project specific template fields.  I
> could see this being useful for consultants who lay out boards for
> multiple customers with differing BOM requirements.




___
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

Re: [Kicad-developers] More default fields in schematic

[Clemens Koller]

Did anybody consider putting the field name templates / alias / mapping things 
into some project or workspace file which can be individually set and loaded 
based on the user's workflow/preference?
I strongly prefer to have any configuration space like "custom" field names not 
in the schematics unless it's actively put there.

Personal note again:
"Distr", "Distr P/N", "Mfgr", "Mfgr P/N", "Specifications" are not what I would 
prefer to place in the libs/schematics/layouts.

Just for information, I have only the mandatory "attibutes" tied into the EDA 
systems as they are needed/created there:
partname, pcbdecal, ref, value, posx, posy, height, rotation, layer 
(top/bottom/inner{n}), smt (Technology SMT/THT), asy (assembled in assembly 
variant(s) x,y), coat (conformal coated), ...
"partname" is an index into a database. refs are usually unique, except in 
multi-pcb projects or multi-channel designs.

All manufacturer / distributor / procurement / warehouse / life-cycle / 
assembly house annotations / whatever information is retrieved from a database 
with a simple (SLQ-) query like:
SELECT partname, mfg, dist, price, stockqty, stockplace, ... FROM schematics, 
database WHERE schematics.partname=database.partname ... 


Divide and conquer,

Clemens

On 2018-05-29 22:06, Jeff Young wrote:
> Field Name Templates is even better as it’s harder to parse wrong.  
> DefaultField Names vs. Default FieldNames suggest different things, while 
> FieldName Templates and Field NameTemplates have pretty much the same 
> connotation.
> 
> I think we need to remove the values for 5.0, though.  Plus, it will fix the 
> “silent” side-effect as a bonus.  Then anything we do in 6.0 can be 
> considered new features.
> 
>> On 29 May 2018, at 20:55, Wayne Stambaugh  wrote:
>>
>> On 5/29/2018 3:16 PM, Jeff Young wrote:
>>> And one more idea: “Default Field Names” would also be a reasonable thing 
>>> to call these (so it’s clear that the /name/ is a default, not the /field/).
>>
>> Would that be "Field Name Templates"?
>>
>>>
 On 29 May 2018, at 19:56, Jeff Young  wrote:

 Another way to fix the side-effect issue:

 1) Go with the seed field model (we can name them "template fields”).
>>
>> This is my preference.  I would stick with the "template" nomenclature.
>> I think "seed" would be tricky to translate although I could be wrong
>> about that.
>>

 2) Don’t allow setting values for template fields.  If you open the Symbol 
 Properties dialog the names will appear in the field list, but without 
 values.  If you want to add a value then the field is now part of your 
 symbol.  No “silent” adding.  
>>
>> I'm OK with have field values as long as they are not added "silently"
>> to the either the schematic or the netlist output.  I recommend that we
>> revert to the previous behavior for the v5 release (at least it is a
>> known in spite of it's flaws) and reset the associated bug report
>> status.  Then make the following changes early in v6 development for a
>> v5 point release:
>>
>> Remove the "silent" add template fields behavior from the symbol
>> properties dialog.
>>
>> Add a button to the symbol properties dialog to add the template fields
>> to the symbol.
>>
>> Add an option in the template field option panel to add the template
>> fields to symbols as they are added to the schematic.
>>
>> Add a menu command and possibly a toolbar button to add the template
>> fields to all symbols in the schematic.
>>
>> Any adding of template fields assumes that any duplicate existing symbol
>> fields will not be overwritten.
>>
>> During v6 development, I would like to see the storage of the template
>> fields moved from the Eeschema config file to the default project file.
>> This would allow users to define project specific template fields.  I
>> could see this being useful for consultants who lay out boards for
>> multiple customers with differing BOM requirements.
>>

 The internal struct name (TEMPLATE_FIELDNAME) suggests this might have 
 been the intention at some point.

 This walks a fine line on the string freeze.  We need to change the dialog 
 to Template Fields, but as they were named that earlier the translation 
 keys might already be in the dictionaries.
>>
>> It's possible the old template strings are still around in the
>> translation files but I suspect not.
>>

> On 29 May 2018, at 19:38, Jeff Young  wrote:
>
> We really must choose a model.  What we have is broken under either model.
>
> If they’re “default” fields, then they need to be there by default.  
> That’s what “default” means.  I understand this isn’t the model you have 
> in mind.
>
> The alternative is “seed” (or “template”) fields.  In this model they 
> must be added by the user.  But that’s NOT what the code does (either 
> before or after the recent change).  If you edit a symbol they are 
> *silently* added (as if they 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

Field Name Templates is even better as it’s harder to parse wrong.  
DefaultField Names vs. Default FieldNames suggest different things, while 
FieldName Templates and Field NameTemplates have pretty much the same 
connotation.

I think we need to remove the values for 5.0, though.  Plus, it will fix the 
“silent” side-effect as a bonus.  Then anything we do in 6.0 can be considered 
new features.

> On 29 May 2018, at 20:55, Wayne Stambaugh  wrote:
> 
> On 5/29/2018 3:16 PM, Jeff Young wrote:
>> And one more idea: “Default Field Names” would also be a reasonable thing to 
>> call these (so it’s clear that the /name/ is a default, not the /field/).
> 
> Would that be "Field Name Templates"?
> 
>> 
>>> On 29 May 2018, at 19:56, Jeff Young  wrote:
>>> 
>>> Another way to fix the side-effect issue:
>>> 
>>> 1) Go with the seed field model (we can name them "template fields”).
> 
> This is my preference.  I would stick with the "template" nomenclature.
> I think "seed" would be tricky to translate although I could be wrong
> about that.
> 
>>> 
>>> 2) Don’t allow setting values for template fields.  If you open the Symbol 
>>> Properties dialog the names will appear in the field list, but without 
>>> values.  If you want to add a value then the field is now part of your 
>>> symbol.  No “silent” adding.  
> 
> I'm OK with have field values as long as they are not added "silently"
> to the either the schematic or the netlist output.  I recommend that we
> revert to the previous behavior for the v5 release (at least it is a
> known in spite of it's flaws) and reset the associated bug report
> status.  Then make the following changes early in v6 development for a
> v5 point release:
> 
> Remove the "silent" add template fields behavior from the symbol
> properties dialog.
> 
> Add a button to the symbol properties dialog to add the template fields
> to the symbol.
> 
> Add an option in the template field option panel to add the template
> fields to symbols as they are added to the schematic.
> 
> Add a menu command and possibly a toolbar button to add the template
> fields to all symbols in the schematic.
> 
> Any adding of template fields assumes that any duplicate existing symbol
> fields will not be overwritten.
> 
> During v6 development, I would like to see the storage of the template
> fields moved from the Eeschema config file to the default project file.
> This would allow users to define project specific template fields.  I
> could see this being useful for consultants who lay out boards for
> multiple customers with differing BOM requirements.
> 
>>> 
>>> The internal struct name (TEMPLATE_FIELDNAME) suggests this might have been 
>>> the intention at some point.
>>> 
>>> This walks a fine line on the string freeze.  We need to change the dialog 
>>> to Template Fields, but as they were named that earlier the translation 
>>> keys might already be in the dictionaries.
> 
> It's possible the old template strings are still around in the
> translation files but I suspect not.
> 
>>> 
 On 29 May 2018, at 19:38, Jeff Young  wrote:
 
 We really must choose a model.  What we have is broken under either model.
 
 If they’re “default” fields, then they need to be there by default.  
 That’s what “default” means.  I understand this isn’t the model you have 
 in mind.
 
 The alternative is “seed” (or “template”) fields.  In this model they must 
 be added by the user.  But that’s NOT what the code does (either before or 
 after the recent change).  If you edit a symbol they are *silently* added 
 (as if they were default fields).  If you understand the model to be seed 
 fields, and all you did was change the symbol orientation, having the seed 
 fields added will be VERY surprising.
 
 This is why I suggested earlier that if we want to treat them as seed 
 fields then we need a button in the Symbol Properties dialog to add the 
 fields.  That way it’s clear to everyone what is happening.
 
> On 29 May 2018, at 16:30, Wayne Stambaugh  wrote:
> 
> I figured out what is going on here.  There are two distinct issues at 
> play.
> 
> It appears that all of the python BOM generation scripts[1] are adding
> non-mandatory fields even if the fields do not exist in the the generic
> (XML) netlist file.  These should be fixed.  I have no idea how much
> work this will be but a quick scan would suggest that it wouldn't be too
> difficult.  I suspect these were provided as examples to create your own
> scripts.  Used as is, they will add extra empty field columns to the
> BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
> long as the default field does not have a value associated with it, the
> generic netlist file does not contain any unexpected field information.
> 
> However, if a default field contains a value then it is added to the
> default netlist even 

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

On 5/29/2018 3:16 PM, Jeff Young wrote:
> And one more idea: “Default Field Names” would also be a reasonable thing to 
> call these (so it’s clear that the /name/ is a default, not the /field/).

Would that be "Field Name Templates"?

> 
>> On 29 May 2018, at 19:56, Jeff Young  wrote:
>>
>> Another way to fix the side-effect issue:
>>
>> 1) Go with the seed field model (we can name them "template fields”).

This is my preference.  I would stick with the "template" nomenclature.
I think "seed" would be tricky to translate although I could be wrong
about that.

>>
>> 2) Don’t allow setting values for template fields.  If you open the Symbol 
>> Properties dialog the names will appear in the field list, but without 
>> values.  If you want to add a value then the field is now part of your 
>> symbol.  No “silent” adding.  

I'm OK with have field values as long as they are not added "silently"
to the either the schematic or the netlist output.  I recommend that we
revert to the previous behavior for the v5 release (at least it is a
known in spite of it's flaws) and reset the associated bug report
status.  Then make the following changes early in v6 development for a
v5 point release:

Remove the "silent" add template fields behavior from the symbol
properties dialog.

Add a button to the symbol properties dialog to add the template fields
to the symbol.

Add an option in the template field option panel to add the template
fields to symbols as they are added to the schematic.

Add a menu command and possibly a toolbar button to add the template
fields to all symbols in the schematic.

Any adding of template fields assumes that any duplicate existing symbol
fields will not be overwritten.

During v6 development, I would like to see the storage of the template
fields moved from the Eeschema config file to the default project file.
This would allow users to define project specific template fields.  I
could see this being useful for consultants who lay out boards for
multiple customers with differing BOM requirements.

>>
>> The internal struct name (TEMPLATE_FIELDNAME) suggests this might have been 
>> the intention at some point.
>>
>> This walks a fine line on the string freeze.  We need to change the dialog 
>> to Template Fields, but as they were named that earlier the translation keys 
>> might already be in the dictionaries.

It's possible the old template strings are still around in the
translation files but I suspect not.

>>
>>> On 29 May 2018, at 19:38, Jeff Young  wrote:
>>>
>>> We really must choose a model.  What we have is broken under either model.
>>>
>>> If they’re “default” fields, then they need to be there by default.  That’s 
>>> what “default” means.  I understand this isn’t the model you have in mind.
>>>
>>> The alternative is “seed” (or “template”) fields.  In this model they must 
>>> be added by the user.  But that’s NOT what the code does (either before or 
>>> after the recent change).  If you edit a symbol they are *silently* added 
>>> (as if they were default fields).  If you understand the model to be seed 
>>> fields, and all you did was change the symbol orientation, having the seed 
>>> fields added will be VERY surprising.
>>>
>>> This is why I suggested earlier that if we want to treat them as seed 
>>> fields then we need a button in the Symbol Properties dialog to add the 
>>> fields.  That way it’s clear to everyone what is happening.
>>>
 On 29 May 2018, at 16:30, Wayne Stambaugh  wrote:

 I figured out what is going on here.  There are two distinct issues at 
 play.

 It appears that all of the python BOM generation scripts[1] are adding
 non-mandatory fields even if the fields do not exist in the the generic
 (XML) netlist file.  These should be fixed.  I have no idea how much
 work this will be but a quick scan would suggest that it wouldn't be too
 difficult.  I suspect these were provided as examples to create your own
 scripts.  Used as is, they will add extra empty field columns to the
 BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
 long as the default field does not have a value associated with it, the
 generic netlist file does not contain any unexpected field information.

 However, if a default field contains a value then it is added to the
 default netlist even if none of the symbols contain said field.  This is
 where I take exception.  The generic netlist file should only contain
 fields that are defined in the symbols.  The assumption that the netlist
 should contain default fields if the are not empty is broken.  This will
 lead to corrupted BOMs for existing projects which is not acceptable.
 This change needs to be reverted.  I know that it was done to fix a bug
 report but this is not an acceptable solution for the bug.  We can push
 that bug fix off until the first v5 point release or v6 because it will
 require a feature 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

And one more idea: “Default Field Names” would also be a reasonable thing to 
call these (so it’s clear that the /name/ is a default, not the /field/).

> On 29 May 2018, at 19:56, Jeff Young  wrote:
> 
> Another way to fix the side-effect issue:
> 
> 1) Go with the seed field model (we can name them "template fields”).
> 
> 2) Don’t allow setting values for template fields.  If you open the Symbol 
> Properties dialog the names will appear in the field list, but without 
> values.  If you want to add a value then the field is now part of your 
> symbol.  No “silent” adding.  
> 
> The internal struct name (TEMPLATE_FIELDNAME) suggests this might have been 
> the intention at some point.
> 
> This walks a fine line on the string freeze.  We need to change the dialog to 
> Template Fields, but as they were named that earlier the translation keys 
> might already be in the dictionaries.
> 
>> On 29 May 2018, at 19:38, Jeff Young  wrote:
>> 
>> We really must choose a model.  What we have is broken under either model.
>> 
>> If they’re “default” fields, then they need to be there by default.  That’s 
>> what “default” means.  I understand this isn’t the model you have in mind.
>> 
>> The alternative is “seed” (or “template”) fields.  In this model they must 
>> be added by the user.  But that’s NOT what the code does (either before or 
>> after the recent change).  If you edit a symbol they are *silently* added 
>> (as if they were default fields).  If you understand the model to be seed 
>> fields, and all you did was change the symbol orientation, having the seed 
>> fields added will be VERY surprising.
>> 
>> This is why I suggested earlier that if we want to treat them as seed fields 
>> then we need a button in the Symbol Properties dialog to add the fields.  
>> That way it’s clear to everyone what is happening.
>> 
>>> On 29 May 2018, at 16:30, Wayne Stambaugh  wrote:
>>> 
>>> I figured out what is going on here.  There are two distinct issues at play.
>>> 
>>> It appears that all of the python BOM generation scripts[1] are adding
>>> non-mandatory fields even if the fields do not exist in the the generic
>>> (XML) netlist file.  These should be fixed.  I have no idea how much
>>> work this will be but a quick scan would suggest that it wouldn't be too
>>> difficult.  I suspect these were provided as examples to create your own
>>> scripts.  Used as is, they will add extra empty field columns to the
>>> BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
>>> long as the default field does not have a value associated with it, the
>>> generic netlist file does not contain any unexpected field information.
>>> 
>>> However, if a default field contains a value then it is added to the
>>> default netlist even if none of the symbols contain said field.  This is
>>> where I take exception.  The generic netlist file should only contain
>>> fields that are defined in the symbols.  The assumption that the netlist
>>> should contain default fields if the are not empty is broken.  This will
>>> lead to corrupted BOMs for existing projects which is not acceptable.
>>> This change needs to be reverted.  I know that it was done to fix a bug
>>> report but this is not an acceptable solution for the bug.  We can push
>>> that bug fix off until the first v5 point release or v6 because it will
>>> require a feature change to fix.
>>> 
>>> [1]: https://git.launchpad.net/kicad/tree/eeschema/plugins/python_scripts
>>> 
>>> On 5/29/2018 10:12 AM, Jeff Young wrote:
 Hi Reece,
 
 Was that generated with a recent build?  Earlier versions of 5.0
 certainly had that bug, but I’m pretty sure it’s been fixed.
 
 Cheers,
 Jeff.
 
 
> On 29 May 2018, at 13:54, Reece R. Pollack  > wrote:
> 
> On 05/29/18 08:27, Jeff Young wrote:
>> Comments inline:
>> 
>>> On 28 May 2018, at 17:28, Reece R. Pollack >> > wrote:
>>> 
>>> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
>>> 
>>> I have five custom default fields defined:
>>> - Mfgr
>>> - Mfgr P/N
>>> - Dist
>>> - Dist P/N
>>> - Specifications
>> 
>> None of these have any default values that make any sense, so I
>> assume they’re all just names with empty values, right?
> 
> Yes, all of these are empty by default, though I typically order from
> DigiKey so I could have set that one. I added them as "Default Fields"
> so that all components would have the same fields, and I wouldn't have
> to depend on adding the field names by hand.
> 
>> 
>>> 
>>> The first two give the manufacturer's name and part number; the
>>> second two give the distributor's name and part number; the third is
>>> a catch-all for specs that are important for ordering but aren't
>>> worth cluttering the schematic with.
>>> 
>>> My biggest issue with the current 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

Another way to fix the side-effect issue:

1) Go with the seed field model (we can name them "template fields”).

2) Don’t allow setting values for template fields.  If you open the Symbol 
Properties dialog the names will appear in the field list, but without values.  
If you want to add a value then the field is now part of your symbol.  No 
“silent” adding.  

The internal struct name (TEMPLATE_FIELDNAME) suggests this might have been the 
intention at some point.

This walks a fine line on the string freeze.  We need to change the dialog to 
Template Fields, but as they were named that earlier the translation keys might 
already be in the dictionaries.

> On 29 May 2018, at 19:38, Jeff Young  wrote:
> 
> We really must choose a model.  What we have is broken under either model.
> 
> If they’re “default” fields, then they need to be there by default.  That’s 
> what “default” means.  I understand this isn’t the model you have in mind.
> 
> The alternative is “seed” (or “template”) fields.  In this model they must be 
> added by the user.  But that’s NOT what the code does (either before or after 
> the recent change).  If you edit a symbol they are *silently* added (as if 
> they were default fields).  If you understand the model to be seed fields, 
> and all you did was change the symbol orientation, having the seed fields 
> added will be VERY surprising.
> 
> This is why I suggested earlier that if we want to treat them as seed fields 
> then we need a button in the Symbol Properties dialog to add the fields.  
> That way it’s clear to everyone what is happening.
> 
>> On 29 May 2018, at 16:30, Wayne Stambaugh  wrote:
>> 
>> I figured out what is going on here.  There are two distinct issues at play.
>> 
>> It appears that all of the python BOM generation scripts[1] are adding
>> non-mandatory fields even if the fields do not exist in the the generic
>> (XML) netlist file.  These should be fixed.  I have no idea how much
>> work this will be but a quick scan would suggest that it wouldn't be too
>> difficult.  I suspect these were provided as examples to create your own
>> scripts.  Used as is, they will add extra empty field columns to the
>> BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
>> long as the default field does not have a value associated with it, the
>> generic netlist file does not contain any unexpected field information.
>> 
>> However, if a default field contains a value then it is added to the
>> default netlist even if none of the symbols contain said field.  This is
>> where I take exception.  The generic netlist file should only contain
>> fields that are defined in the symbols.  The assumption that the netlist
>> should contain default fields if the are not empty is broken.  This will
>> lead to corrupted BOMs for existing projects which is not acceptable.
>> This change needs to be reverted.  I know that it was done to fix a bug
>> report but this is not an acceptable solution for the bug.  We can push
>> that bug fix off until the first v5 point release or v6 because it will
>> require a feature change to fix.
>> 
>> [1]: https://git.launchpad.net/kicad/tree/eeschema/plugins/python_scripts
>> 
>> On 5/29/2018 10:12 AM, Jeff Young wrote:
>>> Hi Reece,
>>> 
>>> Was that generated with a recent build?  Earlier versions of 5.0
>>> certainly had that bug, but I’m pretty sure it’s been fixed.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 29 May 2018, at 13:54, Reece R. Pollack >>> > wrote:
 
 On 05/29/18 08:27, Jeff Young wrote:
> Comments inline:
> 
>> On 28 May 2018, at 17:28, Reece R. Pollack > > wrote:
>> 
>> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
>> 
>> I have five custom default fields defined:
>> - Mfgr
>> - Mfgr P/N
>> - Dist
>> - Dist P/N
>> - Specifications
> 
> None of these have any default values that make any sense, so I
> assume they’re all just names with empty values, right?
 
 Yes, all of these are empty by default, though I typically order from
 DigiKey so I could have set that one. I added them as "Default Fields"
 so that all components would have the same fields, and I wouldn't have
 to depend on adding the field names by hand.
 
> 
>> 
>> The first two give the manufacturer's name and part number; the
>> second two give the distributor's name and part number; the third is
>> a catch-all for specs that are important for ordering but aren't
>> worth cluttering the schematic with.
>> 
>> My biggest issue with the current Default Fields is that I didn't
>> start my current project with them, so using the field edit
>> spreadsheet-like thingie often results in lots of noise in my
>> commits as the empty default fields get added to components.
> 
> If it’s adding empty default fields then it’s a bug.  It should only
> 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

We really must choose a model.  What we have is broken under either model.

If they’re “default” fields, then they need to be there by default.  That’s 
what “default” means.  I understand this isn’t the model you have in mind.

The alternative is “seed” (or “template”) fields.  In this model they must be 
added by the user.  But that’s NOT what the code does (either before or after 
the recent change).  If you edit a symbol they are *silently* added (as if they 
were default fields).  If you understand the model to be seed fields, and all 
you did was change the symbol orientation, having the seed fields added will be 
VERY surprising.

This is why I suggested earlier that if we want to treat them as seed fields 
then we need a button in the Symbol Properties dialog to add the fields.  That 
way it’s clear to everyone what is happening.

> On 29 May 2018, at 16:30, Wayne Stambaugh  wrote:
> 
> I figured out what is going on here.  There are two distinct issues at play.
> 
> It appears that all of the python BOM generation scripts[1] are adding
> non-mandatory fields even if the fields do not exist in the the generic
> (XML) netlist file.  These should be fixed.  I have no idea how much
> work this will be but a quick scan would suggest that it wouldn't be too
> difficult.  I suspect these were provided as examples to create your own
> scripts.  Used as is, they will add extra empty field columns to the
> BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
> long as the default field does not have a value associated with it, the
> generic netlist file does not contain any unexpected field information.
> 
> However, if a default field contains a value then it is added to the
> default netlist even if none of the symbols contain said field.  This is
> where I take exception.  The generic netlist file should only contain
> fields that are defined in the symbols.  The assumption that the netlist
> should contain default fields if the are not empty is broken.  This will
> lead to corrupted BOMs for existing projects which is not acceptable.
> This change needs to be reverted.  I know that it was done to fix a bug
> report but this is not an acceptable solution for the bug.  We can push
> that bug fix off until the first v5 point release or v6 because it will
> require a feature change to fix.
> 
> [1]: https://git.launchpad.net/kicad/tree/eeschema/plugins/python_scripts
> 
> On 5/29/2018 10:12 AM, Jeff Young wrote:
>> Hi Reece,
>> 
>> Was that generated with a recent build?  Earlier versions of 5.0
>> certainly had that bug, but I’m pretty sure it’s been fixed.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 29 May 2018, at 13:54, Reece R. Pollack >> > wrote:
>>> 
>>> On 05/29/18 08:27, Jeff Young wrote:
 Comments inline:
 
> On 28 May 2018, at 17:28, Reece R. Pollack  > wrote:
> 
> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
> 
> I have five custom default fields defined:
>  - Mfgr
>  - Mfgr P/N
>  - Dist
>  - Dist P/N
>  - Specifications
 
 None of these have any default values that make any sense, so I
 assume they’re all just names with empty values, right?
>>> 
>>> Yes, all of these are empty by default, though I typically order from
>>> DigiKey so I could have set that one. I added them as "Default Fields"
>>> so that all components would have the same fields, and I wouldn't have
>>> to depend on adding the field names by hand.
>>> 
 
> 
> The first two give the manufacturer's name and part number; the
> second two give the distributor's name and part number; the third is
> a catch-all for specs that are important for ordering but aren't
> worth cluttering the schematic with.
> 
> My biggest issue with the current Default Fields is that I didn't
> start my current project with them, so using the field edit
> spreadsheet-like thingie often results in lots of noise in my
> commits as the empty default fields get added to components.
 
 If it’s adding empty default fields then it’s a bug.  It should only
 add them if they have non-empty values.
>>> 
>>> Then you have a bug. Here's a small excerpt from a Git diff where a
>>> lot of components had empty fields added. None of these components
>>> were added in this revision; I was simply setting part numbers for
>>> /other/ components using the field editor spreadsheet thingie:
>>> 
>>> diff --git a/Recreation/P170-DH/pcb/P170-DH
>>> Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH
>>> Replacement/ExternalInterface.sch
>>> index 37482ee..e2aea43 100644
>>> --- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
>>> +++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
>>> @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
>>>  F 1 "74LVC1T45" H 3900 2124 50   C CNN
>>>  F 2 

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

I figured out what is going on here.  There are two distinct issues at play.

It appears that all of the python BOM generation scripts[1] are adding
non-mandatory fields even if the fields do not exist in the the generic
(XML) netlist file.  These should be fixed.  I have no idea how much
work this will be but a quick scan would suggest that it wouldn't be too
difficult.  I suspect these were provided as examples to create your own
scripts.  Used as is, they will add extra empty field columns to the
BOM.  BOMs generated with xsltproc do not exhibit this issue so the as
long as the default field does not have a value associated with it, the
generic netlist file does not contain any unexpected field information.

However, if a default field contains a value then it is added to the
default netlist even if none of the symbols contain said field.  This is
where I take exception.  The generic netlist file should only contain
fields that are defined in the symbols.  The assumption that the netlist
should contain default fields if the are not empty is broken.  This will
lead to corrupted BOMs for existing projects which is not acceptable.
This change needs to be reverted.  I know that it was done to fix a bug
report but this is not an acceptable solution for the bug.  We can push
that bug fix off until the first v5 point release or v6 because it will
require a feature change to fix.

[1]: https://git.launchpad.net/kicad/tree/eeschema/plugins/python_scripts

On 5/29/2018 10:12 AM, Jeff Young wrote:
> Hi Reece,
> 
> Was that generated with a recent build?  Earlier versions of 5.0
> certainly had that bug, but I’m pretty sure it’s been fixed.
> 
> Cheers,
> Jeff.
> 
> 
>> On 29 May 2018, at 13:54, Reece R. Pollack > > wrote:
>>
>> On 05/29/18 08:27, Jeff Young wrote:
>>> Comments inline:
>>>
 On 28 May 2018, at 17:28, Reece R. Pollack >>> > wrote:

 I believe you owe me 2c. We can discuss 2c in which currency later. :-)

 I have five custom default fields defined:
  - Mfgr
  - Mfgr P/N
  - Dist
  - Dist P/N
  - Specifications
>>>
>>> None of these have any default values that make any sense, so I
>>> assume they’re all just names with empty values, right?
>>
>> Yes, all of these are empty by default, though I typically order from
>> DigiKey so I could have set that one. I added them as "Default Fields"
>> so that all components would have the same fields, and I wouldn't have
>> to depend on adding the field names by hand.
>>
>>>

 The first two give the manufacturer's name and part number; the
 second two give the distributor's name and part number; the third is
 a catch-all for specs that are important for ordering but aren't
 worth cluttering the schematic with.

 My biggest issue with the current Default Fields is that I didn't
 start my current project with them, so using the field edit
 spreadsheet-like thingie often results in lots of noise in my
 commits as the empty default fields get added to components.
>>>
>>> If it’s adding empty default fields then it’s a bug.  It should only
>>> add them if they have non-empty values.
>>
>> Then you have a bug. Here's a small excerpt from a Git diff where a
>> lot of components had empty fields added. None of these components
>> were added in this revision; I was simply setting part numbers for
>> /other/ components using the field editor spreadsheet thingie:
>>
>> diff --git a/Recreation/P170-DH/pcb/P170-DH
>> Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH
>> Replacement/ExternalInterface.sch
>> index 37482ee..e2aea43 100644
>> --- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
>> +++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
>> @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
>>  F 1 "74LVC1T45" H 3900 2124 50   C CNN
>>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
>>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850
>> 50  0001 C CNN
>> +F 4 "" H 0   0   50  0001 C CNN "Distr"
>> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
>> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
>> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
>> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>>     1    3900 1850
>>     1    0    0    -1 
>>  $EndComp
>> @@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
>>  F 1 "74LVC1T45" H 3900 3324 50   C CNN
>>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
>>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050
>> 50  0001 C CNN
>> +F 4 "" H 0   0   50  0001 C CNN "Distr"
>> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
>> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
>> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
>> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>>     1    3900 3050
>>     1    0    0    -1 
>>  $EndComp
>> @@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50  

Re: [Kicad-developers] More default fields in schematic

[Reece R. Pollack]

That was from a commit I made on 5/24. It looks like I was using a build 
derived from your commit of 5/20:

    3a8a718 A pesky bug, this one is.  (Said in best Yoda impression.)


On 05/29/18 10:12, Jeff Young wrote:

Hi Reece,

Was that generated with a recent build?  Earlier versions of 5.0 
certainly had that bug, but I’m pretty sure it’s been fixed.


Cheers,
Jeff.


On 29 May 2018, at 13:54, Reece R. Pollack > wrote:


On 05/29/18 08:27, Jeff Young wrote:

Comments inline:

On 28 May 2018, at 17:28, Reece R. Pollack > wrote:


I believe you owe me 2c. We can discuss 2c in which currency later. :-)

I have five custom default fields defined:
 - Mfgr
 - Mfgr P/N
 - Dist
 - Dist P/N
 - Specifications


None of these have any default values that make any sense, so I 
assume they’re all just names with empty values, right?


Yes, all of these are empty by default, though I typically order from 
DigiKey so I could have set that one. I added them as "Default 
Fields" so that all components would have the same fields, and I 
wouldn't have to depend on adding the field names by hand.






The first two give the manufacturer's name and part number; the 
second two give the distributor's name and part number; the third 
is a catch-all for specs that are important for ordering but aren't 
worth cluttering the schematic with.


My biggest issue with the current Default Fields is that I didn't 
start my current project with them, so using the field edit 
spreadsheet-like thingie often results in lots of noise in my 
commits as the empty default fields get added to components.


If it’s adding empty default fields then it’s a bug.  It should only 
add them if they have non-empty values.


Then you have a bug. Here's a small excerpt from a Git diff where a 
lot of components had empty fields added. None of these components 
were added in this revision; I was simply setting part numbers for 
/other/ components using the field editor spreadsheet thingie:


diff --git a/Recreation/P170-DH/pcb/P170-DH 
Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH 
Replacement/ExternalInterface.sch

index 37482ee..e2aea43 100644
--- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
+++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
@@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
 F 1 "74LVC1T45" H 3900 2124 50   C CNN
 F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
 F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850 
50  0001 C CNN

+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 1850
    1    0    0    -1
 $EndComp
@@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
 F 1 "74LVC1T45" H 3900 3324 50   C CNN
 F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
 F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050 
50  0001 C CNN

+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 3050
    1    0    0    -1
 $EndComp
@@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
 F 1 "Conn_01x06" H 7719 1466 50   C CNN
 F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H 
7800 1900 50  0001 C CNN

 F 3 "~" H 7800 1900 50  0001 C CNN
+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    7800 1900
    1    0    0    -1
 $EndComp
@@ -209,6 +234,7 @@ F 4 "CTS" H 3900 7100 50  0001 C CNN "Mfgr"
 F 5 "218-4LPST" H 3900 7100 50  0001 C CNN "Mfgr P/N"
 F 6 "DigiKey" H 3900 7100 50  0001 C CNN "Distr"
 F 7 "CT2184LPST-ND" H 3900 7100 50  0001 C CNN "Distr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 7100
    1    0    0    -1
 $EndComp
@@ -321,6 +347,11 @@ F 0 "R127" H 4509 5746 50   L CNN
 F 1 "100K" H 4509 5655 50   L CNN
 F 2 "Resistor_SMD:R_0603_1608Metric" H 4450 5700 50 0001 C CNN
 F 3 "~" H 4450 5700 50  0001 C CNN
+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    4450 5700
    1    0    0    -1
 $EndComp






Cheers,
Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : 

Re: [Kicad-developers] More default fields in schematic

[kristofferodmark90]

On Tue, 2018-05-29 at 15:25 +0200, Clemens Koller wrote:
> Hello!
> 
> Please don't add manufacturer/distributor's information / procurement
> informtion which will end up in the schematics as some empty or non-
> empty defaults.
> Or add them as invisible/all off by default.

It will not be added there, and I cannot even see why that would be a
problem? Empty fields in a file, adding maybe a few kb to each
schematic? 

> This will spoil version management on schematics level and supports
> merging responsibilities of the design-correctness (choosing parts
> and manufacturer(s) and their part no. to fit, incl. a coice of
> second source components) with responsibilities of the procurement
> (choosing dists / sourcing partners).

No it will not, It should not be added to the files unless you
specifically set them, neither will it enforce you to start adding them
or anything. It will suggest for those people who do use them that
these names are recommended. 

> 
> [...]
> 
> Regards,
> 
> Clemens
> 
> 
> On 2018-05-29 14:54, Reece R. Pollack wrote:
> > On 05/29/18 08:27, Jeff Young wrote:
> > > Comments inline:
> > > 
> > > > On 28 May 2018, at 17:28, Reece R. Pollack  > > > > wrote:
> > > > 
> > > > I believe you owe me 2c. We can discuss 2c in which currency
> > > > later. :-)
> > > > 
> > > > I have five custom default fields defined:
> > > >  - Mfgr
> > > >  - Mfgr P/N
> > > >  - Dist
> > > >  - Dist P/N
> > > >  - Specifications
> > > 
> > > None of these have any default values that make any sense, so I
> > > assume they’re all just names with empty values, right?
> > 
> > Yes, all of these are empty by default, though I typically order
> > from DigiKey so I could have set that one. I added them as "Default
> > Fields" so that all components would have the same fields, and I
> > wouldn't have to depend on adding the field names by hand.
> > 
> > > 
> > > > 
> > > > The first two give the manufacturer's name and part number; the
> > > > second two give the distributor's name and part number; the
> > > > third is a catch-all for specs that are important for ordering
> > > > but aren't worth cluttering the schematic with.
> > > > 
> > > > My biggest issue with the current Default Fields is that I
> > > > didn't start my current project with them, so using the field
> > > > edit spreadsheet-like thingie often results in lots of noise in
> > > > my commits as the empty default fields get added to components.
> > > 
> > > If it’s adding empty default fields then it’s a bug.  It should
> > > only add them if they have non-empty values.
> > 
> > Then you have a bug. Here's a small excerpt from a Git diff where a
> > lot of components had empty fields added. None of these components
> > were added in this revision; I was simply setting part numbers for
> > /other/ components using the field editor spreadsheet thingie:
> > 
> > diff --git a/Recreation/P170-DH/pcb/P170-DH
> > Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH
> > Replacement/ExternalInterface.sch
> > index 37482ee..e2aea43 100644
> > --- a/Recreation/P170-DH/pcb/P170-DH
> > Replacement/ExternalInterface.sch 
> > +++ b/Recreation/P170-DH/pcb/P170-DH
> > Replacement/ExternalInterface.sch 
> > @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
> >  F 1 "74LVC1T45" H 3900 2124 50   C CNN
> >  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
> >  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850
> > 50  0001 C CNN
> > +F 4 "" H 0   0   50  0001 C CNN "Distr"
> > +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> > +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> > +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> > +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> > 13900 1850
> > 100-1 
> >  $EndComp
> > @@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
> >  F 1 "74LVC1T45" H 3900 3324 50   C CNN
> >  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
> >  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050
> > 50  0001 C CNN
> > +F 4 "" H 0   0   50  0001 C CNN "Distr"
> > +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> > +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> > +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> > +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> > 13900 3050
> > 100-1 
> >  $EndComp
> > @@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
> >  F 1 "Conn_01x06" H 7719 1466 50   C CNN
> >  F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H
> > 7800 1900 50  0001 C CNN
> >  F 3 "~" H 7800 1900 50  0001 C CNN
> > +F 4 "" H 0   0   50  0001 C CNN "Distr"
> > +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> > +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> > +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> > +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> > 17800 1900
> > 100-1 
> >  $EndComp
> > @@ -209,6 +234,7 @@ F 4 "CTS" H 3900 

Re: [Kicad-developers] More default fields in schematic

[kristofferodmark90]

I just tested this, I cannot reproduce it. No empty fields were added
for me.

- Kristoffer

On Tue, 2018-05-29 at 08:54 -0400, Reece R. Pollack wrote:
> On 05/29/18 08:27, Jeff Young wrote:
> > Comments inline:
> > 
> > > On 28 May 2018, at 17:28, Reece R. Pollack  wrote:
> > > 
> > > I believe you owe me 2c. We can discuss 2c in which currency
> > > later. :-)
> > > 
> > > I have five custom default fields defined:
> > >  - Mfgr
> > >  - Mfgr P/N
> > >  - Dist
> > >  - Dist P/N
> > >  - Specifications
> > 
> > None of these have any default values that make any sense, so I
> > assume they’re all just names with empty values, right?
>  
> Yes, all of these are empty by default, though I typically order from
> DigiKey so I could have set that one. I added them as "Default
> Fields" so that all components would have the same fields, and I
> wouldn't have to depend on adding the field names by hand. 
> 
> > > The first two give the manufacturer's name and part number; the
> > > second two give the distributor's name and part number; the third
> > > is a catch-all for specs that are important for ordering but
> > > aren't worth cluttering the schematic with.
> > > 
> > > My biggest issue with the current Default Fields is that I didn't
> > > start my current project with them, so using the field edit
> > > spreadsheet-like thingie often results in lots of noise in my
> > > commits as the empty default fields get added to components.
> > 
> > If it’s adding empty default fields then it’s a bug.  It should
> > only add them if they have non-empty values.
>  
> Then you have a bug. Here's a small excerpt from a Git diff where a
> lot of components had empty fields added. None of these components
> were added in this revision; I was simply setting part numbers for
> other components using the field editor spreadsheet thingie:
> 
> diff --git a/Recreation/P170-DH/pcb/P170-DH
> Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH
> Replacement/ExternalInterface.sch
> index 37482ee..e2aea43 100644
> --- a/Recreation/P170-DH/pcb/P170-DH
> Replacement/ExternalInterface.sch  
> +++ b/Recreation/P170-DH/pcb/P170-DH
> Replacement/ExternalInterface.sch  
> @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
>  F 1 "74LVC1T45" H 3900 2124 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850
> 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> 13900 1850
> 100-1  
>  $EndComp
> @@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
>  F 1 "74LVC1T45" H 3900 3324 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050
> 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> 13900 3050
> 100-1  
>  $EndComp
> @@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
>  F 1 "Conn_01x06" H 7719 1466 50   C CNN
>  F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H
> 7800 1900 50  0001 C CNN
>  F 3 "~" H 7800 1900 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> 17800 1900
> 100-1  
>  $EndComp
> @@ -209,6 +234,7 @@ F 4 "CTS" H 3900 7100 50  0001 C CNN "Mfgr"
>  F 5 "218-4LPST" H 3900 7100 50  0001 C CNN "Mfgr P/N"
>  F 6 "DigiKey" H 3900 7100 50  0001 C CNN "Distr"
>  F 7 "CT2184LPST-ND" H 3900 7100 50  0001 C CNN "Distr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> 13900 7100
> 100-1  
>  $EndComp
> @@ -321,6 +347,11 @@ F 0 "R127" H 4509 5746 50   L CNN
>  F 1 "100K" H 4509 5655 50   L CNN
>  F 2 "Resistor_SMD:R_0603_1608Metric" H 4450 5700 50  0001 C CNN
>  F 3 "~" H 4450 5700 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
> 14450 5700
> 100-1  
>  $EndComp
> 
> 
> 
> 
> > Cheers,
> > Jeff.
> > 
> > > I was originally against adding such defined fields, as I expect
> > > it will add fields to components that will potentially conflict
> > > with those created by current users. However, if it doesn't do
> > > that, and has the support from parts distributors, I 

Re: [Kicad-developers] More default fields in schematic

[Clemens Koller]

Hello!

Please don't add manufacturer/distributor's information / procurement 
informtion which will end up in the schematics as some empty or non-empty 
defaults.
Or add them as invisible/all off by default.

This will spoil version management on schematics level and supports merging 
responsibilities of the design-correctness (choosing parts and manufacturer(s) 
and their part no. to fit, incl. a coice of second source components) with 
responsibilities of the procurement (choosing dists / sourcing partners).

When you want to implement some version management and/or some product 
life-cycle management / obsolescence-management, you will very likely end up in 
a maintenance nightmare in big projects.
It became also more common that manufacturer names and mfg part numbers keep 
changing over the lifetime od a design. See: 
Motorola->Freescale->NXP(->Qualcomm?) chain of aquisitions.

I strongly suggest to split the design data from the manufacturer data from the 
dist/supply chain data.
It is so easy to put some database connectivity in between to link these 
together to stay flexible.

Regards,

Clemens


On 2018-05-29 14:54, Reece R. Pollack wrote:
> On 05/29/18 08:27, Jeff Young wrote:
>> Comments inline:
>>
>>> On 28 May 2018, at 17:28, Reece R. Pollack >> > wrote:
>>>
>>> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
>>>
>>> I have five custom default fields defined:
>>>  - Mfgr
>>>  - Mfgr P/N
>>>  - Dist
>>>  - Dist P/N
>>>  - Specifications
>>
>> None of these have any default values that make any sense, so I assume 
>> they’re all just names with empty values, right?
> 
> Yes, all of these are empty by default, though I typically order from DigiKey 
> so I could have set that one. I added them as "Default Fields" so that all 
> components would have the same fields, and I wouldn't have to depend on 
> adding the field names by hand.
> 
>>
>>>
>>> The first two give the manufacturer's name and part number; the second two 
>>> give the distributor's name and part number; the third is a catch-all for 
>>> specs that are important for ordering but aren't worth cluttering the 
>>> schematic with.
>>>
>>> My biggest issue with the current Default Fields is that I didn't start my 
>>> current project with them, so using the field edit spreadsheet-like thingie 
>>> often results in lots of noise in my commits as the empty default fields 
>>> get added to components.
>>
>> If it’s adding empty default fields then it’s a bug.  It should only add 
>> them if they have non-empty values.
> 
> Then you have a bug. Here's a small excerpt from a Git diff where a lot of 
> components had empty fields added. None of these components were added in 
> this revision; I was simply setting part numbers for /other/ components using 
> the field editor spreadsheet thingie:
> 
> diff --git a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
> index 37482ee..e2aea43 100644
> --- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> +++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch 
> @@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
>  F 1 "74LVC1T45" H 3900 2124 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850 50  0001 
> C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    3900 1850
>     1    0    0    -1 
>  $EndComp
> @@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
>  F 1 "74LVC1T45" H 3900 3324 50   C CNN
>  F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
>  F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050 50  0001 
> C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    3900 3050
>     1    0    0    -1 
>  $EndComp
> @@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
>  F 1 "Conn_01x06" H 7719 1466 50   C CNN
>  F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H 7800 1900 
> 50  0001 C CNN
>  F 3 "~" H 7800 1900 50  0001 C CNN
> +F 4 "" H 0   0   50  0001 C CNN "Distr"
> +F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
> +F 6 "" H 0   0   50  0001 C CNN "Mfgr"
> +F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
> +F 8 "" H 0   0   50  0001 C CNN "Specifications"
>     1    7800 1900
>     1    0    0    -1 
>  $EndComp
> @@ -209,6 +234,7 @@ F 4 "CTS" H 3900 7100 50  0001 C CNN "Mfgr"
>  F 5 "218-4LPST" H 3900 7100 50  0001 C CNN "Mfgr P/N"
>  F 6 "DigiKey" H 3900 7100 50  0001 C CNN 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

Comments inline:

> On 28 May 2018, at 17:28, Reece R. Pollack  wrote:
> 
> I believe you owe me 2c. We can discuss 2c in which currency later. :-)
> 
> I have five custom default fields defined:
>  - Mfgr
>  - Mfgr P/N
>  - Dist
>  - Dist P/N
>  - Specifications

None of these have any default values that make any sense, so I assume they’re 
all just names with empty values, right?

> 
> The first two give the manufacturer's name and part number; the second two 
> give the distributor's name and part number; the third is a catch-all for 
> specs that are important for ordering but aren't worth cluttering the 
> schematic with.
> 
> My biggest issue with the current Default Fields is that I didn't start my 
> current project with them, so using the field edit spreadsheet-like thingie 
> often results in lots of noise in my commits as the empty default fields get 
> added to components.

If it’s adding empty default fields then it’s a bug.  It should only add them 
if they have non-empty values.

Cheers,
Jeff.

> 
> I was originally against adding such defined fields, as I expect it will add 
> fields to components that will potentially conflict with those created by 
> current users. However, if it doesn't do that, and has the support from parts 
> distributors, I guess I could live with it.
> 
> On 05/22/18 10:56, Fabrizio Tappero wrote:
>> Hello,
>> I'd like to contribute with my 2c. 
>> 
>> I completely agree with Kristoffer, there is a need for a "MPN" field hard 
>> coded exactly as "Value" field is hard coded in Kicad.
>> 
>> As Wayne mentions the current "Preferences - General Options - Default 
>> Fields" is not a bad option to add a "MPN" field. This is what I do and this 
>> is what all my PCB colleges at work do. 
>> 
>> Above solution will however not help the majority to do the same. I would 
>> actually bet 2c that nearly nobody uses the Default Fields feature (most of 
>> the people probably do it component by component). And this makes it a not 
>> so useful feature.
>> 
>> Kicost is a god-made tool and for sure Dave will soon add MPN as a default 
>> field in Kicad.
>> 
>> Cheers
>> Fabrizio
>> 
>> 
>> 
>> 
>> 
>> On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark 
>> mailto:kristofferodmar...@gmail.com>> wrote:
>> My updated patch forgot to add the files before doing the --amend.
>> 
>> So it only updated the commit message. Here is the real file
>> 
>> On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
>> > From a Digi-Key KiCad library standpoint, as we're still in beta, I
>> > would
>> > gladly change the fields to whatever would be decided.  Uniformity
>> > for
>> > plugins use would definitely be an advantage.
>> > 
>> > -Ben
>> > 
>> > On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
>> > kristofferodmar...@gmail.com > wrote:
>> > 
>> > > Thanks! This is exactly what i was going for, non-intrusive
>> > > oppurtunity
>> > > for uniformity!
>> > > 
>> > > I tested the bom2csv plugin, It did not include the empty fields.
>> > > 
>> > > I also tested the bom_csv_sorted_by_ref, it did not include the
>> > > empty
>> > > values, but it included some values I had not specified, such as
>> > > Manufacturer and Vendor even if they were not provided in the
>> > > schematic.
>> > > 
>> > > - Kristoffer
>> > > 
>> > > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
>> > > > I think I like this new patch.  It provides the /opportunity/ for
>> > > > uniformity, without getting in the way of those who want to go
>> > > > their
>> > > > own way.
>> > > > 
>> > > > Do the BOM generators automatically output all default fields or
>> > > > only
>> > > > those with values?
>> > > > 
>> > > > > On 22 May 2018, at 09:22, kristoffer ödmark > > > > > @gma
>> > > > > il.com > wrote:
>> > > > > 
>> > > > > Please disregard my previous mail, it got mangled badly
>> > > > > somehow, it
>> > > > > did
>> > > > > not look like that in my editor at least.
>> > > > > 
>> > > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
>> > > > > > Eeschema already supports creating default optional fields in
>> > > > > > the
>> > > > > > configuration settings dialog.  Used correctly, these will
>> > > > > > give
>> > > > > > you
>> > > > > > the
>> > > > > > same optional field names for every project without having to
>> > > > > > add
>> > > > > > them
>> > > > > > by hand to each symbol and possibly typing in different field
>> > > > > > names
>> > > > > > by
>> > > > > > accident.
>> > > > > 
>> > > > > Different users will still type in different field names for
>> > > > > the
>> > > > > same
>> > > > > things though. What you describe works as long as there is only
>> > > > > one
>> > > > > person in the entire projects lifetime, using only one
>> > > > > computer.
>> > > > > 
>> > > > > > The proposed patch would intermingle the default fields
>> > > > > > with
>> > > > > > existing schematic symbol fields which would break existing
>> > > > > > 

Re: [Kicad-developers] More default fields in schematic

[Reece R. Pollack]

I believe you owe me 2c. We can discuss 2c in which currency later. :-)

I have five custom default fields defined:
 - Mfgr
 - Mfgr P/N
 - Dist
 - Dist P/N
 - Specifications

The first two give the manufacturer's name and part number; the second 
two give the distributor's name and part number; the third is a 
catch-all for specs that are important for ordering but aren't worth 
cluttering the schematic with.


My biggest issue with the current Default Fields is that I didn't start 
my current project with them, so using the field edit spreadsheet-like 
thingie often results in lots of noise in my commits as the empty 
default fields get added to components.


I was originally against adding such defined fields, as I expect it will 
add fields to components that will potentially conflict with those 
created by current users. However, if it doesn't do that, and has the 
support from parts distributors, I guess I could live with it.


On 05/22/18 10:56, Fabrizio Tappero wrote:

Hello,
I'd like to contribute with my 2c.

I completely agree with Kristoffer, there is a need for a "MPN" field 
hard coded exactly as "Value" field is hard coded in Kicad.


As Wayne mentions the current "Preferences - General Options - Default 
Fields" is not a bad option to add a "MPN" field. This is what I do 
and this is what all my PCB colleges at work do.


Above solution will however not help the majority to do the same. I 
would actually bet 2c that nearly nobody uses the Default Fields 
feature (most of the people probably do it component by component). 
And this makes it a not so useful feature.


Kicost is a god-made tool and for sure Dave will soon add MPN as a 
default field in Kicad.


Cheers
Fabrizio





On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark 
> 
wrote:


My updated patch forgot to add the files before doing the --amend.

So it only updated the commit message. Here is the real file

On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I
> would
> gladly change the fields to whatever would be decided.  Uniformity
> for
> plugins use would definitely be an advantage.
>
> -Ben
>
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com
> wrote:
>
> > Thanks! This is exactly what i was going for, non-intrusive
> > oppurtunity
> > for uniformity!
> >
> > I tested the bom2csv plugin, It did not include the empty fields.
> >
> > I also tested the bom_csv_sorted_by_ref, it did not include the
> > empty
> > values, but it included some values I had not specified, such as
> > Manufacturer and Vendor even if they were not provided in the
> > schematic.
> >
> > - Kristoffer
> >
> > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > I think I like this new patch.  It provides the
/opportunity/ for
> > > uniformity, without getting in the way of those who want to go
> > > their
> > > own way.
> > >
> > > Do the BOM generators automatically output all default fields or
> > > only
> > > those with values?
> > >
> > > > On 22 May 2018, at 09:22, kristoffer ödmark
 > > > @gma
> > > > il.com > wrote:
> > > >
> > > > Please disregard my previous mail, it got mangled badly
> > > > somehow, it
> > > > did
> > > > not look like that in my editor at least.
> > > >
> > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > Eeschema already supports creating default optional
fields in
> > > > > the
> > > > > configuration settings dialog. Used correctly, these will
> > > > > give
> > > > > you
> > > > > the
> > > > > same optional field names for every project without
having to
> > > > > add
> > > > > them
> > > > > by hand to each symbol and possibly typing in different
field
> > > > > names
> > > > > by
> > > > > accident.
> > > >
> > > > Different users will still type in different field names for
> > > > the
> > > > same
> > > > things though. What you describe works as long as there is
only
> > > > one
> > > > person in the entire projects lifetime, using only one
> > > > computer.
> > > >
> > > > > The proposed patch would intermingle the default fields
> > > > > with
> > > > > existing schematic symbol fields which would break existing
> > > > > BOMs
> > > > > which I
> > > > > don't think users will appreciate.
> > > >
> > > > The proposed patch will only change default settings, existing
> > > > users
> > > > with a config already in place will not be affected. I
realised
> > > > that
> > > > the fields now accept empty values as well, so 

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

OK, I double-checked.  The schematic doesn’t get the mandatory names at all 
(just 1, 2, 3, 4).  The netlist exporters (at least generic and kicad) write 
the untranslated version in all lower-case.  The BOM exporters use the generic 
netlist exporter.

The 4 known fields are hard-coded, so there’s no existing mechanism we could 
lean on to do the translations for “standard" default fields.  It’d probably be 
best to store them in English and translate going out to the UI….

Cheers,
Jeff


> On 23 May 2018, at 13:00, Wayne Stambaugh  wrote:
> 
> You may want to test this just to be sure.  We had a similar issue with
> translating board layer names in the old board file format which created
> a big headache when we implemented the current board file format.
> 
> On 5/23/2018 4:43 AM, Jeff Young wrote:
>> Reference/Value/Footprint/Datasheet are translated only in the UI: the
>> file always uses the English versions.  (Presumably external tools will
>> look at the files, BOMs, netlists, etc.)
>> 
>>> On 23 May 2018, at 00:41, Wayne Stambaugh >> 
>>> >> wrote:
>>> 
>>> Wouldn't translating them defeat the purpose?  I thought the goal was
>>> consistency.  If you translate them, they will be different for each
>>> language and render code like kicost somewhat useless.
>>> 
>>> On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
 Yes, the only way to make them translateable is to hard-code these and
 other values into kicad, same as the existing hard-coded fields.
 
 That would be a good solution for me, having similar to layers a large
 set of predefined fields, being able to name them and enable them at
 will. But storing them in the files as the hard-codes values.
 
 This means a large change to the code though, at least if we must have
 the enable/disable feature for this, along with creating new custom
 fields. Not even the PCB editor has this yet. 
 
 Also, I don't think any of the bom exporter plug-ins are localized, and
 at least one of them completely ignores custom fields and adds it own
 instead, regardless of what is in the file.
 
 Meanwhile my patch does not affect existing installations, does not
 change any BOM, and does not enforce anything and comes in at a whooping
 3-4 lines of patch in a single file. It will however add 3 lines to two
 dialogs (field editor and symbol editor) for new installations, which
 can be removed, with 6 clicks of the mouse in eeschema. 
 
 - Kristoffer 
 
 On Tue, May 22, 2018, 20:01 Jeff Young 
 >
 >> wrote:
 
I can confirm that default fields only get added when the symbol is
edited AND the default field’s value is non-empty.  So it doesn’t
seem to me that the proposed patch would pollute existing BOMs.  Or
am I missing something?
 
Seth’s comment regarding localisation is an issue, though, as we
don’t currently translate default fields.
 
> On 22 May 2018, at 17:53, Wayne Stambaugh  
> >
> wrote:
> 
> On 5/22/2018 12:43 PM, Jeff Young wrote:
>>> It should output all fields defined in schematic symbols
regardless if
>>> each optional field is defined in every symbol.  If they are
outputting
>>> anything other than that, I would consider this a bug.
>> 
>> I had trouble parsing this.  Are you saying that the list of
output fields should be the union of all fields which have a value
somewhere (but excluding default fields which are uniformly blank)?
> 
> Yes.  It should be the equivalent of a logical OR.  If a field
exists in
> a single symbol, it should get added to the BOM.
> 
>> 
>> As it stands in 5.0, default fields don’t get pushed to symbols
unless the symbol is edited.  At that point I’m not sure if they’re
all pushed, or only those with values.
>> 
> 
> It used to be that fields only get saved when they are added to the
> symbol using the edit symbol properties dialog.  That code has
changed a
> lot since it was originally written so I cannot confirm this.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 >
 

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

You may want to test this just to be sure.  We had a similar issue with
translating board layer names in the old board file format which created
a big headache when we implemented the current board file format.

On 5/23/2018 4:43 AM, Jeff Young wrote:
> Reference/Value/Footprint/Datasheet are translated only in the UI: the
> file always uses the English versions.  (Presumably external tools will
> look at the files, BOMs, netlists, etc.)
> 
>> On 23 May 2018, at 00:41, Wayne Stambaugh > > wrote:
>>
>> Wouldn't translating them defeat the purpose?  I thought the goal was
>> consistency.  If you translate them, they will be different for each
>> language and render code like kicost somewhat useless.
>>
>> On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
>>> Yes, the only way to make them translateable is to hard-code these and
>>> other values into kicad, same as the existing hard-coded fields.
>>>
>>> That would be a good solution for me, having similar to layers a large
>>> set of predefined fields, being able to name them and enable them at
>>> will. But storing them in the files as the hard-codes values.
>>>
>>> This means a large change to the code though, at least if we must have
>>> the enable/disable feature for this, along with creating new custom
>>> fields. Not even the PCB editor has this yet. 
>>>
>>> Also, I don't think any of the bom exporter plug-ins are localized, and
>>> at least one of them completely ignores custom fields and adds it own
>>> instead, regardless of what is in the file.
>>>
>>> Meanwhile my patch does not affect existing installations, does not
>>> change any BOM, and does not enforce anything and comes in at a whooping
>>> 3-4 lines of patch in a single file. It will however add 3 lines to two
>>> dialogs (field editor and symbol editor) for new installations, which
>>> can be removed, with 6 clicks of the mouse in eeschema. 
>>>
>>> - Kristoffer 
>>>
>>> On Tue, May 22, 2018, 20:01 Jeff Young >> 
>>> > wrote:
>>>
>>>    I can confirm that default fields only get added when the symbol is
>>>    edited AND the default field’s value is non-empty.  So it doesn’t
>>>    seem to me that the proposed patch would pollute existing BOMs.  Or
>>>    am I missing something?
>>>
>>>    Seth’s comment regarding localisation is an issue, though, as we
>>>    don’t currently translate default fields.
>>>
 On 22 May 2018, at 17:53, Wayne Stambaugh 
>>>    > wrote:

 On 5/22/2018 12:43 PM, Jeff Young wrote:
>> It should output all fields defined in schematic symbols
>>>    regardless if
>> each optional field is defined in every symbol.  If they are
>>>    outputting
>> anything other than that, I would consider this a bug.
>
> I had trouble parsing this.  Are you saying that the list of
>>>    output fields should be the union of all fields which have a value
>>>    somewhere (but excluding default fields which are uniformly blank)?

 Yes.  It should be the equivalent of a logical OR.  If a field
>>>    exists in
 a single symbol, it should get added to the BOM.

>
> As it stands in 5.0, default fields don’t get pushed to symbols
>>>    unless the symbol is edited.  At that point I’m not sure if they’re
>>>    all pushed, or only those with values.
>

 It used to be that fields only get saved when they are added to the
 symbol using the edit symbol properties dialog.  That code has
>>>    changed a
 lot since it was originally written so I cannot confirm this.
>>>
>>>
>>>
>>> ___
>>> 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
>>>
>>
>> ___
>> 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
> 

___
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

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

Reference/Value/Footprint/Datasheet are translated only in the UI: the file 
always uses the English versions.  (Presumably external tools will look at the 
files, BOMs, netlists, etc.)

> On 23 May 2018, at 00:41, Wayne Stambaugh  wrote:
> 
> Wouldn't translating them defeat the purpose?  I thought the goal was
> consistency.  If you translate them, they will be different for each
> language and render code like kicost somewhat useless.
> 
> On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
>> Yes, the only way to make them translateable is to hard-code these and
>> other values into kicad, same as the existing hard-coded fields.
>> 
>> That would be a good solution for me, having similar to layers a large
>> set of predefined fields, being able to name them and enable them at
>> will. But storing them in the files as the hard-codes values.
>> 
>> This means a large change to the code though, at least if we must have
>> the enable/disable feature for this, along with creating new custom
>> fields. Not even the PCB editor has this yet. 
>> 
>> Also, I don't think any of the bom exporter plug-ins are localized, and
>> at least one of them completely ignores custom fields and adds it own
>> instead, regardless of what is in the file.
>> 
>> Meanwhile my patch does not affect existing installations, does not
>> change any BOM, and does not enforce anything and comes in at a whooping
>> 3-4 lines of patch in a single file. It will however add 3 lines to two
>> dialogs (field editor and symbol editor) for new installations, which
>> can be removed, with 6 clicks of the mouse in eeschema. 
>> 
>> - Kristoffer 
>> 
>> On Tue, May 22, 2018, 20:01 Jeff Young > >> wrote:
>> 
>>I can confirm that default fields only get added when the symbol is
>>edited AND the default field’s value is non-empty.  So it doesn’t
>>seem to me that the proposed patch would pollute existing BOMs.  Or
>>am I missing something?
>> 
>>Seth’s comment regarding localisation is an issue, though, as we
>>don’t currently translate default fields.
>> 
>>> On 22 May 2018, at 17:53, Wayne Stambaugh >> 
>>>> wrote:
>>> 
>>> On 5/22/2018 12:43 PM, Jeff Young wrote:
> It should output all fields defined in schematic symbols
>>regardless if
> each optional field is defined in every symbol.  If they are
>>outputting
> anything other than that, I would consider this a bug.
 
 I had trouble parsing this.  Are you saying that the list of
>>output fields should be the union of all fields which have a value
>>somewhere (but excluding default fields which are uniformly blank)?
>>> 
>>> Yes.  It should be the equivalent of a logical OR.  If a field
>>exists in
>>> a single symbol, it should get added to the BOM.
>>> 
 
 As it stands in 5.0, default fields don’t get pushed to symbols
>>unless the symbol is edited.  At that point I’m not sure if they’re
>>all pushed, or only those with values.
 
>>> 
>>> It used to be that fields only get saved when they are added to the
>>> symbol using the edit symbol properties dialog.  That code has
>>changed a
>>> lot since it was originally written so I cannot confirm this.
>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> ___
> 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 
> 
___
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

Re: [Kicad-developers] More default fields in schematic

[Clemens Koller]

Thank you for your feedback:

On 2018-05-22 17:21, Strontium wrote:
> Hello Everyone,
> 
> I like the patch, and hope it makes it in.
> 
> Clemens,  I don't think anything that is being discussed is in any way 
> going to constrain b) or c).  But I think there is a third group, not just
> 
> 1. Big Manufacturers
> 2. Hobbyist/Student
> 
> but
> 
> 3. Small Scale Professional Manufacturer.

You've put up this list of use-cases/organization sizes. This is off course not 
complete of you just take my two examples and make it 1. and 2.

Regards,

Clemens

___
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

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

Wouldn't translating them defeat the purpose?  I thought the goal was
consistency.  If you translate them, they will be different for each
language and render code like kicost somewhat useless.

On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
> Yes, the only way to make them translateable is to hard-code these and
> other values into kicad, same as the existing hard-coded fields.
> 
> That would be a good solution for me, having similar to layers a large
> set of predefined fields, being able to name them and enable them at
> will. But storing them in the files as the hard-codes values.
> 
> This means a large change to the code though, at least if we must have
> the enable/disable feature for this, along with creating new custom
> fields. Not even the PCB editor has this yet. 
> 
> Also, I don't think any of the bom exporter plug-ins are localized, and
> at least one of them completely ignores custom fields and adds it own
> instead, regardless of what is in the file.
> 
> Meanwhile my patch does not affect existing installations, does not
> change any BOM, and does not enforce anything and comes in at a whooping
> 3-4 lines of patch in a single file. It will however add 3 lines to two
> dialogs (field editor and symbol editor) for new installations, which
> can be removed, with 6 clicks of the mouse in eeschema. 
> 
> - Kristoffer 
> 
> On Tue, May 22, 2018, 20:01 Jeff Young  > wrote:
> 
> I can confirm that default fields only get added when the symbol is
> edited AND the default field’s value is non-empty.  So it doesn’t
> seem to me that the proposed patch would pollute existing BOMs.  Or
> am I missing something?
> 
> Seth’s comment regarding localisation is an issue, though, as we
> don’t currently translate default fields.
> 
> > On 22 May 2018, at 17:53, Wayne Stambaugh  > wrote:
> >
> > On 5/22/2018 12:43 PM, Jeff Young wrote:
> >>> It should output all fields defined in schematic symbols
> regardless if
> >>> each optional field is defined in every symbol.  If they are
> outputting
> >>> anything other than that, I would consider this a bug.
> >>
> >> I had trouble parsing this.  Are you saying that the list of
> output fields should be the union of all fields which have a value
> somewhere (but excluding default fields which are uniformly blank)?
> >
> > Yes.  It should be the equivalent of a logical OR.  If a field
> exists in
> > a single symbol, it should get added to the BOM.
> >
> >>
> >> As it stands in 5.0, default fields don’t get pushed to symbols
> unless the symbol is edited.  At that point I’m not sure if they’re
> all pushed, or only those with values.
> >>
> >
> > It used to be that fields only get saved when they are added to the
> > symbol using the edit symbol properties dialog.  That code has
> changed a
> > lot since it was originally written so I cannot confirm this.
> 
> 
> 
> ___
> 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
> 

___
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

Re: [Kicad-developers] More default fields in schematic

[Kristoffer Ödmark]

Yes, the only way to make them translateable is to hard-code these and
other values into kicad, same as the existing hard-coded fields.

That would be a good solution for me, having similar to layers a large set
of predefined fields, being able to name them and enable them at will. But
storing them in the files as the hard-codes values.

This means a large change to the code though, at least if we must have the
enable/disable feature for this, along with creating new custom fields. Not
even the PCB editor has this yet.

Also, I don't think any of the bom exporter plug-ins are localized, and at
least one of them completely ignores custom fields and adds it own instead,
regardless of what is in the file.

Meanwhile my patch does not affect existing installations, does not change
any BOM, and does not enforce anything and comes in at a whooping 3-4 lines
of patch in a single file. It will however add 3 lines to two dialogs
(field editor and symbol editor) for new installations, which can be
removed, with 6 clicks of the mouse in eeschema.

- Kristoffer

On Tue, May 22, 2018, 20:01 Jeff Young  wrote:

> I can confirm that default fields only get added when the symbol is edited
> AND the default field’s value is non-empty.  So it doesn’t seem to me that
> the proposed patch would pollute existing BOMs.  Or am I missing something?
>
> Seth’s comment regarding localisation is an issue, though, as we don’t
> currently translate default fields.
>
> > On 22 May 2018, at 17:53, Wayne Stambaugh  wrote:
> >
> > On 5/22/2018 12:43 PM, Jeff Young wrote:
> >>> It should output all fields defined in schematic symbols regardless if
> >>> each optional field is defined in every symbol.  If they are outputting
> >>> anything other than that, I would consider this a bug.
> >>
> >> I had trouble parsing this.  Are you saying that the list of output
> fields should be the union of all fields which have a value somewhere (but
> excluding default fields which are uniformly blank)?
> >
> > Yes.  It should be the equivalent of a logical OR.  If a field exists in
> > a single symbol, it should get added to the BOM.
> >
> >>
> >> As it stands in 5.0, default fields don’t get pushed to symbols unless
> the symbol is edited.  At that point I’m not sure if they’re all pushed, or
> only those with values.
> >>
> >
> > It used to be that fields only get saved when they are added to the
> > symbol using the edit symbol properties dialog.  That code has changed a
> > lot since it was originally written so I cannot confirm this.
>
>
___
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

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

I can confirm that default fields only get added when the symbol is edited AND 
the default field’s value is non-empty.  So it doesn’t seem to me that the 
proposed patch would pollute existing BOMs.  Or am I missing something?

Seth’s comment regarding localisation is an issue, though, as we don’t 
currently translate default fields.

> On 22 May 2018, at 17:53, Wayne Stambaugh  wrote:
> 
> On 5/22/2018 12:43 PM, Jeff Young wrote:
>>> It should output all fields defined in schematic symbols regardless if
>>> each optional field is defined in every symbol.  If they are outputting
>>> anything other than that, I would consider this a bug.
>> 
>> I had trouble parsing this.  Are you saying that the list of output fields 
>> should be the union of all fields which have a value somewhere (but 
>> excluding default fields which are uniformly blank)?
> 
> Yes.  It should be the equivalent of a logical OR.  If a field exists in
> a single symbol, it should get added to the BOM.
> 
>> 
>> As it stands in 5.0, default fields don’t get pushed to symbols unless the 
>> symbol is edited.  At that point I’m not sure if they’re all pushed, or only 
>> those with values.
>> 
> 
> It used to be that fields only get saved when they are added to the
> symbol using the edit symbol properties dialog.  That code has changed a
> lot since it was originally written so I cannot confirm this.


___
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

Re: [Kicad-developers] More default fields in schematic

[Seth Hillbrand]

This idea could be a good addition to KiCad eventually.  However, at this
point, it probably makes sense to discuss it in a bug report.

The current strings "Reference", "Value", "Footprint" and "Datasheet" are
all translated strings (not in the files but in the interface).  The patch
adds untranslated default strings.
​
-S​


Am Di., 22. Mai 2018 um 07:57 Uhr schrieb Fabrizio Tappero <
fabrizio.tapp...@gmail.com>:

> Hello,
> I'd like to contribute with my 2c.
>
> I completely agree with Kristoffer, there is a need for a "MPN" field hard
> coded exactly as "Value" field is hard coded in Kicad.
>
> As Wayne mentions the current "Preferences - General Options - Default
> Fields" is not a bad option to add a "MPN" field. This is what I do and
> this is what all my PCB colleges at work do.
>
> Above solution will however not help the majority to do the same. I would
> actually bet 2c that nearly nobody uses the Default Fields feature (most of
> the people probably do it component by component). And this makes it a not
> so useful feature.
>
> Kicost is a god-made tool and for sure Dave will soon add MPN as a default
> field in Kicad.
>
> Cheers
> Fabrizio
>
>
>
>
>
> On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark <
> kristofferodmar...@gmail.com> wrote:
>
>> My updated patch forgot to add the files before doing the --amend.
>>
>> So it only updated the commit message. Here is the real file
>>
>> On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
>> > From a Digi-Key KiCad library standpoint, as we're still in beta, I
>> > would
>> > gladly change the fields to whatever would be decided.  Uniformity
>> > for
>> > plugins use would definitely be an advantage.
>> >
>> > -Ben
>> >
>> > On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
>> > kristofferodmar...@gmail.com> wrote:
>> >
>> > > Thanks! This is exactly what i was going for, non-intrusive
>> > > oppurtunity
>> > > for uniformity!
>> > >
>> > > I tested the bom2csv plugin, It did not include the empty fields.
>> > >
>> > > I also tested the bom_csv_sorted_by_ref, it did not include the
>> > > empty
>> > > values, but it included some values I had not specified, such as
>> > > Manufacturer and Vendor even if they were not provided in the
>> > > schematic.
>> > >
>> > > - Kristoffer
>> > >
>> > > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
>> > > > I think I like this new patch.  It provides the /opportunity/ for
>> > > > uniformity, without getting in the way of those who want to go
>> > > > their
>> > > > own way.
>> > > >
>> > > > Do the BOM generators automatically output all default fields or
>> > > > only
>> > > > those with values?
>> > > >
>> > > > > On 22 May 2018, at 09:22, kristoffer ödmark > > > > > @gma
>> > > > > il.com> wrote:
>> > > > >
>> > > > > Please disregard my previous mail, it got mangled badly
>> > > > > somehow, it
>> > > > > did
>> > > > > not look like that in my editor at least.
>> > > > >
>> > > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
>> > > > > > Eeschema already supports creating default optional fields in
>> > > > > > the
>> > > > > > configuration settings dialog.  Used correctly, these will
>> > > > > > give
>> > > > > > you
>> > > > > > the
>> > > > > > same optional field names for every project without having to
>> > > > > > add
>> > > > > > them
>> > > > > > by hand to each symbol and possibly typing in different field
>> > > > > > names
>> > > > > > by
>> > > > > > accident.
>> > > > >
>> > > > > Different users will still type in different field names for
>> > > > > the
>> > > > > same
>> > > > > things though. What you describe works as long as there is only
>> > > > > one
>> > > > > person in the entire projects lifetime, using only one
>> > > > > computer.
>> > > > >
>> > > > > > The proposed patch would intermingle the default fields
>> > > > > > with
>> > > > > > existing schematic symbol fields which would break existing
>> > > > > > BOMs
>> > > > > > which I
>> > > > > > don't think users will appreciate.
>> > > > >
>> > > > > The proposed patch will only change default settings, existing
>> > > > > users
>> > > > > with a config already in place will not be affected. I realised
>> > > > > that
>> > > > > the fields now accept empty values as well, so existing boms on
>> > > > > new
>> > > > > installations will not be affected either. I updated the patch,
>> > > > > so
>> > > > > it
>> > > > > will not affect anyone that doesnt use the fields.
>> > > > >
>> > > > > > [...] As I've stated before, I can set 10
>> > > > > > different designers down and I will get 10 different sets of
>> > > > > > default
>> > > > > > field names.  This really seems like me to be a configuration
>> > > > > > issue.
>> > > > >
>> > > > > This is the problems I want to address, because those 10
>> > > > > designers
>> > > > > will
>> > > > > by experience also spell the same field in 10 different ways.
>> > > > > Making
>> > > > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc.

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

On 5/22/2018 12:43 PM, Jeff Young wrote:
>> It should output all fields defined in schematic symbols regardless if
>> each optional field is defined in every symbol.  If they are outputting
>> anything other than that, I would consider this a bug.
> 
> I had trouble parsing this.  Are you saying that the list of output fields 
> should be the union of all fields which have a value somewhere (but excluding 
> default fields which are uniformly blank)?

Yes.  It should be the equivalent of a logical OR.  If a field exists in
a single symbol, it should get added to the BOM.

> 
> As it stands in 5.0, default fields don’t get pushed to symbols unless the 
> symbol is edited.  At that point I’m not sure if they’re all pushed, or only 
> those with values.
> 

It used to be that fields only get saved when they are added to the
symbol using the edit symbol properties dialog.  That code has changed a
lot since it was originally written so I cannot confirm this.

___
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

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

> It should output all fields defined in schematic symbols regardless if
> each optional field is defined in every symbol.  If they are outputting
> anything other than that, I would consider this a bug.

I had trouble parsing this.  Are you saying that the list of output fields 
should be the union of all fields which have a value somewhere (but excluding 
default fields which are uniformly blank)?

As it stands in 5.0, default fields don’t get pushed to symbols unless the 
symbol is edited.  At that point I’m not sure if they’re all pushed, or only 
those with values.

___
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

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

On 5/22/2018 6:05 AM, Jeff Young wrote:
> I think I like this new patch.  It provides the /opportunity/ for
> uniformity, without getting in the way of those who want to go their own
> way.

The new patch still has the potential to pollute existing project BOMs.
Just because a user hasn't defined any default optional fields does not
mean that they don't have any projects that don't have any optional
fields.  My proposal prevents any pollution of existing projects.  There
may be other ways to achieve this but none came to mind at the moment.

> 
> Do the BOM generators automatically output all default fields or only
> those with values?

It should output all fields defined in schematic symbols regardless if
each optional field is defined in every symbol.  If they are outputting
anything other than that, I would consider this a bug.

> 
>> On 22 May 2018, at 09:22, kristoffer ödmark
>> >
>> wrote:
>>
>> Please disregard my previous mail, it got mangled badly somehow, it did
>> not look like that in my editor at least.
>>
>> On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
>>> Eeschema already supports creating default optional fields in the
>>> configuration settings dialog.  Used correctly, these will give you
>>> the
>>> same optional field names for every project without having to add
>>> them
>>> by hand to each symbol and possibly typing in different field names
>>> by
>>> accident.  
>>
>> Different users will still type in different field names for the same
>> things though. What you describe works as long as there is only one
>> person in the entire projects lifetime, using only one computer.
>>
>>> The proposed patch would intermingle the default fields
>>> with
>>> existing schematic symbol fields which would break existing BOMs
>>> which I
>>> don't think users will appreciate.  
>>
>> The proposed patch will only change default settings, existing users
>> with a config already in place will not be affected. I realised that
>> the fields now accept empty values as well, so existing boms on new
>> installations will not be affected either. I updated the patch, so it
>> will not affect anyone that doesnt use the fields. 
>>
>>> [...] As I've stated before, I can set 10
>>> different designers down and I will get 10 different sets of default
>>> field names.  This really seems like me to be a configuration issue.
>>
>> This is the problems I want to address, because those 10 designers will
>> by experience also spell the same field in 10 different ways. Making
>> their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
>> those 10 designers remove the fields they do not want instead.
>>
>>> The only possible solution that I would accept is to move the default
>>> field definitions from the eeschema configuration file into the
>>> default
>>> kicad project file.  This way existing projects would not be polluted
>>> with the proposed default fields and users could define their own
>>> default fields in a custom project file.  
>>
>> Default fields does not pollute if they are empty, they just give a
>> hint of what data could be put into the schematic, same as with the
>> datasheet field, which is not often used. Funny how noone ever
>> complains about that one.
>>
>>> [...]
>>> A more flexible solution would be to add a "File->New from Custom
>>> Template" command to KiCad to allow the user to select any custom
>>> project file.  This would allow for multiple custom project files
>>> instead of forcing the user to use only a single default project
>>> file.
>>
>> As long as the "File->New Project" would include the additional fields
>> and then people can use "New from Custom Template" means they can use a
>> template that is empty. Otherwise it would defeat the purpose. I am
>> proposing a slightly different default configuration, not any change in
>> how people will use the software.
>>
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
 I agree, I had the same issue when I was doing my board, I needed a
 field for all components, and I had to manually add it for every
 item,
 there was no way to add this field to all components at the same
 time or
 to have it add by default from the addition of a new component to
 the sheet.

 Which reminds me, Cadence Designer has tools to manipulate fields
 on a
 large scale, whether to add, delete, show, hide, etc, this is
 something
 that would be nice to have in KiCAD, either that or a table of all
 components for the sheet or schematic and columns for each field,
 with
 ability to show/hide each cell individually.

 I think the ultimate goal is to make the Symbol Table more useful,
 but
 that'll take to long for v5 so if Kristoffer's patch allows an easy
 way
 to add fields to all components or similar, I'd say do it because
 people
 will be 

Re: [Kicad-developers] More default fields in schematic

[Strontium]

Hello Everyone,

I like the patch, and hope it makes it in.

Clemens,  I don't think anything that is being discussed is in any way 
going to constrain b) or c).  But I think there is a third group, not just


1. Big Manufacturers
2. Hobbyist/Student

but

3. Small Scale Professional Manufacturer.

And now while 3 might grow into 1, and will have been 2 at some point, 
they almost certainly won't have a large backend with either SAP or 
Custom Generators.  They probably use a spreadsheet, and my opinion is 
having this information default in a sensible/consistent way in kicad 
would make their life a lot easier.  And I say this BECAUSE the engineer 
at the Small Scale shop, is also likely the person putting together the 
BOM and ordering the boards.  They are also making their BOM choices and 
decisions at Design Time, not just saying, its a 48pin tqfp samd21 or 
whatever.  They will be thinking, how much does it cost, what's my 
budget, where can I buy it, what are the MOQs, etc etc.  That's exactly 
the kind of user who would want to encode this into their schematic at 
design time.  And it would feel natural for them to do so. Rather than 
ignore all that, design a board and then make a second pass to do ALL 
that work again and record it in a second system.  I see this as 
supportive of those users, and guiding them, especially new users.


I also think KiCAD is going to find a fit with 2 and 3, much more than 1 
will.  Because with 1 the engineers don't care if the tools cost a 
fortune.  They just want what they want.  However all that said, nothing 
in this proposal would effect a Big manufacturer doing whatever they 
want.  Its simply a guided approach, rather than a blank sheet of paper 
approach.


Steven

On 22/05/18 22:49, Clemens Koller wrote:

Hello, everybody!

Just my five cents:
Can we somehow make sure that people understand and consider and Kicad reflects 
the differences in:

a) Unique partname + associated footprint + other arbitrary parameters 
necessary for the board design.

b) One or more qualified components from a manufacturer + a unique manufacturer 
number to be assembled on a).

c) One or more distributors or manufacturers or representatives to get one ore 
more of the b)'s.

In my case, it would be sufficient for Kicad to be able to handle a) only.
b) and c) are neither standardized nor flexible enough to be handled by most 
EDA systems, when there is more than one EDA system in use.
b) and c) is handled i.e. by SAP at one of my manufacturers site and some 
Generators + Tools + MariaDB at my place.

So, there is an n x m matrix of demands for b) and c) which makes IMO no sense 
to code in one EDA system if you look at the big picture how industrial 
electronics design happens nowadays. Off course I am not talking about hobbyist 
or academic use cases.

Regards,

Clemens

On 2018-05-22 14:52, Ben Hest wrote:

 From a Digi-Key KiCad library standpoint, as we're still in beta, I would 
gladly change the fields to whatever would be decided.  Uniformity for plugins 
use would definitely be an advantage.

-Ben

On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark > wrote:

 Thanks! This is exactly what i was going for, non-intrusive oppurtunity
 for uniformity!

 I tested the bom2csv plugin, It did not include the empty fields.

 I also tested the bom_csv_sorted_by_ref, it did not include the empty
 values, but it included some values I had not specified, such as
 Manufacturer and Vendor even if they were not provided in the
 schematic.

 - Kristoffer

 On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
 > I think I like this new patch.  It provides the /opportunity/ for
 > uniformity, without getting in the way of those who want to go their
 > own way.
 >
 > Do the BOM generators automatically output all default fields or only
 > those with values?
 >
 > > On 22 May 2018, at 09:22, kristoffer ödmark  > il.com > wrote:
 > >
 > > Please disregard my previous mail, it got mangled badly somehow, it
 > > did
 > > not look like that in my editor at least.
 > >
 > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
 > > > Eeschema already supports creating default optional fields in the
 > > > configuration settings dialog.  Used correctly, these will give
 > > > you
 > > > the
 > > > same optional field names for every project without having to add
 > > > them
 > > > by hand to each symbol and possibly typing in different field
 > > > names
 > > > by
 > > > accident.
 > >
 > > Different users will still type in different field names for the
 > > same
 > > things though. What you describe works as long as there is only one
 > > person in the entire projects lifetime, using only one computer.
 > >
 > > > The 

Re: [Kicad-developers] More default fields in schematic

[Fabrizio Tappero]

Hello,
I'd like to contribute with my 2c.

I completely agree with Kristoffer, there is a need for a "MPN" field hard
coded exactly as "Value" field is hard coded in Kicad.

As Wayne mentions the current "Preferences - General Options - Default
Fields" is not a bad option to add a "MPN" field. This is what I do and
this is what all my PCB colleges at work do.

Above solution will however not help the majority to do the same. I would
actually bet 2c that nearly nobody uses the Default Fields feature (most of
the people probably do it component by component). And this makes it a not
so useful feature.

Kicost is a god-made tool and for sure Dave will soon add MPN as a default
field in Kicad.

Cheers
Fabrizio





On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark <
kristofferodmar...@gmail.com> wrote:

> My updated patch forgot to add the files before doing the --amend.
>
> So it only updated the commit message. Here is the real file
>
> On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> > From a Digi-Key KiCad library standpoint, as we're still in beta, I
> > would
> > gladly change the fields to whatever would be decided.  Uniformity
> > for
> > plugins use would definitely be an advantage.
> >
> > -Ben
> >
> > On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> > kristofferodmar...@gmail.com> wrote:
> >
> > > Thanks! This is exactly what i was going for, non-intrusive
> > > oppurtunity
> > > for uniformity!
> > >
> > > I tested the bom2csv plugin, It did not include the empty fields.
> > >
> > > I also tested the bom_csv_sorted_by_ref, it did not include the
> > > empty
> > > values, but it included some values I had not specified, such as
> > > Manufacturer and Vendor even if they were not provided in the
> > > schematic.
> > >
> > > - Kristoffer
> > >
> > > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > > I think I like this new patch.  It provides the /opportunity/ for
> > > > uniformity, without getting in the way of those who want to go
> > > > their
> > > > own way.
> > > >
> > > > Do the BOM generators automatically output all default fields or
> > > > only
> > > > those with values?
> > > >
> > > > > On 22 May 2018, at 09:22, kristoffer ödmark  > > > > @gma
> > > > > il.com> wrote:
> > > > >
> > > > > Please disregard my previous mail, it got mangled badly
> > > > > somehow, it
> > > > > did
> > > > > not look like that in my editor at least.
> > > > >
> > > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > > Eeschema already supports creating default optional fields in
> > > > > > the
> > > > > > configuration settings dialog.  Used correctly, these will
> > > > > > give
> > > > > > you
> > > > > > the
> > > > > > same optional field names for every project without having to
> > > > > > add
> > > > > > them
> > > > > > by hand to each symbol and possibly typing in different field
> > > > > > names
> > > > > > by
> > > > > > accident.
> > > > >
> > > > > Different users will still type in different field names for
> > > > > the
> > > > > same
> > > > > things though. What you describe works as long as there is only
> > > > > one
> > > > > person in the entire projects lifetime, using only one
> > > > > computer.
> > > > >
> > > > > > The proposed patch would intermingle the default fields
> > > > > > with
> > > > > > existing schematic symbol fields which would break existing
> > > > > > BOMs
> > > > > > which I
> > > > > > don't think users will appreciate.
> > > > >
> > > > > The proposed patch will only change default settings, existing
> > > > > users
> > > > > with a config already in place will not be affected. I realised
> > > > > that
> > > > > the fields now accept empty values as well, so existing boms on
> > > > > new
> > > > > installations will not be affected either. I updated the patch,
> > > > > so
> > > > > it
> > > > > will not affect anyone that doesnt use the fields.
> > > > >
> > > > > > [...] As I've stated before, I can set 10
> > > > > > different designers down and I will get 10 different sets of
> > > > > > default
> > > > > > field names.  This really seems like me to be a configuration
> > > > > > issue.
> > > > >
> > > > > This is the problems I want to address, because those 10
> > > > > designers
> > > > > will
> > > > > by experience also spell the same field in 10 different ways.
> > > > > Making
> > > > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc.
> > > > > Let
> > > > > those 10 designers remove the fields they do not want instead.
> > > > >
> > > > > > The only possible solution that I would accept is to move the
> > > > > > default
> > > > > > field definitions from the eeschema configuration file into
> > > > > > the
> > > > > > default
> > > > > > kicad project file.  This way existing projects would not be
> > > > > > polluted
> > > > > > with the proposed default fields and users could define their
> > > > > > own
> > > > > > default fields in a custom project file.
> > > > >
> > > > > Default 

Re: [Kicad-developers] More default fields in schematic

[Clemens Koller]

Hello, everybody!

Just my five cents:
Can we somehow make sure that people understand and consider and Kicad reflects 
the differences in:

a) Unique partname + associated footprint + other arbitrary parameters 
necessary for the board design.

b) One or more qualified components from a manufacturer + a unique manufacturer 
number to be assembled on a).

c) One or more distributors or manufacturers or representatives to get one ore 
more of the b)'s.

In my case, it would be sufficient for Kicad to be able to handle a) only.
b) and c) are neither standardized nor flexible enough to be handled by most 
EDA systems, when there is more than one EDA system in use.
b) and c) is handled i.e. by SAP at one of my manufacturers site and some 
Generators + Tools + MariaDB at my place.

So, there is an n x m matrix of demands for b) and c) which makes IMO no sense 
to code in one EDA system if you look at the big picture how industrial 
electronics design happens nowadays. Off course I am not talking about hobbyist 
or academic use cases.

Regards,

Clemens

On 2018-05-22 14:52, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I would 
> gladly change the fields to whatever would be decided.  Uniformity for 
> plugins use would definitely be an advantage.
> 
> -Ben 
> 
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark 
> > wrote:
> 
> Thanks! This is exactly what i was going for, non-intrusive oppurtunity
> for uniformity!
> 
> I tested the bom2csv plugin, It did not include the empty fields.
> 
> I also tested the bom_csv_sorted_by_ref, it did not include the empty
> values, but it included some values I had not specified, such as
> Manufacturer and Vendor even if they were not provided in the
> schematic.
> 
> - Kristoffer
> 
> On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > I think I like this new patch.  It provides the /opportunity/ for
> > uniformity, without getting in the way of those who want to go their
> > own way.
> >
> > Do the BOM generators automatically output all default fields or only
> > those with values?
> >
> > > On 22 May 2018, at 09:22, kristoffer ödmark  > > il.com > wrote:
> > >
> > > Please disregard my previous mail, it got mangled badly somehow, it
> > > did
> > > not look like that in my editor at least.
> > >
> > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > Eeschema already supports creating default optional fields in the
> > > > configuration settings dialog.  Used correctly, these will give
> > > > you
> > > > the
> > > > same optional field names for every project without having to add
> > > > them
> > > > by hand to each symbol and possibly typing in different field
> > > > names
> > > > by
> > > > accident. 
> > >
> > > Different users will still type in different field names for the
> > > same
> > > things though. What you describe works as long as there is only one
> > > person in the entire projects lifetime, using only one computer.
> > >
> > > > The proposed patch would intermingle the default fields
> > > > with
> > > > existing schematic symbol fields which would break existing BOMs
> > > > which I
> > > > don't think users will appreciate. 
> > >
> > > The proposed patch will only change default settings, existing
> > > users
> > > with a config already in place will not be affected. I realised
> > > that
> > > the fields now accept empty values as well, so existing boms on new
> > > installations will not be affected either. I updated the patch, so
> > > it
> > > will not affect anyone that doesnt use the fields.
> > >
> > > > [...] As I've stated before, I can set 10
> > > > different designers down and I will get 10 different sets of
> > > > default
> > > > field names.  This really seems like me to be a configuration
> > > > issue.
> > >
> > > This is the problems I want to address, because those 10 designers
> > > will
> > > by experience also spell the same field in 10 different ways.
> > > Making
> > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> > > those 10 designers remove the fields they do not want instead.
> > >
> > > > The only possible solution that I would accept is to move the
> > > > default
> > > > field definitions from the eeschema configuration file into the
> > > > default
> > > > kicad project file.  This way existing projects would not be
> > > > polluted
> > > > with the proposed default fields and users could define their own
> > > > default fields in a custom project file. 
> > >
> > > Default fields does not pollute if they are empty, they 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

My updated patch forgot to add the files before doing the --amend.

So it only updated the commit message. Here is the real file

On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I
> would
> gladly change the fields to whatever would be decided.  Uniformity
> for
> plugins use would definitely be an advantage.
> 
> -Ben
> 
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com> wrote:
> 
> > Thanks! This is exactly what i was going for, non-intrusive
> > oppurtunity
> > for uniformity!
> > 
> > I tested the bom2csv plugin, It did not include the empty fields.
> > 
> > I also tested the bom_csv_sorted_by_ref, it did not include the
> > empty
> > values, but it included some values I had not specified, such as
> > Manufacturer and Vendor even if they were not provided in the
> > schematic.
> > 
> > - Kristoffer
> > 
> > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > I think I like this new patch.  It provides the /opportunity/ for
> > > uniformity, without getting in the way of those who want to go
> > > their
> > > own way.
> > > 
> > > Do the BOM generators automatically output all default fields or
> > > only
> > > those with values?
> > > 
> > > > On 22 May 2018, at 09:22, kristoffer ödmark  > > > @gma
> > > > il.com> wrote:
> > > > 
> > > > Please disregard my previous mail, it got mangled badly
> > > > somehow, it
> > > > did
> > > > not look like that in my editor at least.
> > > > 
> > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > Eeschema already supports creating default optional fields in
> > > > > the
> > > > > configuration settings dialog.  Used correctly, these will
> > > > > give
> > > > > you
> > > > > the
> > > > > same optional field names for every project without having to
> > > > > add
> > > > > them
> > > > > by hand to each symbol and possibly typing in different field
> > > > > names
> > > > > by
> > > > > accident.
> > > > 
> > > > Different users will still type in different field names for
> > > > the
> > > > same
> > > > things though. What you describe works as long as there is only
> > > > one
> > > > person in the entire projects lifetime, using only one
> > > > computer.
> > > > 
> > > > > The proposed patch would intermingle the default fields
> > > > > with
> > > > > existing schematic symbol fields which would break existing
> > > > > BOMs
> > > > > which I
> > > > > don't think users will appreciate.
> > > > 
> > > > The proposed patch will only change default settings, existing
> > > > users
> > > > with a config already in place will not be affected. I realised
> > > > that
> > > > the fields now accept empty values as well, so existing boms on
> > > > new
> > > > installations will not be affected either. I updated the patch,
> > > > so
> > > > it
> > > > will not affect anyone that doesnt use the fields.
> > > > 
> > > > > [...] As I've stated before, I can set 10
> > > > > different designers down and I will get 10 different sets of
> > > > > default
> > > > > field names.  This really seems like me to be a configuration
> > > > > issue.
> > > > 
> > > > This is the problems I want to address, because those 10
> > > > designers
> > > > will
> > > > by experience also spell the same field in 10 different ways.
> > > > Making
> > > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc.
> > > > Let
> > > > those 10 designers remove the fields they do not want instead.
> > > > 
> > > > > The only possible solution that I would accept is to move the
> > > > > default
> > > > > field definitions from the eeschema configuration file into
> > > > > the
> > > > > default
> > > > > kicad project file.  This way existing projects would not be
> > > > > polluted
> > > > > with the proposed default fields and users could define their
> > > > > own
> > > > > default fields in a custom project file.
> > > > 
> > > > Default fields does not pollute if they are empty, they just
> > > > give a
> > > > hint of what data could be put into the schematic, same as with
> > > > the
> > > > datasheet field, which is not often used. Funny how noone ever
> > > > complains about that one.
> > > > 
> > > > > [...]
> > > > > A more flexible solution would be to add a "File->New from
> > > > > Custom
> > > > > Template" command to KiCad to allow the user to select any
> > > > > custom
> > > > > project file.  This would allow for multiple custom project
> > > > > files
> > > > > instead of forcing the user to use only a single default
> > > > > project
> > > > > file.
> > > > 
> > > > As long as the "File->New Project" would include the additional
> > > > fields
> > > > and then people can use "New from Custom Template" means they
> > > > can
> > > > use a
> > > > template that is empty. Otherwise it would defeat the purpose.
> > > > I am
> > > > proposing a slightly different default configuration, not any
> > > > change in
> > > > how people will 

Re: [Kicad-developers] More default fields in schematic

[Ben Hest]

>From a Digi-Key KiCad library standpoint, as we're still in beta, I would
gladly change the fields to whatever would be decided.  Uniformity for
plugins use would definitely be an advantage.

-Ben

On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
kristofferodmar...@gmail.com> wrote:

> Thanks! This is exactly what i was going for, non-intrusive oppurtunity
> for uniformity!
>
> I tested the bom2csv plugin, It did not include the empty fields.
>
> I also tested the bom_csv_sorted_by_ref, it did not include the empty
> values, but it included some values I had not specified, such as
> Manufacturer and Vendor even if they were not provided in the
> schematic.
>
> - Kristoffer
>
> On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > I think I like this new patch.  It provides the /opportunity/ for
> > uniformity, without getting in the way of those who want to go their
> > own way.
> >
> > Do the BOM generators automatically output all default fields or only
> > those with values?
> >
> > > On 22 May 2018, at 09:22, kristoffer ödmark  > > il.com> wrote:
> > >
> > > Please disregard my previous mail, it got mangled badly somehow, it
> > > did
> > > not look like that in my editor at least.
> > >
> > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > Eeschema already supports creating default optional fields in the
> > > > configuration settings dialog.  Used correctly, these will give
> > > > you
> > > > the
> > > > same optional field names for every project without having to add
> > > > them
> > > > by hand to each symbol and possibly typing in different field
> > > > names
> > > > by
> > > > accident.
> > >
> > > Different users will still type in different field names for the
> > > same
> > > things though. What you describe works as long as there is only one
> > > person in the entire projects lifetime, using only one computer.
> > >
> > > > The proposed patch would intermingle the default fields
> > > > with
> > > > existing schematic symbol fields which would break existing BOMs
> > > > which I
> > > > don't think users will appreciate.
> > >
> > > The proposed patch will only change default settings, existing
> > > users
> > > with a config already in place will not be affected. I realised
> > > that
> > > the fields now accept empty values as well, so existing boms on new
> > > installations will not be affected either. I updated the patch, so
> > > it
> > > will not affect anyone that doesnt use the fields.
> > >
> > > > [...] As I've stated before, I can set 10
> > > > different designers down and I will get 10 different sets of
> > > > default
> > > > field names.  This really seems like me to be a configuration
> > > > issue.
> > >
> > > This is the problems I want to address, because those 10 designers
> > > will
> > > by experience also spell the same field in 10 different ways.
> > > Making
> > > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> > > those 10 designers remove the fields they do not want instead.
> > >
> > > > The only possible solution that I would accept is to move the
> > > > default
> > > > field definitions from the eeschema configuration file into the
> > > > default
> > > > kicad project file.  This way existing projects would not be
> > > > polluted
> > > > with the proposed default fields and users could define their own
> > > > default fields in a custom project file.
> > >
> > > Default fields does not pollute if they are empty, they just give a
> > > hint of what data could be put into the schematic, same as with the
> > > datasheet field, which is not often used. Funny how noone ever
> > > complains about that one.
> > >
> > > > [...]
> > > > A more flexible solution would be to add a "File->New from Custom
> > > > Template" command to KiCad to allow the user to select any custom
> > > > project file.  This would allow for multiple custom project files
> > > > instead of forcing the user to use only a single default project
> > > > file.
> > >
> > > As long as the "File->New Project" would include the additional
> > > fields
> > > and then people can use "New from Custom Template" means they can
> > > use a
> > > template that is empty. Otherwise it would defeat the purpose. I am
> > > proposing a slightly different default configuration, not any
> > > change in
> > > how people will use the software.
> > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > > On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> > > > > I agree, I had the same issue when I was doing my board, I
> > > > > needed a
> > > > > field for all components, and I had to manually add it for
> > > > > every
> > > > > item,
> > > > > there was no way to add this field to all components at the
> > > > > same
> > > > > time or
> > > > > to have it add by default from the addition of a new component
> > > > > to
> > > > > the sheet.
> > > > >
> > > > > Which reminds me, Cadence Designer has tools to manipulate
> > > > > fields
> > > 

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

On 5/22/2018 4:11 AM, Maciej Sumiński wrote:
> One more field that could become predefined and receive a special
> meaning is 'Mounted' or similar. This will come handy when we decide to
> support assembly variants and will let us add a visual distinction
> between mounted and not mounted components if we want it.

The concept of "mounted" is going to be part of the new schematic file
format so making this a field will not be necessary.

> 
> The remaining fields is a matter of configuration, particularly that
> there is a way to specify the default fields in eeschema. I am quite
> sure that there are existing libraries using other field names than the
> ones we would hard-code, so such change would make users upset. I do not
> see there is a reason to enforce field naming for everyone, unless the
> field needs to be treated in a special way:
> 
> - "Reference" as the unique component identifier and a link between
> schematics and board
> - "Footprint" to pick the physical representation with the footprint browser
> - "Datasheet" lets open corresponding documentation for a component
> - "Value" is the only field that serves the description purpose only,
> but it seems a sensible exception to the rule
> 
> Cheers,
> Orson
> 
> On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
>> Hello!
>>
>> I will open this can of worms again, I feel that I have to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we have a
>> collaboration issue, maybe not a mayor one. But one nonetheless.
>>
>> We really need more default fields for our schematic symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>     - Collaborators working on the same project will not create
>> duplicate fields in libs/projects describing the same thing by mistake
>>     - Projects that aim to interact or add to Kicad can assume that the
>> Fields will exist, and will know what name/tag to look for
>>   (bom exporters, price checkers, MacroFab, etc)
>>     - Open source projects will be easier to collaborate, read and order
>>
>> The reason I think it is better to have the fields by default than the
>> current solution to add them is that the majority will use
>> what exists, and tools can support it from the very beginning, people
>> with inhouse tools seems to dislike this, since they map their
>> parts with an inhouse number - and then handle the information about the
>> part there. From what I gather, this is not the majority, and
>> these persons still modify the default fields settings.
>>
>> I spent maybe 30-40 mins checking the "made with kicad" projects, I
>> found that the most common addition to libs and schematics are:
>>     - Manufacturers part number, these were named widely different in
>> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>>         I even saw a mix of these in the same project once, along with
>> some people having the vendor id only.
>>     - Manufacturer ( found some different languages though )
>>
>> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
>> 16V ), Vendor information and different Descriptions. They were named
>> and abbreviated
>> very differently accross projects.
>>
>> What I would like to see is these additional fields by default, but
>> hidden from the schematic unless changed by user.
>>     Tolerance ( used for setting tolerances of resistors, capacitors,
>> oscillators, etc )
>>     MaxRating ( field were one can specify max Voltage, Ampere,
>> Frequency, or whatever the component needs )
>>     Manufacturer ( For inhouse numbers, they could either just remove
>> it, or use the company/group name )
>>     MPN ( Maybe PartNumber could be used here, and people who use
>> inhouse numbers use it aswell, I dont really care what its called, as
>> long as its called something )
>>     Vendor
>>     Notes
>>
>> I would be all up for extra additions/removals, but I would prefer if
>> the naming is not discussed, but rather just decided/agreed upon by
>> someone in the lead team.
>> The very least I think should be added in case the previous is to much are:
>>     Tolerance
>>     Manufacturer
>>     MPN
>>
>> I attach a patch for the minimal set, tested on linux by removing the
>> .config/kicad/eeschema file.
>>
>> - Kristoffer
>>
>>
>> ps
>> Some github files i reviewed, not all:
>> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>>
>> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>>
>> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
>>
>> 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

Thanks! This is exactly what i was going for, non-intrusive oppurtunity
for uniformity! 

I tested the bom2csv plugin, It did not include the empty fields.

I also tested the bom_csv_sorted_by_ref, it did not include the empty
values, but it included some values I had not specified, such as
Manufacturer and Vendor even if they were not provided in the
schematic.

- Kristoffer

On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> I think I like this new patch.  It provides the /opportunity/ for
> uniformity, without getting in the way of those who want to go their
> own way.
> 
> Do the BOM generators automatically output all default fields or only
> those with values?
> 
> > On 22 May 2018, at 09:22, kristoffer ödmark  > il.com> wrote:
> > 
> > Please disregard my previous mail, it got mangled badly somehow, it
> > did
> > not look like that in my editor at least.
> > 
> > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > Eeschema already supports creating default optional fields in the
> > > configuration settings dialog.  Used correctly, these will give
> > > you
> > > the
> > > same optional field names for every project without having to add
> > > them
> > > by hand to each symbol and possibly typing in different field
> > > names
> > > by
> > > accident.  
> > 
> > Different users will still type in different field names for the
> > same
> > things though. What you describe works as long as there is only one
> > person in the entire projects lifetime, using only one computer.
> > 
> > > The proposed patch would intermingle the default fields
> > > with
> > > existing schematic symbol fields which would break existing BOMs
> > > which I
> > > don't think users will appreciate.  
> > 
> > The proposed patch will only change default settings, existing
> > users
> > with a config already in place will not be affected. I realised
> > that
> > the fields now accept empty values as well, so existing boms on new
> > installations will not be affected either. I updated the patch, so
> > it
> > will not affect anyone that doesnt use the fields. 
> > 
> > > [...] As I've stated before, I can set 10
> > > different designers down and I will get 10 different sets of
> > > default
> > > field names.  This really seems like me to be a configuration
> > > issue.
> > 
> > This is the problems I want to address, because those 10 designers
> > will
> > by experience also spell the same field in 10 different ways.
> > Making
> > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> > those 10 designers remove the fields they do not want instead.
> > 
> > > The only possible solution that I would accept is to move the
> > > default
> > > field definitions from the eeschema configuration file into the
> > > default
> > > kicad project file.  This way existing projects would not be
> > > polluted
> > > with the proposed default fields and users could define their own
> > > default fields in a custom project file.  
> > 
> > Default fields does not pollute if they are empty, they just give a
> > hint of what data could be put into the schematic, same as with the
> > datasheet field, which is not often used. Funny how noone ever
> > complains about that one.
> > 
> > > [...]
> > > A more flexible solution would be to add a "File->New from Custom
> > > Template" command to KiCad to allow the user to select any custom
> > > project file.  This would allow for multiple custom project files
> > > instead of forcing the user to use only a single default project
> > > file.
> > 
> > As long as the "File->New Project" would include the additional
> > fields
> > and then people can use "New from Custom Template" means they can
> > use a
> > template that is empty. Otherwise it would defeat the purpose. I am
> > proposing a slightly different default configuration, not any
> > change in
> > how people will use the software.
> > 
> > > Cheers,
> > > 
> > > Wayne
> > > 
> > > On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> > > > I agree, I had the same issue when I was doing my board, I
> > > > needed a
> > > > field for all components, and I had to manually add it for
> > > > every
> > > > item,
> > > > there was no way to add this field to all components at the
> > > > same
> > > > time or
> > > > to have it add by default from the addition of a new component
> > > > to
> > > > the sheet.
> > > > 
> > > > Which reminds me, Cadence Designer has tools to manipulate
> > > > fields
> > > > on a
> > > > large scale, whether to add, delete, show, hide, etc, this is
> > > > something
> > > > that would be nice to have in KiCAD, either that or a table of
> > > > all
> > > > components for the sheet or schematic and columns for each
> > > > field,
> > > > with
> > > > ability to show/hide each cell individually.
> > > > 
> > > > I think the ultimate goal is to make the Symbol Table more
> > > > useful,
> > > > but
> > > > that'll take to long for v5 so if Kristoffer's patch allows an

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

I think I like this new patch.  It provides the /opportunity/ for uniformity, 
without getting in the way of those who want to go their own way.

Do the BOM generators automatically output all default fields or only those 
with values?

> On 22 May 2018, at 09:22, kristoffer ödmark  
> wrote:
> 
> Please disregard my previous mail, it got mangled badly somehow, it did
> not look like that in my editor at least.
> 
> On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
>> Eeschema already supports creating default optional fields in the
>> configuration settings dialog.  Used correctly, these will give you
>> the
>> same optional field names for every project without having to add
>> them
>> by hand to each symbol and possibly typing in different field names
>> by
>> accident.  
> 
> Different users will still type in different field names for the same
> things though. What you describe works as long as there is only one
> person in the entire projects lifetime, using only one computer.
> 
>> The proposed patch would intermingle the default fields
>> with
>> existing schematic symbol fields which would break existing BOMs
>> which I
>> don't think users will appreciate.  
> 
> The proposed patch will only change default settings, existing users
> with a config already in place will not be affected. I realised that
> the fields now accept empty values as well, so existing boms on new
> installations will not be affected either. I updated the patch, so it
> will not affect anyone that doesnt use the fields. 
> 
>> [...] As I've stated before, I can set 10
>> different designers down and I will get 10 different sets of default
>> field names.  This really seems like me to be a configuration issue.
> 
> This is the problems I want to address, because those 10 designers will
> by experience also spell the same field in 10 different ways. Making
> their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
> those 10 designers remove the fields they do not want instead.
> 
>> The only possible solution that I would accept is to move the default
>> field definitions from the eeschema configuration file into the
>> default
>> kicad project file.  This way existing projects would not be polluted
>> with the proposed default fields and users could define their own
>> default fields in a custom project file.  
> 
> Default fields does not pollute if they are empty, they just give a
> hint of what data could be put into the schematic, same as with the
> datasheet field, which is not often used. Funny how noone ever
> complains about that one.
> 
>> [...]
>> A more flexible solution would be to add a "File->New from Custom
>> Template" command to KiCad to allow the user to select any custom
>> project file.  This would allow for multiple custom project files
>> instead of forcing the user to use only a single default project
>> file.
> 
> As long as the "File->New Project" would include the additional fields
> and then people can use "New from Custom Template" means they can use a
> template that is empty. Otherwise it would defeat the purpose. I am
> proposing a slightly different default configuration, not any change in
> how people will use the software.
> 
>> 
>> Cheers,
>> 
>> Wayne
>> 
>> On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
>>> I agree, I had the same issue when I was doing my board, I needed a
>>> field for all components, and I had to manually add it for every
>>> item,
>>> there was no way to add this field to all components at the same
>>> time or
>>> to have it add by default from the addition of a new component to
>>> the sheet.
>>> 
>>> Which reminds me, Cadence Designer has tools to manipulate fields
>>> on a
>>> large scale, whether to add, delete, show, hide, etc, this is
>>> something
>>> that would be nice to have in KiCAD, either that or a table of all
>>> components for the sheet or schematic and columns for each field,
>>> with
>>> ability to show/hide each cell individually.
>>> 
>>> I think the ultimate goal is to make the Symbol Table more useful,
>>> but
>>> that'll take to long for v5 so if Kristoffer's patch allows an easy
>>> way
>>> to add fields to all components or similar, I'd say do it because
>>> people
>>> will be pissed and waste their time doing it for every component in
>>> their schematic.
>>> 
>>> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
>>> 
 wrote:
>>> 
>>>I obvviously disagree, the correct solution would be to have
>>> both.
>>>This does not hinder that, its not even the same problem.
>>> 
>>>The problem is for everyone who want for example the
>>> Manufacturer
>>>Part Number will have to define a fieldname, which every time
>>>results in them abbreviating it to something different. Hence
>>> nobody
>>>can work with Manufacturer Part Numbers.
>>> 
>>>Here is something similar, Imagine all of the colours in Kicad
>>> 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

On Tue, 2018-05-22 at 10:11 +0200, Maciej Sumiński wrote:
> One more field that could become predefined and receive a special
> meaning is 'Mounted' or similar. This will come handy when we decide
> to
> support assembly variants and will let us add a visual distinction
> between mounted and not mounted components if we want it.
> The remaining fields is a matter of configuration, particularly that
> there is a way to specify the default fields in eeschema. I am quite
> sure that there are existing libraries using other field names than
> the
> ones we would hard-code, so such change would make users upset. I do
> not
> see there is a reason to enforce field naming for everyone, unless
> the

There is no enforcement, there is only suggestion with a default
config. I feel that maybe I am not getting that point across. For
example, giving the users the field MPN as an option field gives them a
starting point, nothing with my approach locks them into using that
specific name or even keep it, they can change it. It only helps when
people wants to use it, since it hints that this name might be
compatible with other tools.

> field needs to be treated in a special way:
> 
> - "Reference" as the unique component identifier and a link between
> schematics and board
> - "Footprint" to pick the physical representation with the footprint
> browser
> - "Datasheet" lets open corresponding documentation for a component
> - "Value" is the only field that serves the description purpose only,
> but it seems a sensible exception to the rule

MPN - When I want to forward my schematic to a one-click order or check
 price on mouser, digikey or wherever. But we dont have that now, and
we can never have that. Because we can not suggest a name, that would
be rude. I dont get the problem with a default config that hints at
what it might be called. I chose MPN in my example since it is used be
the Digikey library on github amongst other projects i found.

> 
> Cheers,
> Orson
> 
> On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
> > Hello!
> > 
> > I will open this can of worms again, I feel that I have to. So from
> > what
> > I gather we have proffessionals as the main aim in Kicad.
> > The reason I will open this issue again is that I feel we have a
> > collaboration issue, maybe not a mayor one. But one nonetheless.
> > 
> > We really need more default fields for our schematic symbols. Im
> > not
> > proposing required fields, I am *ONLY* proposing that
> > there should be default fields added into the default fields
> > settings
> > tab. I am not proposing they need to be filled in the
> > libraries, nor that people need to use them. only that they need to
> > exist with a fresh install of kicad so that easy problems
> > such as theese do not happen:
> > 
> > - Collaborators working on the same project will not create
> > duplicate fields in libs/projects describing the same thing by
> > mistake
> > - Projects that aim to interact or add to Kicad can assume that
> > the
> > Fields will exist, and will know what name/tag to look for
> >   (bom exporters, price checkers, MacroFab, etc)
> > - Open source projects will be easier to collaborate, read and
> > order
> > 
> > The reason I think it is better to have the fields by default than
> > the
> > current solution to add them is that the majority will use
> > what exists, and tools can support it from the very beginning,
> > people
> > with inhouse tools seems to dislike this, since they map their
> > parts with an inhouse number - and then handle the information
> > about the
> > part there. From what I gather, this is not the majority, and
> > these persons still modify the default fields settings.
> > 
> > I spent maybe 30-40 mins checking the "made with kicad" projects, I
> > found that the most common addition to libs and schematics are:
> > - Manufacturers part number, these were named widely different
> > in
> > projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value
> > field )
> > I even saw a mix of these in the same project once, along
> > with
> > some people having the vendor id only.
> > - Manufacturer ( found some different languages though )
> > 
> > more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W,
> > 85C,
> > 16V ), Vendor information and different Descriptions. They were
> > named
> > and abbreviated
> > very differently accross projects.
> > 
> > What I would like to see is these additional fields by default, but
> > hidden from the schematic unless changed by user.
> > Tolerance ( used for setting tolerances of resistors,
> > capacitors,
> > oscillators, etc )
> > MaxRating ( field were one can specify max Voltage, Ampere,
> > Frequency, or whatever the component needs )
> > Manufacturer ( For inhouse numbers, they could either just
> > remove
> > it, or use the company/group name )
> > MPN ( Maybe PartNumber could be used here, and people who use
> > inhouse numbers use it aswell, I 

Re: [Kicad-developers] More default fields in schematic

[kristoffer ödmark]

Please disregard my previous mail, it got mangled badly somehow, it did
not look like that in my editor at least.

On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> Eeschema already supports creating default optional fields in the
> configuration settings dialog.  Used correctly, these will give you
> the
> same optional field names for every project without having to add
> them
> by hand to each symbol and possibly typing in different field names
> by
> accident.  

Different users will still type in different field names for the same
things though. What you describe works as long as there is only one
person in the entire projects lifetime, using only one computer.

> The proposed patch would intermingle the default fields
> with
> existing schematic symbol fields which would break existing BOMs
> which I
> don't think users will appreciate.  

The proposed patch will only change default settings, existing users
with a config already in place will not be affected. I realised that
the fields now accept empty values as well, so existing boms on new
installations will not be affected either. I updated the patch, so it
will not affect anyone that doesnt use the fields. 

> [...] As I've stated before, I can set 10
> different designers down and I will get 10 different sets of default
> field names.  This really seems like me to be a configuration issue.

This is the problems I want to address, because those 10 designers will
by experience also spell the same field in 10 different ways. Making
their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let
those 10 designers remove the fields they do not want instead.

> The only possible solution that I would accept is to move the default
> field definitions from the eeschema configuration file into the
> default
> kicad project file.  This way existing projects would not be polluted
> with the proposed default fields and users could define their own
> default fields in a custom project file.  

Default fields does not pollute if they are empty, they just give a
hint of what data could be put into the schematic, same as with the
datasheet field, which is not often used. Funny how noone ever
complains about that one.

> [...]
> A more flexible solution would be to add a "File->New from Custom
> Template" command to KiCad to allow the user to select any custom
> project file.  This would allow for multiple custom project files
> instead of forcing the user to use only a single default project
> file.

As long as the "File->New Project" would include the additional fields
and then people can use "New from Custom Template" means they can use a
template that is empty. Otherwise it would defeat the purpose. I am
proposing a slightly different default configuration, not any change in
how people will use the software.

> 
> Cheers,
> 
> Wayne
> 
> On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> > I agree, I had the same issue when I was doing my board, I needed a
> > field for all components, and I had to manually add it for every
> > item,
> > there was no way to add this field to all components at the same
> > time or
> > to have it add by default from the addition of a new component to
> > the sheet.
> > 
> > Which reminds me, Cadence Designer has tools to manipulate fields
> > on a
> > large scale, whether to add, delete, show, hide, etc, this is
> > something
> > that would be nice to have in KiCAD, either that or a table of all
> > components for the sheet or schematic and columns for each field,
> > with
> > ability to show/hide each cell individually.
> > 
> > I think the ultimate goal is to make the Symbol Table more useful,
> > but
> > that'll take to long for v5 so if Kristoffer's patch allows an easy
> > way
> > to add fields to all components or similar, I'd say do it because
> > people
> > will be pissed and waste their time doing it for every component in
> > their schematic.
> > 
> > On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
> > 
> > > wrote:
> > 
> > I obvviously disagree, the correct solution would be to have
> > both.
> > This does not hinder that, its not even the same problem.
> > 
> > The problem is for everyone who want for example the
> > Manufacturer
> > Part Number will have to define a fieldname, which every time
> > results in them abbreviating it to something different. Hence
> > nobody
> > can work with Manufacturer Part Numbers.
> > 
> > Here is something similar, Imagine all of the colours in Kicad
> > for
> > all of the layers where white by default. Have fun defining all
> > the
> > colours yourself.
> > Maybe you want to define them yourself, nobody is stopping you
> > now
> > either, just get cracking.
> > 
> > How easy would it be for you to look at the board someone else
> > made
> > later and understand what is what? Maybe for some that is a
> > better
> > solution, but for me that

Re: [Kicad-developers] More default fields in schematic

[Maciej Sumiński]

One more field that could become predefined and receive a special
meaning is 'Mounted' or similar. This will come handy when we decide to
support assembly variants and will let us add a visual distinction
between mounted and not mounted components if we want it.

The remaining fields is a matter of configuration, particularly that
there is a way to specify the default fields in eeschema. I am quite
sure that there are existing libraries using other field names than the
ones we would hard-code, so such change would make users upset. I do not
see there is a reason to enforce field naming for everyone, unless the
field needs to be treated in a special way:

- "Reference" as the unique component identifier and a link between
schematics and board
- "Footprint" to pick the physical representation with the footprint browser
- "Datasheet" lets open corresponding documentation for a component
- "Value" is the only field that serves the description purpose only,
but it seems a sensible exception to the rule

Cheers,
Orson

On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
> Hello!
> 
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
> 
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
> 
>     - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>     - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>   (bom exporters, price checkers, MacroFab, etc)
>     - Open source projects will be easier to collaborate, read and order
> 
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
> 
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>     - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>         I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>     - Manufacturer ( found some different languages though )
> 
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
> 
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>     Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>     MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>     Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>     MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>     Vendor
>     Notes
> 
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>     Tolerance
>     Manufacturer
>     MPN
> 
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
> 
> - Kristoffer
> 
> 
> ps
> Some github files i reviewed, not all:
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
> 
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
> 
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> 
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 

Re: [Kicad-developers] More default fields in schematic

[kristoffer Ödmark]

The proposed patch would intermingle the default  > fields with existing schematic symbol fields which would break > 
existing BOMs which I don't think users will appreciate. The proposed 
patch will only change default settings, existing users with a config 
already in place will not be affected. I realised that the fields now 
accept empty values as well, so existing boms on new installations will 
not be affected either. I updated the patch, so it will not affect 
anyone that doesnt use the fields.
As I've stated before, I can set 10 different designers down  > and I will get 10 different sets of default field names. This really 
> seems like me to be a configuration issue. This is the problems I 
want to address, because those 10 designers will by experience also 
spell the same field in 10 different ways. Making their designs 
incompatable, resulting in 100 different fields, but only describing 10 
different things
Is this feature not  > useful enough or not documented well enough for users? Hard coding > 
default field names that no one can agree upon is not going to > happen. 
The problem is that they will spell differently, MPN, MFPN, #mfg, 
ManufPart, etc etc The problem is really that those who want to embedd 
the part number can not to that in an easy way, they cannot set the 
field in any compatible way, creating many problems for people that has 
to compare/view others design. Many hours can be lost, just because the 
simple phrase "Set the Manufacturers Part number in the schematic of 
your desing", all that can be solved by a single step of spelling the 
value name for the users. Ofcourse they will still be able to change it 
later if they want.
the same optional field names for every project without having to add  > them by hand to each symbol As long as you assume there will only 
ever be one person involved here, and that they will always use the same 
computer over the projects lifetime. > The only possible solution that I 
would accept is to move the > default field definitions from the 
eeschema configuration file into > the default kicad project file. This 
way existing projects would not > be polluted with the proposed default 
fields and users could define > their own default fields in a custom 
project file. I would like this as well, all I want is a default name, 
to give users a hint, I really do not care where it is set, or even if 
there would be a lot of fields that I personally will never use in it, 
because it is much easier to remove the fields than to add them in a 
uniform way over the globe. Still though, I think having the fields set 
in eeschema is better, makes my changes stick over different projects. > 
This would allow for multiple > custom project files instead of forcing 
the user to use only a single > default project file. As long as the 
"File->New Project" would include the additional fields and then people 
can use "New from Custom Template" means they can use a template that is 
free from the fields, sure. Otherwise we are back at square one, and we 
added a lot of shit, helping no one. - Kristoffer On 2018-05-22 00:22, 
Wayne Stambaugh wrote:
introduced a change that allows the user to define a custom template  > path which takes precedence over the system template path so this > 
solution is workable. A more flexible solution would be to add a > 
"File->New from Custom Template" command to KiCad to allow the user > to 
select any custom project file. > > Cheers, > > Wayne > > On 05/20/2018 
06:27 PM, Andrey Kuznetsov wrote: >> I agree, I had the same issue when 
I was doing my board, I needed >> a field for all components, and I had 
to manually add it for every >> item, there was no way to add this field 
to all components at the >> same time or to have it add by default from 
the addition of a new >> component to the sheet. >> >> Which reminds me, 
Cadence Designer has tools to manipulate fields >> on a large scale, 
whether to add, delete, show, hide, etc, this is >> something that would 
be nice to have in KiCAD, either that or a >> table of all components 
for the sheet or schematic and columns for >> each field, with ability 
to show/hide each cell individually. >> >> I think the ultimate goal is 
to make the Symbol Table more useful, >> but that'll take to long for v5 
so if Kristoffer's patch allows an >> easy way to add fields to all 
components or similar, I'd say do it >> because people will be pissed 
and waste their time doing it for >> every component in their schematic. 
>> >> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark >> 
> > 
wrote: >> >> I obvviously disagree, the correct solution would be to 
have both. >> This does not hinder that, its not even the same problem. 
>> >> The problem is for everyone who want for example the Manufacturer 
>> Part Number will have to define a fieldname, which every time >> 
results in them abbreviating it to something different. 

Re: [Kicad-developers] More default fields in schematic

[Ingo Kletti]

Hello,

Am 22.05.2018 um 00:22 schrieb Wayne Stambaugh:

[...]


> Hard coding default field names that no one can agree
> upon is not going to happen.  As I've stated before, I can set 10
> different designers down and I will get 10 different sets of default
> field names.  This really seems like me to be a configuration issue.
>
> [...]


The only possible solution that I would accept is to move the default
field definitions from the eeschema configuration file into the default
kicad project file.  This way existing projects would not be polluted
with the proposed default fields and users could define their own
default fields in a custom project file.


I can absolutely understand your position about not hardcoding default 
fields.


From my point of view (and use case) moving the default field config 
from the eeschema config to the default kicad project file would be a 
very useful solution (and my guess is that many others might be OK with 
it, too).


Regards,

Ingo

___
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

Re: [Kicad-developers] More default fields in schematic

[Wayne Stambaugh]

Eeschema already supports creating default optional fields in the
configuration settings dialog.  Used correctly, these will give you the
same optional field names for every project without having to add them
by hand to each symbol and possibly typing in different field names by
accident.  The proposed patch would intermingle the default fields with
existing schematic symbol fields which would break existing BOMs which I
don't think users will appreciate.  The new symbol field editor should
make editing the optional field values much easier than using the symbol
edit dialog.  Is this feature not useful enough or not documented well
enough for users?  Hard coding default field names that no one can agree
upon is not going to happen.  As I've stated before, I can set 10
different designers down and I will get 10 different sets of default
field names.  This really seems like me to be a configuration issue.

The only possible solution that I would accept is to move the default
field definitions from the eeschema configuration file into the default
kicad project file.  This way existing projects would not be polluted
with the proposed default fields and users could define their own
default fields in a custom project file.  I recently introduced a change
that allows the user to define a custom template path which takes
precedence over the system template path so this solution is workable.
A more flexible solution would be to add a "File->New from Custom
Template" command to KiCad to allow the user to select any custom
project file.  This would allow for multiple custom project files
instead of forcing the user to use only a single default project file.

Cheers,

Wayne

On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote:
> I agree, I had the same issue when I was doing my board, I needed a
> field for all components, and I had to manually add it for every item,
> there was no way to add this field to all components at the same time or
> to have it add by default from the addition of a new component to the sheet.
> 
> Which reminds me, Cadence Designer has tools to manipulate fields on a
> large scale, whether to add, delete, show, hide, etc, this is something
> that would be nice to have in KiCAD, either that or a table of all
> components for the sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
> 
> I think the ultimate goal is to make the Symbol Table more useful, but
> that'll take to long for v5 so if Kristoffer's patch allows an easy way
> to add fields to all components or similar, I'd say do it because people
> will be pissed and waste their time doing it for every component in
> their schematic.
> 
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
> > wrote:
> 
> I obvviously disagree, the correct solution would be to have both.
> This does not hinder that, its not even the same problem.
> 
> The problem is for everyone who want for example the Manufacturer
> Part Number will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody
> can work with Manufacturer Part Numbers.
> 
> Here is something similar, Imagine all of the colours in Kicad for
> all of the layers where white by default. Have fun defining all the
> colours yourself.
> Maybe you want to define them yourself, nobody is stopping you now
> either, just get cracking.
> 
> How easy would it be for you to look at the board someone else made
> later and understand what is what? Maybe for some that is a better
> solution, but for me that
> would be an extreme example of bad default values.
> 
> This is how the default fields are now, they are white, or more like
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as
> I previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to.
> But, tools like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well.
> So for the majority of users, who doesnt change defaults,
> the tool would just work.
> 
> I will reiterate, I do not care what they are named, I want a
> default field where I can put my manufacturer part number, amongs
> others.
> The specific abbreviation or name does not matter, If i care, I can
> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that
> dont, It will not matter.
> 
> Sane defaults matter. A lot actually.
> 
> - Kristoffer
> 
> On 2018-05-20 23:40, José Ignacio wrote:
> 
> I dont like this, the right solution would be to allow for
> importing a default config into kicad for 

Re: [Kicad-developers] More default fields in schematic

[Seth Hillbrand]

I've opened a bug report to address this item

https://bugs.launchpad.net/kicad/+bug/1772529

Please feel free to add elements to be considered for this feature on the
bug report.  Kristoffer, I like the idea behind your patch.  Clearly people
have many use cases for this; let's make sure that we address all elements
so that we don't end up getting bug reports against the feature.

-S​



Am Mo., 21. Mai 2018 um 14:59 Uhr schrieb Russell Oliver <
roliver8...@gmail.com>:

> I don't know if this approach is what is being proposed but the way I
> envisage it working is to have the ability to set a list of default fields
> at a project level, which you could also set as your default for new
> projects. Not necessarily adding to the list of default fields currently
> hard coded into Kicad.
>
> Any time you place a symbol or footprint, it would copy the additional
> default fields into the list found in the properties editor.
>
> Users would be free to include what ever fields they like as default. I
> typically use MPN and Manufacturer then Digikey, Mouser etc
>
> On Tue, 22 May 2018 04:31 Ingo Kletti,  wrote:
>
>> I'll throw in my weight as my job is supporting students working on
>> their assigntments in electronics engineering (40-50 students per
>> semester) and for many their first contact with EDA software is KiCad.
>>
>> I've created a small atomic library representing the parts we have
>> readily available but the majority of parts are special to the task at
>> hand and need to be sourced from Digikey, Mouser et al.
>>
>> We could impose a policy about additional fields, but from experience
>> I'd say that we would have to reject about half of the projects.
>>
>> So if the fields like Manufacturer Part Number or Vendor were
>> pre-defined, this would give first-time users like our students a much
>> better idea about the usefulness of the fields without me and my
>> colleagues explaining the same thing over and over.
>>
>> In addition external tools and plugins would finally know what terms to
>> look for and work without the need for fine-tuning for keywords before
>> being useful.
>>
>> And for the argument of "part number must be unique and Manufacturer and
>> Vendor must be handled by the company database":
>>
>> This is complete overkill for one-off project like the ones our students
>> work on, but nevertheless we need a way to enable external tools for
>> handling the component sourcing.
>>
>> I guess this is also true for a big but silent part of the Kicad user
>> base.
>>
>> Regards,
>>
>> Ingo
>>
>> ___
>> 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
>>
> ___
> 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
>
___
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

Re: [Kicad-developers] More default fields in schematic

[Russell Oliver]

I don't know if this approach is what is being proposed but the way I
envisage it working is to have the ability to set a list of default fields
at a project level, which you could also set as your default for new
projects. Not necessarily adding to the list of default fields currently
hard coded into Kicad.

Any time you place a symbol or footprint, it would copy the additional
default fields into the list found in the properties editor.

Users would be free to include what ever fields they like as default. I
typically use MPN and Manufacturer then Digikey, Mouser etc

On Tue, 22 May 2018 04:31 Ingo Kletti,  wrote:

> I'll throw in my weight as my job is supporting students working on
> their assigntments in electronics engineering (40-50 students per
> semester) and for many their first contact with EDA software is KiCad.
>
> I've created a small atomic library representing the parts we have
> readily available but the majority of parts are special to the task at
> hand and need to be sourced from Digikey, Mouser et al.
>
> We could impose a policy about additional fields, but from experience
> I'd say that we would have to reject about half of the projects.
>
> So if the fields like Manufacturer Part Number or Vendor were
> pre-defined, this would give first-time users like our students a much
> better idea about the usefulness of the fields without me and my
> colleagues explaining the same thing over and over.
>
> In addition external tools and plugins would finally know what terms to
> look for and work without the need for fine-tuning for keywords before
> being useful.
>
> And for the argument of "part number must be unique and Manufacturer and
> Vendor must be handled by the company database":
>
> This is complete overkill for one-off project like the ones our students
> work on, but nevertheless we need a way to enable external tools for
> handling the component sourcing.
>
> I guess this is also true for a big but silent part of the Kicad user base.
>
> Regards,
>
> Ingo
>
> ___
> 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
>
___
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

Re: [Kicad-developers] More default fields in schematic

[Ingo Kletti]

I'll throw in my weight as my job is supporting students working on 
their assigntments in electronics engineering (40-50 students per 
semester) and for many their first contact with EDA software is KiCad.


I've created a small atomic library representing the parts we have 
readily available but the majority of parts are special to the task at 
hand and need to be sourced from Digikey, Mouser et al.


We could impose a policy about additional fields, but from experience 
I'd say that we would have to reject about half of the projects.


So if the fields like Manufacturer Part Number or Vendor were 
pre-defined, this would give first-time users like our students a much 
better idea about the usefulness of the fields without me and my 
colleagues explaining the same thing over and over.


In addition external tools and plugins would finally know what terms to 
look for and work without the need for fine-tuning for keywords before 
being useful.


And for the argument of "part number must be unique and Manufacturer and 
Vendor must be handled by the company database":


This is complete overkill for one-off project like the ones our students 
work on, but nevertheless we need a way to enable external tools for 
handling the component sourcing.


I guess this is also true for a big but silent part of the Kicad user base.

Regards,

Ingo

___
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

Re: [Kicad-developers] More default fields in schematic

[Thomas Pointhuber]

I agree that it would be very beneficial (especially for 3rd-party
tools) to have a standardized naming convention.

Related discussions:

 *
https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/65

 * https://github.com/KiCad/kicad-library/issues/808

I don't see much harm done when new projects have some standard names
set as "Default Fields". It rather simplifies the work and would for
example also allow the library to add MPN in the future.

My 50cents: I would prefer "Manufacturer Part Number" or similar instead
of the abbreviation "MPN", to help new users understanding the meaning
of the field.

Regards, Thomas

Am 2018-05-21 um 15:13 schrieb Marcos Chaparro:
> I second Kristoffer. Some made with kicad examples are mine, some use
> #mfg and some use MPN because there is no common way to address a
> basic thing like a part number and for me it changed over the years,
> rendering old projects hard to maintain. Now I'leaning towards MPN
> only because kicost didn't support (or I coudnlt figure out) a #mfg
> field.
>
> Those who want a different field name can add a new field and use it,
> but IMO kicad needs some common ground on this particular issue.
>
> Marcos
>
> On Mon, May 21, 2018 at 8:55 AM, Kristoffer Ödmark
> >
> wrote:
>
> No, that is one usage of it, some people likes to make the
> schematic their bom, some tools and services can also rely on such
> values.
>
> Once again, the only people complaining are the ones that do not
> use it, and also the ones that will not be affected. Sure name it
> PartNum and use it the way you describe, you would never use any
> other tools to interact anyway, since that apparently is not your
> job... I only want there to be a common denomination for the the
> field names by default.
>
> Because right now, anyone who actually uses the Schematic this
> way, which are quite many will always have to randomly define and
> abbreviate the same field, which just hinders anything smart to be
> done on top of it.
>
> To better go with your thinking, I suggest you remove all the
> keybindings i KiCad, and then set them to what you want. That way
> you will get the current field experience. Everything is better
> with no defaults, amiright?
>
>  -Kristoffer
>
> On 2018-05-21 06:13, Jean-Paul Louis wrote:
>
> That discussion once again shows how people misunderstand the
> concept of part number.
> In a schematic, the part number attached to a RefDes should be
> unique AND NOT a manufacturer number.
>    There should be a one to one relationship between a part
> number (symbol) and a physical shape, so the PCB will be a
> unit manufacturable only when the BOM is generated, and is one
> to one relationship between part number and Mfg part number.
> The BOM is only for manufacturing assembly and procurement purpose
> and does not need to be part of the design database, so
> Manufacturing can use Equivalent Mfg numbers for a given part
> number. That’s why many companies use internal numbering
> systems that are non picture coded and just sequential.
> The relationship Symbol, Shape, Supplier is the responsibility
> of the master library, not the designers.
>
> Just my $0.02,
> Jean-Paul
> N1JPL
>
>
>
> On May 20, 2018, at 6:27 PM, Andrey Kuznetsov
> > wrote:
>
> I agree, I had the same issue when I was doing my board, I
> needed a field for all components, and I had to manually
> add it for every item, there was no way to add this field
> to all components at the same time or to have it add by
> default from the addition of a new component to the sheet.
>
> Which reminds me, Cadence Designer has tools to manipulate
> fields on a large scale, whether to add, delete, show,
> hide, etc, this is something that would be nice to have in
> KiCAD, either that or a table of all components for the
> sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
>
> I think the ultimate goal is to make the Symbol Table more
> useful, but that'll take to long for v5 so if Kristoffer's
> patch allows an easy way to add fields to all components
> or similar, I'd say do it because people will be pissed
> and waste their time doing it for every component in their
> schematic.
>
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
>  > wrote:
> I 

Re: [Kicad-developers] More default fields in schematic

[Marcos Chaparro]

I second Kristoffer. Some made with kicad examples are mine, some use #mfg
and some use MPN because there is no common way to address a basic thing
like a part number and for me it changed over the years, rendering old
projects hard to maintain. Now I'leaning towards MPN only because kicost
didn't support (or I coudnlt figure out) a #mfg field.

Those who want a different field name can add a new field and use it, but
IMO kicad needs some common ground on this particular issue.

Marcos

On Mon, May 21, 2018 at 8:55 AM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> No, that is one usage of it, some people likes to make the schematic their
> bom, some tools and services can also rely on such values.
>
> Once again, the only people complaining are the ones that do not use it,
> and also the ones that will not be affected. Sure name it PartNum and use
> it the way you describe, you would never use any other tools to interact
> anyway, since that apparently is not your job... I only want there to be a
> common denomination for the the field names by default.
>
> Because right now, anyone who actually uses the Schematic this way, which
> are quite many will always have to randomly define and abbreviate the same
> field, which just hinders anything smart to be done on top of it.
>
> To better go with your thinking, I suggest you remove all the keybindings
> i KiCad, and then set them to what you want. That way you will get the
> current field experience. Everything is better with no defaults, amiright?
>
>  -Kristoffer
>
> On 2018-05-21 06:13, Jean-Paul Louis wrote:
>
>> That discussion once again shows how people misunderstand the concept of
>> part number.
>> In a schematic, the part number attached to a RefDes should be unique AND
>> NOT a manufacturer number.
>>There should be a one to one relationship between a part number
>> (symbol) and a physical shape, so the PCB will be a unit manufacturable
>> only when the BOM is generated, and is one to one relationship between part
>> number and Mfg part number.
>> The BOM is only for manufacturing assembly and procurement purpose
>> and does not need to be part of the design database, so Manufacturing can
>> use Equivalent Mfg numbers for a given part number. That’s why many
>> companies use internal numbering systems that are non picture coded and
>> just sequential.
>> The relationship Symbol, Shape, Supplier is the responsibility of the
>> master library, not the designers.
>>
>> Just my $0.02,
>> Jean-Paul
>> N1JPL
>>
>>
>>
>> On May 20, 2018, at 6:27 PM, Andrey Kuznetsov 
>>> wrote:
>>>
>>> I agree, I had the same issue when I was doing my board, I needed a
>>> field for all components, and I had to manually add it for every item,
>>> there was no way to add this field to all components at the same time or to
>>> have it add by default from the addition of a new component to the sheet.
>>>
>>> Which reminds me, Cadence Designer has tools to manipulate fields on a
>>> large scale, whether to add, delete, show, hide, etc, this is something
>>> that would be nice to have in KiCAD, either that or a table of all
>>> components for the sheet or schematic and columns for each field, with
>>> ability to show/hide each cell individually.
>>>
>>> I think the ultimate goal is to make the Symbol Table more useful, but
>>> that'll take to long for v5 so if Kristoffer's patch allows an easy way to
>>> add fields to all components or similar, I'd say do it because people will
>>> be pissed and waste their time doing it for every component in their
>>> schematic.
>>>
>>> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
>>> kristofferodmar...@gmail.com> wrote:
>>> I obvviously disagree, the correct solution would be to have both. This
>>> does not hinder that, its not even the same problem.
>>>
>>> The problem is for everyone who want for example the Manufacturer Part
>>> Number will have to define a fieldname, which every time
>>> results in them abbreviating it to something different. Hence nobody can
>>> work with Manufacturer Part Numbers.
>>>
>>> Here is something similar, Imagine all of the colours in Kicad for all
>>> of the layers where white by default. Have fun defining all the colours
>>> yourself.
>>> Maybe you want to define them yourself, nobody is stopping you now
>>> either, just get cracking.
>>>
>>> How easy would it be for you to look at the board someone else made
>>> later and understand what is what? Maybe for some that is a better
>>> solution, but for me that
>>> would be an extreme example of bad default values.
>>>
>>> This is how the default fields are now, they are white, or more like
>>> see-throught, which makes life harder for anyone that
>>> wants to contribute or create tools that interact with kicad, and as I
>>> previously said, this is only a default, you are still
>>> equally able to add/remove or change the fields how you want to. But,
>>> tools like kibom or various other web-based tools can 

Re: [Kicad-developers] More default fields in schematic

[Kristoffer Ödmark]

No, that is one usage of it, some people likes to make the schematic 
their bom, some tools and services can also rely on such values.


Once again, the only people complaining are the ones that do not use it, 
and also the ones that will not be affected. Sure name it PartNum and 
use it the way you describe, you would never use any other tools to 
interact anyway, since that apparently is not your job... I only want 
there to be a common denomination for the the field names by default.


Because right now, anyone who actually uses the Schematic this way, 
which are quite many will always have to randomly define and abbreviate 
the same field, which just hinders anything smart to be done on top of it.


To better go with your thinking, I suggest you remove all the 
keybindings i KiCad, and then set them to what you want. That way you 
will get the current field experience. Everything is better with no 
defaults, amiright?


 -Kristoffer

On 2018-05-21 06:13, Jean-Paul Louis wrote:

That discussion once again shows how people misunderstand the concept of part 
number.
In a schematic, the part number attached to a RefDes should be unique AND NOT a 
manufacturer number.
   There should be a one to one relationship between a part number (symbol) and 
a physical shape, so the PCB will be a unit manufacturable only when the BOM is 
generated, and is one to one relationship between part number and Mfg part 
number.
The BOM is only for manufacturing assembly and procurement purpose
and does not need to be part of the design database, so Manufacturing can use 
Equivalent Mfg numbers for a given part number. That’s why many companies use 
internal numbering systems that are non picture coded and just sequential.
The relationship Symbol, Shape, Supplier is the responsibility of the master 
library, not the designers.

Just my $0.02,
Jean-Paul
N1JPL



On May 20, 2018, at 6:27 PM, Andrey Kuznetsov  wrote:

I agree, I had the same issue when I was doing my board, I needed a field for 
all components, and I had to manually add it for every item, there was no way 
to add this field to all components at the same time or to have it add by 
default from the addition of a new component to the sheet.

Which reminds me, Cadence Designer has tools to manipulate fields on a large 
scale, whether to add, delete, show, hide, etc, this is something that would be 
nice to have in KiCAD, either that or a table of all components for the sheet 
or schematic and columns for each field, with ability to show/hide each cell 
individually.

I think the ultimate goal is to make the Symbol Table more useful, but that'll 
take to long for v5 so if Kristoffer's patch allows an easy way to add fields 
to all components or similar, I'd say do it because people will be pissed and 
waste their time doing it for every component in their schematic.

On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark 
 wrote:
I obvviously disagree, the correct solution would be to have both. This does 
not hinder that, its not even the same problem.

The problem is for everyone who want for example the Manufacturer Part Number 
will have to define a fieldname, which every time
results in them abbreviating it to something different. Hence nobody can work 
with Manufacturer Part Numbers.

Here is something similar, Imagine all of the colours in Kicad for all of the 
layers where white by default. Have fun defining all the colours yourself.
Maybe you want to define them yourself, nobody is stopping you now either, just 
get cracking.

How easy would it be for you to look at the board someone else made later and 
understand what is what? Maybe for some that is a better solution, but for me 
that
would be an extreme example of bad default values.

This is how the default fields are now, they are white, or more like 
see-throught, which makes life harder for anyone that
wants to contribute or create tools that interact with kicad, and as I 
previously said, this is only a default, you are still
equally able to add/remove or change the fields how you want to. But, tools 
like kibom or various other web-based tools can much
easier integrate to it, or at least support a default value as well. So for the 
majority of users, who doesnt change defaults,
the tool would just work.

I will reiterate, I do not care what they are named, I want a default field 
where I can put my manufacturer part number, amongs others.
The specific abbreviation or name does not matter, If i care, I can manually 
add/remove my own fields *JUST AS I DO NOW*, but for the people
who use it, it will be easier across projects, for the people that dont, It 
will not matter.

Sane defaults matter. A lot actually.

- Kristoffer

On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a default 
config into kicad for things like that, as different groups will have different 
policies.

On Sun, May 20, 2018 

Re: [Kicad-developers] More default fields in schematic

[José Ignacio]

Kicad v5 has that feature, it's called the field editor.

On Sun, May 20, 2018 at 5:27 PM, Andrey Kuznetsov 
wrote:

> I agree, I had the same issue when I was doing my board, I needed a field
> for all components, and I had to manually add it for every item, there was
> no way to add this field to all components at the same time or to have it
> add by default from the addition of a new component to the sheet.
>
> Which reminds me, Cadence Designer has tools to manipulate fields on a
> large scale, whether to add, delete, show, hide, etc, this is something
> that would be nice to have in KiCAD, either that or a table of all
> components for the sheet or schematic and columns for each field, with
> ability to show/hide each cell individually.
>
> I think the ultimate goal is to make the Symbol Table more useful, but
> that'll take to long for v5 so if Kristoffer's patch allows an easy way to
> add fields to all components or similar, I'd say do it because people will
> be pissed and waste their time doing it for every component in their
> schematic.
>
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
> kristofferodmar...@gmail.com> wrote:
>
>> I obvviously disagree, the correct solution would be to have both. This
>> does not hinder that, its not even the same problem.
>>
>> The problem is for everyone who want for example the Manufacturer Part
>> Number will have to define a fieldname, which every time
>> results in them abbreviating it to something different. Hence nobody can
>> work with Manufacturer Part Numbers.
>>
>> Here is something similar, Imagine all of the colours in Kicad for all of
>> the layers where white by default. Have fun defining all the colours
>> yourself.
>> Maybe you want to define them yourself, nobody is stopping you now
>> either, just get cracking.
>>
>> How easy would it be for you to look at the board someone else made later
>> and understand what is what? Maybe for some that is a better solution, but
>> for me that
>> would be an extreme example of bad default values.
>>
>> This is how the default fields are now, they are white, or more like
>> see-throught, which makes life harder for anyone that
>> wants to contribute or create tools that interact with kicad, and as I
>> previously said, this is only a default, you are still
>> equally able to add/remove or change the fields how you want to. But,
>> tools like kibom or various other web-based tools can much
>> easier integrate to it, or at least support a default value as well. So
>> for the majority of users, who doesnt change defaults,
>> the tool would just work.
>>
>> I will reiterate, I do not care what they are named, I want a default
>> field where I can put my manufacturer part number, amongs others.
>> The specific abbreviation or name does not matter, If i care, I can
>> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
>> who use it, it will be easier across projects, for the people that dont,
>> It will not matter.
>>
>> Sane defaults matter. A lot actually.
>>
>> - Kristoffer
>>
>> On 2018-05-20 23:40, José Ignacio wrote:
>>
>>> I dont like this, the right solution would be to allow for importing a
>>> default config into kicad for things like that, as different groups will
>>> have different policies.
>>>
>>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>>> kristofferodmar...@gmail.com >
>>> wrote:
>>>
>>> The patch should only affect first startup, changes to the fields
>>> will be saved
>>>
>>> On May 20, 2018 22:18, "Seth Hillbrand" >> > wrote:
>>>
>>> ​Hi Kristoffer-
>>>
>>> This feels like a management issue rather than a tool issue.
>>> If the user doesn't want any extra fields, how would your
>>> patch allow that?
>>>
>>> -S
>>>
>>>
>>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>>> >> >:
>>>
>>>
>>> Hello!
>>>
>>> I will open this can of worms again, I feel that I have
>>> to. So from what
>>> I gather we have proffessionals as the main aim in Kicad.
>>> The reason I will open this issue again is that I feel we
>>> have a
>>> collaboration issue, maybe not a mayor one. But one
>>> nonetheless.
>>>
>>> We really need more default fields for our schematic
>>> symbols. Im not
>>> proposing required fields, I am *ONLY* proposing that
>>> there should be default fields added into the default
>>> fields settings
>>> tab. I am not proposing they need to be filled in the
>>> libraries, nor that people need to use them. only that
>>> they need to
>>> exist with a fresh install of kicad so that 

Re: [Kicad-developers] More default fields in schematic

[Jean-Paul Louis]

That discussion once again shows how people misunderstand the concept of part 
number.
In a schematic, the part number attached to a RefDes should be unique AND NOT a 
manufacturer number.
  There should be a one to one relationship between a part number (symbol) and 
a physical shape, so the PCB will be a unit manufacturable only when the BOM is 
generated, and is one to one relationship between part number and Mfg part 
number.
The BOM is only for manufacturing assembly and procurement purpose
and does not need to be part of the design database, so Manufacturing can use 
Equivalent Mfg numbers for a given part number. That’s why many companies use 
internal numbering systems that are non picture coded and just sequential.
The relationship Symbol, Shape, Supplier is the responsibility of the master 
library, not the designers.

Just my $0.02,
Jean-Paul
N1JPL


> On May 20, 2018, at 6:27 PM, Andrey Kuznetsov  wrote:
> 
> I agree, I had the same issue when I was doing my board, I needed a field for 
> all components, and I had to manually add it for every item, there was no way 
> to add this field to all components at the same time or to have it add by 
> default from the addition of a new component to the sheet.
> 
> Which reminds me, Cadence Designer has tools to manipulate fields on a large 
> scale, whether to add, delete, show, hide, etc, this is something that would 
> be nice to have in KiCAD, either that or a table of all components for the 
> sheet or schematic and columns for each field, with ability to show/hide each 
> cell individually.
> 
> I think the ultimate goal is to make the Symbol Table more useful, but 
> that'll take to long for v5 so if Kristoffer's patch allows an easy way to 
> add fields to all components or similar, I'd say do it because people will be 
> pissed and waste their time doing it for every component in their schematic.
> 
> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark 
>  wrote:
> I obvviously disagree, the correct solution would be to have both. This does 
> not hinder that, its not even the same problem.
> 
> The problem is for everyone who want for example the Manufacturer Part Number 
> will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody can work 
> with Manufacturer Part Numbers.
> 
> Here is something similar, Imagine all of the colours in Kicad for all of the 
> layers where white by default. Have fun defining all the colours yourself.
> Maybe you want to define them yourself, nobody is stopping you now either, 
> just get cracking.
> 
> How easy would it be for you to look at the board someone else made later and 
> understand what is what? Maybe for some that is a better solution, but for me 
> that
> would be an extreme example of bad default values.
> 
> This is how the default fields are now, they are white, or more like 
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as I 
> previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to. But, tools 
> like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well. So for 
> the majority of users, who doesnt change defaults,
> the tool would just work.
> 
> I will reiterate, I do not care what they are named, I want a default field 
> where I can put my manufacturer part number, amongs others.
> The specific abbreviation or name does not matter, If i care, I can manually 
> add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that dont, It 
> will not matter.
> 
> Sane defaults matter. A lot actually.
> 
> - Kristoffer
> 
> On 2018-05-20 23:40, José Ignacio wrote:
> I dont like this, the right solution would be to allow for importing a 
> default config into kicad for things like that, as different groups will have 
> different policies.
> 
> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark 
> > wrote:
> 
> The patch should only affect first startup, changes to the fields
> will be saved
> 
> On May 20, 2018 22:18, "Seth Hillbrand"  > wrote:
> 
> ​Hi Kristoffer-
> 
> This feels like a management issue rather than a tool issue. 
> If the user doesn't want any extra fields, how would your
> patch allow that?
> 
> -S
> 
> 
> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>  >:
> 
> 
> Hello!
> 
> I will open this can of worms again, I feel that I have
> to. So from what
> I gather we 

Re: [Kicad-developers] More default fields in schematic

[Andrey Kuznetsov]

I agree, I had the same issue when I was doing my board, I needed a field
for all components, and I had to manually add it for every item, there was
no way to add this field to all components at the same time or to have it
add by default from the addition of a new component to the sheet.

Which reminds me, Cadence Designer has tools to manipulate fields on a
large scale, whether to add, delete, show, hide, etc, this is something
that would be nice to have in KiCAD, either that or a table of all
components for the sheet or schematic and columns for each field, with
ability to show/hide each cell individually.

I think the ultimate goal is to make the Symbol Table more useful, but
that'll take to long for v5 so if Kristoffer's patch allows an easy way to
add fields to all components or similar, I'd say do it because people will
be pissed and waste their time doing it for every component in their
schematic.

On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> I obvviously disagree, the correct solution would be to have both. This
> does not hinder that, its not even the same problem.
>
> The problem is for everyone who want for example the Manufacturer Part
> Number will have to define a fieldname, which every time
> results in them abbreviating it to something different. Hence nobody can
> work with Manufacturer Part Numbers.
>
> Here is something similar, Imagine all of the colours in Kicad for all of
> the layers where white by default. Have fun defining all the colours
> yourself.
> Maybe you want to define them yourself, nobody is stopping you now either,
> just get cracking.
>
> How easy would it be for you to look at the board someone else made later
> and understand what is what? Maybe for some that is a better solution, but
> for me that
> would be an extreme example of bad default values.
>
> This is how the default fields are now, they are white, or more like
> see-throught, which makes life harder for anyone that
> wants to contribute or create tools that interact with kicad, and as I
> previously said, this is only a default, you are still
> equally able to add/remove or change the fields how you want to. But,
> tools like kibom or various other web-based tools can much
> easier integrate to it, or at least support a default value as well. So
> for the majority of users, who doesnt change defaults,
> the tool would just work.
>
> I will reiterate, I do not care what they are named, I want a default
> field where I can put my manufacturer part number, amongs others.
> The specific abbreviation or name does not matter, If i care, I can
> manually add/remove my own fields *JUST AS I DO NOW*, but for the people
> who use it, it will be easier across projects, for the people that dont,
> It will not matter.
>
> Sane defaults matter. A lot actually.
>
> - Kristoffer
>
> On 2018-05-20 23:40, José Ignacio wrote:
>
>> I dont like this, the right solution would be to allow for importing a
>> default config into kicad for things like that, as different groups will
>> have different policies.
>>
>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
>> kristofferodmar...@gmail.com >
>> wrote:
>>
>> The patch should only affect first startup, changes to the fields
>> will be saved
>>
>> On May 20, 2018 22:18, "Seth Hillbrand" > > wrote:
>>
>> ​Hi Kristoffer-
>>
>> This feels like a management issue rather than a tool issue.
>> If the user doesn't want any extra fields, how would your
>> patch allow that?
>>
>> -S
>>
>>
>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>> > >:
>>
>>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have
>> to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we
>> have a
>> collaboration issue, maybe not a mayor one. But one
>> nonetheless.
>>
>> We really need more default fields for our schematic
>> symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default
>> fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that
>> they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not
>> create
>> duplicate fields in libs/projects describing the same
>> thing by mistake
>>   

Re: [Kicad-developers] More default fields in schematic

[kristoffer Ödmark]

I obvviously disagree, the correct solution would be to have both. This 
does not hinder that, its not even the same problem.


The problem is for everyone who want for example the Manufacturer Part 
Number will have to define a fieldname, which every time
results in them abbreviating it to something different. Hence nobody can 
work with Manufacturer Part Numbers.


Here is something similar, Imagine all of the colours in Kicad for all 
of the layers where white by default. Have fun defining all the colours 
yourself.
Maybe you want to define them yourself, nobody is stopping you now 
either, just get cracking.


How easy would it be for you to look at the board someone else made 
later and understand what is what? Maybe for some that is a better 
solution, but for me that

would be an extreme example of bad default values.

This is how the default fields are now, they are white, or more like 
see-throught, which makes life harder for anyone that
wants to contribute or create tools that interact with kicad, and as I 
previously said, this is only a default, you are still
equally able to add/remove or change the fields how you want to. But, 
tools like kibom or various other web-based tools can much
easier integrate to it, or at least support a default value as well. So 
for the majority of users, who doesnt change defaults,

the tool would just work.

I will reiterate, I do not care what they are named, I want a default 
field where I can put my manufacturer part number, amongs others.
The specific abbreviation or name does not matter, If i care, I can 
manually add/remove my own fields *JUST AS I DO NOW*, but for the people
who use it, it will be easier across projects, for the people that dont, 
It will not matter.


Sane defaults matter. A lot actually.

- Kristoffer

On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a 
default config into kicad for things like that, as different groups 
will have different policies.


On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark 
> 
wrote:


The patch should only affect first startup, changes to the fields
will be saved

On May 20, 2018 22:18, "Seth Hillbrand" > wrote:

​Hi Kristoffer-

This feels like a management issue rather than a tool issue. 
If the user doesn't want any extra fields, how would your
patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark
>:

Hello!

I will open this can of worms again, I feel that I have
to. So from what
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we
have a
collaboration issue, maybe not a mayor one. But one
nonetheless.

We really need more default fields for our schematic
symbols. Im not
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default
fields settings
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that
they need to
exist with a fresh install of kicad so that easy problems
such as theese do not happen:

 - Collaborators working on the same project will not
create
duplicate fields in libs/projects describing the same
thing by mistake
 - Projects that aim to interact or add to Kicad can
assume that the
Fields will exist, and will know what name/tag to look for
   (bom exporters, price checkers, MacroFab, etc)
 - Open source projects will be easier to collaborate,
read and order

The reason I think it is better to have the fields by
default than the
current solution to add them is that the majority will use
what exists, and tools can support it from the very
beginning, people
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the
information about the
part there. From what I gather, this is not the majority, and
these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad"
projects, I
found that the most common addition to libs and schematics
are:
 - Manufacturers part number, these were named widely
different in
projects, (BOM, MP, 

Re: [Kicad-developers] More default fields in schematic

[José Ignacio]

I dont like this, the right solution would be to allow for importing a
default config into kicad for things like that, as different groups will
have different policies.

On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark <
kristofferodmar...@gmail.com> wrote:

> The patch should only affect first startup, changes to the fields will be
> saved
>
> On May 20, 2018 22:18, "Seth Hillbrand"  wrote:
>
> ​Hi Kristoffer-
>
> This feels like a management issue rather than a tool issue.  If the user
> doesn't want any extra fields, how would your patch allow that?
>
> -S
>
>
> Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
> kristofferodmar...@gmail.com>:
>
>> Hello!
>>
>> I will open this can of worms again, I feel that I have to. So from what
>> I gather we have proffessionals as the main aim in Kicad.
>> The reason I will open this issue again is that I feel we have a
>> collaboration issue, maybe not a mayor one. But one nonetheless.
>>
>> We really need more default fields for our schematic symbols. Im not
>> proposing required fields, I am *ONLY* proposing that
>> there should be default fields added into the default fields settings
>> tab. I am not proposing they need to be filled in the
>> libraries, nor that people need to use them. only that they need to
>> exist with a fresh install of kicad so that easy problems
>> such as theese do not happen:
>>
>>  - Collaborators working on the same project will not create
>> duplicate fields in libs/projects describing the same thing by mistake
>>  - Projects that aim to interact or add to Kicad can assume that the
>> Fields will exist, and will know what name/tag to look for
>>(bom exporters, price checkers, MacroFab, etc)
>>  - Open source projects will be easier to collaborate, read and order
>>
>> The reason I think it is better to have the fields by default than the
>> current solution to add them is that the majority will use
>> what exists, and tools can support it from the very beginning, people
>> with inhouse tools seems to dislike this, since they map their
>> parts with an inhouse number - and then handle the information about the
>> part there. From what I gather, this is not the majority, and
>> these persons still modify the default fields settings.
>>
>> I spent maybe 30-40 mins checking the "made with kicad" projects, I
>> found that the most common addition to libs and schematics are:
>>  - Manufacturers part number, these were named widely different in
>> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>>  I even saw a mix of these in the same project once, along with
>> some people having the vendor id only.
>>  - Manufacturer ( found some different languages though )
>>
>> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
>> 16V ), Vendor information and different Descriptions. They were named
>> and abbreviated
>> very differently accross projects.
>>
>> What I would like to see is these additional fields by default, but
>> hidden from the schematic unless changed by user.
>>  Tolerance ( used for setting tolerances of resistors, capacitors,
>> oscillators, etc )
>>  MaxRating ( field were one can specify max Voltage, Ampere,
>> Frequency, or whatever the component needs )
>>  Manufacturer ( For inhouse numbers, they could either just remove
>> it, or use the company/group name )
>>  MPN ( Maybe PartNumber could be used here, and people who use
>> inhouse numbers use it aswell, I dont really care what its called, as
>> long as its called something )
>>  Vendor
>>  Notes
>>
>> I would be all up for extra additions/removals, but I would prefer if
>> the naming is not discussed, but rather just decided/agreed upon by
>> someone in the lead team.
>> The very least I think should be added in case the previous is to much
>> are:
>>  Tolerance
>>  Manufacturer
>>  MPN
>>
>> I attach a patch for the minimal set, tested on linux by removing the
>> .config/kicad/eeschema file.
>>
>> - Kristoffer
>>
>>
>> ps
>> Some github files i reviewed, not all:
>> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-
>> I_SN.lib
>> https://github.com/jonpe960/blixten/blob/master/Blixten%
>> 20LED%20Device/Blixten.sch
>> https://github.com/paltatech/half-bridge/blob/master/pcb%
>> 20design/IGBT_board-cache.lib
>> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>> https://github.com/jim17/memtype/blob/master/schematic_
>> pcb/electronic_design_kicad/electronic_design_kicad.sch
>> ___
>> 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
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : 

Re: [Kicad-developers] More default fields in schematic

[Kristoffer Ödmark]

The patch should only affect first startup, changes to the fields will be
saved

On May 20, 2018 22:18, "Seth Hillbrand"  wrote:

​Hi Kristoffer-

This feels like a management issue rather than a tool issue.  If the user
doesn't want any extra fields, how would your patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:

> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
>
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
>
>  - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>  - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>(bom exporters, price checkers, MacroFab, etc)
>  - Open source projects will be easier to collaborate, read and order
>
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
>
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>  - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>  I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>  - Manufacturer ( found some different languages though )
>
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
>
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>  Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>  MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>  Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>  MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>  Vendor
>  Notes
>
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>  Tolerance
>  Manufacturer
>  MPN
>
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
>
> - Kristoffer
>
>
> ps
> Some github files i reviewed, not all:
>
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> ___
> 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
>
___
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

Re: [Kicad-developers] More default fields in schematic

[Seth Hillbrand]

​Hi Kristoffer-

This feels like a management issue rather than a tool issue.  If the user
doesn't want any extra fields, how would your patch allow that?

-S


Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:

> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
>
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
>
>  - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>  - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>(bom exporters, price checkers, MacroFab, etc)
>  - Open source projects will be easier to collaborate, read and order
>
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
>
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>  - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>  I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>  - Manufacturer ( found some different languages though )
>
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
>
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>  Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>  MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>  Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>  MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>  Vendor
>  Notes
>
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>  Tolerance
>  Manufacturer
>  MPN
>
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
>
> - Kristoffer
>
>
> ps
> Some github files i reviewed, not all:
>
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
>
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
>
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
>
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> ___
> 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
>
___
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

[Kicad-developers] More default fields in schematic

[kristoffer Ödmark]

Hello!

I will open this can of worms again, I feel that I have to. So from what 
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we have a 
collaboration issue, maybe not a mayor one. But one nonetheless.


We really need more default fields for our schematic symbols. Im not 
proposing required fields, I am *ONLY* proposing that
there should be default fields added into the default fields settings 
tab. I am not proposing they need to be filled in the
libraries, nor that people need to use them. only that they need to 
exist with a fresh install of kicad so that easy problems

such as theese do not happen:

    - Collaborators working on the same project will not create 
duplicate fields in libs/projects describing the same thing by mistake
    - Projects that aim to interact or add to Kicad can assume that the 
Fields will exist, and will know what name/tag to look for

  (bom exporters, price checkers, MacroFab, etc)
    - Open source projects will be easier to collaborate, read and order

The reason I think it is better to have the fields by default than the 
current solution to add them is that the majority will use
what exists, and tools can support it from the very beginning, people 
with inhouse tools seems to dislike this, since they map their
parts with an inhouse number - and then handle the information about the 
part there. From what I gather, this is not the majority, and

these persons still modify the default fields settings.

I spent maybe 30-40 mins checking the "made with kicad" projects, I 
found that the most common addition to libs and schematics are:
    - Manufacturers part number, these were named widely different in 
projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
        I even saw a mix of these in the same project once, along with 
some people having the vendor id only.

    - Manufacturer ( found some different languages though )

more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C, 
16V ), Vendor information and different Descriptions. They were named 
and abbreviated

very differently accross projects.

What I would like to see is these additional fields by default, but 
hidden from the schematic unless changed by user.
    Tolerance ( used for setting tolerances of resistors, capacitors, 
oscillators, etc )
    MaxRating ( field were one can specify max Voltage, Ampere, 
Frequency, or whatever the component needs )
    Manufacturer ( For inhouse numbers, they could either just remove 
it, or use the company/group name )
    MPN ( Maybe PartNumber could be used here, and people who use 
inhouse numbers use it aswell, I dont really care what its called, as 
long as its called something )

    Vendor
    Notes

I would be all up for extra additions/removals, but I would prefer if 
the naming is not discussed, but rather just decided/agreed upon by 
someone in the lead team.

The very least I think should be added in case the previous is to much are:
    Tolerance
    Manufacturer
    MPN

I attach a patch for the minimal set, tested on linux by removing the 
.config/kicad/eeschema file.


- Kristoffer


ps
Some github files i reviewed, not all:
https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
>From f0af6575bfa46e70168c1d3cfcafdf19dbc7b125 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Sun, 20 May 2018 21:59:13 +0200
Subject: [PATCH] Added minimal set of default template fields

---
 eeschema/eeschema_config.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/eeschema/eeschema_config.cpp b/eeschema/eeschema_config.cpp
index 205ab2674..53b510bac 100644
--- a/eeschema/eeschema_config.cpp
+++ b/eeschema/eeschema_config.cpp
@@ -588,7 +588,10 @@ void SCH_EDIT_FRAME::LoadSettings( wxConfigBase* aCfg )
 m_replaceStringHistoryList.Add( tmpHistory );
 }
 
-wxString templateFieldNames = aCfg->Read( FieldNamesEntry, wxEmptyString );
+// Read the template field settings, use default if no found
+const wxString defaultTemplateFieldNames =
+"(templatefields (field (name Tolerance)(value ~)) (field (name Manufacturer)(value ~)) (field (name MPN)(value ~)))";
+wxString templateFieldNames = aCfg->Read( FieldNamesEntry, defaultTemplateFieldNames );
 
 if( !templateFieldNames.IsEmpty() )
 {
-- 
2.17.0

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :