Dwain,

Are you indicating that Expedition created an intersecting polygon using the ODB++ output interface built within the application?  This is not the Valor ODBG plugin, but the actual ODB++ interface.

If that is the case, it would be very helpful to obtain this design from you to troubleshoot from.  I have not seen this out of Expedition yet as it pertains to ODB++.  I would like to provide it as an example to the development team.

Thanks,

Max

Dwain,

I understand about the design, sometime it is not possible.  What I recommend you consider looking at is the Expedition built-in ODB++ functionality.  This is the method that Expedition users should be heavily moving to.  This interface was developed by Mentor and is currently under review by a Valor R&D person the is very familar with the format.  Any issues with ODB++ generation going forward will be dealt using this ODB++ interface.  No work is really planned to continue with the ODBG interface going forward.

If you need some assistance with the built-in ODB++ interface please ask your local Mentor support contacts.

Hopes this helps.

Regards,

Max

Dear Yanfeng,

I am trying to understand your position from a technical level.

Let's start with Expedition.  Expedition has to methods for generating ODB++.

The first method is to generate an ODBG file and passing the file through Valor's ODBG Translator to generate ODB++.  The stand alone translator is the same translator used by either the Enterprise or vSure application.  So depending on what version you have, if the version of the ODB++ Inside module is the same as your application, the translation should be exactly the same.  However, this method of transfering design databases from Expedition to Enterprise or vSure is out of date and is no longer being updated.  I would not count on this method going forward in your procedures.  Both Mentor and Valor have stopped improving this data exchange process.

The second method is to generate ODB++ directly out of Expedition. Meaning no Valor ODBG interface.  This interface is the method to use going forward.  Both Mentor and Valor are commited to make this interface right.  I know of customers that only rely on this method today for transferring designs into production using ODB++.

Next you comment that Gerber 274X out of I what I believe is Expedition is creating SIPs.  If I have that correct, later when you read the Gerber data in, vSure had to extrapolate what to do with the offending intersections in the copper pours.  In some cases those extrapolations were incorrect.  So the problem is in the original creation of the Gerber data and then later how a system tries to deal with the interpetation.  Now if I have understood your comments correctly, we need to correct the source which is the Gerber 274X data.  Interpeting data like we have is our best "guess", that is why this option is behind a configuration parameter.  If our best guess is not correct, then you need to return your setting to simply fail.  We can try to improve our code to guess better, but guessing is still guessing and no matter what you will find exceptions.

I recommend that you continue to file service request with this type of output issue.  I will take an action to contact our data exchange contact to see what his input to me is on this subject.  If I get back anything to share, I certainly will.

Right now, examples is about all we can asked for.

Thanks,

Max

I would like to also add to this discussion. We recently had a design that could have been a disaster with self intersections and the truncation issue.

The issue we see is this:

• Not all users use ODB++ as a deliverable output. (We still send gerber data - eventually we will)
• Some of our offshore vendors cant use ODB++
• With Dynamic planes values with settings such as 2:4 data formats truncates values (The tool only can do 2:5?)
• We manually tried to force 2:6 and it looked much better but was incorrectly scaled (unusable)
• Most PCB Vendors have "workarounds" via valor/genesis settings but some DONT or they are not permitted to modify the data in any way.
• If we transition product to a vendor or the cam user doesnot have the correct settings then bad product can be produced.

For our case we were forced into using ODB++ to be able to produce the design.

We would like to see a method where there is NO self intersections and/or possiblity to use a data format that prevents it.

Q. Is there any way to prevent trunctation on gerber output and/or have a ratio that is correct without scale issues like 2:6?

Numerous shorts in planes

Chris,

I appreciate the details you provided in your description.  The void you are not seeing, I believe, is a display issue within vSure.  This display issue has been identified and corrected in the upcoming release of vSure 9.1.  The behavior only occurs in rather unique cases.    You can test this theory by determining if the netlist passes.  If the netlist does pass, then the missing void is a display issue.  Regardless, I would be more than happy to verify the condition if you would like to provide the test case.  You can also open a service request and our customer service team would be more than happy to verify.

What you found in the RS-274X documentation is correct.  Using a low numerical precision will cause rounding issues in most applications resulting in intersecting polygons. What you are finding with the use of Gerber 274X is one of the reasons Mentor Graphics promotes the use of ODB++ as the best-practice method for transferring a product from the design-domain to the manufacturing-domain. Traditional CAM data is a set of fragmented files that are then reverse-engineered into an integrated manufacturing-oriented product-model.  That process provides no direct value and introduces more potential for misunderstandings and risk.  By using ODB++ the time-wasting process of re-integrating all that information into a single manufacturing-model of the product and the associated risk are eliminated.

Regards,

Max Clark

max_clark@mentor.com

You are correct and noted.  I will convey this issue to the Expedition team.

Thanks,

Max

Chris,

I do not believe 2:6 format to be the correct solution to your problem.

When I look at your screenshot of the voids around the vias, my assumption is that the image came directly from the vendor, correct? Now, unless you deliberately removed the scallops from between the lower group of three vias during design time (using plane sketches for example), I don't believe the planes would surround the vias in that manner.

I suspect that your vendor is in fact, modifying the data you are supplying. The vendor may not know it of course. With CAM tools such as Genesis and many others, there is a Gerber import option that allows for the interpretation of Self Intersecting Polygons (SIPs).

The options, if I recall, would be to:

1. Allow SIPs as-is (i.e. reproduce them exactly as they appear in the Gerber file.
   
2. Reject them (and therefore fail to import the Gerber file altogether).
   
3. "fix" the SIPs. In other words make assumptions and actually change the data. You can see this with the lower group of vias.
   

I'm pretty sure your vendor is using option number 3 above. This goes back to the comment made earlier in this thread in that there is a certain amount of interpretation regarding the Gerber 274X format. Even though Gerber is very simplistic, the specification is not entirely without ambiguity. This is a fundamental problem with the 274X format.

Although I completely agree with Max's suggestion that ODB++ is the way to go long term, I think you have another option: Tell your vendor NOT to "fix" the SIPs. With the option set as it is, your vendor is most assuredly modifying your data. There is absolutely no need to do this.

Regards,

Ian Gabbitas