ODB++ Export with BoM

ODB++ is 'board' (e.g. PCB) data. The BOM is assembly data. Never even considered putting the BOM in the ODB++ data, and don't see the need for it. When I supply my assemblers data, I provide them the ODB++ (unless they're cheap and want the gerbers), the solderpaste files, an assembly drawing, and the BOM (eXcel format). Why are you wanting it in the ODB++ file? Your fab vendor wouldn't need it.

we want to feed our assembly maschines with the odb++ data and to be able to then see the part number of the placed part for example. Another idea is to import another BoM to the odb++ to assemble antoher variant for example.

Usually no one is willing to rev board artwork every time a value was changed..    A software engineer working on the standard thought it would be a great idea.  It really isn't.

Engineers would jump on the opportunity to sneak in copper tweaks to bypass our exhaustive/expensive review process on a "BOM Rev" and cause someone from regulatory to start screaming.  (explosions off in the distance, then you hear sirens.  It's actually a big problem.) 

 And, someone in purchasing will scrap an inventory of boards and reorder them because of the artwork rev.   

With obselecence, availability causing MPN substitution at the last minute, the risk of actually assembling to BOM data directly from embedded ODB or IPC data is just too great. 

This is why Downstream's Blueprint is so awesome.   Anyone can import a new CSV or SQL data and easily update assembly documentation.

Plus - and you can mark my words - if you give an assembler the ODB++ with the BOM incorporated, AND you supply them a BOM file (e.g. eXcel BOM, or Agile generated) they will disregard the BOM in the ODB++ and solely use the electronic BOM.

Much like if you give a PCB supplier the ODB++ and also the fabrication drawing. The supplier will ALWAYS look at discrepancies between the 2 and ask which is correct.

"We want to feed our assembly machines with the odb++ data" -  someone places A LOT of faith in their assembly equipment. I've never heard of this being done, FOR THE BOM.

The BOM data structures in ODB++ were added when Valor developed their Trilogy 5000 tool suite, which had the ability of reading BOM data with AVL component information

Their EDA interfaces for Cadence & Mentor were never updated to import BOM data, since none of the CAD tools support the AVL component information directly IMHO