Ian and the group,

Shapes, be they spiral, oblong, obtuse, or whatever, are not the issue.

The issue is that an RF Choke is a legitimate device made with a copper
connection of some geometric shape from one point (terminal) to another
point (terminal), which Protel considers to be a direct short and
therefore an error.

Other types of "shorts" have been discussed here in the list in the
past.

I was hoping to entice someone into convincing Protel that they need to
make a provision for a person to be able to design such a footprint, and
tell the program that yes, you know it is a direct short in copper, but
that nonetheless you as a designer need to be able to tell the software
that believe it or not in this case you are smarter than the software
and therefore that as far as this component footprint is concerned,
ignore the short, if for no other reason than I told you so, and use
this component footprint just like any other 2 terminal component
footprint, and don't screw up my netlist, and don't tell me it is an
error, but I could probably live with a warning that I would have to
override when the component was first used.

JaMi Smith


-----Original Message-----
From: Ian Wilson [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 20, 2002 2:38 PM
To: Protel EDA Forum
Subject: Re: [PEDA] RF footprints

On 04:43 PM 20/02/2002 -0500, Abd ul-Rahman Lomax said:

>At 12:42 PM 2/20/2002 -0800, JaMi Smith wrote:
>
>>(Go ahead, ask Protel what
>>an RF Choke is, and how to make one in Protel).
 . . .

 . . .

There are Client Basic macros around to help in laying out spirals -
thanks 
mainly to Brian Guralnick (I think) plus a host of others that added
their 
tuppence worth.  This is but one example of what is possible.  Others
could 
be created to create meanders, transmissions lines with chamfers.... as 
desired.  Client basic is (almost) powerful enough to do this.

Functions such as laying down RF components are best left the users to 
develop rather than Protel trying to add to the core program. Protel, 
though, should ensure that even the simple macro language has some 
reasonable access into the database and the user interface.  The big
gaps 
here in Client Basics access to the database, mostly the lack of a
process 
in PCB to prompt the user to select a location (fixed by a third party 
server), and, in both Sch and PCB, the lack of  access to component
fields 
(currently no server that I know has this capability - but it could
easily 
be provided).

I think that such wizards and servers and macros are best left to the
users 
to create and Protel to concentrate on making the underlying SDK and
core 
processes reliable.

The area of users co-operating on creating macros and servers is one
area I 
think the user community can go much further than it currently does.

Ian Wilson

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to