X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Envelope-From: paubert AT iram DOT es Date: Thu, 22 Oct 2015 13:36:35 +0200 From: "Gabriel Paubert (paubert AT iram DOT es) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] A lesson from gnet-makefile Message-ID: <20151022113635.GA16105@visitor2.iram.es> References: <201510220112 DOT t9M1Ccfq013731 AT envy DOT delorie DOT com> <201510220136 DOT t9M1a5Uw015222 AT envy DOT delorie DOT com> <201510220149 DOT t9M1nrIe016145 AT envy DOT delorie DOT com> <20151022023002 DOT GA25952 AT recycle DOT lbl DOT gov> <20151022090751 DOT ecb5bc25c7d968646dea2e85 AT gmail DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -1.0 (-) X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.1776] 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 Precedence: bulk On Thu, Oct 22, 2015 at 12:19:32PM +0200, Kai-Martin Knaak wrote: > Nicklas Karlsson wrote: > > > Yes, only problem with star ground symbol in gschem is how many pins > > it should have. In pcb for many cases it would make sense with one > > common connection point. > > > Last time this topic surfaced on the mailing list the most practical > suggestion was to exploit a pecularity of text in copper: > The connection check of geda-pcb completely ignores letters. Insert a > large "-" and make regular tracks overlap with the character but not > connect to each other. > > This is of course an abuse of a missing feature (connection check of > strings in copper) which might break if/when somebody takes the time > to fix it. But at least it works now. > > And it gives a hint for a second best solution: Add a tag "ignore-for- > connection-check" which can be attached to a track segment. This would > of course also not check for unwanted connections to the tagged > segment. But since it is an explicit localized exception, the risk is > manageable. After all, we live with not connection checked text all > the time... Indeed, having "non-conductive copper" is probably the best solution, it also allows to build some RF structures like directional couplers. Gabriel