Page 1 of 1

OrCAD Gerber format

Posted: Mon Apr 04, 2005 3:07 pm
by *claus*
Hi

I haven't used SFE PCB service yet but I'm planning to.
On the site I see that Gerber format RS274X is supported but my version of OrCAD (version 9.1) seems to produce RS-274D or Extended Gerber. Now what would you prefer?

Also, I have a rather long list of possible output files. I would expect the needed files to be:
Top and bottom layers, Top and bottom soldermask, Top and bottom silkscreen and last the drill drawing layer.
There are also top and bottom solder paste layers. Are they needed?

/claus

Posted: Tue Apr 05, 2005 5:09 am
by Steve
Hi Claus,

I can answer your question, though I don't work at SFE. I have a lot of experience with PCB ordering, but someone from SFE might have slightly different advice for you.

Extended gerber format IS RS274X. (X = Extended)

Required files are:-

Drill file
Top and bottom copper
Top and bottom solder mask
Top and bottom silkscreen (if required)
Border outline layer

Solder paste files are not needed unless you are ordering a paste mask. Paste masks are used for screening solder paste on to surface mount pads for mounting components using a pick and place machine.

The drill file should probably be in basic Excellon format, which is a text file that looks like this (it's also based on RS274):-

M48
INCH,TZ
T01C0.020
T02C0.040
%
T01
X1000Y1000
X1500
...
T02
X2000Y4000
...
M30


Steve.

Posted: Tue Apr 05, 2005 10:11 am
by *claus*
Great Steve!

Only problem now (besides finding the time to make the layout) is, that I can't find a border outline layer. I can, however, make a "border outline" obstacle on one of the copper layers. Will that do? If yes, is one enough or must there be one on both sides?

The drill file (.tap) from an old project looks like this:

%
T2C0.071F200S100
X-035700Y-005100
X-035600Y-011100
X-034900Y-012700
... I remove some lines
X-009700Y-007800
X-006030Y-012570
X-001600Y-003700
T1C0.059F200S100
X-037700Y-005500
X-037700Y-004500
X-036700Y-009600
... I remove some lines
X-001900Y-008600
X-001600Y-006600
X-001600Y-005600
M30

Is this right?

/claus

Posted: Wed Apr 06, 2005 3:54 am
by Steve
Only problem now (besides finding the time to make the layout) is, that I can't find a border outline layer. I can, however, make a "border outline" obstacle on one of the copper layers. Will that do? If yes, is one enough or must there be one on both sides?
One outline is enough. If you don't have a special layer available, then it doesn't really matter which one it's on. Actually, top silkscreen is probably a better choice. Whoever processes your files will have to copy the outline pattern onto their own border layer. This isn't difficult, but easier if it's not necessary. :)

As for the drill file...
%
T2C0.071F200S100
X-035700Y-005100
X-035600Y-011100
X-034900Y-012700
... I remove some lines
M30

Is this right?
It's semi right. It doesn't really conform to Excellon drill file format, yet most required information is there. Software that reads Excellon files might not (probably won't) read it properly. So it will probably require human text editing to make it right. I just tried your file in the shareware version of CAM350, which is a professional CAM package for manufacturers, and it failed to import it.

I was about to start explaining Excellon format so you can edit the file yourself, but instead I'll write a program to do the conversion. Leave me your email address in a private message, and I'll send it to you.

I'll also post an explanation of Excellon format, if anyone is interested.

Steve.

Posted: Wed Apr 06, 2005 6:13 am
by Steve
OK Claus, the little conversion program is done if you want it (or anyone else wants it). It's pretty simple, but will work for any file in exactly the format you pasted.

On a somewhat philosophical note, I want to whine about PCB CAD programmers. In the sample you pasted, tool definition lines like this:-
T2C0.071F200S100
Appeared in the 'part program body' (after the %) instead of in the header where they belong. Note that the tool definition includes the parameters F200 and S100. These are feed rate and spindle speed values.

Whine #1

Why would a PCB CAD programmer put such manufacturer specific detail into a drill file? Choice of feeds and speeds is entirely in the manufacturer's domain, and depends on the machinery they have, and probably also on the brand of drill bits they buy. Why would anyone writing a PCB CAD program even think they had any idea what such values should be?

Whine #2

If CAD programmers know Excellon format well enough to put such detail into a drill file, why can't they export the file in the proper format?


The reason I'm whinging, is that I work in a PCB factory and I deal with weird formats that customers sometimes send in. I've been absolutely stunned at times by the errors and rubbish output by some packages.

I guess the main problem is that the PCB Manufacturer is not the CAD vendor's customer. We can either fix problems or lose some customers. The CAD vendors don't care. As an example, there's been a small but annoying problem with Protel gerber files since they're first windows version. I reported the problem to them in 1996 yet the same bug has been in every version of Protel since then. 2.7, 2.8, 3.0. 3.1, 98, 99SE, DXP... Same old bugs, and we keep fixing the files. ;)

End of whinging...

Steve.

Posted: Thu Apr 07, 2005 10:17 pm
by MGP
Hey Steve - just out of curiosity, what is the problem with Protel gerber files?

I've been using Protel for years and done 100's of PCBs and never had a complaint from a PCB vendor or had any trouble viewing the gerber files in several different commercial gerber viewers.

I don't doubt you at all but I'm curious nonetheless.

And I agree about the CAD vendors not giving a rat's rear end about problems. There are still simple and easy to fix problems with Protel2004 that have been around (and reported) since the Protel Advanced PCB days. Same with Orcad and others. It seems to me they are more interested in adding bullet points to their sales brochures than they are making bulletproof tools.

:x

Posted: Fri Apr 08, 2005 4:16 am
by Steve
Hey Steve - just out of curiosity, what is the problem with Protel gerber files?
Hi MGP,

I'm not an Electronics designer. My only experience with Protel is to use it to output gerber/excellon files for manufacturing. I can't comment on what Protel is like as a designer's package.

However, I can answer your question from a manufacturer's point of view. I hope I can remember all the bugs ;) I haven't used DXP much, so maybe they've finally fixed some of these.

First of all, two Excellon file problems. An Excellon file has a header section starting with M48, and a body section which starts after a %. For a long time Protel exported drill files with a unit code, M71 or M72 *before* the M48 (start of header).

It's probably technically incorrect to have anything *before* the M48, but perhaps the real problem is that they used the *wrong* unit code. If you exported your file in INCH mode it would start with M71 (Metric), and if you exported as METRIC it would start with M72 (Inch). They actually fixed the unit problem a few years ago, but I think they still put a unit code before the M48. An excellon file has INCH or METRIC in the header anyway, so the other M code for units is redundant even if it's correct.

The second Excellon problem is in their tool definitions. Like orcad, protel also puts drill feeds and speeds in the tool definition, though at least they put the tool definition in the header where it's supposed to be.
However, their feed and speed rates are set to 0, so there's no point even having them there (and it's stupid to have them there in any case). Also, since they put the feed and speed before the tool diameter, CAM350, at least, can't correctly read the tool definition. Actually, I blame CAM350 for that one...

Example of typical (older Protel version) excellon header,

M71 <- incorrect unit and probably incorrect M code placement
M48
INCH,LZ
T01F00S00C0.039 <- useless F and S codes before tool diameter
...
%

I've written programs to automatically fix these, so they're not really a problem for us. But you can see why I slap my forehead at CAD package programmers ;)

OK, now on to Gerber problems.

#1 Octagons
Protel incorrectly defines octagons in their RS274X gerbers. In RS274X, an octagon aperture definition includes a rotation code. It's actually an 8 sided regular polygon with the first point on the positive X axis. So for an octagon to have a flat bottom (which is how they look inside protel) a rotation of 22.5 degrees must be specified. Protel exports them with a rotation of 0. They should look like this:-

%ADD10P,0.1X8X22.5*% ; Aperture definition, Dcode 10, Polygon, size 0.1, 8 sides, 22.5 rotation.

Also (from memory, not 100% sure) Protel gets the size of the octagon wrong. In RS274X files the size is the outside diameter, that is, the distance between opposite points. Protel outputs the size as the distance across the flats.

#2 Aperture size.
Older versions of Protel allowed you to set the maximum aperture size, which is not a bad idea since some photoplotters have a limit on aperture size, typically 1 or 2 inches. If the size of your pad in protel exceeded the maximum configured aperture size, protel would attempt to create the shape by 'drawing' instead of 'flashing'. In the case of octagons, at least, it would get the shape and size wrong.

#3 number of dcodes/'flash' fills.
Gerber imposed a limit on the maximum number of apertures allowed in a gerber file. The dcodes should only range from D10 to D999. Everyone ignores the limit these days, I think, including Protel. BUT, if Protel generates a gerber file with more than 990 apertures, the apertures D1000 and above have incorrect definitions. They all come out as 0 sized circles, or something like that.

The only time I've seen this happen is when 'flashes' are used to create fills. Protel must have an option to make fills out of myriads of rectangles of various sizes. Apparently this overflows an internal dcode table.

#4 The small circle shorting problem. Fills part 2
Fills in protel files are often made up of lots of thin tracks, side by side. The boundaries of these areas often have tracks around them, on the edges. It's difficult to describe, unfortunately. Perhaps you'll know what I mean.

These fill border tracks also have arcs that surround parts of fills around round pads. Sometimes this results in very short arcs of perhaps only .0005". In such a case, if you output your gerber files in 2.3 format (with a resolution of .001") the result is an arc with the start and end points rounded to the same position. In gerber format, an arc that starts and ends in the same position is a complete circle.

Thus we sometimes see films plotted that have tens or hundreds of little circles shorting out tracks and planes. It's not really incorrect gerber data, so it imports perfectly into a CAM program. The place to detect and correct it is during gerber output when the rounding happens.

#5 Fills part 3
This is not a Protel bug, just something for your information. Some protel files we get have fills made of very fine tracks spaced very close together. Perhaps .0005" tracks at .0005" spacing, and some have horizontal as well as vertical tracks, even though either would be enough to fill the space. This creates nice smoothly defined fills, however it eats enormous amounts of memory. The biggest gerber file I've seen is over 20MB. With fast computers and almost free memory these days, it's not a huge issue, but it still slows things down significantly. Protel files with such fills are also huge, of course.

Gerber format actually includes command for filled irregular polygons which would take up much less space. They can't be complex (crossing lines) but they CAN have arcs in the boundary.

#6
For information only, later versions of Protel don't properly import Autotrax files. Advanced PCB 2.8 is the only version I'd use. The problem is in multilayer files. Inner layer pad connections get screwed up.

#7
Another autotrax issue. If you're an autotrax user, avoid using strings of a size that is not a multiple of 12, otherwise they might appear on your board at a different size than what appears on your screen, and such text on copper layers can even cause shorts.

#8
Also not a gerber output problem. I don't know about DXP, but in protel 99se you're inviting disaster if you use cut/paste to combine two designs into one. Even using 'paste special' you might find that 99se merges nets in the two different designs, and I've seen it silently redraw fills on one of the designs such that they randomly cross components and tracks.

#9 Protel deletes 'redundant' holes while exporting excellon files. (That is, to ensure that there is only one hole at any location). It would be nice if they also checked for overlapping or very close holes, since these cause broken drills and if spotted will most likely result in the order being held while referring the problem back to the customer.

That's all I can think of for now. This is basically a list of problems some of which, at least, are most likely quietly fixed by your PCB Manufacturer without you even knowing about them.

Feel free to send this list to Altium ;)

Steve.

Posted: Fri Apr 08, 2005 4:25 am
by Steve
hehe MGP :)

That was probably a longer answer than you were after...

The small but annoying problem I originally referred to was the octagon rotation/size problem.

Steve.

Posted: Fri Apr 08, 2005 4:59 am
by Steve
And just one more thing, MGP :)
It seems to me they are more interested in adding bullet points to their sales brochures than they are making bulletproof tools.
Do you think making bulletproof tools would increase their market share? It seems obvious to me that it would, yet many seem to take the glossy brochure path. What are your thoughts?

Steve.

Posted: Sat Apr 09, 2005 6:10 am
by Steve
I've been reading an Excellon manual. Here's the online version:-

http://www.excellon.com/applicationengi ... rogram.htm

I've decided to ease up on Orcad for not having a 'part program' header section. I still think they should have one, but the Excellon manual doesn't actually require it. In fact, the format is fairly loose in many respects.

The format is intended for controlling drilling machines, not really for transferring drill information around, so I guess I should go easy on Excellon too ;)

So, orcad's drill file format is technically legal, but far from ideal.

My opinion of their having feed and speed rates in tool definitions hasn't changed. It's a pointless thing to do.

Steve.

Posted: Wed Jun 08, 2005 11:24 am
by Tre
Can I get the program you wrote to convert from Orcad 10 drillfiles (drd) and tap files into the Excellon file format? I sent you a private message so you can email it or if you just want to post it here, either would be great.

Thanks again