Maker Pro
Maker Pro

DXP and dulplicate components

J

JamesB

Jan 1, 1970
0
Hi,

I've got a problem with DXP.

When viewing the gerbers, it appears that we have some components
duplicated outside of the board area, but only on certain layers -
specifically the solder and paste layers, but not on the normal top layer.

I've tried the old trick of selecting outside area and trying to delete
them but they won't show up at all in Protel. Using the inspector list,
I can't see them either and definately can't delete them.

Any ideas?

Thanks,
 
T

TT_Man

Jan 1, 1970
0
JamesB said:
Hi,

I've got a problem with DXP.

When viewing the gerbers, it appears that we have some components
duplicated outside of the board area, but only on certain layers -
specifically the solder and paste layers, but not on the normal top layer.

I've tried the old trick of selecting outside area and trying to delete
them but they won't show up at all in Protel. Using the inspector list, I
can't see them either and definately can't delete them.

Any ideas?

Thanks,

Typical..... how about turning all layers on and retrying? I've found
library errors that cause similar problems in the old 'Client' version and
the culprit was in an odd ball layer.
 
B

Brad Velander

Jan 1, 1970
0
My suggestion,
Check all your library parts used in the design in the library editor,
check that none of them have extraneous bits spread out away from the main
body of the part. In the library viewer window the part should roughly come
in filling the screen (either X or Y) with all layers turned on so you can
see anything on any layer. If it comes in smaller, then there is probably a
primitive spread out away from the main body of the part. Then update the
PCB parts from the library once you have confirmed your library parts are
alright. I suspect that you have gotten some primitives from a land
pattern/footprint accidently moved out to the extremes of the database. If
you get it fixed, make sure that all your land patterns have their
primitives locked so that they cannot be moved separate from the whole land
pattern again. That's my best guess at what may be going on.

To try and just remove the problem, the selection trick that should work
is actually. Turn on all used layers. Select All, then Deselect Inside
mousing just around your board outline, then Shift-Delete. The details of
this operation are: This selects everything regardless of it's location.
Then you deselect anything within the board outline. Then delete the still
selected items.
The key operation is the Deselect anything bounded by the board outline.
If it is even a segment of a land pattern that was moved outside the board
outline, that item will not be deselected by bounding the board outline.
Then when you Shift Delete, you will remove that offending item with
remnants out in the extremes because it was not deselected by the bounding
box only around the PCB outline. If this seems to work then run the Update
PCB from your schematic again, it will probably add back components that you
did delete fixing the problem. Finally run your DRC to see that everything
is still as per the rules and connectivity.

By your original comments, the only way that soldermask portions of a
part land pattern can move away from the pads is when they are added into
the land pattern as a separate primitive. Otherwise most of the normal
soldermask detail is calculated from the pads. Since you say there are no
pads in that area, then the culprit(s) must be from land patterns that have
separate soldermask primitives (fills, traces, polygons on the soldermask
layers) within the land pattern. Does that help you zero in on the culrpit
parts?
 
J

JamesB

Jan 1, 1970
0
Brad Velander wrote:
[cut..]
To try and just remove the problem, the selection trick that should work
is actually. Turn on all used layers. Select All, then Deselect Inside
mousing just around your board outline, then Shift-Delete. The details of
this operation are: This selects everything regardless of it's location.
Then you deselect anything within the board outline. Then delete the still
selected items.
The key operation is the Deselect anything bounded by the board outline.
If it is even a segment of a land pattern that was moved outside the board
outline, that item will not be deselected by bounding the board outline.
Then when you Shift Delete, you will remove that offending item with
remnants out in the extremes because it was not deselected by the bounding
box only around the PCB outline. If this seems to work then run the Update
PCB from your schematic again, it will probably add back components that you
did delete fixing the problem. Finally run your DRC to see that everything
is still as per the rules and connectivity.

By your original comments, the only way that soldermask portions of a
part land pattern can move away from the pads is when they are added into
the land pattern as a separate primitive. Otherwise most of the normal
soldermask detail is calculated from the pads. Since you say there are no
pads in that area, then the culprit(s) must be from land patterns that have
separate soldermask primitives (fills, traces, polygons on the soldermask
layers) within the land pattern. Does that help you zero in on the culrpit
parts?

Thanks Brad. I did your select trick which solvevd the problem. Funnily
enough, re-updating the PCB didn't cause any changes and the problem
hasn't come back.

Love to know why that happened, but I've given up trying to find logic
with DXP sometimes.

Thanks,
 
T

TT_Man

Jan 1, 1970
0
Thanks Brad. I did your select trick which solvevd the problem. Funnily
enough, re-updating the PCB didn't cause any changes and the problem
hasn't come back.

Love to know why that happened, but I've given up trying to find logic
with DXP sometimes.

Thanks,

You and half the other protel users around the world no doubt.... A similar
thing happens with copy .sch to new.sch and part of the .sch is outside the
paper size box.....
Rather the devil you know, I suppose.
 
A

Anton Erasmus

Jan 1, 1970
0
Typical..... how about turning all layers on and retrying? I've found
library errors that cause similar problems in the old 'Client' version and
the culprit was in an odd ball layer.

I have seen this sort of thing as well. Sometimes it is a very small
section of arc which has a big radius with the centre outside the
visible area. These arcs cannot be selected and deleted. I have
exported such files in ASCII format, and deleted the relevant ARC's
in a text editor.

Regards
Anton Erasmus
 
B

Brad Velander

Jan 1, 1970
0
James,
Glad I could help.

That selection/delete technique is almost fool proof. Other combinations
or variations may work in limited cases but the one that I explained is the
most common one to fix these problems because everything is selected, then
the desired and well behaved section of the selection is removed from the
selection and the unruly bits are deleted. But there are some very unique
cases where it doesn't work either. That selection and deletion routine also
works with the infamous items in the unviewable negative quadrants of the
database, i.e. less than zero on either the X or Y axis.

How you got there? Well the most common manner in which someone gets to
that point is via the fact that they copied-pasted or moved something while
they inadvertently had something else selected, somewhere outside of their
current view/section o fthe design. When they move what they want to move
they also copy/duplicate/move something that they were unaware they had
selected at the time and it ends up somewhere out in the boonies. The most
important practice to force into your brain is to "X" (Deselect), "A"ll
before making a selection(s) for any copy or move operations.

The items that you deleted must not have been anything important to the
design if a subsequent update from the schematic did not add anything back
in. I had suspected that maybe the operation would remove a spread out
footprint and then the update would bring in a fresh one.

AD/DXP/Protel is actually a fairly logical package, however too many
people compare it against their former tools in determining their view of
that logic and a lot of the other tools are not that logical when examined
with pure logic in mind. I have used a number of them over my years and they
all have their quirks to one extent or the other. The largest number of
complaints definitely come from users forced to switch over but that is
always the case with every package. Most are being forced to change from
another package, not changing by choice. After a while a number of them do
eventually see that light and only look for improvements, not to turn the
whole package upside down.
 
Top