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.
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
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
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:
>>
>>
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
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
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
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
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
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
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
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
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
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;
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
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
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
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.
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
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
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
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
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
> 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
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
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
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.
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
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
>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!
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
53 matches
Mail list logo