| www.delorie.com/archives/browse.cgi | search |
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f |
| X-Recipient: | geda-user AT delorie DOT com |
| X-Original-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=googlemail.com; s=20161025; | |
| h=mime-version:in-reply-to:references:from:date:message-id:subject:to; | |
| bh=WIZ5NoY2/Ize2ZKh+D/0nsQpKMnCH+wN5bAjcIhhqOg=; | |
| b=IOjbQwdSD5w2nEHJCIhZA+sMCA5YsWEWoeckgmp1Tdc7rQGc/2XUmwOgF8oY33kylX | |
| H/SgVbkG34lM+gZ36kvdIgkzKsXuGgU28wdirLGlPgxuF0UwtXWQnkEs7b3V7Nr5zYLL | |
| 2vj+WJxsBFiCkZIWsXnJWXKg4NHUE2powaRujFfUY16BGgiM6Lysq9R4pzUFGQDrOgrD | |
| /QlDVy8Lzn6PqaEHP7RBlKjjofvVy8GqkOGlK+kv/v1ATL/Vwyokml4vk1S4u4QelBgE | |
| vxxwczLw/u+HsXW5OaCjgIEeUJPWmF4NpNFMEJYJlkc/6W+SU4wKyZ5xxCw289ZgsW9p | |
| vTBw== | |
| X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=1e100.net; s=20161025; | |
| h=x-gm-message-state:mime-version:in-reply-to:references:from:date | |
| :message-id:subject:to; | |
| bh=WIZ5NoY2/Ize2ZKh+D/0nsQpKMnCH+wN5bAjcIhhqOg=; | |
| b=DEmuiyGge8eO6ynHGzEwVC/N64MJfT2qgeLxa2Q/gRIh6G/RGT3VwP15OPsB26dm8x | |
| 2zy44KtlwBAG6kcaDkkfqhVmJquOJUTe1MJ2AXv83FEq68920B5ub0hMENU2Du/TZ/1B | |
| zZr0KWYNLczz+xg6LNGXMAD/4vebMPH1SBCBrWoE1QhUrC7Cnw1//Z15T4z7uQsmu/GM | |
| 9EN6kp11W8uT37GCNHd67anU+xPlb9C+pHnw5H0wBe2Od+6RcmTrIncVylByxkrRSt0C | |
| hxWYA7cPPTcZzJPSToZ8VqehuqKvuT3TksPP7xjU22Jkiz53bg/zQ5Bgd1d09qk0PaDu | |
| DttQ== | |
| X-Gm-Message-State: | AIkVDXIh6lw115lTq0lGvv9fqsvQbMHtLDvEqfyW845Fon5OGUUNXDH+RiHqD/hLJeFyXDaWqeM72oC/lDGCiw== |
| X-Received: | by 10.55.74.3 with SMTP id x3mr14902305qka.275.1485637999595; Sat, |
| 28 Jan 2017 13:13:19 -0800 (PST) | |
| MIME-Version: | 1.0 |
| In-Reply-To: | <1485636780.3072.196.camel@linetec> |
| References: | <1485607260 DOT 3072 DOT 77 DOT camel AT linetec> <CAJXU7q8k4synABy2rOSbjmcarmZ_TONwKxG7ED9f4mP6jAiwJw AT mail DOT gmail DOT com> |
| <1485629830 DOT 3072 DOT 163 DOT camel AT linetec> <CAJXU7q9GkEOuzakRg3=hU3QVmC_gc=mnsarnUoJfKH3DNwjOcg AT mail DOT gmail DOT com> | |
| <1485636780 DOT 3072 DOT 196 DOT camel AT linetec> | |
| From: | "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> |
| Date: | Sat, 28 Jan 2017 21:13:19 +0000 |
| Message-ID: | <CAJXU7q9EU-7ceNkf0hcZMHgZx+n=dtprOMdRFW-ygTi+g5dswg@mail.gmail.com> |
| Subject: | Re: [geda-user] PCB antenna question |
| To: | gEDA User Mailing List <geda-user AT delorie 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 |
--001a11488a423b205b05472e0d9a Content-Type: text/plain; charset=UTF-8 On 28 Jan 2017 20:55, "Richard Rasker (rasker AT linetec DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote: > For the pcb resistor / inductors, I guess similar could work - > although it is probably desirable to implement within some kind of > "footprint" like construct in order to get the end connection points > tested as a part of the netlist. The above is indeed what I had in mind: a possibility to make some copper traces/shapes invisible for the netlister, combined with one or more normal pins or pads for proper netlist processing. Then again, this introduces the problem of checking the 'no-net' copper for shorts with other traces. In other words: how can be made certain that any connections to this copper are made through the designated pins exclusively? And that's probably just one of several tricky problems to solve when treating not all copper in the same way... Yes, tricky indeed. (And sometimes it might still be useful to extract the netlist as and ohm meter might see it). I had thought it should probably be a DRC error if any no-net copper not in the "footprint" gets touched by features external to the footprint other than the designated pads. The star net case is awkward too, as depending on the width of traces leading up to it (and exact contact points), it isn't clear how "pure" the star connection is. Give it some thought as to how it should behave from a usage point of view.. if it is possible to reconcile that with a clean, consistent data model, all the better. --001a11488a423b205b05472e0d9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma= il_quote">On 28 Jan 2017 20:55, "Richard Rasker (<a href=3D"mailto:ras= ker AT linetec DOT nl">rasker AT linetec DOT nl</a>) [via <a href=3D"mailto:geda-user AT del= orie.com">geda-user AT delorie DOT com</a>]" <<a href=3D"mailto:geda-user@= delorie.com">geda-user AT delorie DOT com</a>> wrote:<br type=3D"attribution"><= blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"><div class=3D"quoted-text"><br> > For the pcb resistor / inductors, I guess similar could work -<br> > although it is probably desirable to implement within some kind of<br> > "footprint" like construct in order to get the end connectio= n points<br> > tested as a part of the netlist.<br> <br> </div>The above is indeed what I had in mind: a possibility to make some<br= > copper traces/shapes invisible for the netlister, combined with one or<br> more normal pins or pads for proper netlist processing.<br> Then again, this introduces the problem of checking the 'no-net' co= pper<br> for shorts with other traces. In other words: how can be made certain<br> that any connections to this copper are made through the designated pins<br= > exclusively? And that's probably just one of several tricky problems to= <br> solve when treating not all copper in the same way...</blockquote></div></d= iv></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes, tricky indeed. = (And sometimes it might still be useful to extract the netlist as and ohm m= eter might see it).</div><div dir=3D"auto"><br></div><div dir=3D"auto">I ha= d thought it should probably be a DRC error if any no-net copper not in the= "footprint" gets touched by features external to the footprint o= ther than the designated pads.</div><div dir=3D"auto"><br></div><div dir=3D= "auto">The star net case is awkward too, as depending on the width of trace= s leading up to it (and exact contact points), it isn't clear how "= ;pure" the star connection is.</div><div dir=3D"auto"><br></div><div d= ir=3D"auto">Give it some thought as to how it should behave from a usage po= int of view.. if it is possible to reconcile that with a clean, consistent = data model, all the better.</div><div dir=3D"auto"><br></div><div dir=3D"au= to"><br></div></div> --001a11488a423b205b05472e0d9a--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |