kicad-developers team mailing list archive

[Marcos Chaparro <nitrousnrg@xxxxxxxxx>]

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 <
kristofferodmark90@xxxxxxxxx> 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 <kandrey89@xxxxxxxxx>
>>> 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 <
>>> kristofferodmark90@xxxxxxxxx> 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 <
>>> kristofferodmark90@xxxxxxxxx <mailto:kristofferodmark90@xxxxxxxxx>>
>>> wrote:
>>>
>>>      The patch should only affect first startup, changes to the fields
>>>      will be saved
>>>
>>>      On May 20, 2018 22:18, "Seth Hillbrand" <seth.hillbrand@xxxxxxxxx
>>>      <mailto:seth.hillbrand@xxxxxxxxx>> 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
>>>          <kristofferodmark90@xxxxxxxxx
>>>          <mailto:kristofferodmark90@xxxxxxxxx>>:
>>>
>>>
>>>              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/AnaviTechnology/anavi-gardening/blob/
>>> master/MCP3002-I_SN.lib>
>>>              https://github.com/jonpe960/blixten/blob/master/Blixten%20L
>>> ED%20Device/Blixten.sch
>>>              <https://github.com/jonpe960/blixten/blob/master/Blixten%20
>>> LED%20Device/Blixten.sch>
>>>              https://github.com/paltatech/half-bridge/blob/master/pcb%20
>>> design/IGBT_board-cache.lib
>>>              <https://github.com/paltatech/half-bridge/blob/
>>> master/pcb%20design/IGBT_board-cache.lib>
>>>              https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_sm
>>> d.lib
>>>              <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_s
>>> md.lib>
>>>              https://github.com/jim17/memtype/blob/master/schematic_pcb/
>>> electronic_design_kicad/electronic_design_kicad.sch
>>>              <https://github.com/jim17/memtype/blob/master/schematic_pcb
>>> /electronic_design_kicad/electronic_design_kicad.sch>
>>>              _______________________________________________
>>>              Mailing list: https://launchpad.net/~kicad-developers
>>>              <https://launchpad.net/%7Ekicad-developers>
>>>              Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>              <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>              Unsubscribe : https://launchpad.net/~kicad-developers
>>>              <https://launchpad.net/%7Ekicad-developers>
>>>              More help   : https://help.launchpad.net/ListHelp
>>>              <https://help.launchpad.net/ListHelp>
>>>
>>>
>>>
>>>      _______________________________________________
>>>      Mailing list: https://launchpad.net/~kicad-developers
>>>      <https://launchpad.net/%7Ekicad-developers>
>>>      Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>      <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>      Unsubscribe : https://launchpad.net/~kicad-developers
>>>      <https://launchpad.net/%7Ekicad-developers>
>>>      More help   : https://help.launchpad.net/ListHelp
>>>      <https://help.launchpad.net/ListHelp>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> --
>>> Remember The Past, Live The Present, Change The Future
>>> Those who look only to the past or the present are certain to miss the
>>> future [JFK]
>>>
>>> kandrey89@xxxxxxxxx
>>> Live Long and Prosper,
>>> Andrey
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>