Semantic problem with KiCad component treatment?

[dennischi]

@paulvdh

(This is also a terrible hijack and I trust it will be split off by a moderator)

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).

[paulvdh]

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.

[dennischi]

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.

[Tojan]

@robomartin

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.

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.

@robomartin

The information is not there. Anywhere.

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?

@robomartin

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.

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.

@robomartin

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 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.

[dennischi]

@Tojan

therefore a standardization to one way would be harmfull to others

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.

[SembazuruCDE]

@albin

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.

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.

[paulvdh]

@dennischi

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.

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.

[robomartin]

@Tojan

there is no standardized way to deal with manufacturer part numbers as you claim

There absolutely is: It’s the part number you order from any distributor (which sometimes requires the manufacturer name to disambiguate).

@Tojan

some track the parts not in manufacturer part numbers but in their own internal part numbers

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.

@Tojan

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.

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.

@Tojan

where is the improvement?

Standards improve things. A baseline standard is just that: A starting point. Use it or ignore it.

@Tojan

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.

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.

[Aris_Kimi]

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!!

[Tojan]

@robomartin

There absolutely is: It’s the part number you order from any distributor (which sometimes requires the manufacturer name to disambiguate).

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.

@robomartin

Did you even read what I wrote? Don’t use the field. Or, better yet, stuff it with your internal part number.

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

@robomartin

Standards improve things. A baseline standard is just that: A starting point. Use it or ignore it.

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.

@robomartin

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.

I think you missed what I said about this as well:

@Tojan

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?

@Tojan

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.

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.

[paulvdh]

@Tojan

and btw personal sidenote: I tend to stop take persons serious who start screeming in a discussion

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.

[robomartin]

@Aris_Kimi

KiCad v6 came with a Package and Content Manager (PCM). Right out of the box… Maybe you can use that to demonstrate your ideas

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.

[Aris_Kimi]

Current PCM also has some libraries to download:

EDIT: You can have your approach there so that users can make use with an out of the box experience.

Do you think of this as sufficient enough at the moment?

[robomartin]

OK, well, I do appreciate the input of those who have been constructive in this thread. I will use this to run through experiments in the coming weeks and create a well-documented request to submit.

I have been using various discussion forums for some 40 years, going back to USENET, Compuserve and private BBS’s. Something that has not changed in all of that time is that there are always people who, for one reason or another, fail to engage, fail to understand, choose to not be constructive or simply love to argue just for sport. Or worse, engage in personal attacks. Like I said, I’ve seen this for decades. These people don’t typically contribute anything aside from noise and insults. All I can say is “Live long and prosper”.

The other thing I know is that there’s a silent majority who is rarely represented in these conversations. This is true for a range of reasons. This kind of thing can be a huge time sink. Others see the kind of food fight these things can become and just don’t have a stomach for it or don’t want to have to defend themselves against the mobs that can form. And yet, without someone pushing back the mobs win.

This silent majority doesn’t necessarily agree with everything being said, of course. However, I think I can say from prior experience, they tend to be the kind of people with whom you would actually want to have constructive conversations in person. I’ve had that happen many times over the years and developed many wonderful friendships this way, locally, nationally and internationally.

I know that those who engage in critical thinking got the message dozens of posts ago. I wish there was a way to have conversations with them rather than the mob. I also know what I am proposing is important. That does not mean the KiCad team has the time to implement it (or that they will agree with me at all). If I had a non-trivial amount of money to throw at having this developed I would, in a microsecond. I can’t fund it. All I can do is explain why it is a good idea, provide support for it and see what happens. That’s what I am going to do.

[robomartin]

@Aris_Kimi

You can have your approach there so that users can make use with an out of the box experience.

Do you think of this as sufficient enough at the moment?

I don’t think so. Part of it is because it would not have the benefit of having these fields have a meaning other than to be extra fields in the libraries.

A simple example of this is how you can click on a part, type “D” and have the datasheet pop-up on a browser. That happens because there’s code in KiCad that implements this functionality.

The other issue is this problem of the value field being connected to the symbol name. I don’t understand why this is so other than to assume it was a convenience function that went too far.

I could write a Python program over the weekend that processed every single standard Python library to add three fields and a new independent value field. Put that up on Github and say “Hey, here’s a better starting point for full schematic documentation”. This would have to be supported with (I think) at least one python script to produce a decent BOM based on having those fields in every component.

As I continue experimenting with KiCad (which I absolutely love, BTW) it is becoming more and more obvious to me that this issue is important; it solves many problems. Like I have said multiple times, you simply cannot create a fully documented design with KiCad out of the box. You can’t even create a BOM from which you can order parts. That’s a problem.

Is that a good idea? It’s half a solution. Maybe it’s enough to prove the point. It could be worth giving it some thought. I am not opposed to exploring that approach at all. I’ll give it some thought.

[Tojan]

@robomartin

Something that has not changed in all of that time is that there are always people who, for one reason or another, fail to engage, fail to understand, choose to not be constructive or simply love to argue just for sport. Or worse, engage in personal attacks

I mean everything in this quote exactly reflects your doing in this discussion and on top you now ended up creating a fully meta post, claiming you are talking for the silent mayority. very fitting to the whole picture I have to say.

only for you to maybe reflect how this whole thread happened from my opinion:

• you created this topic with an idea and you activly requested feedback on it. so far so normal.
• you got feedback, some supportive, some other not so keen on your idea. also absolut normal.
• but now it got out of hand: instead of recognizing the counter-arguments you dismissed them as invalid or simply ignored them.
• instead you posted your initial arguments again, without realy adjusting them to the critics.
• so you got the same counter arguments again (no suprise) and so the loop had started…

@robomartin

Is that a good idea? It’s half a solution. Maybe it’s enough to prove the point. It could be worth giving it some thought. I am not opposed to exploring that approach at all. I’ll give it some thought.

btw, this shows exactly, that you were not interested in a discussion in the first place. you think your idea is the way to go so no open ended discussion can ever happen.

[paulvdh]

@Tojan

but now it got out of hand: instead of recognizing the counter-arguments you dismissed them as invalid or simply ignored them.

Unfortunately that is not all.
I see quite some veiled statements that could easily be interpreted as insults (he is better than the “mob” he dismisses and does not want to engage with it.)

I think I got “banned” by him for repeatedly asking for some clarification and asking for a response to my idea of the “Virtual Fields” which I later put in a different topic to keep it away from all this noise. Maybe he did give some answer that got lost in all the noise, but I’m not going to read those 170 posts again. I know I have some faults, and one of them is not being able to recognize a good idea when it’s covered by too much noise. When I was working out some details about those “Virtual Fields” I discovered it’s already implemented in KiCad. KiCad V6 is also still quite new to me.

He also writes whole paragraphs over how good he is and how much work he has done and how much experience he has. He clearly has a high opinion of himself, but that does not mean much to me. According to his statistics he has viewed 74 topics and read 743 posts in the 20 day’s he’s a member. He does put a lot of effort in it, and not only in this post, so that at least is something positive.

[paulvdh]

Am I correct in thinking that the only thing robomartin wants is to have a standardized field for “part number” added to the symbol libraries so it can be used in scripts and such?

[hermit]

I gotta ask seriously. Is this thread actually going somewhere at this point? As a rule we don’t close ongoing threads if possible but pissing contests always get ugly.

@paulvdh

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.

@paulvdh

Am I correct in thinking that the only thing robomartin wants is to have a standardized field for “part number” added to the symbol libraries so it can be used in scripts and such?

Maybe close the thread and start fresh with a narrow focus?

Personally I can’t verify what is off topic in this thread at this point.