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
<[email protected] <mailto:[email protected]>>
wrote:
The patch should only affect first startup, changes to the fields
will be saved
On May 20, 2018 22:18, "Seth Hillbrand" <[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>>:
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%20LED%20Device/Blixten.sch
<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/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/pluggee/KiCADLibs/blob/master/sch/cap_smd.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 : [email protected]
<mailto:[email protected]>
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 : [email protected]
<mailto:[email protected]>
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 : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
