Polygon in Protel 99SE
Faizal Rezi
I place a polygon on top layer as GND net. When I print preview, the polygon
has some circle on some pad.
Anyone has experience on this?
Best regards,
Faizal Rezi
Adam Seychell
Faizal Rezi wrote:
>
> Dear,
>
> I place a polygon on top layer as GND net. When I print preview, the polygon
> has some circle on some pad.
> Anyone has experience on this?
Not long ago there was a discussion in this group on Polygons in RS-274X
Gerber files. It appears there has been much confusion in the standard
and as a result many produces of CAD software have implemented different
ways. Protel will replace octagonal polygons with equivalent sized
rounded pad if rotation angle is not 0 degrees. I believe how the Gerber
RS-274X standard defined the polygon is to blame for this. Lets hope
future versions will be corrected. For now don't use octagonal polygons.
AbdulraHman Lomax
>I place a polygon on top layer as GND net. When I print preview, the polygon
>has some circle on some pad.
>Anyone has experience on this?
When a polygon pour is created or edited, there is a series of options
regarding hatching, that is, the filling of the polygon with track. If
one selects no hatching, and there is a pad not connected to the
polygon net inside the polygon, one will see a circle around the pad.
This is the edge of the polygon around that pad. If you double-click
on the polygon and set one of the hatch options, and then allow the
polygon to re-pour, you will see the filled polygon. In Final display
mode, you will not see the circle except as an opening around the pad.
A hint about polygon pours in Protel: if you want a solid polygon with
maximum pour efficiency (i.e., number of tracks necessary to
accomplish the pour), set the pour grid-size to zero. A zero grid does
*not* create an infinite loop; rather, Protel, when the grid is zero,
ignores the grid and pours the tracks with no gap; i.e., a 10 mil
track will be poured with a 10 mil grid. You may see some apparent
gaps on screen, but if you zoom in on them and they don't appear to be
any larger, they are display artifacts, not real gaps. They will not
appear on the gerber plots. Also, don't make the pour track size any
smaller than necessary. You can always make it smaller if you find
unwanted gaps in the pour. I also set the minimum track length to 1
mil.
Abd ulRahman Lomax
Printed Circuit Consulting since 1975, Training, Protel license resales.
www.lomaxdesign.com
Stephen Adam
"Adam Seychell" <ASey...@vet.com.au> wrote in message
news:3AE368EA...@vet.com.au...
I think Faisal meant a different sort of polygon. As for RS274X, the
standard for the polygon aperture shape is clear, but I had to read it a
few times before I got it. :)) It states that the first point will be on
the
positive X axis (ie: Y = 0). Therefore, to generate an octagon with a
flat bottom it must be rotated 22.5 degrees. Every windows version
of Protel (which I have seen) has got this wrong. They always generate
8 sided polygon aperture definitions with a 0 rotation. I don't know
what kind of service Protel gives designers, but they *never* seem
to fix bugs reported by manufacturers. Last time we reported some
problems they suggested that we buy Borland Delphi and use it to
write our own Gerber/Excellon output routines under the EDA.
Just as a side note to all of you designers out there using Protel.
Please try to avoid using very narrow tracks in those polygon pours.
Sometimes *huge* gerber files are generated with 100,000 objects
or more. This can make CAM processing *very* slow.
Geoff Harland
> I think Faisal meant a different sort of polygon. As for RS274X, the
> standard for the polygon aperture shape is clear, but I had to read it a
> few times before I got it. :)) It states that the first point will be on
> the
> positive X axis (ie: Y = 0). Therefore, to generate an octagon with a
> flat bottom it must be rotated 22.5 degrees. Every windows version
> of Protel (which I have seen) has got this wrong. They always generate
> 8 sided polygon aperture definitions with a 0 rotation. I don't know
> what kind of service Protel gives designers, but they *never* seem
> to fix bugs reported by manufacturers. Last time we reported some
> problems they suggested that we buy Borland Delphi and use it to
> write our own Gerber/Excellon output routines under the EDA.
> Stephen Adam
If someone in Protel really did say that, then that suggests that Protel are
now at least aware that there is a problem with the Gerber files produced by
their application, and as such, a succeeding SP or major version release
might even rectify this problem.
As someone who uses Protel to design PCBs, I have created (and now use) an
addon Server incorporating a process which "zeros" the rotational angle of
all pads (or at least all those pads whose rotational angle is an integral
multiple of 90 degrees; pads having a rotational angle of 90 degrees or 270
degrees also have their X-Size and Y-Size values transposed, so the width
and height of such pads are not changed as a consequence of this "zeroing"
procedure), and that deals with one currently problematic aspect of
octagonal pads, in which such pads are flashed with a circular aperture
(instead of with an octagonal aperture) unless their rotational angle is
zero degrees. And to rectify the embedded aperture definitions for octagonal
flashes, I use a Perl script (on the Gerber files) which changes the
rotational angle for each octagonal aperture definition from zero degrees to
22.5 degrees; this same script also scales (upwards) the diameter of each
such aperture definition by a factor of the secant of 22.5 degrees.
While it is not out of the question that Delphi could be used to create
customised processes which implement customised output routines, I strongly
suspect that no small amount of work would be required to actually achieve
this. As such, it is not something that I would attempt to undertake myself.
(OTOH, the addon server and Perl script just described were developed in a
relatively small amount of time.)
--
Regards,
Geoff Harland.
(Remove the non-kosher/non-halal food for correspondence.)
ghar...@pork-ingenico.com.au
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.
Stephen Adam
> > Last time we reported some
> > problems they suggested that we buy Borland Delphi and use it to
> > write our own Gerber/Excellon output routines under the EDA.
> If someone in Protel really did say that,
It was said, but not directly to me. In fairness to Protel,
it was probably a response to a question about how we can
ensure that the Gerber/Excellon files are suitable for our CAM
procedures. (ie: Not a response to a bug report).
>then that suggests that Protel are now at least aware that
>there is a problem with the Gerber files produced by
> their application, and as such, a succeeding SP or major
>version release might even rectify this problem.
Fingers crossed then, eh...
> [...]
> zero degrees. And to rectify the embedded aperture
>definitions for octagonal flashes, I use a Perl script
>(on the Gerber files) which changes the rotational angle
>for each octagonal aperture definition from zero degrees
>to 22.5 degrees; this same script also scales (upwards)
>the diameter of each such aperture definition by a factor
>of the secant of 22.5 degrees.
I think you've gone to too much trouble. Rotation does
not change the diameter of a regular polygon aperture.
Geoff Harland
> > [...]
> > zero degrees. And to rectify the embedded aperture
> >definitions for octagonal flashes, I use a Perl script
> >(on the Gerber files) which changes the rotational angle
> >for each octagonal aperture definition from zero degrees
> >to 22.5 degrees; this same script also scales (upwards)
> >the diameter of each such aperture definition by a factor
> >of the secant of 22.5 degrees.
> >
>
> I think you've gone to too much trouble. Rotation does
> not change the diameter of a regular polygon aperture.
>
I fully agree that rotation does not change the diameter of a regular
polygon aperture. But my reading of the RS274X standard for polygonal
apertures is that the diameter specified within the aperture definition is
the vertix to (opposite) vertix distance (the diameter of the circumcircle
if the polygon has an odd number of sides), but Protel's software seems to
think that this distance is the edge to (opposite) edge distance instead.
And that distance is *smaller* than the vertix to (opposite) vertix
distance, and by a factor of the cosine of 22.5 degrees.
There was a time when my Perl script *only* changed the rotational angle
from 0 degrees to 22.5 degrees. But after receiving back PCBs in which the
octagonal pads were not as "meaty" as they should have been (in particular
the amount of copper between the outside edge of each such pad and the
outside edge of its associated hole), I re-examined the RS274X standard and
then modified my Perl script so that the specified diameter of each such
aperture was scaled upwards. As such, the nature of my Perl script is based
on real world experience.
AbdulraHman Lomax
[Mr. Harland wrote:]
>>then that suggests that Protel are now at least aware that
>>there is a problem with the Gerber files produced by
>> their application, and as such, a succeeding SP or major
>>version release might even rectify this problem.
>
> Fingers crossed then, eh...
I'm sure that "Protel" is aware of the issue, i.e., that someone with
responsibility, like the Product Manager, is aware of it. However,
it's not obvious what to do about it. Fixing it is the first-glance
solution, so that the Gerber output matches the RS-274X standard. But
there are fab houses out there accustomed to receiving files with
octagons from Protel clients, and they, I expect, routinely modify the
polygons. So there could be some problems. Still, I think it should be
fixed.
But what if the Protel octagon does not have an equal x and y
dimension? (I checked: the pad displays as intended, i.e., a
rectangular pad of dimensions x,y, with the corners chamfered at 45
degree angle. The dimension of the chamfer is not what would be
expected if the pad were merely a regular octagon stretched in one
direction. I then made the polygon have equal x and y dimensions and,
sure enough, the edges of the octagon are not equal. The Protel
octagon, in the database, is not a regular octagon.)
The use of the RS-274X polygon aperture in Protel is a complete
mistake. The PCB "octagon" is an octagon, all right, but it is not a
regular octagon, so there is no way to flash it using the polygon
primitive (though it could be drawn). It is not just a matter of
fixing the Gerber output routines: the Gerber import would need to be
fixed as well. And one might as well improve the whole concept of pad
shape at the same time.
It is quite useful that pads, in Protel, setting aside the octagon
question for a moment, are always flashed. This means that
retranslation from gerber easily identifies pads as such. Complex pads
would not be so simple to identify.
>[...]
>>And to rectify the embedded aperture
>>definitions for octagonal flashes, I use a Perl script
>>(on the Gerber files) which changes the rotational angle
>>for each octagonal aperture definition from zero degrees
>>to 22.5 degrees; this same script also scales (upwards)
>>the diameter of each such aperture definition by a factor
>>of the secant of 22.5 degrees.
>
> I think you've gone to too much trouble. Rotation does
>not change the diameter of a regular polygon aperture.
Rotating a normal octagon by 22.5 degrees changes the maximum x and y
dimensions. The Protel octagon, zero rotation, is defined with x and y
being the dimensions flat-to-flat. The RS-274X octagon is defined with
x and y being the distance across the points, it appears (the standard
is ambiguous). This is one more example of how the standard was *not*
designed by someone familiar with the needs of PCB design. It's really
easy to see why Protel got it wrong. Chamfered rectangular pads would
be a simple-to-define and very useful creature. The chamfer dimension
simply becomes another field. Instead we got regular polygons, which
are next to useless.
Note that one could create an aperture macro for a chamfered rectangle
and then use it like any other aperture. I think this is the way
forward. Forget fixing octagons, get rid of them (but leave the
capacity to interpret them from old files). Macros could then be
imported back as pads of the appropriate shape. But I haven't
experimented with macros.
Stephen Adam
"Geoff Harland" <ghar...@pork-ingenico.com.au> wrote in message
news:9cl26m$120$1...@merki.connect.com.au...
<much snipping>
> There was a time when my Perl script *only* changed the rotational angle
> from 0 degrees to 22.5 degrees. But after receiving back PCBs in which the
> octagonal pads were not as "meaty" as they should have been (in particular
> the amount of copper between the outside edge of each such pad and the
> outside edge of its associated hole), I re-examined the RS274X standard
and
> then modified my Perl script so that the specified diameter of each such
> aperture was scaled upwards. As such, the nature of my Perl script is
based
> on real world experience.
I've examined this and yes, you are quite correct. Protel generates
octagon
apertures as though their dimension should be specified across the flats.
My
knowledge is also based on real world experience, but my expertise is in
Gerber files, not in Protel.
Stephen Adam
news:3aede32c...@news2.vom.com...
<Big snip>
> there are fab houses out there accustomed to receiving files with
> octagons from Protel clients, and they, I expect, routinely modify the
> polygons. So there could be some problems. Still, I think it should be
> fixed.
I agree that it should be fixed because I'm certain that fab houses
often *don't* modify the polygons, except to ensure proper rotation.
This was Geoff Harland's experience:- "But after receiving back PCBs
in which the octagonal pads were not as "meaty" as they should have been "
> But what if the Protel octagon does not have an equal x and y
> dimension? (I checked: the pad displays as intended, i.e., a
> rectangular pad of dimensions x,y, with the corners chamfered at 45
> degree angle. The dimension of the chamfer is not what would be
> expected if the pad were merely a regular octagon stretched in one
> direction. I then made the polygon have equal x and y dimensions and,
> sure enough, the edges of the octagon are not equal. The Protel
> octagon, in the database, is not a regular octagon.)
>
> The use of the RS-274X polygon aperture in Protel is a complete
> mistake. The PCB "octagon" is an octagon, all right, but it is not a
> regular octagon, so there is no way to flash it using the polygon
> primitive (though it could be drawn). It is not just a matter of
> fixing the Gerber output routines: the Gerber import would need to be
> fixed as well. And one might as well improve the whole concept of pad
> shape at the same time.
I agree with all you've written, except that I believe it would be
quite easy for Protel to change their output routines so that octagonal
flashes are very close to the intended shape. The octagonal pad shapes
in Protel (2.8 at least) are called OCTnn. Do you think they actually
*intended* the octagons to be irregular?
> It is quite useful that pads, in Protel, setting aside the octagon
> question for a moment, are always flashed. This means that
> retranslation from gerber easily identifies pads as such. Complex pads
> would not be so simple to identify.
As a matter of interest. When you are exporting Gerbers from Protel,
try setting the 'maximum aperture size' to a value smaller than the largest
octagon you have in the file. Protel (2.8) will generate drawn pads, which
look very wrong to me.
<more snipping>
> > I think you've gone to too much trouble. Rotation does
> >not change the diameter of a regular polygon aperture.
>
> Rotating a normal octagon by 22.5 degrees changes the maximum x and y
> dimensions. The Protel octagon, zero rotation, is defined with x and y
> being the dimensions flat-to-flat. The RS-274X octagon is defined with
> x and y being the distance across the points, it appears (the standard
> is ambiguous). This is one more example of how the standard was *not*
> designed by someone familiar with the needs of PCB design. It's really
> easy to see why Protel got it wrong.
Yes, but also easy for them to fix. The RS274X octagon only has
a single dimension. In my opinion the standard is not ambiguous. The
"Gerber Format Guide" from 1994 states clearly that the dimension
of a polygon aperture is "Outside dimension in inches or millimetres".
The only possible way I can interpret that is for the dimension to
specify the diameter of a circle on which the points of the polygon
will lie. I haven't seen any older Gerber standards.
I have experimented with CAM programs (CAM350 and Lavenir
V2001) and checked films from a Fire9000 photoplotter as well as
a Gerber Crescent 30 photoplotter and in every case their interpretation
of the standard matches my own.
>Chamfered rectangular pads would
> be a simple-to-define and very useful creature. The chamfer dimension
> simply becomes another field. Instead we got regular polygons, which
> are next to useless.
Why? This is a genuine question. I'm not an electrical engineer and
I'm (almost) completely ignorant of board design.
> Note that one could create an aperture macro for a chamfered rectangle
> and then use it like any other aperture. I think this is the way
> forward. Forget fixing octagons, get rid of them (but leave the
> capacity to interpret them from old files). Macros could then be
> imported back as pads of the appropriate shape. But I haven't
> experimented with macros.
The problem with macros is that they are very general. It's
possible to make very complex images. In some circumstances
it might be very difficult for a program like Protel to import
an aperture macro and know what pad shape it is supposed
to represent.
Stephen Adam
> I'm sure that "Protel" is aware of the issue, i.e., that someone with
> responsibility, like the Product Manager, is aware of it. However,
> it's not obvious what to do about it.
I just remembered something that might go a long way to
explaining why the Octagon apertures are difficult to fix. Of
course you already know the procedures for exporting gerbers.
First we generate an aperture table. Now, if we export the
table as an APT file and generate gerbers *without* embedded
apertures, then the octagons will be sized correctly. All CAM
programs which import Protel APT files do so correctly, and the
dimension of an Octagon flash in the APT file is across the flats.
As we have discussed, the dimension of an octagon flash
in an RS274X file is across the points. Therefore, to properly
generate RS274X octagon flashes, Protel would need to
reorganise their gerber output system so that a different
aperture table is generated in this case.
AbdulraHman Lomax
> I agree with all you've written, except that I believe it would be
>quite easy for Protel to change their output routines so that octagonal
>flashes are very close to the intended shape. The octagonal pad shapes
>in Protel (2.8 at least) are called OCTnn. Do you think they actually
>*intended* the octagons to be irregular?
Yes. You can easily make an "octagon" in Protel which has, say, a 100
mil x dimension and a 200 mil y dimension. No way is that going to be
a regular octagon. Yet it is a very useful pad shape for printed
circuit design.
So Protel could fix their output routines so that, for octagons where
x=y, which I will call semiregular (since x can equal y without the
octagon being geometrically regular), a regular octagon is outputted
which is *approximately* the shape of a Protel octagonal pad. But it
won't be the same, because the face dimensions on a Protel octagon are
not equal. Take a square pad and nip some off the corners. Obviously,
there are various places where you could put that chamfer. Protel, in
the PCB database, has put *not* in a place where the faces are of
equal length; rather, the orthagonal faces are shorter than the
diagonal faces, by a factor of the square root of 2. This is basically
a stop sign shape; it is *not* a regular octagon, and the Gerber
polygon aperture is by definition a regular polygon.
So changing the output routines would not be enough; and, my ultimate
conclusion was that abandoning the use of the gerber polygon entirely
would be superior. Instead a Protel octagonal pad can be *drawn* with
a regular polygon; if this is made into a macro, then the flash/pad
correlation would remain.
It's too bad that RS-274X included a polygon aperture instead of the
more useful chamfered or rounded rectangles. (In a rounded rectangle,
the corner radius is greater than zero; i.e., the corners are not
sharp, but rounded. Tango had such a pad shape; I always defined it in
the aperture table including the corner radius. A chamfered rectangle
is similar, except that the corner is chamfered instead of rounded. A
complete definition of a chamfer would include the chamfer angle, but
it would be simplest to set that at 45 degrees.)
Anyway, all these shapes could easily be created with macros; then the
shape could be processed as if they were simple RS-274X apertures.
This is also the way to create off-center pad shapes. So I'd rather
see Protel abandon the polygon aperture entirely. As I said, it was a
mistake from day one.
[...]
> As a matter of interest. When you are exporting Gerbers from Protel,
>try setting the 'maximum aperture size' to a value smaller than the largest
>octagon you have in the file. Protel (2.8) will generate drawn pads, which
>look very wrong to me.
It's still wrong in Protel 99SE. My general advice to Protel users has
been "Don't use octagons." There are way too many problems. (By the
way, setting the maximum aperture size to a value smaller than any
pads is not recommended. About the only value I can see to it would be
to force fills to be drawn rather than flashed. (Protel flashes fills,
i.e., solid rectangles, by defining an aperture. I have not
experimented to see what would happen if 999 apertures are exceeded.
It should draw the largest, I would think, but I don't know.)
[I wrote:}
>> Rotating a normal octagon by 22.5 degrees changes the maximum x and y
>> dimensions. The Protel octagon, zero rotation, is defined with x and y
>> being the dimensions flat-to-flat. The RS-274X octagon is defined with
>> x and y being the distance across the points, it appears (the standard
>> is ambiguous). This is one more example of how the standard was *not*
>> designed by someone familiar with the needs of PCB design. It's really
>> easy to see why Protel got it wrong.
>
> Yes, but also easy for them to fix. The RS274X octagon only has
>a single dimension. In my opinion the standard is not ambiguous. The
>"Gerber Format Guide" from 1994 states clearly that the dimension
>of a polygon aperture is "Outside dimension in inches or millimetres".
>The only possible way I can interpret that is for the dimension to
>specify the diameter of a circle on which the points of the polygon
>will lie. I haven't seen any older Gerber standards.
I think the standard has said different things at different times;
further, "outside dimension" is not a term of general use with
polygons; it generally refers to circular objects like pipe. I have an
old reference showing mechanical hardware. "Outside dimension" is used
for washers; for hex nuts, the terms "points" and "flats" are used.
Mr. Adam correctly restricted the interpretation of "outside
dimension" by saying "the only possible way I can interpret that ..."
But there is another way.
I have a pad, and I want to put a hole in the pad. The minimum annular
ring would be the difference between the "outside dimension" and the
hole diameter, divided by two (assuming the hole is centered).
That is, in fact, how I'd expect a PC designer to think, more than the
other way. Obviously, however, it is possible to consider the matter
in two different ways, and they lead to two different results. That's
why I said that the standard was "ambiguous."
Now, it appears that Mr. Adam's interpretation is the one which was
intended, though that is not totally certain. I have a 1997 revision B
of the standard, and on page 22, in the Aperture Macro section, there
is a diagram of a polygon. In that diagram, "diameter" is defined. It
is across the flats. In revision D, dated this year, the diagram has
been corrected to show the dimension across the points.
My guess is that the left hand did not know what the right hand was
doing. So the standard was written one way, and perhaps the
programmers read it another, and the first machines interpreting
RS-274X used the point dimension. At that point it may have been
cheaper to change the "standard" rather than change the machines. But
this is speculation.
[...]
>>Chamfered rectangular pads would
>> be a simple-to-define and very useful creature. The chamfer dimension
>> simply becomes another field. Instead we got regular polygons, which
>> are next to useless.
>
> Why? This is a genuine question. I'm not an electrical engineer and
>I'm (almost) completely ignorant of board design.
One might use a hexagon in an application where one needs to pack pads
hexagonally. I've never seen such a need. Octagons are typically used
in Protel to indicate pin 1 where the other pins are circular. It is
not particularly visible if the pad is small; hexagons would be more
visible. Squares, which are obviously useful, can already be made as a
square aperture. A triangle could be used to make a sharp point, 60
degrees rather than the 90 degrees possible with square shapes (i.e.,
a fill). I've seen, once, a need for that in RF work. I built it up
with very small track.
There was an article in PC Design magazine years back, in the tape and
mylar days, recommending what I call, above, "rounded rectangles." The
reason was that you get additional routing area, compared to a sharp
rectangle, while still enlarging the pad over an oval pad. A chamfered
rectangle is the same idea, only a little better, perhaps; I'd use
these pads all the time if they were available in Protel. In fact, I
might want to chamfer, just a little, *all* square pads. Makes it
harder for them to peel up.
[...]
> The problem with macros is that they are very general. It's
>possible to make very complex images. In some circumstances
>it might be very difficult for a program like Protel to import
>an aperture macro and know what pad shape it is supposed
>to represent.
I disagree. Certainly it is a problem, but not a difficult one. If an
aperture macro has been used, Protel would assume it is a pad. It
would then create a pad shape matching it. It's got the center offset
information, it's got the shape information, and it's got the rotation
information. An aperture macro would be a complete pad shape
definition.
Yes, "in some circumstances" there would be problems. But that is
already true; Protel does not know what to make of any drawn pad. What
is difficult now is to distinguish a drawn pad from just plain drawn
track or polygon fill. That becomes much easier if a "flashed"
aperture is always a pad (which is what Protel now assumes). Actually
using macros would make it so, in many more situations.
Perhaps I should explain, for those who may not know, that a gerber
macro defines an "aperture," which can then be used like any other
aperture; it has its assigned D-code, etc.
AbdulraHman Lomax
> First we generate an aperture table. Now, if we export the
>table as an APT file and generate gerbers *without* embedded
>apertures, then the octagons will be sized correctly. All CAM
>programs which import Protel APT files do so correctly, and the
>dimension of an Octagon flash in the APT file is across the flats.
I think this is true, though it depends on the statement about "all
CAM programs," and it depends on the fabricator using one of those CAM
programs. But that's probably the case. It makes the file transmission
just a tad more complex, and there are a few other minor problems. But
if you need octagons, this would be the way to do it.
>
> As we have discussed, the dimension of an octagon flash
>in an RS274X file is across the points. Therefore, to properly
>generate RS274X octagon flashes, Protel would need to
>reorganise their gerber output system so that a different
>aperture table is generated in this case.
And I think they might as well reorganise the whole pad definition
system, because, as I wrote previously, the Protel "octagon" is not a
regular octagon. And changing that would affect legacy files.
With aperture macros, you can make any shape you want, and it is
totally explicit, and it is RS-274X, so you don't need separate
aperture tables.
Stephen Adam
> "Stephen Adam" <saa...@bigpond.com> wrote:
>
> >All CAM
> >programs which import Protel APT files do so correctly, and the
> >dimension of an Octagon flash in the APT file is across the flats.
>
> I think this is true, though it depends on the statement about "all
> CAM programs,"
I should not have made such a sweeping statement. I would
have edited that but I didn't notice until after I'd sent the post.
Stephen Adam
> "Stephen Adam" <saa...@bigpond.com> wrote:
[...]
> Mr. Adam correctly restricted the interpretation of "outside
> dimension" by saying "the only possible way I can interpret that ..."
>
> But there is another way.
>
> I have a pad, and I want to put a hole in the pad. The minimum annular
> ring would be the difference between the "outside dimension" and the
> hole diameter, divided by two (assuming the hole is centered).
>
> That is, in fact, how I'd expect a PC designer to think, more than the
> other way. Obviously, however, it is possible to consider the matter
> in two different ways, and they lead to two different results. That's
> why I said that the standard was "ambiguous."
But the documentation is intended to be read by programmers,
not PC designers. It's up to the programmer to implement Gerber
format accurately in software. In an ideal world the (well written)
software should save the PC designer from ever having to deal
with it. Of course, we don't live in an ideal world.
I'll use Postscript as an analogy. A programmer writing a
postscript printer driver (for example) needs to understand
postscript. Someone who works in a print bureau probably
needs some knowledge of postscript too. But the rest of us
only need to know how to click on the 'Print' button.
> Now, it appears that Mr. Adam's interpretation is the one which was
> intended, though that is not totally certain. I have a 1997 revision B
> of the standard, and on page 22, in the Aperture Macro section, there
> is a diagram of a polygon. In that diagram, "diameter" is defined. It
> is across the flats. In revision D, dated this year, the diagram has
> been corrected to show the dimension across the points.
>
> My guess is that the left hand did not know what the right hand was
> doing. So the standard was written one way, and perhaps the
> programmers read it another, and the first machines interpreting
> RS-274X used the point dimension. At that point it may have been
> cheaper to change the "standard" rather than change the machines. But
> this is speculation.
I think your almost spot on. I'm sure that the people designing
and programming the Photoplotters knew exactly what they were
doing, but they weren't the people who wrote the documentents.
Same old story.
> > The problem with macros is that they are very general. It's
> >possible to make very complex images. In some circumstances
> >it might be very difficult for a program like Protel to import
> >an aperture macro and know what pad shape it is supposed
> >to represent.
>
> I disagree. Certainly it is a problem, but not a difficult one. If an
> aperture macro has been used, Protel would assume it is a pad. It
> would then create a pad shape matching it. It's got the center offset
> information, it's got the shape information, and it's got the rotation
> information. An aperture macro would be a complete pad shape
> definition.
Well, my opinion is not likely to change. Gerber format is a
graphical output format. That's all it is *supposed* to do, and
I think it is OK for that. To use the Postscript analogy again,
it is theoretically possible to read a Postscript file and extract
the text into a .TXT file. This easy if the text is in strings, but
there is no guarantee of that in Postscript. Text might be
hidden in internal bitmaps or compex font references. While
Gerber format is nowhere near as complex as Postscript,
the same problem can occur. Aperture macros can describe
shapes in such a variety of ways that it would be easy to fool
a program like Protel as it tries to convert them back to known
pad shapes.
Having said that, the problem is easy to fix if you are only
importing Gerber files created by Protel, since macros can
be created according to well defined rules.
I think that Gerber format is quite good for graphical
output of PCB data. As you say, it is possible to represent
almost any shape that a PC designer might want, using for
example, aperture macros and G36 area fills.
I don't think there's any excuse for CAD software to
get it wrong. Gerber format has been criticised for various
reasons, but it's not really difficult to find out how it is
meant to work.
My first post in this thread was a sort of soft complaint
that Protel does not seem to care about problems that PCB
manufacturers have. It's probably appropriate for Protel to
give priority to those features required by their customers,
the PC designers.
But from a manufacturing perspective it's frustrating
to have to throw away artworks and sometimes finished
panels, and have arguments with disappointed customers
because of Protel's problems interpreting a standard
which is really not very difficult to implement. I think
they should have it right by now.
AbdulraHman Lomax
>Aperture macros can describe
>shapes in such a variety of ways that it would be easy to fool
>a program like Protel as it tries to convert them back to known
>pad shapes.
>
> Having said that, the problem is easy to fix if you are only
>importing Gerber files created by Protel, since macros can
>be created according to well defined rules.
This is, of course, what I had in mind. Protel is *not* a gerber
editor. It contains gerber import so that it can deal with its own
gerber, and, yes, it can already easily be flummoxed by gerber
generated by other programs.
However, if it were possible to turn off the automatic conversion of
flashed macros to pads, having the facility would be nothing but an
improvement. Without the use of macros, there would be *no* way to
identify pads other than full-blown AI. With macros, the pads would
have rotation attributes.
This could be done now for RS-274X output without waiting for
improvements to the pad library (i.e., shapes beyond the three present
shapes). It would immediately allow the x and y dimensions of octagons
to be different.
Normally, we discuss this kind of stuff on the Protel users list,
where we know, for sure, that Protel pays close attention. Perhaps
I'll take some of this over there. For those who don't know about the
list, if you are a Protel user, don't leave home without it!
Subscribe through the user's link at