No, sorry @Joan_Sparky, I admit this could be clearer but this is simply about agreeing on standard fields in the symbols when they are part of schematics. I can’t edit the original post since I put a poll in it but I’ll put up an amended proposal in a few weeks and change the wording then. And yes nothing will be hardcoded, these are merely suggestions for people to follow.
@mse, that looks like a great application but please keep this thread on topic.
@kuro68k thanks, the integer it’s referring to is only the integer after the field name e.g. MPN1 and SKU1 so definitely should not be able to be negative. I think it’s better to start this at 1 as well.
@walter yes quoting is also an option, it’s really a matter of if people prefer the added complexity to get the compactness first of all.
Thanks @mse, but this proposal is to have clearly defined fields so all tool builders know where to look for them and populate them. VALUE1 and VALUE2 doesn’t really define anything so it wouldn’t help in that regard. I can see how it would work with your application but not with others.
I read this in the opposite way so it would be nice for @devbisme to clarify.
I am finding the community overall quite negative on everything. The frustrating part is picking out the constructive criticism from the overall un-constructive negativity.
This is what I am talking about. Please try and be a bit more constructive. I have in the meantime retrieved a list of vendors in JSON format and am in dialogue with Octopart to retrieve a full list of manufacturers. My current thinking is to put everything in a git repo along with the document and put it up on GitHub and give people commit access to it if they have an interest in maintaining it.
Additionally I have mentioned on the developer mailing list that it would be good to put the document and links to the lists up on kicad.org.
You are free to do that with or without this proposal being put in place and tool builders should do that anyway. Your statement is completely orthogonal to the current proposal and totally un-constructive. It’s the equivelent of saying: “we should just give up”. If that’s your attitude please feel free to not take part in the discussion at all because it is just discouraging.
I agree, this forum can be rather alienating at times. But in this case I think the negativity is well placed. Especially as the proposal currently stands.
I disagree, the statement suggests an alternative that would not only be more flexible but would render the current proposal redundant.
I see, let’s filter out all the negativity so that it looks like all the feedback is positive.
It is hard to be constructive about the current proposal. How many months have you been trying to push this idea? And you weren’t the first.
EDIT: Just re-read this, I had initiall read it wrong, but “filter out”, huh? I was merely trying to understand how @devbisme felt about the proposal because I actually make use of his KiField and KiCost tools.
Sorry, I don’t understand, your alternative proposal seems to be let’s do nothing and hope people make their tools more flexible?
I have been in constant dialogue with people throughout the process and amended goals accordingly.
Please tell me, what’s wrong with the proposal that isn’t already being addressed through the polls I put up? Give me some constructive amendments if you are unhappy with it, but don’t tell me: “nah just scrap the whole idea, it’s rubbish”.
I am trying to push this so that we can make tools that make everyone more productive with their CAD work and spend less time on boring things such as populating MPN and SKU fields.
I hope you don’t consider the poll binding. It’s important to consider user input, but following it outright can lead to very messy, incoherent design.
Yes, that makes sense @c4757p. But regarding the separator issue I am coming round following discussions here and on the dev mailing list. Regarding the abbreviations, I really don’t care and am happy to follow the poll on that.
@kasbah, my apologies for my ambiguous comment. I’ll try to be clearer while I wait for my pork chops to cook.
You’ve stumbled into the prototypical bike shed topic: easy to understand and easy to have an opinion about.
I’m not too concerned about standardized names any more. I have a list of acceptable names in KiCost and I can just add whatever is decided upon.
Regarding the combined manufacturer:part number format, I’m not crazy about lumping both things into the same field, but I could adapt to that if it became the way things were done. As to the colon separator problem, maybe a backslash could be used to escape any colons that are in manufacturer names or part numbers.
In regards to full field names or abbreviations, I would tend toward shorter field names because KiCad users may have to manually create those fields for some of their parts. No use making it hard for them.
I think I would have just been happy to use and promote the KiCost defaults in the past if it wasn’t for the lack of a definition of how to define multiple manf# fields per schematic symbol. Are you open to letting KiCost be adapted to allow this use case with the field name schema we will put in this document?
I have gone off the : seperator idea unless someone else makes a strong supporting case for it.
What’s your plan for handling multiple part information in the spreadsheet? I’m open to anything as long as it doesn’t make things more complicated for the basic user who only has a single part number/manufacturer for each part.
The spreadsheet needs to be able to adapt to the possibility of additional headings though. Is this what you were asking? Would that break anything for you?
My question is even more basic: if I have multiple part numbers for a part, how does my costing spreadsheet figure out the total price of all the parts?
KiCost doesn’t currently keep any vendor names or SKUs on the left-hand portion of the sheet. The vendors are handled on the right-hand side with a set of columns for each vendor (Digikey, Mouser, etc.) showing ordering codes, pricing, availability. One advantage of KiCost is you don’t have to handle the vendor codes because it figures that out for you using the manufacturer’s number.
If KiCost only handles the first available part it finds at a particular vendor, then you might have cases where one manufacturer’s part would be ordered from Digikey, but another manufacturer’s part might be ordered from Mouser. The same issue arises if you do cost optimization.
Is that really a problem though? Doesn’t it make sense to not add multiple MPNs if you care about the exact part that needs to be ordered? By putting on multiple MPNs you are effectively saying “these are equivalent in this context”.
EDIT: Just a thought, we could even standardise on calling the first MPN field just MPN and the second one MPN2 etc. I guess this would be more backwards compatible with existing tools actually!?
I’m just thinking it would be a surprise to the designer, especially if they ordered parts from both vendors and they were different (even if functionally the same).
Yes, if MPN is used for the first choice, then KiCost doesn’t need any modifications.
I was merely trying to understand how 