@Anonymous wrote:
Context: in my effort to automate BOM creation, I'm trying to create a set of components in my library that have all the necessary attributes (VALUE, MANUFACTURER_PART_NUMBER, VENDOR) pre-populated. This works great, except I want to make this process less error-prone. If someone changes the value of my 2.2pF capacitor to 4pF, but forgets to actually replace the component, the BOM will mismatch the schematic. What I'd like to have, then, is the opportunity to make the value of the component immutable - that way whoever makes changes to the schematic is forced to actually change to a different technology of the component, and subsequently generate a correct BOM.
Hi Filipp,
I like your thinking on making sure everything is in place and correct for easy BOM creation.
My first thought was that the attributes in the library just need to be set to constant. This works for most attributes and prevents them being changed in the attributes dialog but when you specify a VALUE attribute in the library a) this does not appear in the attributes dialog and b) the VALUE command edits it freely.
I believe VALUE is treated as a special case attribute so doesn't appear in the attributes list and has a dedicated command to change its value but I think it should be changed so that if VALUE is specified in the library and set to constant then the VALUE command should respect that setting and refuse to update the part. I remember now why I don't have a library with pre-populated standard values and associated part numbers now. I think I went down this road many moons ago and discovered this potential consistency issue.
I don't think there is currently a nice way to solve this which doesn't involve additional work for validity checking before running your BoM output. You could change your part to also include a LIBVALUE attribute that matches the default VALUE setting when your create the library, then have a ULP which works through every part in your design and comparing VALUE with LIBVALUE and generating a list of consistency errors which you can then fix prior to generating your BoM. You could even incorporate this into the BoM generation process. You sound like you've put a lot of thought into your process so you may have written your own BoM generation ULP already so could incorporate this into there, maybe even then use other constant attributes defined in the part to automatically change the part to the correct values one from the library.
Best Regards,
Rachael
