At 10:48 PM 2/13/2002 +1100, Ian Wilson wrote:
BTW -  I like the old subject heading "Serious Bug: Polygons still 
connecting to pads" better than the revised.

Yes, keepouts are a red herring here. The problem is in the polygon pour 
routines; if a keepout has the net attribute of the polygon, the polygon, 
set for pour over same net, treats the keepout as if it were an ordinary 
track, it does not cause a violation and pour will not avoid it. I consider 
this desirable behavior. If you want an unconditional keepout, create it 
with no_net.

I went down a whole deceiving road with this, working with a test pcb that, 
I don't recall how, had the board clearance rules disabled. Naturally, I 
got some weird behavior for pours.

I would expect that Protel took the simple path in creating the keepout 
attribute: really, all a keepout needs to be is a primitive that does not 
plot and does not implement a connection. Everything else should be the 
same. Knowing this could allow some complex controllable behavior for 
keepouts. For example, one could set a routing keepout that allowed only a 
single net to cross the keepout. While I would prefer to be able to set a 
net *class* for a keepout, the simpler behavior would still be useful, and 
I could work around the limitation by setting keepout segments for each net 
I wanted to be able to pass through the boundary. Does this work now? I 
haven't tested it.

Documentation should inform users that keepouts are no-plot primitives. 
Otherwise they are (or should be) the same. I used to place ordinary track 
of a distinctive size to function as keepouts for the router. It worked 
fine. Then, when routing was done, I selected that track with a global edit 
and deleted it or moved it to a mech layer in case I wanted to use it 
later. By creating the keepout attribute, Protel made the removal step 
unnecessary. We asked for it and they gave it to us.

There is, however, what we could call a net memory problem. Once a track 
(keepout or otherwise) has the net of a polygon, changing it to no-net does 
not directly change polygon pour behavior, pour over same net still treats 
the primitive as being of the same net.  (I have not tested whether or not 
other primitives exhibit the same behavior.) Instead, changing the track to 
another net seems to be necessary to clear out the pour-over.

With the tracks as No_Net and the GND polygon set to no-hatch, I wrote out 
the file as ASCII, and then reloaded. It appeared the same, as expected, 
since the polygon had not been rebuilt. When I rebuild the polygon, the 
outline track was created. The history bug does not persist through the 
ASCII database.

Then I edited one of the tracks (which are endpoint-connected) to GND and 
repoured. One of the tracks was outlined, the other was not. The outline 
shorted the tracks, but they were already shorted. Then I edited the GND 
track back to No_Net. The pour did not change. I saved the file as binary, 
version 3, and repoured. The pour now was correct, clearing both tracks.

I then edited one track to GND and immediately back to No_Net. Rebuild now 
was incorrect.

I saved the file as version 4 binary. Rebuild was now correct, whatever 
glitch exists is not preserved through any kind of save.

This makes the workaround obvious. Save the file, close it, reopen it. This 
may, in fact, explain why we have not heard much about this bug.
Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to