Skip navigation
216,995 Views 19 Replies Last post: Aug 3, 2011 7:15 PM by yu.yanfeng RSS
yu.yanfeng EDA JEDI 1,206 posts since
Jul 23, 2008
Currently Being Moderated

Jun 9, 2010 7:07 AM

A Nightware on Vsure 9.0 Validating Expeditionpcb Design

Vsure 9.0 is released. Although I found this version isn't so stable and buggy, but I still hope it can smoothly process Expeditionpcb's output. Unfortunatly, things always go to bad. Now Vsure 9.0 will report all Expeditionpcb designs having many problemtic surfaces and self-intersection polygons.

 

This make me to think another mergering story. Tens years ago, Mentor acquired Examplar, a leading systhesis company, soon Examplar losted leading in technology.

I hope this story not happened to Valor.

 

What a nighware!

 

 

Yanfeng

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jun 9, 2010 10:17 AM in response to: yu.yanfeng
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

Dear Yanfeng,

 

Let me introduce myself.  My name is Max Clark and I am the Product Marketing Manager for the vSure product line.  Prior to being with Mentor, I was with Valor for 17 years and have been part of this product since the original creation.

 

For this community entry I see that you are experiencing issue with ODB++ that I would really like to assist you on.  The good news is that we had a vSure beta process that lasted about 9 month long with a customer that created ODB++ out of Expedition and feed this into vSure prior to the version release.  I do understand that you are experiencing issues, but there must be an explanation that I can hopefully assist in solving.

 

In addition, internally Mentor and prior Valor contacts are reviewing the entire ODB++ generation process out of Expedition to ensure that it is best-in-class.  As you can imagine this will take some time to complete, but once finished the output from Expedition will definitely be as clean and correct as possible.  This is an advantage Mentor customers will have.

 

My email contact is max_clark@mentor.com, if I can be of further assistance please just let me know.  As vSure has just been released after a lengthy beta process I would also be interested in your comments related to the stability of version.  Our internal and beta customer experience seems quite different than what you appear to be experiencing.

 

Please let me assist you further.

 

Sincerely,

Max Clark

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jun 9, 2010 4:59 PM in response to: yu.yanfeng
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

Dear Yanfeng,

 

I look forward to trying to assist you offline, but have two suggestions to share with the community.

 

Prior to Mentor acquiring Valor, they were aware of this issue.  I am not certain of what version of Expedition you are currently running, but I believe Mentor did some work in order to eliminate this as an issue.  The most common problem was not creating the Gerber 274X data at a resolution large enough to capture the representation of a polygon accurately.  If you are not forcing the numbering format to be at least 2.6, then I would not be surprised if there are intersecting polygons.  Please double check the resolution you are creating the Gerber files in.

 

While intersecting polygons are illegal and the behavior of Enterprise and vSure is to reject these files, there is a solution built into the application enabling these files to be read in.  Within the system configuration is a parameter iol_274x_ill_polygon.  If this is set to yes then the system will read into the application with these errors.  Next within the Graphic Station there is a surface analyzer that will locate the offending intersections.  You should be able to correct them using the surface editing tool.

 

The above described behavior has been within Enterprise and vSure for many years now.  There should have been no changes in the behavior been version 8 or version 9.  If you believe something otherwise has happen, we definitely need to look into it.

 

If the issue deals with the creation of Gerber 274X out of Expedition, after you contact me, we will together get you to an Expedition contact that can help.

 

Regards,

Max Clark

strangd Aficionado 125 posts since
Feb 9, 2009
Currently Being Moderated
Jun 10, 2010 10:41 AM in response to: yu.yanfeng
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

Hi Guys:

 

We are using 2007.8 update 5 and just yesterday I received a self-intersecting polygon error when reading a ODB++ file into a third party software package.  Fortunately, that software will automatically fix the polygon.

 

Dwain

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jun 10, 2010 11:31 AM in response to: strangd
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

strangd Aficionado 125 posts since
Feb 9, 2009
Currently Being Moderated
Jun 10, 2010 11:47 AM in response to: max_clark
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

The source to the gateway file came from Expediton.  It was my understanding that there is Valor software that translates the data generated from Expedition into a ODB++ database.

 

I am not sure that our space designs can be sent with getting a lot of paperwork signed.

 

Sorry

Dwain

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jun 10, 2010 1:59 PM in response to: strangd
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jun 10, 2010 4:16 PM in response to: yu.yanfeng
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

chris.smith Active 59 posts since
Aug 25, 2008
Currently Being Moderated
Jul 29, 2011 12:20 PM in response to: yu.yanfeng
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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?

 

defectplane1.png

Numerous shorts in planes

defectplane2.png

chris.smith Active 59 posts since
Aug 25, 2008
Currently Being Moderated
Jul 29, 2011 2:13 PM in response to: chris.smith
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

http://www.ucamco.com/public/RS-274X_Extended_Gerber_Format_Specification_201012.pdf  (page 51)

 

There is an interesting section of the RS-274X spec that lists Intersection problems based on low numerical precision

 

planedefect4.png

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Jul 29, 2011 4:48 PM in response to: chris.smith
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

artsiom.shchatsko Aficionado 155 posts since
Sep 4, 2008
Currently Being Moderated
Aug 2, 2011 7:26 AM in response to: max_clark
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

We're all for ODB++ but the reality is that many PCB manufacturers still require Gerbers.

So there is no excuse for a major PCB design tool for producing corrupt Gerber data.

max_clark Aficionado 114 posts since
May 26, 2010
Currently Being Moderated
Aug 2, 2011 5:17 PM in response to: artsiom.shchatsko
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

 

Thanks,

Max

chris.smith Active 59 posts since
Aug 25, 2008
Currently Being Moderated
Aug 3, 2011 9:05 AM in response to: max_clark
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

Max,

 

Our SR is 2419919424ok

 

The issues for us are this:

 

  1. We can not migrate overnight to ODB++ and some of our vendors can not use it yet.
  2. The technical issue is "truncation" is it possible to use 2:6 out of mentor expedition? (other tools support 2:6)
  3. We tried 2:6 manually by editing the GMF (gerber machine format) and the vendor reported it solved the problems but scaling was incorrect and the file was "unusable"

 

We would like to use ODB++ as our vendors support it but, gerber exports from expedition should offer the ability of higher values like 2:6 (accurately)

so there is less of a chance of an production failure because someone did not "modify" Genesis or Valor.

 

I would hope that expedition can fully support the latest version of the RS274-X Spec and provide the highest accuracy possible.

vs. generically saying just use ODB++.

ian_gabbitas Contributor 10 posts since
Dec 30, 2008
Currently Being Moderated
Aug 3, 2011 6:37 PM in response to: chris.smith
Re: A Nightware on Vsure 9.0 Validating Expeditionpcb Design

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

 

More Like This

  • Retrieving data ...

Bookmarked By (0)