Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add extra supported fields #2

Open
kevinb456 opened this issue Mar 5, 2016 · 3 comments
Open

Add extra supported fields #2

kevinb456 opened this issue Mar 5, 2016 · 3 comments

Comments

@kevinb456
Copy link

Suggestions for fields to add, some more/less important than others;

  • 'Value' - its common for BOMs to have the value (e.g. 10k for a resistor) in a separate field.
  • 'Supplier' & 'Supplier Part' - at our company we just have one 'supplier' field which may say e.g. Farnell, then the 'Supplier Part' contains the Farnell code.
  • 'Fit Part' / 'Part Fitted' / 'DNF' - a bit more complex as theres probably no one standard but again at work we have a separate field in our BOM to denote whether the part is fitted. If blank it is, if marked 'DNF' then Do Not Fit. Another convention is just 'NF' or No Fit, similarly my last company used 'OC' or 'O/C' for Open Circuit. People may also put this in the Value field instead of having a separate field. Until recently our company used '1k; DNF' for a not-fitted 1k resistor.
  • 'Manufacturer' - sometimes you want a specific manufacturer for a part e.g. the 1N4148 diode is made by lots & lots of manufacturers, but the one by NXP may be the one tested to work.
@kasbah
Copy link
Member

kasbah commented Apr 21, 2016

The format kind of grew out of the minimum necessary to add components to retailer carts (but with references on the line notes).

It's all a bit of a trade-off between catching as much of convention as possible but not over stretching ourselves. To address each one individually:

  • 'Value' would currently go in a description field. It could just be an additional description field for search.
  • 'Supplier' & 'Supplier Part' is actually quite close to the legacy format which is still supported but being phased out. Since version 0.6 a warning pops up if you input data in the legacy format with a request to contact the project if you use that format. So far there hasn't been anyone.
  • 'DNF', I think needs a bit of thought. The question is why are you putting the part into 1-click-BOM if you don't want it on your project? If we parse a DNF should we simply ignore those lines?
  • 'Manufacturer' field is sort of supported now as well. It was it's own column originally but is currently parsed and added in front of the part number. This was done to allow multiple manufacturers and manufacturer part numbers per line like in this Arduino Uno BOM. Recently I have been considering the convention to separate the manufacturer and manufacturer part with a : like so:
References Qty Description Part Number
SW1 1 Switch TE Connectivity: 4-1437565-1

Let me know your thoughts.

@kevinb456
Copy link
Author

I agree its best not to over-stretch, and the conventions for industry may not be the best ones to follow (even though I prefer them) if this is primarily for hobbyists who dont do the same thing. My thoughts;

  • Having the value field separate is ubiquitous in industry, so it looks unusual to me, though nothing inherently wrong with it. The main disadvantage I see that all design programs and component libraries I know of have it separate (such as Kicad's Value field) so the natural export will also have it separate - requiring an extra merge step for people to fit into your format. But then if theres an exporter you've written which can merge then this is mitigated. I also think its better practice to have the BOM fields match the component fields in the design. But as I said nothing inherently wrong, its a design decision to take.
  • I retract! On second thoughts it makes more sense in this application to have separate supplier fields the way it is. The exporter could always have a feature added to try auto-export to the correct field based on a "supplier" field in the design libraries if so desired.
  • I think support of DNF is an important feature so I would recommend finding some way to include. DNF components are very common in designs to allow development / configuration options without having to change the PCB. I've worked on very few designs (cant think of any right now!) which have zero DNF parts. Looking at my latest one at work 14% of them are DNF! (possibly unusually high however due to how its evolved). You _could _choose not to export DNF parts to the .tsv BOM but then it doesnt have a 1-1 match with components in the design which would be a red flag to me. You're right this needs thought, there is no one convention. Usually its some string such as "DNF" "OC" or "NF" in the description/value fields, or a separate "Part Fitted" field which is then true/false.
  • I like the look of this, it gets my vote! If you have people manually generating the .tsv I can see people missing the ':' but possibly they'll just have to lump it. To mitigate we can make as automated as possible.

@kasbah
Copy link
Member

kasbah commented Apr 30, 2016

Another interesting idea is to add a designator for "generic" like 0603/0805 resistors and capacitors, 0.1" pin headers and the like. The allow for a function to "order without generics".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants