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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to