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/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
