First you need to solve old problems with gerber and only then introduce a new standard… Due to the lack of a cam editor, at best you will get a converter with its glitches and bugs … In general, preparing files for production is a weak point of kicad … For machine installation is usually used pick and place file where there is all the necessary information
The PCB fabs have their own cam editors, often some version of CAM350
the whole problem is that they will edit based on their production needs and not as you need … their task is to assemble and your task is to make it work … for example, when ordering boards, if there are errors, they will simply refuse you, but so you I need an editor to fix it
If you have errors in gerbers, it is better to fix your pcb and re-generate gerber files, instead of correct gerbers and keeps original pcb with errors.
8 Likes
Unfortunately the pos file isnt enough and that is because of the inconsistency of libraries.
- Centre of rotation
- Pin1 datum
This results in manual check.
GERBER-X3 provides this information so all an assembly house has todo is feed in the T&R orientation
ODB++ and IPC-2581 also do this (along with a netlist information to help with card testing)
GERBER-X3 should be enough these days
It’s a bit more complex than just the position file. Here is the fab package I zip up to send to an assembly house to fab a PCB full-turn with assembly:
- Gerbers
- Drill File
- Position File (rotations must still be double checked due to different Pick’n’Place, Packaging, etc.)
- BOM
- README PDF: Layer stackup, PCB core, copper thicknesses, plate finishes, controlled impedance callouts
- Top Fabrication View PDF: All part rotations marked, diode directions, etc.
- Bottom Fabrication View PDF: All part rotations marked, diode directions, etc.
- IPC-D-356 Netlist: Controlled Impedance, Electrical Testing, vendor CAM DRC
It is a lot to keep up with and make sure everything stays in sync, which costs engineering time (read: money). This is all contained in the IPC-2581 (or ODB++) file and does reduce errors (more money). As PCB assembly houses move to being more automated and turnkey, this leads to lower costs and less errors. Assembly houses that do not take Gerbers, but do take native Kicad, ODB++ and IPC-2581 that I am aware of:
- MacroFab
- Tempo
- CircuitHub
- Aisler (Kicad Sponsor)
I am not affiliated with any of these, other than having used them in the past, and I am sure there are more out there. This will clearly be the way the market is moving going forward, especially for commercial builds.
1 Like
It’s not about errors on the board itself, but an error in the generation itself … When, for example, you need to get a site with a certain macro on complex forms … the production files include not only the files of the board itself …
are you talking about paneling?
And about the error, including … The fact is that the gerber cannot describe all the necessary files, and therefore they come up with x2-3 formats … kicad, for example, generates a stencil file strictly according to the board in just two versions, either with or without macros for all holes and platforms and all this is sent to the manufacturer without the ability to specify where you need a complex form and where not …
if you have issues with aperture macros, you should open an issue at gh…
if the error is generated by the process in producing gerber it should be fixed there, not patched after the gerber generation imo
3 Likes
The answer was that it is very difficult. For these things, you need the editor itself … The fundamental problem is that you cannot change the gerber without changing the board, plus changing the board does not guarantee the right gerber …
Indeed, most problems in data sent to manufacturing is because of inconsistencies or incompleteness in part libraries. If the library is wrong, it makes no difference whether you sent the data in Gerber X3, ODB++, IPC-2581 or directly by telepathy.
Actually, both Gerber and ODB++ are a set of separate files, e.g. one for each copper layer, which are then compressed in a single archive, such as zip or tar. IPC-2581 is indeed a single XML file; this is a disadvantage as it is practical to be able to extract a layer easily as in a Gerber of ODB++ archive.
Actually ODB++ also contains separate files for the image layers, netlist, BOM, the PDF’s, each in their own format. This is logical, as these are different things. The only difference with Gerber is that they are all called ODB++. Calling them the same name does not really solve any problem, I suppose.IPC-2581 is indeed a single file, but each type of data has its own subtree with a dedicated schema; the main difference here is that the IPC-2581 spec is much harder to read, and it is less clear how to make a partial implementation.
Dear all,
I join this topic quite late but I would like to give some additional comments and suggestions.
I noticed, that ODB++ is a very familiar interchange format in between, although I didn’t used it so far. However, I noticed some discussion about the usage of this format. Since all! information of a board are included in the data package, a reverse engineering is quite easy to be applied. This is a concern, which may arise in certain situations. Therefore the Gerber files had some positive aspects: the PCB manufacturer got the PCB related files only, the assembly house the assembly related information (if they don’t do the PCB together). You might be able to remove the sections/subfolders in the ODB++ archive, but I don’t know if this would be save.
Since it is already planned to implement the IPC-2581 into the version 8 of KICAD, we have to wait for this update. However, since the information is here written to into only one large file, I can follow the concern, that this would be hard to handle if you only need or want a partial implementation.
So my suggestion is not to write a complete data set each time but to allow the user to select the neccessary parts at the export step, similarly to the current production file selection.
… And I hope, a viewer will be implemented too…
I would like to comment here as a semi outsider, but having worked as a CAD translator programmer in the past (mainly STEP and data that can not fit STEP files). It is generally vastly preferable to have more less complicated formats, this allows things to be implemented faster and allows for more extensibility.
Now the one file argument, you can always just zip things up. You’d be surprised just how many of the native format of applications are just damn zip files, with text in them. It is generally a very good thing, even if you cant process all of it you can process what you can process.
With a tightly integrated file format, you often end up in a situation where you cant read anything because something is slightly different. Then you and up with all kinds of bureaucratic nightmares where, at worst, standardization agency starts demanding cross checking with other tool chains to validate that your working with others. This is prohibitively expensive on long run as it:
- Becomes more expensive as time goes by.
- Undermines the specification over time as working with others becomes a hidden specification that the new comer has to pay for.
- Hard to extend. Trust me this will become an issue later.
So i would be in favor of having tool chains that can through a GUI automatically specify how to package differently named files in a zip file. Because eventually you will want something none of the formats do and then you end up with having:
- Standard file,
- rider files, that themselves are different standards named approximately.
And the circle closes again… We are back where we started from, voices start to ask for a new format.
I wonder who is responsible for the IPC-2581 implementation? And what’s the current status.
That can be seen in wish list IPC-2581 compliance (lp:#594013) (#1954) · Issues · KiCad / KiCad Source Code / kicad · GitLab. The fact that it has been assigned to somebody and there’s a milestone is better than nothing, but notice that it’s not a guarantee or promise.
(I’m not a developer but) I don’t think ODB++ is still really on the table (for v8), it is a very expensive commercial standard that KiCad probably doesn’t have the resources to buy into. IPC-2581 standard is not free, but the cost is much much lower (and hopefully IPC-DMX will edge out ODB++ in the future for that exact reason).
If you are excited about IPC-2581 support, make sure to put a thumbs up on the gitlab issue! And/Or get your employer to donate money to support that development. I keep badgering my manager about spending a little less on Altium and a little more on KiCad for a future project, but it is slow going.
2 Likes