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. [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://firstname.lastname@example.org * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *