delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
Date: | Wed, 9 Jul 2014 13:57:13 -0400 |
Message-Id: | <201407091757.s69HvCq0022117@envy.delorie.com> |
From: | DJ Delorie <dj AT delorie DOT com> |
To: | geda-user AT delorie DOT com |
In-reply-to: | <hy3k3tfjgbnf6pe3r6efesvv.1404910483313@email.android.com> |
(message from Peter Clifton on Wed, 09 Jul 2014 13:58:44 +0100) | |
Subject: | Re: [geda-user] pour clearing around pads |
References: | <hy3k3tfjgbnf6pe3r6efesvv DOT 1404910483313 AT email DOT android DOT com> |
Reply-To: | geda-user AT delorie DOT com |
Errors-To: | nobody AT delorie DOT com |
X-Mailing-List: | geda-user AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
> Alternatively, take the view that the variations are infact distinct > footprints. In my blue-sky on the subject, I mentioned a database of selection criteria, and the criteria could be part-specific or project-wide. So if you had a field for "hand-solderable" that selected between normal footprints for reflow, or extended pads for home soldering, you could use that field to select alternate footprints. But that assumes you have a fairly complex database mapping groups of symbols to groups of components which select groups of footprints. *That* I've used before, way back when, but it was a very small database. > OR.. That the variations could (for some cases) be applied in a > mapping / post processing step during CAM export. There's no reason why footprints can't be dynamically generated based on parameters. We started with the m4 library and migrated to a fixed library to better support Windows and the parts library dialog, but if we can come up with a better way of doing it...
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |