ODB++ when will it finally be available?

[Anonymous]

Hi there,

I think it was in November 2017 when here was anounces that ODB++ extport for Eagle is on the roadmap and might be released by the end of the year 2017. Now 2 years later I am still waiting for it. Many serial manufacturers demand on ODB++ instead of Gerber.

Since I am very familar with Eagle and pleased with it in general, I've always resisted to swap to Altium - they try to catch us Eagle users all day long... But based on the demand in my business it would be very helpful to see this feature in near future.

Best Regards, Steffen

[jorge_garcia]

Hello @Anonymous,

Thanks for the follow up. This continues to be a feature that's on the wishlist however it hasn't received much priority so I don't have a timeline.

The big issue is that 99.9% of Board manufacturers can work with Gerbers, so even though ODB++ and IPC-2581 provide a much richer dataset commercial adoption has not caught on like the creators of those standards would've hoped.

It's still something we want to do, but we don't have a fixed time line for it.

Let me know if there's anything else I can do for you.

Best Regards,

[info]

Hello PCB manufacturers are increasingly asking for ODB++ files.

Even the free DesignSpark now supports it.

Please hurry up we Eagle PCB designers are facing manufacturers applying extra costs for not giving them ODB++ files. We are really starting suffering industry discrimination for this missing feature.

Regards,

--Vito.

[jorge_garcia]

Hi @info,

Thanks for bumping this thread, the more people request a certain function the more likely it is to be implemented.

Let me know if there's anything else I can do for you.

Best Regards,

[Anonymous]

I beg to differ on ODB++ now days must consider total assembly supply chain. ODB++ is used more than just for PCB domain...

Gerber is not well suited for PCB assembly NPI data set generation . Where as ODB++ and IPC standards can address this.. Other software and tools to generate other production files for assembly can leverage off the more wholistic data in the format. Not to mention DFA, DFT analysis tools out side pure fabrication use case.

Using Gerber for above means a lot of additional work and tools to get even close. Even the new gerber274x2 would not satisfy.

I believe is about time Autodesk takes plunge and elevates Eagle EDA capabilities...to include ODB++ and IPC formats. ODB++ is of course more mature of the two and first port call. Altium would be main competitors has ODB++ , Mentor, Cadence, Zuken and others....

All the main EDA tool vendors support ODB++ so if Eagle wants to move from entry level type of EDA and offer this export it would be beneficial.

Even if initially a paid option etc..

[Anonymous]

Whilst most PCB Fabricators can work with Gerber's, most CEM's prefer to use ODB++ as this cuts out any ambiguity in the programming of the assembly machines such as Pick and Place, Jet Printers and AOI. ODB provides a direct link between the CAD and manufacturing. 

[Paul.MooreQGPPG]

Cadence Sigrity and Ansys DCIR require ODB++ format to import the PCB into their analysis tools.

Please provide an Eagle export function for this format.

[jevRXJLV · Accepted solution]

Hi,

I am just another hardware engineer, who is asking for ODB++ exporting feature... it seems people keep asking and asking for the same in the past few years with no success … Majority of electronics manufacturer/assemblers nowadays do request ODB++ (UK, China, US). I bet majority of hardware engineers could backup me on this.  Unfortunately, the use of the workarounds increases risk adding errors to the project. I really hope you will push this to high priority list! 

TIA, 
Jev

[admin449WS]

Hi,

Just chiming in here as another engineer in need of an ODB++ file. A vendor is requesting it for a flying probe test. I guess I'll try a work around with DesignSpark but I felt I needed to contribute to this thread as the squeaky wheel gets the oil. 

[alexA3RDM]

Adding my name to this list. Nothing pisses off a customer like hearing they can't have the file format their CM is demanding. 

[jevRXJLV]

Fully agree! Majority of manufacturers asking for ODB++... but looks like Eagle stuck in the stone age, unfortunately. 

Dear Autodesk, please review this request! This feature is very important for us engineers!

[jevRXJLV]

Dear Jorge & Autodesk, please review this request! This feature is very important for us engineers!

[c_nicks]

I'm in the same boat now. Previous manufacturers who were fine with XY/gerber files are now requiring OBD++ format or similar for etest programming.
Gone are the days when support would just write a ulp to address these issues instead of having to dedicate core programming time.

[jorge_garcia]

Hi Everyone,

Thanks for continuing to push on this feature. The more comments in this regard, the more likely we can push this task up in the queue.
@c_nicks Implementing ODB++ in ULP would be extremely difficult to not say impossible. Once the Python API is available maybe that becomes a more realistic proposition but I think it would be a tall order for a user to take on.

It will get done, it's just a matter of time.

Best Regards,

[c_nicks]

Maybe the XML compromise version (IPC-2581) would be easier to generate with the current ULP tools.
Also requested by others.
https://forums.autodesk.com/t5/eagle-forum/ipc-2581/td-p/7336057

[duc.chunguyen]

+1 for adding ODB++ output

[gkingFV4M2]

I am one more that could use OBD output, It creates issues for me because I can't generate it and my vendors with Altium can.

[seantG9ESY]

+1 

But much as I would like to stay within Fusion it seems that to get the functionality that I need I will have to move to something else, Altium or Eagle with PADs for layout. 

[Anonymous]

This was just a deal breaker for moving our work to Fusion360. 

Everyone we work with requires ODB++ 

[Anonymous]

Jorge,

With all due respect, the "It is just a matter of time" is past wearing thin. I realize you don't make the call on what gets implemented. To that end, please make sure the product manager for Eagle and their team receive this post.

The concerning issue is that it appears those setting priorities at Autodesk don't understand the business they have entered when they bought CADSoft. Further, they do not seem to understand what their users need. They have continued to add bolt-on accessories and toys while ignoring the single item that is most rapidly eroding the utility of the tool. I don't care how pretty the 3D render is, and I don't care how elegantly I can make the PCB mount in the enclosure, and I don't care how pretty the video renders in my PowerPoint is IF I CANT GET BOARDS BUILT.

I previously worked as the Director of Prototype services at a major electronics manufacturing services (EMS) company in Huntsville, Alabama (i.e., Rocket City, USA). I can assure you we did everything in our power to ensure every board that traversed our lines had ODB++ support to validate the line setup. I personally walked away from many projects I deemed too complicated to be assembled without it. Let that sink in... As an assembly house, I was willing to walk away from work without ODB++ data. That was over 4 years ago.

This is not a board fab issue (although you are losing ground there every day). Every EMS workflow with a decent quality program will require ODB++ of the design to validate the SMT programming, stencil design/past jetting, AOI programming, work instruction generation, and on and on. If an EMS uses a factory automation system, like Aegis provides, to support their workflow, you lose all the smart/dynamic work instructions if you don't set the project up with ODB++. What does an EMS see when they lose all the benefits of those technologies they spent lots of money and time putting in place? Risk, the very thing such systems are put in place to help reduce.

Risk translates directly to money. They either jack the price way up or walk away from YOUR CUSTOMERS' projects. I'd happily still be paying for both Eagle and Fussio360 simply for this feature.

Does Autodesk want to dominate yet another CAD market? Then, show your customers Eagle brings value? How do you show value? REDUCE RISK. Why was ODB++ developed? To avoid translation errors across disparate systems from various manufacturers. That reduces risk. Boards are shrinking. Even placing silkscreen at every component is becoming a luxury. You must have reliable ECAD data for assembly.

Autodesk used to understand this. CAD drawings can be replicated, modified, transmitted, copied, and archived at great speed. Doing all those operations in CAD vs. paper reduces RISK. You can reduce the entire Autodesk business model to reducing RISK for your customers at a profit. I was willing to pay if you reduce mine as well.

And to that end, I deem you have failed. I also hung my hat on that promise of ODB++ several years ago. Thinking that Autodesk purchasing CadSoft was going to jump-start them into having a real EDA tool. Apparently, they just wanted a bolt-on ECAD tool for their mechanical solutions. It looks slick if you don't need a real ECAD tool.

I'm sure you are sick of my ranting, and I need to email the local Altium representative for a quote. I'm done holding out hope for a product that doesn't seem to understand the basic needs of customers or the industry. I don't understand a commercial product that needs people to pile on in a forum to understand what the basic functionality should be for the given industry. That's what hobbyist do, not professionals.

R,

Tom