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).
>Printed components tend to not have fixed sizes, unless they have fixed 
>values or functions. If one wanted to make an RF choke footprint, one 
>would have to have a separate footprint for each value, with variations on 
>that for various choke parameters.
>Instead, one would provide a wizard for generating such parts; feed the 
>wizard the PCB parameters -- which is already in the PCB file --, type of 
>pattern, desired parameters, and the wizard would attempt to create a 
>pattern that satisfied the conditions. I have in the past been given 
>dimensions for creating series of certain narrowly defined parts, the 
>dimensions came from work with a field solver or other similar programs. 
>(I'm not an RF engineer, but I work closely with one.)
>All this would fit very nicely into the Protel mission, but it is not a 
>simple piece of work.

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:
* 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