Just what the world needs, three competing standards.
I suspect that whatever China takes up will win
Why was IPC-2581 favoured for V8?
1 Like
Perhaps because ODB++ is proprietary (Valor/Mentor/Siemens).
@Rusky, the request is fair, but I want you and all other new forum members to understand why some requests meet lukewarm reception with grudges.
Every now and then someone new comes here and tells why KiCad should do this or that to be taken seriously, and that the developers don’t understand something or don’t care about user requests or don’t really know PCB design (I think these are the top three statements). Sometimes that newcomer just doesn’t want to accept or doesn’t want to try to understand the way KiCad development works even when explained. Sometimes they insist knowing better even though there are many professionals here in the forum who understand that everybody’s experience and skills are limited and that “professional” is often used as a means of elevating oneself above others or at least to categorize oneself to higher class above those whose products, workflows and processes are not to be taken seriously.
I hope you belong to the rest of us and want to take part in the KiCad development and community constructively.
6 Likes
That slide is deceptive. It’s really more “ideas for v8” rather than “things that will happen in v8”.
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