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 <kandre...@gmail.com> >>> 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 <mailto: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" <seth.hillbr...@gmail.com >>> <mailto:seth.hillbr...@gmail.com>> 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 >>> <mailto: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/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@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> 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@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> 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@lists.launchpad.net >>> 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] >>> >>> kandre...@gmail.com >>> Live Long and Prosper, >>> Andrey >>> _______________________________________________ >>> 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