Tom Frayda
11-19-2001, 11:58 AM
I have unfortunately had the copper circle/arc problem resurface in a couple of designs lately in both ver 3.6 and ver 4.0 output in RS-274-X format. The copper arc is not usually visible in PADS or any post-processing CAM software and often does not show up until the photoplots are made.
I have long followed the recommendations of Tracker #14423... set the precision to (3,5), photoplots to the lower left, smoothing radius recommendations, etc. I assure you that the copper circle/arc bug has not been resolved.
I have had extensive correspondence with PADS through both official tech support channels and through email with Mr. Woundy, who was kind enough to open Defect Tracking Number 16632 on my behalf.
According to Mr. Woundy, this is not the same problem as Tracker #14423, which dealt strictly with low precision causing circles to occur in CAM outputs and could be corrected by changing the precision in the CAM.
He informed me that this form of the copper arc problem stems from an error in the flooding routine that allows the creation of a flood area smaller than the hatch outline width (ie: a self-intersecting polygon). As we are all aware, PADS does not allow self-intersecting polygons during manual copper shape creation, but that check is not being performed during the copper flood routine.
That means that the flaw is present in the PADS design itself. In every case, I have been able to get the arc to display by carefully selecting a segment of the pour outline adjacent to where the arc is known to be and hitting CTRL+E to instatiate the move mode without actually moving anything and out pops the arc. Unfortunately, you must know the location of the arc to do this, but it does verify the defect to be present in the design.
To help minimize the occurrence of the problem, I was told that the minimum hatch area setting should never be made less than the hatch/pour outline width. It is likely that we've had so many problems with this in the past because we use a pour outline width of 0.010" and, when setting up our default files, my predecessors chose to set the minimum hatch area to 0 in order to maximized the copper back-fill.
However, the problem is truly within the PADS flooding algorithm and can only be conclusively corrected there. Unfortunately, Mr. Woundy informs me that the defect was reviewed for implementing a fix in version 4.01 (due out in December), but due to the complexity of the fix and the possibility of introducing new errors, a correction will not be considered until version 5.0 (due out in Q3 2002).
The problem is more likely to surface when the Gerber data is processed through older CAM software (particularly Lavenir for some reason). Obviously including a netlist and requiring electrical test would prevent being burned by this, but we don't typically do that for prototype quantities.
I just figured I'd put this out here because I felt that you should all be aware of this defect. Questions or comments are welcome.
+Tom
I have long followed the recommendations of Tracker #14423... set the precision to (3,5), photoplots to the lower left, smoothing radius recommendations, etc. I assure you that the copper circle/arc bug has not been resolved.
I have had extensive correspondence with PADS through both official tech support channels and through email with Mr. Woundy, who was kind enough to open Defect Tracking Number 16632 on my behalf.
According to Mr. Woundy, this is not the same problem as Tracker #14423, which dealt strictly with low precision causing circles to occur in CAM outputs and could be corrected by changing the precision in the CAM.
He informed me that this form of the copper arc problem stems from an error in the flooding routine that allows the creation of a flood area smaller than the hatch outline width (ie: a self-intersecting polygon). As we are all aware, PADS does not allow self-intersecting polygons during manual copper shape creation, but that check is not being performed during the copper flood routine.
That means that the flaw is present in the PADS design itself. In every case, I have been able to get the arc to display by carefully selecting a segment of the pour outline adjacent to where the arc is known to be and hitting CTRL+E to instatiate the move mode without actually moving anything and out pops the arc. Unfortunately, you must know the location of the arc to do this, but it does verify the defect to be present in the design.
To help minimize the occurrence of the problem, I was told that the minimum hatch area setting should never be made less than the hatch/pour outline width. It is likely that we've had so many problems with this in the past because we use a pour outline width of 0.010" and, when setting up our default files, my predecessors chose to set the minimum hatch area to 0 in order to maximized the copper back-fill.
However, the problem is truly within the PADS flooding algorithm and can only be conclusively corrected there. Unfortunately, Mr. Woundy informs me that the defect was reviewed for implementing a fix in version 4.01 (due out in December), but due to the complexity of the fix and the possibility of introducing new errors, a correction will not be considered until version 5.0 (due out in Q3 2002).
The problem is more likely to surface when the Gerber data is processed through older CAM software (particularly Lavenir for some reason). Obviously including a netlist and requiring electrical test would prevent being burned by this, but we don't typically do that for prototype quantities.
I just figured I'd put this out here because I felt that you should all be aware of this defect. Questions or comments are welcome.
+Tom