Oscar, That can be a pain! I've come across the 'overlapping shapes' in Gerber error before, and you have to dig through log files to get your artwork completed, while in Allegro, it may be a permissible feature (Same Net shape). Andrew From: icu-pcb-forum-bounce@xxxxxxxxxxxxx [mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of O Migs Sent: Monday, July 26, 2010 10:15 PM To: icu-pcb-forum@xxxxxxxxxxxxx Subject: [PCB_FORUM] Re: ODB++ output (*.tgz) to Fab (no gerbers) On the same subject but a slightly off. In Allegro I have found a limitation with shapes. I could not generate a gerber layer that contained multiple, overlapping, or various types of shapes. The workaround was to search for errors the photoplot.log and find the xy to fix. Lot of time wasted by merging, deleting, or searching for errors.. What I'm trying to say is that I was able to extract Valor ODB++ and could not with RS274x or 6X00. -oscar -oscar On Mon, Jul 26, 2010 at 9:31 PM, Hutchins, David J <david.j.hutchins@xxxxxxxxx> wrote: Hi Randy, ODB++ handles the HDI drill structures correctly (IMHO) We have been using custom skill code for adding back-drill vias for 8+ years ( before Cadence added their limited back-drill capability ) & Valor translates those drill structures correctly... From: icu-pcb-forum-bounce@xxxxxxxxxxxxx [mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Dawson Sent: Monday, July 26, 2010 6:06 PM To: icu-pcb-forum Subject: [PCB_FORUM] Re: ODB++ output (*.tgz) to Fab (no gerbers) Hi Gary, Still in Ft. Collins? I sent ODB++ to my board shop, Prototron while I was at Micron, a few hundred PCBs. And I concur with Oscar, ODB is a good measure of the capabilities of a board shop. (and their financial strength, the V in Valor stands for Very Expensive) Related question does an ODB++ dataset have the intelligence for blind, buried and backdrilling? If we set up the padstacks for HDI technology, is ODB++ suficient or do we still need to split out separate drill files? Randy Dawson Tektronix ________________________________ Date: Mon, 26 Jul 2010 16:30:11 -0700 From: o.miguelino@xxxxxxxxx To: icu-pcb-forum@xxxxxxxxxxxxx Subject: [PCB_FORUM] Re: ODB++ output (*.tgz) to Fab (no gerbers) I have been supplying ODB++ to suppliers in Asia, Europe, and US for over a year now. Anyway I have found that quality suppliers support ODB++ and the bad ones do not. Best regards, -oscar Oscar Miguelino HP | Palm GBU | PSG 950 W Maude Ave | Sunnyvale | CA 94085 Confidentiality Notice: This e-mail and its contents contain information that is proprietary and confidential to Palm, Inc. and that may also be privileged. Any review, use, disclosure, distribution or reproduction of this email or its contents by anyone other than an authorized recipient is prohibited and may be unlawful. If you are not an authorized recipient, please immediately notify me, permanently delete this message from your system and destroy any copies thereof, including any attachments. Thank you. -- Sent from my Palm Pre ________________________________ On Jul 26, 2010 3:56 PM, jwages <jwages@xxxxxxxxx> wrote: I use both types. It is always good to have gerbers for comparison to the ODB++ files. Jim S. Wages SR PCB Layout Designer H) 919-237-3915 C) 919-484-2963 From: icu-pcb-forum-bounce@xxxxxxxxxxxxx [mailto:icu-pcb-forum-bounce@xxxxxxxxxxxxx] On Behalf Of Macindoe, Gary Sent: Monday, July 26, 2010 6:27 PM To: icu-pcb-forum@xxxxxxxxxxxxx Subject: [PCB_FORUM] ODB++ output (*.tgz) to Fab (no gerbers) Hey guys, Has anyone been supplying only the *.tgz file (instead of gerbers, drill, ipc etc.) to the Fab house? If you have, have you run into any issues (besides a Fab house unable or unwilling to use only the *.tgz file)? Thanks for any input. Regards, Gary MacIndoe Senior PCB Layout Designer Contract - Kelly Services Covidien EbD R&D 5920 Longbow Drive Boulder, CO 80301 303.476.7458 www.covidien.com ________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. <http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL :ON:WL:en-US:WM_HMP:042010_3>