RE: [PROTEL EDA USERS]: No Net assignments on tracks & vias...

["Terri Rothwell" <TerriR@appliedmicro.com>]

Hopefully, Protel will use some of the features from their new product
AccelEDA.  This is already taken care of there.  If you route a trace to an
unassigned via, it will attach automatically.  For other objects such as
pads, mtg holes etc, you can manually attach a net name with a simple
process.

I'm sure that as time goes on that the two packages will become one using
the best of the two.

Terri

-----Original Message-----
From: TSListServer [mailto:owner-proteledausers@techservinc.com]On
Behalf Of Abd ul-Rahman Lomax
Sent: Friday, September 01, 2000 11:39 AM
To: Multiple recipients of list proteledausers
Subject: Re: [PROTEL EDA USERS]: No Net assignments on tracks & vias...


At 07:41 AM 9/1/00 -0400, Brian Guralnick wrote:

>     I think I'll suggest this addition to Protel.  Does anyone know of an
>email link to someone within Protel where this might get some attention?

Sure. This mailing list. I'm sure that not all of them read it all the
time, but, at least at one point, nearly every Protel employee was a
subscriber to this list. You can also write protelcsc@protel.com.au

(csc stands for Customer Service Center if you want to be able to easily
remember it. I don't know if the .au is necessary, but that is how the mail
comes into this list.)

If enough users express support for an idea on this list, and the reasoning
is cogently expressed, we have seen Protel move very responsively, even
where no comment was ever made here in response. The proof is in the
pudding: the SE release of Protel 99 was truly astonishing in its
implementation of nearly everything we had been requesting.

But if you want a direct response, csc is the place to write. You might get
one.... they've been getting better about that too....

As to the suggestion, it does need more thought.

I'd suggest that when a DRC error pops up which exists because of a No_Net
assignment, there be a quick and simple command to assign the connecting
net to any No_Net copper. If the No_Net primitive is a component primitive,
I'd say that this command should not work; rather net reassignment of
component pad primitives should only take place through the net list or
through deliberately editing the net assignment in the pad dialog.

One more related comment: Non-pad component primitives in electrical
contact with a component pad within the same component should automatically
take on the pad's net. This little change would make our lives quite a bit
easier whenever we need to make custom copper shapes as part of a
component; it would allow us to build complex surface pad shapes, for
example.

If we build parts with connecting copper within them, we will *always* want
this copper to take on the proper net. We should get an error only if
*pads* with differing nets are shorted within the component. One more
refinement: if a no-net pad is shorted by component primitives to a
net-assigned pad *within* the component, likewise the no-net pad should
take on the appropriate net.

marjan@vom.com
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433