At 09:18 PM 10/17/01 -1100, Douglas McDonald wrote:
>I put your suggestion to my gerber-speaking colleague and he says that it 
>would be easy to hook up the RS-274X in the manner that you prescribe. His 
>only negative comments were : 1) that the definition files might be 
>different eg one user's definition of "complex-teardrop1" might conflict 
>with another user's defintion and these shapes would have to be defined 
>for each and every library component.

Yes. This is the greatest difficulty in implementing complex padshapes. 
However, I think that my post indicated a solution, which is that the 
complex shapes are stored in the library part simply as ordinary primitives 
and the *extra* primitives for a pad are distinguished by a pad naming 
convention. Free track in a footprint would be treated as at present, 
perhaps, the only change we need with free track is for it to automatically 
connect to the pad instead of having to run Update on it. This latter 
should have been implemented from the beginning. If we put primitives in a 
footprint that contact a pad, we *always* want them to connect.

This still leaves a complication: the calculated layers. I think there is a 
solution for that as well, but I'll leave that for now.

>  2) The "simple" shapes of round and rectangular are not good enough for 
> many of the shapes that he has defined which are mixtures of polygons, 
> lines and arcs as well as round and rectangular.

Of course, this is why one may want to use free primitives. A polgyon, in 
the end, is nothing but a collection of free primitives.

For design ease, we may want to allow polygons in primitives, but they are 
not absolutely necessary. Essentially, a "polygon" is a collection of 
primitives defined by an outline track and a fill algorithm.

Protel, however, should move away from the reduction of polygons to free 
primitives, because it is not as flexible as the RS-274X polygonal fill 
language. In the end, Protel should be able to support full RS-274X 
functionality, which includes both positive and negative elements. But this 
is beyond the scope of the present suggestion, which merely deals with a 
method of providing complex padshaps with a minimum of disturbance to the 
present file structure and program. I don't think that a file structure 
change is necessary at all.

>  3) The DRC speed would inevitably suffer since pads become complex 
> objects - when comparing two ordinary pads there is 1 calculation but 
> comparing two complex objects would be n x m calculations where n and m 
> are the number of primitives in the two pads. There would be equal 
> implications in screen refresh time and some implications in file size.

This is inherent in the use of multiple primitives, and it applies whether 
or not the primitives are part of the footprint or are added later. 
However, since the primitives in contact within a footprint would be 
assigned the same net, DRC time may not suffer as much as it might 
otherwise suffer.

The most simple change we need is one which has already been suggested many 
times: footprint primitives in contact with a footprint pad (withint the 
same footprint) should automatically be assigned identical nets. (If there 
is a conflict as a result, presumably because two pads named separately in 
the netlist are assigned different nets but, in fact, contact each other, 
then, of course, there would be an error reported. It would not be 
necessary to change anything for that and the assignment routines could 
simply function assigning nets according to first-come, first-served, which 
would necessarily leave a DRC error under the present system, which is the 
desired behavior.)

>There are tools which seem to offer all the required functionality while 
>maintaining speed, so it's definitely not impossible to achieve...

That a process takes time is a poor reason for designing it into the 
system. I do think that particularly long processes should have a warning 
dialog with a time estimate. It can be really frustrating to accidentally 
begin a long process -- such as the autorouter, there is a key combination 
which does it which is quite similar to a frequently-used combination, I've 
been bit a few times -- and then be unable to use Protel until the process 
completes and returns control to the keyboard.

But my point here is that computers constantly are getting faster. I'm 
still using a K6-450; I could easily go out and buy a cheap computer which 
is about three times as fast, or more.

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to