But drawings and all that require manual work, expensive and error-prone. Maybe it is unavoidable. If fabricators refuse to clean up their CAM software, they must continue to get data as it is today. It is after all their problem if it is more work.
It indeed looks we will continue with folk lore and rumors for a while.
Any chance KiCad will support ODB++?
Why bother? It is a massive amount of work, and brings nothing Gerber not already brings. That work would better be spent on the many things that are not possible now.
And IPC-2581 has more advantages over ODB++
initial IPC-2581 was targeted for v6 but got pushed back to v7 (see the bug I linked)
The problem with all this is there is an expectation that kicad supports it and then fab/assy houses to support it. So far I have seen none take IPC-2581 or GERBER-x3 (since x3 add assy info) but FAB’s happily take GERBER-x2 and assy grudgingly take GenCAN (preferring ODB++)
Sorry for the lengthy reply, but I will answer this ODB++ propaganda point by point.
ODB++
The format allows an optimized data exchange between design and manufacturing.
This is hot air.
No delays in the pre production/engineering because of a well aligned data set for printed circuit board manufacturing within ODB++.
If you align them in Gerber they are aligned too. If you don’t align them in ODB++, they aren’t. Where is the difference?
Improved quality hence there is no room for misinterpretations in the data set. Data formats like RS274X where various dialects are possible, can cause different results on different CAM systems.
Actually, the Gerber spec is more precise and unequivocal that the ODB++ spec. Try to read the ODB++ spec. There are plenty of bugs in ODB++ implementations, more than in Gerber, probably nothing to do with the formats itself, but just to do that Gerber is around longer.
The output of the layout data in ODB++ will reduce the amount of data while extensive filling of surfaces with vectors can be avoided in this format.
Nonsense. There is no need to vector fill in Gerber, KiCad does not for instance. There are plenty of painted ODB++ files. Same reason as for Gerber: Lazy CAD developers simply take an existing output and tweak it to a new format.
ODB++ is a fully expandable ASCII data format with the following advantages:
all datas are included in one file.
Nonsense. ODB++ is a fiendishly complex folder stucture. Yes, zipped in one file for transfer. So are the Gerbers. Where is the difference, except that a Gerber archive is far cleaner than an ODB++
there is a exact description of the graphical data. No unnecessary filling of copper areas or pads with special forms which have to be modified/optimized by the pcb manufacturer.
Nonsense. Answered above
to describe elements attributes may be assigned.
So does Gerber X2, and KiCad uses this extensively. Plenty of ODB++ implementations have no or very limited attributes
it is possible to forward the CAD netlist for usage in the Printed circuit board manufacturing process.
So does Gerber, and KiCad uses this. Plenty of ODB++ do not contain the netlist.
the format contains a description for the naming convention and the board built up.
So does Gerber X2, and KiCad uses this. An alternative is the Protel extensions.
ODB++ can handle in the drill and rout layers the information for plated/unplated elements as well as the depth together with the layer connection.
So does Gerber, and KiCad uses is.
notes can be attached to layers or elements like a digital usage of post it.
Gerber has custom attributes, but, admittedly, KiCad does not use this.
Hi Naib,
I am sure IPC-2581 is fine. However, is it worth the massive effort to develop it? I guess that is why adoption is so slow. After all, it is already 15 years old, and has practically zero market share.
Consider your reply above:
At present, if ODB++ isn’t used there is tonnes of setup time and a large degree of room for error during ASSEMBLY
on one hand you are recommending to remove as much manual interaction as possible but then dismissing that which has the largest setup time and error inducer in a card build
The beauty of opensource is if someone really wants it, it will be added. The downside of opensource is it will be added when someone wants to.
On the basis that more and more assembly houses are expecting ODB++, if kicad doesn’t support ODB++ or IPC-2581 the cost of using such outfits will increase as they pass the setup time onto the end-user. Now it will be easier for a CAM package that already accepts ODB++ to accept IPC-2581 for one that does accept any of these databases.
True. ODB++ was the first to include machine-readable assembly information. Mentor should be praised for that. And there are both output and input implementations. Of course, assembler prefer this over drawings and so on. Note, however, that the biggest problem is not the formats, P&P files and BOMs are not that hard to read, but the poor quality of the component libraries. No format will solve that.
But Gerber now supports components. X3. KiCad has implemented the output. As X3 uses the same syntax as X2 implementing input is straightforward, assuming your CAM software has component capability.
So should KiCad go through the massive effort to implement 2581, which nearly nobody uses today, or should CAM vendors do the modest effort to implement X2, and fabricators spend some money to buy upgrades, which they would have to do also for 2581.
KiCad provides all the information, in a simple, standardized machine readable format. Today. It is up to the fabricators and assemblers to pick up that data.
I maintain my position, 2581 may be fine, but there is a far simpler solution for the problem it solves.
The two parallel lines on the edge cut is probably an artifact of converting to dxf. In the G-Code (which is what one usually sends to the board house) it would be a single line with a width defined by an aperture size. The coordinates of that single, wide line is the centerline.
If you had looked at the corners you would have probably seen two half-circle-arcs, one for each side of the edge cut shown. If so, my suspicion is the dxf conversion represents the oval line in KiCad with the oval’s perimeter instead of a thick line with round end-caps.
I don’t remember exactly what file I used, but that is not what I remember seeing.
I have a board that I sent out for Fab before I even knew edge widths and copper pull was a thing. I measured the board with a caliper and found it to be 2.51 inches.
I can’t guarantee that I have not made changes to the board file, but I do not recall making any changes.
Certainly looks to me that the line width in KiCad V5, and earlier is generating a Gerber file that the Fab houses are interpreting as center of Edge.Cuts layer +line width (or some percentage).
Arcs are not supported for tracks with the released versions as of yet… only outlines and drawings. That was my point. And yes I do know that it’s coming.
I was only writing about edge cuts or did you mean something else with your phrasing?
Yes I think the confusion was that I was thinking that edge cuts are not true arcs but piecewise line segments. Even though the tool allows drawing “arcs” but honestly I’m not sure if that is true or not.
I have a board with 4 rounded corners.
$ grep 'gr_arc.*Edge' ttlclock.kicad_pcb
(gr_arc (start 83.82 137.16) (end 78.74 137.16) (angle -90) (layer Edge.Cuts) (width 0.05) (tstamp 5CEE65D3))
(gr_arc (start 83.82 48.26) (end 83.82 43.18) (angle -90) (layer Edge.Cuts) (width 0.05))
(gr_arc (start 167.64 137.16) (end 167.64 142.24) (angle -90) (layer Edge.Cuts) (width 0.05) (tstamp 5CEE65D6))
(gr_arc (start 167.64 48.26) (end 172.72 48.26) (angle -90) (layer Edge.Cuts) (width 0.05))
I think it means that arcs are primitives in the .kicad_pcb file for the EdgeCuts layer. I can’t work out whether the arcs are primitives in the EdgeCuts gerber file.
You’d just have to figure out if segments are being generated for that or not in the gerber file.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.