At 05:53 AM 2/20/2002 -0500, [EMAIL PROTECTED] wrote: >In a message dated 2/19/2002 6:20:58 PM Eastern Standard Time, >[EMAIL PROTECTED] writes: > > > One thing to check for in the PCB database is a duplicate net.
>Bingo! And since I've that net is supposed to all be one, I'd bet that I've >got other occurances like that, so I'm off on the hunt. Most likely this came >about because of using Ports Only Global, Yes, if one has not set the option to add sheet numbers to the net name. (This may also happen with Sheet Entry/Port connections Only, I'm not sure.) It is good practice to routinely check that option when using the restricted scopes, and our readers may know that I generally recommend using such restriction. > and I have something unconnected >that I intended to have connected, and quite possibly more than a few >"somethings". But this sure is a strange way to find out about it. However, >it's like a lot of other things in Protel - when it does something odd, I >don't just ignore it. Usually it's a symptom of something much deeper and >more troublesome, as it is here. Yes. It is routine practice for me to re-run the synchronizer even when it reports no errors. If macros are still created, I run it again (because pins might be placed *after* macro creation, which happens with footprint changes, so they are not assigned nets the first time). If there are *still* macros then I have, almost certainly one of the following: (1) duplicate pads, and I am using the netlist load process, which has a bug with respect to these; it will alternately assign and unassign the net. If the pads begin in the same state, they will end in the same state, if they are in a different state when the netlist is loaded, they will swap states. (2) duplicate nets. When the synchronizer or netlist load process sees these, it does not report a warning (it should). Instead, it sees errors and it "corrects" them, because it is examining, I think, one net at a time. This net obviously has too many nodes. (3) for completeness, there is a third possibility: one is keeping components that do not exist on the schematic, like targets. I recommend putting such components on the schematic off in a corner somewhere, perhaps with a note to keep future generations from scratching their heads. I want to see three things by the time I complete a design: (1) No ERC warnings or errors, with a strict error matrix. No-ERC Directives are used to suppress "errors" or warnings that are absolutely verified to be legitimate, such as unconnected outputs or unused connector pins or, perhaps I/O pins that are connected, for example, to an Output. (2) No DRC warnings or errors except for the warning about primitives on inner planes, when a board edge clearance track has been used on those layers. Protel should more carefully check inner planes, but another solution for this would be PWB equivalents for No-ERC Directives. How these would work has been described elsewhere, but a summary would be that they would be *very* specific. They would suppress an "exact" warning message. It is conceivable that some operations, such as a block move of an entire PCB, would result in a modification of the No-DRC Directive so that it still suppressed the error, I can't think of another excuse for leaving it applicable that would always work. (3) Synchronization that produces no macros, the only exception being macros to remove non-schematic footprints, if such have been allowed. Many designers don't take the trouble, however, based on what I have seen. Penny-wise and pound-foolish. I suspect that the typical reason is that it can seem difficult to identify and fix the source of all ERC warnings (it is with the schematic that designers are more lax); this is circular, because if one *does* take the trouble, with persistence -- including asking this list if necessary -- it will become easy. I.e., one does not do it because it is difficult, and it is difficult because one does not do it. Protel could fix the latter, perhaps, we could get better error reporting; net shorts, for example, are often reported elsewhere than the location of the net labels that create the problem, maybe they pop up on the first occurrence of each net. Final comment et seq: use the Synchronizer (Schematic:Design/Update PCB) Preview the changes. Better than Load Netlist. (You can also use PCB:Design/Update Schematic, which, among other things will take footprint names back into the Schematic, there is no longer any excuse to not have them correspond. Once they correspond, one can change, for example, an 0805 capacitor to an 0603 in the Schematic, take it over to the pcb, and all that would needs to be done is to draw over the connections with Loop Removal. Protel should give us a means of automatically adjusting all track to terminate on pad center. Together with an angle restriction rule that actually was workable, one could make changes like this quickly and without even looking at the parts, unless they create DRC errors.) [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://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
