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.
Just a quick point of order, this is true for many of the parts (especially the jelly bean parts like resistors and caps that are sprinkled through most schematics) with regard to both the footprint field and the component value. Both workflows currently apply.
As for the first workflow, if making changes en masse to multiple symbols (and across the entire schematic) the edit fields table interface makes this task more efficient than selecting and editing the properties of each symbol individually.
Yes there is.
Hard coded fields into libraries are confusing when dealing with those libraries, especially if you use similar, but slightly different fields for some reason.
1 Like
There absolutely is: Itâs the part number you order from any distributor (which sometimes requires the manufacturer name to disambiguate).
Did you even read what I wrote? Donât use the field. Or, better yet, stuff it with your internal part number.
And, if the updated API allows for this to trigger an external program you could set that up to automatically cause a lookup in your database, excel file, CSV or whatever.
No, I have not. You are reading whatever you want into my very detailed posts. Not my problem if you canât understand it.
What you are saying in this quoted text is patently false on all points. Demonstrably so.
Standards improve things. A baseline standard is just that: A starting point. Use it or ignore it.
This has been addressed so many times in this thread it is just ridiculous that you are saying this. So, here it is, in big letters, one last time, in case it helps:
THIS IS ABOUT THE OUT OF THE BOX EXPERIENCE FOR THE MAJORITY OF USERS.
WITHOUT PLUGINS.
WITHOUT HAVING TO ADD FIELDS IN SCHEMATIC.
WITHOUT HAVING TO USE DATABASES.
WITHOUT HAVING TO CUSTOMIZE LIBRARIES.
WITHOUT HAVING TO WRITE CODE.
WITHOUT HAVING TO EDIT EXCEL, CSV, TEXT OR WHATEVER FILES.
EVERY SINGLE KICAD USER HAS TO SOLVE THIS PROBLEM. EVERY SINGLE ONE OF THEMâŚ
THEY ALL HAVE TO REINVENT THE WHEEL RIGHT AFTER THE INSTALL KICAD, AND CREATE A SCHEMATIC
THEY ARE PRESENTED WITH NOWHERE TO RECORD A PART NUMBER OR MANUFACTURER NAME
THEY, QUITE LITERALLY, CANNOT RECORD THIS INFORMATION AND MUCH LESS TRACK IT, GENERATE USABLE BOMS AND GENERALLY CREATE A COMPLETE DESIGN.
EVERY SINGLE KICAD USER HAS TO SOLVE THIS PROBLEM. EVERY SINGLE ONE OF THEM.
WHICH MEANS THIS IS A REAL PROBLEM.
YOU CANNOT CREATE A MANUFACTURABLE BOARD WITH KICAD OUT OF THE BOX WITHOUT SOLVING THIS PROBLEM.
AND IF YOU WANT TO CREATE PLUGINS FOR KICAD YOU HAVE NO SEMANTICALLY SENSIBLE STANDARD TO USE SUCH THAT YOUR PLUGIN WILL BE ABLE TO WORK FOR ALL USERS WITH A BASELINE OUT-OF-THE-BOX INSTALLATION.
What fields need to be added?
Iâll repeat this one more time for those who insist on creating fantasy interpretations that have no relationship to what is being said.
In big letters, once again:
1- PART NUMBER
2- MANUFACTURER
3- VALUE (it has to be disconnected from the symbol name)
4- DB LINK
NAME THESE ANTYHING SO LONG AS THEY HAVE A REASONABLE SEMANTIC CONNECTION TO THE DATA THEY HOLD
MAKE THEM EMPTY BY DEFAULT the impact in terms of the file size growth for libraries is but a rounding error. Insignificant.
ADD FUNCTIONALITY AND API ACCESS TO MAKE GIVE THESE FIELDS THE IMPORTANCE AND UTILITY THEY DESERVE
#3 is there, it just needs to be uncoupled from the symbol name so.
If thatâs the baseline out-of-the box KiCad installation it would be massively more useful than what comes out of the box today.
Raise your hand if you can actually fully document a design, generate a BOM and order the parts with KiCad out of the box without adding plugins, adding fields, writing/modifying code and manually editing excel or other files.
Yeah. Thatâs what I though.
You canât.
Thatâs the problem.
This is the solution.
If KiCad is a hobby tool and thatâs all it wants to be, none of this is relevant or important. Not one bit of it.
Well, KiCad v6 came with a Package and Content Manager (PCM). Right out of the box⌠Maybe you can use that to demonstrate your ideas. If those are widely adopted, things might change⌠This is a situation that can make a good use of that new feature.
One more time, Package and Content Manager, with the same font size.
Not the official libraries. Still same size and no bold.
And once again, if you base your opinion of KiCad, based on its libraries, a lot of things are to be questioned.
It was a nice thread, thank you!!
This answer is wrong on two sides:
- first of all you missread (again) was was said: it was not about the value of the field but on the naming on the field itself.
- then the point itself is also wrong. I can take a random manufacturer part number, go to Mouser and in one of three cases I get at least two if not more results for the same part number. why? because distributers often offer the same component in different delivery options. the claimed of the number in this context is therefore not given.
yes, but you obvously ignored everything which was said about why âdonât use a mandatory fieldâ is simply a bad idea. for example here: Semantic problem with KiCad component treatment? - #162 by paulvdh
thats just wrong. I can give you multiple examples from my own work experience as well as from international history where enforcing good meant standards just lead to confusion, problems and in the end losing more time in enforcing the standard then just doing it it in the individual way.
also: a standard nobody uses is useless.
I think you missed what I said about this as well:
and btw personal sidenote: I tend to stop take persons serious who start screeming in a discussion. I will now start to just cite my own already given answers on your arguments as long as you just keep repeating them without acknoledge the answers on them.
1 Like
Me to.
This thread also started running in circles after about 20 posts, maybe even earlier, but no sensible person will read it all or can keep it organized in their head.
@robomartin
Iâm sure you mean well but you are properly not the right person to make a concise proposal for an improvement. There is far to many people getting confused and running in circles. Writing longer explanations from your side also does not help. Donât take this as a personal attack, but just as an observance. We canât be good at everything we do or want to do.
1 Like
You canât because this requires Python API access from Schematic, which does not exist as far as I can tell. Otherwise, yes, you would be absolutely correct.
I have some ideas on how to get around this. Iâve done this in the past. It involves writing a DLL to intercept communications between letâs call it the main program and DLLs. You can, in this way, put your code in the middle of the process and effectively create an API where it did not exist.
This does not work universally. There are a number of conditions that have to exist before something like this could even be attempted. And, perhaps more importantly, it would be a horrible hack that should never leave my desk. In other words, if this can work I could make it work for us but there is no way it makes sense to release such a beast to the world. Like I said, Iâve done this a couple of times in the past with closed source applications we had to modify in some way but this is not a solution, itâs just a clever hack. And it is a ton of work.