in a question from Lucy I have outlined briefly what is IPC2581. and in some others I have described what is included.
The major difference between Gerber Based Packages and IPC2581 is that Gerber based packages are created by converting intelligent design data into a series of files through multiple steps in your PCB design tool - that make each of the file of data set useless without reassembling these unintelligenet files back into intelligent usable data. How backwards in this day and age.
IPC2581 is intelligent data and all that you need to build a board is included in one file. There is security designed in by producing only the fab data or only the assembly data or only the stencil data
Gerber is a hand off package, while IPC-2581 is an exchange format. With IPC-2581, you can exchange stack up data with your manufacturer eliminating the need to manually enter stack up data particularly if you are using any high speed signals and require target impedances on outer or innner layers.
IN addition to stack up exchange, IPC-2581 revision C also supports DFx exchange.
In summary IPC-2581 is intelligent, open, IPC standard that is bi-directional. Gerber is not.
Great question Joe
There are many fabricators that support IPC-2581. The numbers are increasing every month. One of the key question to ask a sales rep from a fabricator is what PreCAM software they use. Most of the preCAM software vendors support IPC-2581.
The consortium provides a support martix on the website - ipc2581.com - that includes manufacturers as well as software vendors that support the manufacturers.
The best way to get a manufacturer to support IPC2581 is when their customers ask them to do so. And more customers asking for support encourages them to move to support 2581 sonner.
As Hemant mentioned IPC-2581 supports bi-directional DFX exchange between designers and manufacturing or assembly. Feedback or information can be linked directly to the object of concern (via, trace, component, etc) in electronic format, eliminating the need to provide separate notes or drawings
1 Like
Being XML based IPC-2581 can interface with, or be enhanced by, other systems, like PLM or ERP. For example, you could add additional properties to part numbers from your PLM system that you want your manufacturer to see that are not in your source CAD system, yet still maintain the one file format. It also means IPC-2581 can be used as a payload to describe design data in the IPC-2591 Connected Factory Exchange (CFX) format, which is being widely adopted in the manufacturing industry. IPC-2581 is the only format built form the ground up to support these capabilities, to truly embrace Industry 4.0 and future possibilities.
So IPC-2581 is bidirectional, but Altium is not. Am I correct?
In particular, if I want to view IPC-2581 DFM suggestions from my fabricator, I would have to install and learn to use an IPC-2581 viewer such as the one from Numerical Innovations. Is that true? (No fabricator has ever mentioned that possibility to me, but that is expected from something new and shiny.)
After that, I would make notes from what the IPC-2581 viewer app shows me, revise the design in Altium, then export another IPC-2581 document, and repeat the process. Is that roughly where we stand with IPC-2581 integration?
Kevin, you are correct about the current process if the CAD tools do not support IPC-2581 DFM exchange. However, as more Altium customers realize how useful the exchange is between fab house for waivers and stackup design and the assembly house for communicating DFM, they will request the IPC-2581 DFM feature be added to the Altium process. Any CAD software vendor will only add features if they are requested by their customers. The more you and your colleagues ask for this feature, the better chance it will get added.
1 Like
Kevin
The CAD tools have to support IPC2581 and support the DFx integration, then you wont have to take manual notes, You will view DFx in the CAD tool and fix the problem and resend the design to your manufacturing partner. All of the manual work would be eliminated
1 Like
Iâm still not seeing the advantage over modern Gerber (with attributes). Is it that tools could produce a more integrated workflow, so that feedback is stored inside the design documents, instead of as notes at altium365 or something? Are there great tools to ensure that sufficient (but only necessary) information is sent to each vendor, while using gerbers requires you to decide this manually? Is it just using XML vs an annotated drawing, which might integrate better with tools from purchasing? (Or maybe Gerbers rely on the drawing to verify that connectivity matches a netlist, but IPC-2581 somehow guarantees that the drawing will be correct?)
Gerber based packages send multiple files that often have conflicting information that the fabricator has to resolve. Also, when the 2581 file is used effectively, you donât need to create fab drawings, netlists, BOMâs, stackup drawings, etc. The requirements can be in the 2581 file and this reduces time and eliminates duplicate drawing issues. A report can be created from 2581 to create any drawing format that you require.
Here is one example from my PCB front-end experience. Stackups. Some customers want the information sent/received in their specific format. The fab house has their standard format. When I used the 2581 stackup, we received their requirements in 2581 and we read it into our engineering software automatically. We then reviewed/analyzed the input, then sent back our suggested changes in 2581. Our customers would open the file in their system and view it using their format. The 2581 file can contain all of the modified versions in one file, so the original and final stackup are held together. This reduced the amount of time that my PEâs had to manually enter our suggestion into their format.
1 Like
IPC-2581 has actually fixed a couple of bugs in the old IPC-D-356 format. The most common netlist failure, other than wrong version is provided, is intentional net shorts. The designer can designate that two nets, say GND_Analog and GND_Digital, are intentionally shorted and 2581 wonât produce a read-in error. We will be discussing at IPC-APEX in a couple of months to add IPC-2581 to the IPC-9252 electrical test standard. We are proposing that a netlist is not required to sent with 2581 data because it doesnât find anything. It can just be output from 2581 for the factory to use. This check is a carry-over from the old EIA-RS-274-D format issues.
I have not used Gerber for 25+ years but back then we created our own script to generate each individual Gerber file per layer, generate the separate netlist file and any other drawing and/or text file required, and bundle everything into a package to give to our fabricators. Our fabricators in turn developed their own scripts to import our package.
When our layer naming convention expanded or changed the script had to be changed to match, and we had to communicate the change to each fabricator, so that their scripts could be kept in sync also. We imagined that the fabricators had to spend a lot of time maintaining scripts for each customer. But even with a script there were still some additional manual steps involved, which were forgotten sometimes. If there was a last minute change to the design then care and time had to be taken to re-generate all affected Gerber files, netlist, and/or supporting documents that made up the fab package. Errors were often made when versions of the different files required were not kept in sync. Have things changed since then? Is there a way avoid having to manaully sync the updated Gerber files?
The Consortium cannot coax the fabricators. They only respond to customer demand. Remember that when it comes to PCB fabricators there are multiple choices and you are the customer, who is always right. If you go to a liquor store for your favorite beer and they say âwe donât have it, byeâ but then you go to another store and they say âsorry sir we donât have it but weâll get it for youâ then which store will you go back to? It might cost the second store more at first to order your beer but it will be worth it in the end if that beer is popular because theyâll be the one with all the customers. But if the first store says âwe donât have it but we have this alternative insteadâ because its easier for them to get the alternative but itâs not quite what you wanted, yet you still say âwell OKâ then who is to blame for that?
JimJJewett, change the concept of what a drawing is for. Put all of the technical data in the 2581 file. Treat the drawing then as a report, not as a method to transfer information.
This ⌠actually helps. As a software analogy, it now sounds like 2581 is source code and Gerbers are pre-compiled binaries. Or, alternatively, that Gerbers are giving a print shop camera-ready copy, while 2581 is sending them text (or possibly a word document) and assuming theyâll format it reasonably.
If you have to make changes, you absolutely want source code. (Though Iâm not sure 2581 actually provides that, vs the internal storage and files used by Altium or KiCad. Maybe it is closer to an intermediate representation after pre-processing.)
It sounds like 2581 was written on the assumption that you would use source code version control, and keep notes and history, and so it plays well with such tools. Gerber ⌠had a lot of ad-hoc tools built around it.
If you absolutely trust the recipient, and assume there is something strange about their environment that you donât know, you would prefer to send them source code and let them recompile on their own, possibly after doing some porting.
If your trust is a bit less, you may not want to provide source code. If your faith in their good judgment is a bit less, you may want to be very specific about what youâre expecting â the equivalent a giving a print shop camera-ready copy instead of just a text file that you hope theyâll format nicely.
Does this match your understanding?
This sounds like you have a much better workflow around 2581.
Do you think it is really about the format, as opposed to the particular tool you are using?
Is use of 2581 sort of a flag to indicate âweâre using modern processesâ, as opposed to Gerbers signaling something closer to âThe box says they included instructions in English â I guess weâll find out?â
Please, all register for our webinar on Feb 20th:
Hi Jim,
IPC-2581 is like Gerber in a sense. Its purpose is just to transmit data from one system to another, or one system to equipment. The master data stays in the original CAD system. The data in an IPC-2581 file is in XML based. It is 100% human readable. When we developed it 24 years ago, we started with the Valor ODB++(XML) file. Valor was, and still is, on the committee (though they are part of Siemens now).
A couple key reasons it was developed:
- Provide all of the data required to build, assemble and test a PCB in one file. Including the manufacturer-to-designer TQ file communication (Our DfX module).
- It had to be bi-directional, not single directional like Gerber packages.
- A Gerber file requires several additional files to provide all of the information: drill files, fab print, stackup, BOM/AVL, netlist, etc. 2581 only requires one file.
- From a data security standpoint, we implemented the function mode concept, so you can select what data you want to provide, e.g., only the stencil file, stackup/impedance data.
- It had to be an international industry standard. Both Gerber and ODB++ are proprietary formats owned by German companies.
If you have any other questions. Contact me at dana.korf@korf.com or 408-643-1144. I also provide consulting services to OEMâs to improve the DFM process and to board shops to improve their front-end engineering processes.
The conversion to this format will be beneficial to you after the conversion is complete.
Regards,
Dana
1 Like