Hi, I recently needed a way to manage information for a handful of designs for one of my customers, so started scratching out a tool/process for this.
There are other tools out there (12), but would like something that is a little more general, works with multiple CAD systems (PCB and mechanical) and usable at a slightly higher layer multi-level BOMs, product assemblies, etc.
I think Git is a generally useful tool that can be used in many workflows beyond software source code that require collaboration and review, and have been experimenting with using it in different ways. Perhaps it can be used to manage PLM data changes and review.
Neat! I’ll take a closer look when I have time. I think having an open PLM tool and workflow that is designed for Git and compatible with KiCad is great. I think using proper PLM techniques is a good idea even for tiny companies or individuals making PCBs – if your products will have any lifetime at all, using internal part numbers (HPNs as Cliff calls them) in your CAD tool instead of manufacturer part numbers is a really good idea, but to make that easy you need a tool to manage the mapping between internal part numbers and actual purchasable items (manufacturer part numbers) over time, and this is one of the important things a PLM system does.
This is very interesting! I will have a closer look too see in this can fit in my workflow. Or at least get inspiration for functions to add to my own scripts.
Any thoughts on what to call internal part numbers. I’m currently using HPN (house part number), but that might be confused with board house or assembly house. Another options is IPN (internal part number). Thoughts? What is typically used in industry?
write log file when processing BOM (see PCB-019.log). This ensures any errors are
captured in a file that is automatically generated and can be stored in Git.
“internal part number” seems OK to me as a long-form name. We just call them “part numbers” for short most of the time (i.e. “part number” is assumed to mean internal part number, if you meant the manufacturer’s, you would say MPN)
support multiple sources of parts in partmaster – simply put on separate
lines. GitPLM will select the part with lowest Priority field value. Other
fields like Description are merged – only need to be entered on one line.
See CAP-000-1001 in examples/partmaster.csv for an example of how to do
this.
if BOM includes subassemblies (ASY, or PCB IPNs), also create a purchase BOM that is a recursive aggregate of all parts used in the design. This BOM is
named CCC-NNN-VVVV-all.csv
I’m thinking of changing the PN format from CCC-NNN-VVVV to CCC-NNNN-VVVV.
Reason is this would allow for ~10,000 major part types in each category. This would give enough numbers to allow this format to scale to large organizations and be re-used across multiple organization – kind of like a UPC code for components. I don’t think the increase to 4 digits hurts readability any, and is perhaps more consistent.
This also begs the question should CCC be CCCC …
Could also allow any number of characters in each section. Then sorting becomes more complex, but that may be most flexible and best long term, and writing a smart sorter would not be that hard.
add support for checked column. This value now gets propogated from the
partmaster to all BOMs and can be used for a process where a part information
is double checked for accuracy.
