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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​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

[Kicad-developers] More default fields in schematic

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