The connector is a 96-way Eurocard type.
The schematic symbol has all the pins as "Passive", since on some boards the signals
go OUT, and some IN.
I may have to bite the bullet and make separate sch. symbols for each board, depending
It might be a PITA having half a dozen 96-way Eurocard connector symbols though, each
with different pin attributes, which is why I'm looking for a more robust solution (if
there is one).
> -----Original Message-----
> From: Tony Karavidas [mailto:[EMAIL PROTECTED]
> Sent: Friday, 15 August 2003 12:26
> To: Protel EDA Forum
> Subject: Re: [PEDA] Unacceptable Bug in Protel 99 SE SP6..!
> Don't you show the connectors leading to the bus? Wouldn't
> they be the source of the address on your peripheral cards
> and therefore you shouldn't have any "Unconnected Input Pins"?
> On Fri, 15 Aug 2003 08:49:02 +1000, Damon Kelly wrote:
> >?I have been designing some bus-based cards (with a processor card,
> >?and other peripheral cards), and have the problem that on many of
> >?the other cards, the address signals (in particular) have no
> >?"outputs" (they come from the processor card).
> >?This causes lots of "Unconnected Input Pin" type errors (I can't
> >?remember the exact wording).
> >?While I can live with that, I worry that I'll miss a _real_ error
> >?in the mass of spurious ones.
> >?Any suggestions on a robust solution, not based on No-ERC
> >?Damon Kelly
> >?Hardware Engineer
> >>?-----Original Message-----
> >>?From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED] Sent:
> >>?Friday, 15 August 2003 07:03 To: Protel EDA Forum
> >>?Subject: Re: [PEDA] Unacceptable Bug in Protel 99 SE SP6..!
> >>?At 05:09 AM 8/14/2003, Edi Im Hof wrote:
> >>?It's also a good idea to set the ERC a bit tighter. [...]
> >>>?On intentionally left open pins, I place a "no erc mark" on
> >>?it. Keystrokes
> >>>?p-i-n, witch is easy to remember because you'll place them on a
> >>>?I have found quite a lot of schematic errors this way.
> >>?I'd like to underscore this. Especially when one is new to
> >>?Protel, and is
> >>?faced with a host of mostly phoney errors, it's tempting to set
> >>?the ERC to
> >>?tolerate open pins and type incompatibilities. And it's a bad
> >>?As to unconnected pins, when you deliberately leave a pin open,
> >>?it is very
> >>?simple to place a No-ERC directive on it. You'll never have to
> >>?look at it
> >>?again. And if you forget to do this, you'll get a warning and you
> >>?can quickly and easily fix it. The large majority of schematic
> >>?errors leave an unconnected pin.
> >>?Years ago, designing with mylar and tape, I had an engineer who
> >>?used to
> >>?take a design and quickly go over it for unconnected pins. Even
> >>?on a complex multilayer design (complex for those days might have
> >>?meant 6 layers), it was easy to see this. And then he'd make sure
> >>?that they were
> >>?all properly unconnected. He'd find the bulk of errors very
> >>?quickly with this....
> >>?As to other errors, many types of pin type combinations will
> >>?generate an
> >>?error with the default matrix. The best solution may be to fix
> >>?the pin
> >>?types, i.e., make, for example, a connector pin be an input or an
> >>?output or
> >>?passive instead of I/O, which doesn't like to be connected to an
> >>?But this is not always practical. so, once again, it's simple to
> >>?No-ERC directives, though in this case I'd wait until running the
> >>?ERC. If it is easy to understand why an error is popping up, it
> >>?may be
> >>?relatively safe to suppress it with No-ERC, but if it is at all
> >>?the safe path is to figure out why the error is happening. You
> >>?might just
> >>?find an error. And once you know, and it is not practical to fix
> >>?it --
> >>?i.e., the error is purely formal -- then it should be suppressed.
> >>?It only
> >>?takes minutes at most to deal with even a host of connector pins.
> >>?The goal is to generate a clean ERC report. Ideally, No-ERC
> >>?markers would
> >>?not be used, but practical reasons make us very glad that the
> >>?exists: at least we have made a conscious decision that a
> >>?particular "error" or warning can be disregarded, and the markers
> >>?allow us to avoid
> >>?having to make this decision with every revision of the schematic.
> >>?The cost of a schematic error can be very high, both in terms of
> >>?money and
> >>?in time-to-market, so it's worth the effort to learn to use the
> >>?error-checking tools to best advantage. In the end, it's easy,
> >>?the difficulty is only in the beginning....
> >>?It's too bad that Protel 99SE does not have editable pin types at
> >>?the schematic level: Tango DOS allowed this.... (In Protel, pin
> >>?types are only
> >>?editable in the Library editor.) What I'd have liked to see would
> >>?have been
> >>?a symbol attribute that is "Allow Pin Electrical Type Edits." If
> >>?checked in
> >>?the library, the pin types would be editable at the schematic
> >>?level. If
> >>?not, they'd be locked. So a connector symbol, generally, would
> >>?have editable pin types. And then the error checking could get
> >>?even better. I'd
> >>?also like to have a way to quickly see the pin type of a pin.
> >>?(Again, this was easy in Tango DOS).
> >>?Has any of this been done in DXP?
> >?* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * *
> >? * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* Forum Guidelines Rules:
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *