I think that in schem if the pin number is null (blank) then the pin
name will be used in the netlist, no?
If both are filled out then the pin number is used.

I agree the ERC is useful, but as you point out there is a lot of
potential hassles with the pin types (input, output, etc.), namely
outputs shorted together that you do want shorted, likewise powers.  
Since I am most often looking for hanging inputs or open power pins to
simply things (and consequently perhaps reducing the potential
effectiveness of the ERC) I generally make power 'input', inputs
'input', outputs often passive.
not perfect, but it has sped me up without problems (yet....)

Dennis Saputelli


Abd ul-Rahman Lomax wrote:
> 
> At 03:48 PM 2/27/01 -0700, Colby - PowerStream wrote:
> 
> >ERC is a subject I will leave open for anyone that uses it, I do not.
> >
> >So it sounds like the first problem to tackle is to make sure the Pad
> >Designators on your Footprints match the Pin numbers for the corresponding
> >schematic symbol.
> 
> Last first. good advice on the potential symbol/footprint pad designator
> mismatch. This is the source of most errors of the kind described.
> Remember, also, that the schematic pad "number" is what appears in the net
> list and which needs to match the pad designator on the PCB. The name is
> fluff, unless the pin is hidden, in which case it becomes a net name.
> 
> First second. Not ERC-ing a schematic is about as dangerous as not DRC-ing
> a PCB. Years ago, an engineer from whom I was doing PC design showed me how
> he checked the designs. The very first thing he did was to place the
> tapeups on a light table and look for unconnected pads. It was easy to do
> this even on complex multilayer designs. While many unconnected pads
> represented legitimate unconnected pins, the fact was that the majority of
> errors on PC designs resulted in an unconnected pin.
> 
> While you can examine the unconnected pads on the PCB (it's an option on
> the DRC report), it has become much easier to check this at the schematic
> level. When I am placing a symbol which has a pin which I want to maintain
> as unconnected, I immediately put a No-ERC marker on it. My error matrix
> detects all unconnected pins, but those pins don't show up.
> 
> Some engineers don't use ERC because it can be time-consuming to clean up a
> schematic which has been drawn without regard for error checking, and
> especially if the part pins do not have the correct electrical types. But
> this is penny wise and pound foolish. It allows difficulties to accumulate,
> making things more difficult for everyone else down the road, which might
> include oneself. I receive many schematics from engineers containing errors
> which I can easily detect with ERC; thus I know that they did not run the
> ERC report, or they saw the errors and warnings and did not bother to track
> down the cause of each one.
> 
> Once one has corrected a schematic, it should run with no errors. If one
> then makes changes to the project, any errors or warnings appearing upon a
> new ERC may well represent real errors.
> 
> I have the right as a designer to simply execute the board according to the
> schematic which was given to me. I don't do this, where I suspect an error,
> but I also don't catch everything.
> 
> ERC will not catch all errors. For example, a net with four pins may have a
> pullup resistor, a driver, and two inputs. If the net is broken such that
> the pullup and one input are in one section, and the driver and other input
> are in the other section, DRC is happy; there are no floating inputs. It's
> really easy to have this mistake across sheets by having minute variations
> in net names. Like AO1 and A01. That's one I've seen more than once.
> 
> But ERC *will* detect a high percentage of schematic drawing errors, and
> thus save much time and money. And many of the errors that it misses will
> be *relatively* minor. I'd rather have a floating input (as in the example
> I gave) than have a short, for example. Many kinds of shorts will be
> detected by ERC.
> 
> [EMAIL PROTECTED]
> Abdulrahman Lomax
> P.O. Box 690
> El Verano, CA 95433
> 
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> *  This message sent by: PROTEL EDA USERS MAILING LIST
> *
> *  Use the "reply" command in your email program to
> *  respond to this message.
> *
> *  To unsubscribe from this mailing list use the form at
> *  the Association web site. You will need to give the same
> *  email address you originally used to subscribe (do not
> *  give an alias unless it was used to subscribe).
> *
> *  Visit http://www.techservinc.com/protelusers/subscrib.html
> *  to unsubscribe or to subscribe a new email address.
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

-- 
___________________________________________________________________________
www.integratedcontrolsinc.com            Integrated Controls, Inc.    
   tel: 415-647-0480                        2851 21st Street          
      fax: 415-647-3003                        San Francisco, CA 94110

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*  This message sent by: PROTEL EDA USERS MAILING LIST
*
*  Use the "reply" command in your email program to
*  respond to this message.
*
*  To unsubscribe from this mailing list use the form at
*  the Association web site. You will need to give the same
*  email address you originally used to subscribe (do not
*  give an alias unless it was used to subscribe).
*
*  Visit http://www.techservinc.com/protelusers/subscrib.html
*  to unsubscribe or to subscribe a new email address.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

________________________________________________________
To leave the EDAFORUM discussion list, send a email with
'leave edaforum' in the body to '[EMAIL PROTECTED]'

Reply via email to