Site hosted by Angelfire.com: Build your free website today!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



<x-flowed>
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



</x-flowed>