What is actually happening in V8, at the moment and expected?
https://forum.kicad.info/t/post-v7-new-features-and-development-news/
No feature is truly official until it’s in the master branch before feature freeze. 
1 Like
@eelik, yes I completely agree. Having participated in opensource development for a long time now, I know bun fights are easily started between in-clubs and newcomers.
I really like the idea by @straubm to start a discussion around different file formats. Hopefully this should lead to feature implementation without manufacturers, as @mf_ibfeew said, needing to come and ‘demand’ ODB++.
Hopefully that can be done without anyone being called:
- moronic
- presumptious
- purposely contentious
- pushing agendas
- anecdotal
I’ll leave your club in peace and will stick to Mentor, it’s been a blast.
. I took the liberty to correct that.If you just want BARE PCB’s then GERBER literally is all you need and every board house will accept that.
Its the assembly where you will find the bigger push for ODB++ but that has been replaced with a bigger and louder push for IPC-2581 (as they don’t want to be locked into Siemens proprietary format that isn’t fully open). They want to cut cost,time and errors and these rich files are becoming a necessity.
Sure GERBER-X3 closes the gap and provides the assembly information (to compliment X2 w.r.t. stackup & test) but it doesn’t appear to be as widely accepted as ODB++ was or IPC-2581 is.
IPC-2581 is the only thing I am missing to really push Kicad replaces altium as the “rapid dev” toolsuite
1 Like
@davidsrsb For reference, here was my feedback from my experience with PCB+Assembly board houses (as a professional manufacturing commercial boards) during the switch to V6 last year.
I missed that thread.
Its a good idea to use a stable ( I hope!) exchange format rather than native KiCad V6…7…8…
I still think that adoption by the big Chinese assemblers is going to decide which that format will be
1 Like
I’d never heard of ODB++ until today, when I first started reading this thread I assumed it was something new . . . then I read the Wiki page . . . the ++ was added to “ODB” in 1997, so that’s 26 years ago.
A closed standard is never going to be universal adopted as the new defacto standard by PCB manufacturers/assemblers as it would inevitably limit their market to those who have paid up memberships to the closed standard club.
2 Likes
I appreciate the subtle sarcasm here. Reading through the thread again, it was mostly deserved. The reason for using these words was the same I already explained, and many of us have become oversensitive about certain kinds of discussion starters. You couldn’t have known them, but some of us react immediately to phrases like “I’m surprised KiCad doesn’t have this or that feature” (especially the stronger version “I was shocked to find out”) or “It just strikes me odd” etc. Our constant experience tells us that it can go downhill from there very easily.
The “vision” of the KiCad project is to compete with big boys, but it’s just a long-time abstract goal which steers many development decisions. It doesn’t mean anyone would be boasting about KiCad going there soon, and to be honest I don’t know how realistic it is, and even whether I would want that.
You said “if you wanted to compete with professional electronics CAD software” which was probably based on some information available to you, but that information needs interpretation and some background. The development just doesn’t happen so that big companies tell what are the most important features for them and those would be implemented in that order. It’s much more complicated.
As for the actual request, you don’t even have to try to justify your need because the main developers have wanted to add ODB++ and IPC-2581 for a long time. They probably know better than an average forum user (like me) how much there’s needs for those.
Many users just don’t understand this when they try KiCad and then come to tell how their need is the most important to add to KiCad because they are so sure that’s how a good EDA sw would behave, and then they explicitly insult the developers and the forum volunteers when they don’t get the response they would have liked.
To be clear, based on your posts this far, I don’t see you being one of those, but I hope this helps you understand our reactions.
3 Likes
Gerber is sort of closed as it is owned by Ucamco, but there are no fees to use it
I believe JP Carras has been closely involved with them for ages, to get KiCads Gerber exports correct
just a similar discussion I’ve found at this forum:
here a post from Thomas @pointhi
It has to be noted, that there is a plan to integrate the successor of ODB++ into KiCad (IPC-2581). Dunno how many manufacturer support this standard as well already. To my knowledge, IPC-2581 is better in the sense of having less cross-compability issues than ODB++ due to better specification.
ODB++ support: Implement ODB++ export (lp:#1573973) (#2019) · Issues · KiCad / KiCad Source Code / kicad · GitLab
IPC-2581 support: wish list IPC-2581 compliance (lp:#594013) (#1954) · Issues · KiCad / KiCad Source Code / kicad · GitLab
To my knowledge, there is no one at the moment coding an importer/exporer for those formats. If there is enough interest in adding it sooner than later, someone needs to step up and either code it itself or pay someone to do it (like KiPro). I’m sure there is interest from multiple companies to add support, so the costs can be divided up. In terms of development time, I would guess something between 1/2 - 3 Months (expert KiCad developer vs intern).
I think it is much more likely that IPC-2581 comes to KiCad than ODB++ at this point, unless a specific manufacturer or other interested party is willing to pay for the implementation of ODB++. Many of the people we’ve talked to who originally were interested in ODB++ have shifted focus to 2581. Given limited resources, it makes more sense to me to only implement the newer, more open, standard.
8 Likes
What exactly do you mean by: ‘[Manufacturers] will just ignore KiCad as an option and continue to use the toolsets that do support that functionality’
What would they do differently if KiCad where to output ODB++?
this is from ipc-2581 site, so it could be little biased (and not updated to these days)
1 Like
The question then is % of which manufacturing jobs.
Anyhow, in bare board fabrication IPC-2881 - called DPMX nowadays - is very rare, with many, if not most, fabricators not even accepting it.
I don’t think any of these advanced exports are accepted by the more popular PCB fabs yet.
A quick check on the largest manufacturers in Malaysia draws a blank
I just picked one example of a board manufacturer at random:
Eurocircuits support Gerber X, X2 plus, X3 and ODB++. IPC2581 / DPMX seems not to be on their list.
They comment on both Gerber X3 and ODB++ that they are for “customers that are willing to transfer their entire design to the manufacturer”, implying that you might not want to if you only want to have the bare boards made.
(I don’t know whether or imply that Eurocircuits is a “more popular PCB fab”, I just wrote at the end of the thread.)
I think that this may be an Asia vs West thing. The PCB houses here are mainly doing very high volume consumer boards and have low labour costs
For quick turn test or development boards at work, we normally still do Gerbers-X2 since all of the assembly is done in house. The built in Gerber viewer makes it easy to double check and the cheap/free IPC2581 viewer options are fairly limited still. (Same for ODB++ to be fair…)
Everyone accepts Gerbers even if I have to play with the labeling a little for some automated manufacturers to recognize the various layers. (All of our manufacturers for work are mainland USA, for context.)
For our larger flight boards, it makes a difference to include All The Information We Can in “one” file as provided by ODB++ or IPC2581. Even still, some manufacturing/assembly houses request Gerbers in addition for stencil making (arguably a bad idea to use a different export for stencil, but that’s what they do sometimes…)
I was curious about the IPC-2581 vs ODB++ acceptance a year or so ago. When I started asking our contractors (not a representative sample for sure) the answers I got leaned pretty heavily towards “IPC-2581? What’s that?” and eventually they learned they could ingest those files with the same software for ODB++, but no one had ever requested it. I’m still hopeful that when KiCad adds IPC-2581 export (and maybe viewer in the much longer term?) the manufacturers will figure it out quickly enough.
I have now found a few factories claiming IPC-DPMX, the “2581” seems to be relegated