I was asked by our pcb fab & assembly folks it would be better if we could submit ODB++ format files of our design instead of old-style Gerber.
Any idea how this could be done from KiCAD designs?
Isn’t ODB++ somebody’s proprietary protocol & thus not available for use by us general users of other tools than those who paid licens fees for ODB++?
Will appreciate any info on this matter.
Use the Forum’s “Search” feature. It may be a good time to update previous discussions, or supply new information. You ask valid questions, and I’m interested to see the responses.
Dale
2 Likes
I think the questions about ODB++ format (although not KiCad support) are at least partly answered in the wikipedia article https://en.wikipedia.org/wiki/ODB%2B%2B.
See also https://bugs.launchpad.net/kicad/+bug/594013 (and https://github.com/KiCad/kicad-source-mirror/blob/master/Documentation/development/road-map-r6.md).
OK - so support for IPC-2581 is at least in the V6 roadmap. That puts it, at best guess, at least two years away (though it might show up in nightly builds before then). It’s still an open question whether this will be a truly useful feature, or merely a bullet-point on a marketing brochure. Let’s hope other stakeholders in the EDA world see it as a useful feature.
Dale
Personally I don’t see it useful until cheap manufacturers support it. 10 years? Never? But as can be seen in the original post, some may need it (although it’s not ODB++). And when it’s needed it may be worth $$$$$$.
Apparently, our partners felt they would benefit if we provided in IPC2581 format or a n open source equivalent that can be “imported”.
They are definitely not one of the “big” players in this arena.
Question is : what do we do …stay gerber or “move forward” …
I think it was clear by now: IPC-2581 is in plans but will be realized probably only after a couple of years. Until then KiCad doesn’t export those formats.
IPC-2581 was wanted in another thread, too. Maybe @Seth_h is willing to share some information about the state of the development?
We need to circulate the draft requirements first. Strawman export seems reasonable for basic boards but there’s a lot of complexity that overlooks atm.
I’d venture 6-8 weeks after the export requirements document is approved. Import is a larger task and likely 10-12 weeks after the export is pushed. At that point, we are still just testing and it shouldn’t be used for production exports until we fully verify it for v6. We’re working with the IPC 2581 working group to certify the outputs but we also need to work through a number of test cases before I’d trust it with a full job.
2 Likes
What does import mean? Conversion to native KiCad board?
What about viewer support, in gerbview? That would be the first Open Source IPC-2581 viewer as far as I know, and even the first gratis without restrictions.
(I tried some of the viewers linked to from the website but they required giving your information, or were demo versions etc. It really didn’t leave a good taste and didn’t raise any confidence about the future of the standard. Really, guys, it’s 2019, almost everything in software market has at least some free-without-strings-attached alternatives nowadays, they don’t have even one lousy viewer. It makes me feel that they aren’t really committed. I don’t want to spread FUD and I really want this to succeed and maybe KiCad will make difference in the future, but otherwise the whole thing hasn’t been very convincing this far. Now I’ll close the parenthesis and return to my more helpful mode.)
The question is really why do we need this more complex format. Gerber is a proprietary but free to use format that has become the industry standard because it gets the job done.
Changing to something else has to have a better justification than somebody else wanting to take control.
The low cost fabs face having to receive jobs in all accepted formats and merge them onto their production panels, that gets messy very easily.
1 Like
Yes.
That is approximately the same task for KiCad. We separate the GerbView in KiCad because it represents a completely different object set of graphical primitives. IPC-2581, on the other hand is a board specification including (potentially) graphic elements, design rules, BOM, netnames, component outlines, etc. Writing a separate viewer in GerbView is twice the same task for us but a different object architecture, so duplicates the work.
Not everyone does. But it can eliminate many production headaches that come with ECOs and user error. Since it reduces engineer time at the fab house, I think you’ll see a slow migration in this direction. You might even see assembly houses offering discounts for using 2581 in the future based on the easier handling.
Certainly for low cost bare-board houses, there’s no substantial benefit over gerber, so you likely won’t see this happening at the low end for many years, if ever.
1 Like
I’m sad to hear that. But in any case low-end users will benefit indirectly if KiCad is adopted by more high-end companies because of 2581 support.
This would be truth useful if Hyperlink or other PCB simulations tool take ODB++ files. I do not know Hyperlink do it - because I have not have a hand on the license at my current company yet.
[ADDED] Example use case - https://www.ansys.com/-/media/ansys/corporate/resourcelibrary/application-brief/cadence-to-icepak.pdf
[ADDED2] The more I googling the “import ODB++”. Look like most of the commercial simulation tools taking this file format. Like the way STEP file adopted in commercial world. So it may be a very good bridge to go for powerful simulation tools.
1 Like
@nhatkhai, the first link you posted says that ANSYS also imports from IPC 2581 (and prefer that over the ODB++ format). Other vendors such as COMSOL also seem to have the IPC 2581 import, and it seems it is starting to be adopted by more companies (so I wouldn’t be surprised if HyperLynx implements it if it isn’t already).
1 Like
I think you mean IPC2581-B. So far I see ODB++ is the most importable file format. only IPC2581-B got more import support than IPC2581, but still look like less than ODB++. Also, IPC2581 may too new for Kicad to chasing with it’s change in format with limited resourced. But I can be wrong since I have never read/find a actual specification format for either types…
IPC 2581 import/export is on the roadmap for v6, they just don’t specify whether it is for A or B. Perhaps @Seth_h can clairfy that.
IPC-2581B. 2581A is deprecated. All testing resources and certification is against 2581B
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.