I guess this really relates to the method of application and purpose of polygon fills in designs and how the designer is using the tool. I have used polyfills on internal layers to make split planes and to fill ground around components on the surfaces of the board... Your comment about the 'undo-ing' of moves on polygon fills makes me think that may have been the source of the cause for the problem I experienced. In selecting components to move or traces to edit, sometimes I accidentally select the polygon plane and the software, of course, will ask if I want to regen the polygon fill. Its not very good to use them for internal ground planes because of the editing difficulties, and I have since used the 'Internal Plane layer' features and had better success with being able to make changes simply without generating all the errors that happen when you try to put a via through multiple fill planes and then have to regenerate the planes. It seems that a weak point in the software design is the point of view from the developers standpoint is limited to 'first time new design' and not 'editing an existing design'. Of, course I can rant about the 'Design Explorer' which is a sore point with all the users at our company... I hate how it has complicated the use of the program and the file storage and manipulation. But we live with it... using the 'windows filing system ' and just storing the design file, gerbers, and schematic in a safe place, and remaking a ddb file when we need to edit the file for new revisions. I may have had this 'move the polygon fill thing' happen and then hit undo to place the polygon back where it was supposed to be... thus causing the disconnected image of the fill. I didn't notice it until I went to update the fill again later after finishing the changes to the board.. it looked like I couldn't change the fill, or delete it. Selecting the entire board and moving it all to a new location and allowing the polygons to regen did in fact correct the ghosting problem. Its good to have some idea of the cause.. I will try to replicate the cause and effect to see how it reacts. Thanks for the insight. Bill Brooks PCB Design Engineer DATRON WORLD COMMUNICATIONS INC. 3030 Enterprise Court Vista, CA 92083 Tel: (760)597-1500 Ext 3772 Fax: (760)597-1510 mailto:[EMAIL PROTECTED] IPC Designers Council, San Diego Chapter http://www.ipc.org/SanDiego/ http://home.fda.net/bbrooks/pca/pca.htm -----Original Message----- From: Geoff Harland [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 23, 2001 9:03 PM To: Protel EDA Forum Subject: Re: [PEDA] help - Please... Filled Ground plane <Ghosts>... cannot be deleted <snip> > I have said this before, but this thread warrants my repeating it. I believe > that when one or more polygons have been moved, and that move command is > then undone, Protel *should* have (also) recorded which option the user > previously selected, as far as repouring that/those polygon(s) was > concerned. If the user did *not* select repour, the polygon(s) should be > restored to its/their previous location(s) (boundaries and contents), with > no re-calculation of the associated contents. And when the user *did* select > repour, each polygon should be "unrepoured". And regardless of which > (repour) option was selected previously, Protel should *not* be asking the > user *again*, during the Undo command, as to whether the polygon(s) should > be repoured (during the Undo feature), as it should have recorded which > option was selected previously (when the polygon(s) were first being moved). > > However, I appreciate that supporting "unrepour" of polygons would be > something of a big ask, because of the amount of data that could have to be > stored in some cases. That said, non-repoured polygons could still be > restored without too much bother, while polygons which had been repoured > could be handled (with less pain) by the user being prompted as to whether > (the moved) polygons be "unmoved" without repouring, or "unmoved" with > repouring. As such, polygons which had been repoured previously would not be > "unrepoured" during the Undo command (with either of those options), but at > least the suggested implementation would still be a very welcome improvement > upon the current buggy situation. > > (Note that the user would *not* be prompted for a repour of the polygon(s) > during the Undo command if the polygon(s) had *not* been repoured when > it/they were first moved; such a prompt would occur *only* if this/these > polygon(s) *had* been repoured previously. Then again, if "unrepour" was not > supported, it could be argued that repouring the polygon(s) *again* during > the Undo command would/could typically make this/these even less similar to > the polygon(s) prior to the initial move command. As such, perhaps polygons > should *always* be "unmoved", but *otherwise* unchanged, during the Undo > command. And if that was the case, then the user would/should *never* be > prompted as to whether the polygon(s) should be repoured during the Undo > command. What do others think?) > > Geoff Harland. Having thought about this a bit more since the time I posted the above message, I consider that there would be times when users *would* prefer any polygon(s) being "unmoved" to be repoured at the same time (*if* "unrepouring" of polygons being "unmoved" was *not* supported). (A polygon could be on a copper layer, and assigned to a particular net. If it was not repoured during the "unmove" command, DRC errors would typically be produced, as a consequence of primitive items within the polygon coming in contact with items assigned to *other* nets.) As such, I now think that the user *should* be prompted as to whether the polygon(s) should be repoured during an "unmove" command. (But this prompt still should *not* occur if the polygon(s) had *not* been repoured during the previous move command.) And there is probably something to be said for the query box informing the user that "unrepour" is not supported, and as such, the user is currently being asked whether repour should occur during the (current) "unmove" command. Although I have not changed my mind about the perceived difficulty and data requirements of supporting "unrepour" of polygons, I have since come to the view that it is not out of the question that it could in fact be implemented. At present, it is possible to select everything in a Pcb file, and then invoke the command of deleting all selected items. This combination of commands will remove everything from the Pcb file. If the Undo command is then invoked, everything which had previously been removed from the Pcb file will now be restored to this. The associated data requirements for a complex Pcb are not trivial, but as this is supported, it is not out of the question to further support "unrepouring" of polygons. Regards, Geoff Harland. ----------------------------- 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. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Browse or Search previous postings: * http://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
