Let's talk ECAD MCAD Collaboration (EMN/EMP, IDF, IDX, etc...) - Holes!!!

[jwagh]

We work in a dual ECAD environment - PADs and Xpedition.

We are trying to move to the IDX standard, but we keep on hitting road blocks, especially with holes.

For those that use these formats, how do you collaborate with holes?

Some issues:

• Current Hole feature doesn't include any copper ring that we would want to be shown on the ECAD side when we send it over.
• Current BOARD Hole feature doesn't allow for ref des' to be placed
• PADS doesn't support BOARD holes, only holes in a 'part'. They also don't support MTG hole type. Which means every MTG hole is coming in as a PIN type. However, PIN types are not collaborated upon in Creo for IDX, because they should be coming from the components.

How are you handling holes with collaboration? 

[tbraxton]

I have had to deal with similar issues in the past. I would suggest to first establish what level of IDF support your ECAD design tools have. They must fully support IDF 2.0+ for the IDF format to be of much use. I have seen some lower end ECAD tools that only have a partial implementation of the IDF format. If they do not fully support the IDF format then it is a lot more work and you may want to explore using STEP files instead. My experience is with Cadence Allegro, Mentor Board Station, and Altium so not directly relevant to your tools.

 IDF specs for reference:

IDF standards documents 

Holes have always been an issue with IDF and the 3.0 spec which Creo supports has improved hole support. Look at the the Creo documentation (config options and the like for ECAD) and establish how the holes need to be handled in the ECAD tool and during export. Configuration and data exchange filters for import/export of IDF files may resolve some of your issues.

I have found that many ECAD designers are not knowledgeable about IDF and therefore create data in the ECAD tool in a way that does not support the use of IDF. This is very common especially with hole and shape definitions that should be part of the board. Start by reviewing section 3.10 of the IDF 3.0 specification which defines how drilled holes are handled. This is the only type of hole type supported for the IDF board file. So if you have mounting holes in the ECAD layout they need to be exported as drilled holes or "other_outlines" if they are non circular cut outs. You can open the IDF export file in a text editor to see if the ECAD tool is compliant with this or not.

The IDF files are text files and can be easily manipulated by scripting tools such a PERL. I developed and used scripting tools to deal with similar issues with the IDF files. Preprocessing them with scripts before importing to Pro/E. The main issue with holes back then was with hole type via coming across in the board file into Pro/E which needed a filter to avoid 800 holes in the PCB import. That issue was dealt with in IDF 3.0 spec. Scripting is very specific to your workflow so you need to establish that first and make sure it is adopted or if it is even needed.

In summary I would say you need to understand/define the capability on the ECAD and MCAD side and define a workflow and configuration management scheme before anything else for data exchange. Once you have that write the standards and deploy them to all users.

For specific issues you are best served by posting examples of the files with the problems here to get relevant feedback.

[jwagh]

Thank you so much for your response!

To answer some of your questions:

1. We are working off of IDF 3.0, but we want to upgrade to IDX standard. So the processes we fine-tune for the IDF should also work with IDX.
2. I've read through the IDF 3.0 spec for years and have configured out hole features to be plated, mounting, etc... However, that doesn't resolve the issues above.
3. Yes, we do export our mounting holes as drill holes. The issue is that Mentor PADs doesn't support drill holes. They only have holes as part of a 'part' (as far as I understand). Therefore each hole needs a part, especially if it has an annular ring (which makes sense). This is why I'm hoping someone who is fluent with the ins-and-outs of PADs collaboration will help as well. I did open a few tickets with mentor about this, but it seems like their support doesn't know much either.

Do you have additional 'parts' for holes that are mapped via the ecad_hint.map file? What ECAD tool does your team use? I'd prefer not to have the MEs do extra work, like adding additional ghost parts to the assembly and having them manually linking the REF DES of these ghost parts to the ECAD_ASSOCIATED_PART parameter for the hole feature. It seems like too much work to make the process 'easier'.

Thanks!

[tbraxton]

I have no experience with the IDX interface in practice, so I can not help there. I have no experience with PADS either. If PADS supports the other_outline section of IDF you may be able to exploit that. If PADS can export the hole data (X,Y, dia) to a text file you could use scripting to add the holes to an IDF file in an automated fashion. I would think that you could leverage the drill file out of PADS for that. You can also use the IDF regions constructs to get geometry across.

Using IDF all drilled holes and other cuts in the PCB substrate were covered by drilled_holes or other_outline constructs. We created library parts for things like test pads or ground pads that were important to manage with the interface. This was due to traces/conductors not being supported in IDF 3.0. Not ghost parts but it did require creating MCAD models mapped to the ECAD library.

As mentioned above I have used IDF 3.0 with Cadence Allegro, Mentor Boardstation, and Altium. All of these tools fully support IDF 3.0 AFAIK. The most sophisticated deployment used Allegro and Boardstation with Pro/E. This required libraries for both ECAD and MCAD models of parts, a single hint map file to map all parts (thousands) in the library and full time librarians for parts to be added to the libraries within 2 business days of the request for a new part. The standards were deployed on mirrored servers across the globe so all teams were always using the correct data sets. We also had Windchill for configuration management duties. It took 5+ years and millions of dollars to get it working globally. If you have a small team in one place obviously it is easier to deal with.

[jwagh]

Thanks for the response. So when you write "We created library parts for things like test pads or ground pads that were important to manage with the interface. ", you had a hole in the board and then another separate part with the pad put on the assembly? Was this a manual process of something fancy with UDFs, Family tables, and/or mapkeys?

Thanks! 

[tbraxton]

Library parts were created for both the 2D ECAD symbol and the 3D geometry for the MCAD. No holes were involved unless a hole was required for the part to be placed on the PCB in reality. Some pads and the like were often gold plated substrates that were reflowed on the PCB so they were actually placed parts. Test points were typically hard gold plate on the PCB but we used parts placed on the board to represent them so that they could be exchanged using the IDF files.

We did create many parametric models for standard JEDEC packages (BGA, QFP, etc.) that enabled fast creation of packages on the MCAD side. We did not ever use family tables for part variants in the library. We would modify and save the master model as a stand alone part.

These Pro/E models were also leveraged for simulation (thermal , vibe/shock, and electromagnetic) where different geometry reps were needed depending on mesh requirements in the simulation environment.

[jwagh]

Thanks again!

You write "No holes were involved unless a hole was required for the part to be placed on the PCB in reality."

So for pcb mounting holes, you had a hole feature in the pcb part and a separate part in the assembly for proper collaboration? How did you manage mounting holes?

Thanks!

[tbraxton]

I think you mentioned earlier that your ECAD tool did not support the hole type for IDF export. If that is true then you will have to find some workaround.

This is what was implemented once IDF 3.0 was supported in MCAD and ECAD tools. All of our tools had full support for IDF interface.

In summary the mounting holes were created in the Pro/E model of the PCB  under the paradigm described below. 

Using the IDF standard 3.0 there is a provision to define holes (mounting) in either the ECAD or MCAD system and assign ownership to either MCAD or ECAD tool. A decision was made in the project to have some holes defined by the mechanical team and those would be created in Pro/E and then exported with the PCB outline via IDF to the ECAD design team. Any holes not included in this IDF import from Pro/E belonged to the ECAD team and were designated as such.

The ME team always owned the PCB outline, geometry and holes that impacted the interface of the PCB to other mechanical parts. Physical interface components placement was typically owned by the ME team. If there was a connector that had holes associated with it then those holes would be created in Pro/E and the location of the part also defined in Pro/E using the MCAD library component for the connector. The Pro/E PCB model would also be used to define place regions, keep outs etc. these would also come across to the ECAD tool via IDF.

[jwagh]

Yes, our process is practically the same. The only difference is that PADs doesn't support board level mounting holes. Mounting holes would need to be created as a 'part'. Which means, if we want to automate and collaborate, it would 'appear to me' that we would need to add assembly components that represent holes along with the holes in the pcb part as well. This would allow for the ecad_hint.map file to map them properly on the ecad side. Of course, then you need to match the hole feature REF DES to the part, and this becomes a lot of work for something that should be simple.