Well, all the best then. Really.
So what’s the workflow that you have in mind? Say these two (or three) fields are added to all standard libraries, but left empty. The standard libraries are write protected, so the user is left with two alternatives:
- Add the symbol to the schematic.
- Edit the symbol properties and fill in the fields.
The drawback to this is that if the same symbol is added again, the values are not filled in in that instance. The symbol can however by copied and pasted in the schematic to include the data.
OR
- Copy the symbol to a personal library.
- Fill in the fields.
- Add the symbol to the library.
Which of these two scenarios do you have in mind, or both? Just to make sure you have the same picture.
weird argumentation as the standardization of the field name is also not relevant for 90% of the users.
Its ok that you don’t understand why some want a special name for their part number field but this does not mean that they are wrong. imagine for example they use additional programs and scripts which work exactly with these defined field names and adjusting the software accordingly would be a painful or even not possible process.
you also keep ignoring the fact, that keeping this field empty (as you recommended if not used) can cause confusion in different levels of the production chain → far from ideal and time consuming.
@dennischi wrote: an example about different field-values for a multi-unit-symbol where all fields should have the same value. … This is clearly not right… The current situation arises because the software does not attach any semantic meaning to the part number added by the user.
two point from this quotation:
- “This is clearly not right” —> agree.
- but the conclusion is false. This situation is not caused by the use of user-setable fields. This is a simple bug. You can provoke this situation also with the much hyped “first class mandatory fields”. I can create the same situation with the value/footprint-fields. So there is no difference in creating this discrepancy for “first class mandatory fields” and user-setable “second class custom fields”. → this example is no argument for introducing additional mandatory fields, there are better/other arguments needed
- to help you with this bug and circumvent this issue: use the symbol properties dialog (or the symbol field table dialog) to enter the new value for mandatory (value/footprint) and custom fields. Than the string propagates to all subunits. Only the “Edit custom field” dialog allows different strings for every subunit.
- to help with fixing this bug: you could prepare a nice demonstration-schematic. With an original multi-unit-symbol with uniform custom fields. And a copy of this multi-unit-symbol (as your screenshot above) with different field-strings for every subunit. Together with a description how you created this situation. Together with a step-by-step-description uploading to gitlab - wait until fix is ready.
I have reproduced this bug, reported it on gitlab and added both a link to your post and an example project.
If you have further comments, please add them to:
I did a bit of research and made a new thread with a similar but more flexible proposal in:
And as I have also added as a header to that thread, I discovered it is already implemented in KiCad.
The only thing missing is the semantics for some of those "pre defined names in the template.
Your example is flawed because it is quite possible for U1, U2, and U3 to be units of three independent parts that just happen to be placed close together on the schematic. It is only a problem if units with the same base designator, Unnn, have different part numbers.
Oops, thank you for mentioning it. I have to fix that.
First annotation was for the same part, but a later annotation cycle changed the part numbers to U1A, U2B and U3C and I missed that.
This is not true, as Paul has discovered (see his Gitlab report at Multi part schematic symbols can have different values for each part. (#11579) · Issues · KiCad / KiCad Source Code / kicad · GitLab. KiCad correctly detects and reports inconsistencies in the value field of units of a part because it has be written with an expectation for the values in those fields.
The KiCad developers can’t implement checks and rules for fields that may or not be there, and may have any arbitrary names when they are there. They can have no expectations for the contents of such fields. They can only do tests for first class fields.
1 Like
I had no problem creating user defined fields with a blank value in my library parts. I used the Library Symbol Properties dialog (File->Symbol Properties…) in the Symbol Editor to add the two fields.
After placing a new instance of one of these library parts on a schematic I see the following in the Symbol Properties dialog (E or right-click->Properties).
I’m pretty sure the part number and part source fields can be left blank if they are added to the libraries.
They can only do tests for first class fields.
No. proof:
- take your example from above. (3x opampl with ST/TI/onsemi)
- change the manufacturer with the “symbol properies dialog” → change is set for all subunits
- change the manufacturer with the “edit custom field dialog” → change is set for only one subunit. This is a only a bug (my opinion). And the ERC should catch this inconsistancy as well as inconsistancies with the value-field. The test is simple: all subunits must contain the same value in each custom field. This is also the standard if you load a symbol from library with predefined custom fields. All equal.
I will take the example project from @paulvdh and describe this exactly (but I need time - first work, than free voluntary tasks).
You will have to be more specific about which dialogs you are using and how you opened them, because I can clearly use the Symbol Properties dialog (right click on one subunit and select Properties from the context menu) to change the values for for one unit only.
give me some time, maybe this evening. with pictures. yes, RMB->context-menu->properties works (proposes value to all subunits). directly clicking on custom-field-value doesn’t proposes value - value changed only for specific subunit. v6.0.5+v6.99. Windows10. Maybe it’s time to split these into extra-topic.
ERC also catches it if there is a mismatch in the footprint field:
I’ve also experimented a bit with a “Manufacturer” field.
ERC does not care if half the part is made by Uncle bob, and the other by Aunt Daisy.
That is the only link with the rest of this thread. Because a “Manufacturer” tag has no defined meaning, ERC can not check for it (unless you make a custom rule maybe).
In Schematic Editor / Tools / Edit Symbol Fields only the manufacturer of U1A is shown, the others are invisible.
(This is also a terrible hijack and I trust it will be split off by a moderator)
Not true. Today 100% of users do not have a place to record the actual part number you can order and the manufacturer, both of which are required in order to actually make a board.
More than 90% of users have absolutely no need for a database-driven component repository. It might even be more than 95%. This is rare because it is a lot more work than working with simple component libraries. Discussing database-driven solutions in the context of what I am proposing needs fixing simply isn’t relevant, except in the case of noting that the approach I am proposing would actually enable that 1% to 10% of users to link to a database if they need to.
KiCad, today, out of the box, requires the user to jump through hoops in order to create a BOM that contains actual part numbers you can order. If you don’t touch anything, don’t add fields, don’t install plugins, write your own, edit existing plugins or, worse, manually edit and maintain a BOM, you cannot go from a stock KiCad install to ordering parts. The information is not there. Anywhere.
At a minimum you have to add fields in Schematic. Which is a broken solution because you’ll have to do this over and over again in every single project. Yet, again, the point --which is an important one-- is that if you have to do this to every part, in every project, for every board you do, it is yelling and screaming at you that something fundamental is missing.
Several posts back I presented a simple analog low pass filter schematic and asked people to go through the exercise of implementing this super-simple design using stock KiCad (no plug ins, no added fields, no hand-created or managed BOMs) to then arrive at a design you can actually build. Anyone who attempts this task will fail. There is no way to record and manage the two most important bits of information you need in order to complete it: part number and manufacturer.
That’s a problem. A serious one at that. By establishing no baseline standard it drops everyone --including plugin writers-- on their heads to fend for themselves. This means that every KiCad project is an albatross with different and confusing decisions and no standards.
Let’s say you wanted to have a website where KiCad designs could be shared. Manufacturable designs. Designs with real BOMs and part numbers people could order. Well, the first thing you’d have to do is add part number and manufacturer fields and make that standard across all projects posted on this site. Without that it would be a royal mess.
Adding these fields --and the internal functionality to semantically support them-- will provide for a rich ecosystem where designs can be shared with ease and standardized plugins can do great things.
This isn’t about imposing or forcing anyone to use them. The “Datasheet” field is a good example of this. You don’t have to use it. Not at all. You can leave it blank. And yet, if you do, it is embedded with one special property, if you click on a part and type “D” it will open that link on a browser. That is fantastically useful. And that precisely the kind of thing I am talking about when it comes to these much-needed fields. Adding the fields to the libraries isn’t sufficient. Adding them to the schematic manually or through “Edit Field Symbols” isn’t adequate or sustainable. The right path is to have these fields carry some weight in the form of KiCad functionality that makes them more than just a text field in the library. Just like the “Datasheet” field becoming a link you can access with “D”.
What I find interesting about this discussion is that I know, without any shadow of a doubt, that everyone participating on this thread who isn’t doing hobby projects or just hacking has to deal with this issue. Nobody in that group can build a board without real part numbers you can order. In that context, it should really bother you that KiCad makes no statement about this and provides no minimum viable product to establish a baseline standard for it. Your life would be far, far simpler if they did. The tools you would have access to would be far more powerful. The baseline ecosystem, which likely includes more than 90% of the user base would be far better served.
No it’s not. It is a clear example of the things that could be done with a standard part number field added to the libraries.
I agree, there is no bug in KiCad as it is now. It can and does check the Value and Footprint fields since they are always present and have expected meanings for KiCad to check.
KiCad can’t do a similar check for a user defined part number field though because it has no idea if the field exists, what its name is, or what values are legal or illegal.
However, similar check could be implemented for standardized part number fields (in the future, as time permits) if they are added to the libraries.
KiCad should not rely on the Value field for this purpose since it should be used for the value of a circuit component. As an example, a resistor array could contain multiple units, perhaps with several different values (say an R-2R array) which should be reflected in the Value field of the units, but these units should all have the same part number fields.
Part numbers really should be first class fields in KiCad and its libraries should support that. The standard libraries should not include specific part numbers for most parts (though an argument could be made for adding them for specific single source parts that are added to the standard libraries).
1 Like
Does anyone have an idea of when parts A and B of a schematic symbol can have different values in fields? Even the Reference field is the same, the “A”, “B”, “C” suffix is added in another way.
Yes. Add a user defined field to the library part. Then you can put whatever values you want in those fields for each unit of the part. That’s the problem with user defined part numbers.
you (still) miss the point, even as multiple persons already explained it to you. the problem with your push for standardization here is not, that we all do not use manufacturing numbers. we all do. the problem is, that there is no standardized way to deal with manufacturer part numbers as you claim. some track them in a single property. some have multiple properties to track also variants (e.g. lead free, RoHS complaint, automotive, etc.). some don’t track (all) parts in the CAD design but decide in a later production phase which actual component will be used. some track the parts not in manufacturer part numbers but in their own internal part numbers and so on.
up to this point you completly failed to acknowledge that there are different ways to handle the manufacturer part number in and outside of your CAD tool and that therefore a standardization to one way (your way) would be harmfull to others.
sorry to dissappoint you, but your proposed solution would not change anything in this matter. the user still would have to add the manufacturer number either with a tool or by hand if your standard-field would be there. at least if you still hold true what you said before, that kicad should not provide the manufacturer part numbers with their libraries but only the field as empty template. instead of creating a new field with the value the user/tool would with your solution have to adjust an existing field. where is the improvement?
Thats not a KiCad problem, its a thing for literally all CAD tools out there. I worked in different institiutions with Eagle, Altium and KiCad and in every one of them the approach on which and how to track component properties in the CAD tool was (slightly) different. and the most important point thereby is: it was never a problem. because these different implementations are integrated in the other processes of these companies and everyone working with the designs knows how to deal with them. standardization is a good goal, but it always should have a purpose and should not harm the flexibility of a solution, if the flexibility is actually needed.
No the opposite case is true: it does not bother at all. because 90% of the professional users anyway don’t use standard libraries for their projects but their own, often highly modified libraries where all sorts of custom fields are tracked with their own developed standards.
4 Likes
No it wouldn’t. Those with custom fields and other solution could continue to use them as the do now. There would be no harm.
In all likelihood though, many such users would migrate to adopt the standard fields where they could, and reap the benefits of any new features and function using the standard fields.