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!
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 firstname.lastname@example.org, 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.
Much thanks!. The issue is mainly in Gerber in side, not in ODB++ in. The issue comes from Expeditionpcb Side. Because Expeditionpcb always generated gerber data with self-intersectiong polygon, so it possibly make Valor to raster wrongly.
During past two years, I tried to contact Mentor, but no real feedback receivec. I will contact you offline.
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.
Much thanks for your explaination. We currently use 2007.7 and 2007.8. We don't seen any improvment on this from WG 2002 to EE 2007.7. I known the problem is caused by a roundoff issue inherient in Expeditionpcb plane algorithm.
Expeditionpcb GUI only support 5:5 Data format, it can't support bejond 5 decimal. The only way to output 2:6 data is that you should have modifyed the gerber
configration file manually by notepad editor. But I have to point out 6 digital decimals doesn't eliminate SIP at all( I will send you with sample 4:6 format data).
And We knonw how to set Valor configuration paramters to readin those Gerber data with SIPs and knonw how to repaire it. However, it make us have to waste much of times and it only processed interactively.
I hope you may help to touch Expedtionpcb team to solve this issue or hope Valor can fill Expeditionpcb's hole.
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.
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.
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.
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.
ODBG gateway file will include SIPs and sometime can't read by Valor Enterprise 3000. We found this symptom years ago, and dropped it, turned to ODB++. We have designed thousands PCBs and no SIP found in ODB++ except 3 design. Now I checked ODBG Gateway file in Vsure 9.0, Vsure 9.0 reported there are SIPs in the ODBG gateway file and stop reading.
Vsure or Enterprise may repairs SIPs when reading in Gerber data. But if you use metric system instead of imperial system, most of time it can't repaired successfully, sometimes it will make shorts and open, that is the danger. The problem is in both Expeditionpcb and Vsure (Enterperise) side.
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.
You are right that gerber data with ill polygons make Vsure(Enterperse) to raster wrongly becasue guessing. Indeed, Expeditionpcb generates those gerber data with ill polygons. I have logged many service requests during last two years in the supportnet and finnally I received a reply from mentor, saying they will solve it, and then Mentor acquired Valor.
I also have validate those gerber which Valor raster wrongly on other CAM tools such as CAM350, Gerbertool etc, Mostly these 3rd partied tools show good result, and some of data may crashed those tools. I have send you with a sample gerber data.
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:
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
There is an interesting section of the RS-274X spec that lists Intersection problems based on low numerical precision
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.
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.
You are correct and noted. I will convey this issue to the Expedition team.
Our SR is 2419919424ok
The issues for us are this:
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++.
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:
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.
Yes. I agree th decimal setting can't solve the SIP issue. I have clearly explained why Expeditionpcb always outgputs SIP 274X data in previous posts(searching SIP on the community). And I believe Mentor don't have any intention to re-write 274X output utility because it's risky and Mentor hope industry migrate to an intelligent format sucha as ODB++ soon.