delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/12/14/23:23:26

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 15 Dec 2012 05:31:36 +0100 (CET)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Find rat lines
In-Reply-To: <1355518375.31713.8.camel@localhost>
Message-ID: <alpine.DEB.2.00.1212150520210.26605@igor2priv>
References: <1355518375 DOT 31713 DOT 8 DOT camel AT localhost>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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


On Fri, 14 Dec 2012, Peter Clifton wrote:

> On Fri, 2012-12-14 at 18:16 +0000, Chris Smith wrote:
>> On 14/12/2012 17:29, Markus Hitter wrote:
>>> Am 14.12.2012 17:58, schrieb Chris Smith:
>>>> The advantage of net
>>>> association is that it can work online -- it can tell the user 'what you
>>>> are doing right now is going to cause a problem' ...
>>>
>>> In other words, assinging a track to a net is sort of a cache? While
>>> answering that other message I came to a similar conclusion.
>>
>> No, I don't think of it that way.  To me it is a fundamental attribute,
>> not just a cache.
>
>
> Personally - I think we should support this too. I _often_ wish to
> assign "net=GND" to a polygon, for example. It would then let you invoke
> actions to auto-thermal pins belonging to the GND net.
>
> I don't think it should be _required_, as I certainly wouldn't use it
> for most of my general signal tracking.
>
> PCB being _aware_ that you're about to short something out is still
> possible, even if you haven't told it what net you are trying to draw.
>
> The smart heuristics can then dig you out of the more complex holes, and
> in general - would be used to pick out the objects which cause shorts.
> (Explicit net tags on any copper here will aid to identify the short
> location more effectively - as per the designer's intentions).
>

I agree, we could support both (if developers have enough time...); that 
variant of the tagging should be choosen that allows floating nets without 
warning (there could be an option to make it more strict).

At the end the user could choose to use tagging only (if everything is 
tagged no other algorithm is ran on shorts), depend on PCB's guess on a 
short (no tagging at all) or a combination (tagging VCC and GND only, for 
example). First touch should be optional - for users who want to do zero 
tagging, it would often cause extra work resolving tags they didn't need.

I can also imagine a different combination of the tools, for the UI, for 
the mixed case. I very often can route more than 90% of the board without 
ever having a short. Actually most shorts I have after I first thought the 
board was ready but figured I'd need to make modifications. PCB could copy 
tagging from existing physical connections (per net or for the whole 
board) when the user wants.

This would allow me to go in a special mixed way: no tagging while heavy 
modification of the board, then teach PCB what I want when I already have 
most of the board in copper and start using tagging from there.

Another thing I realized that in the VCC/GND case I most often have a 
separate layer. Having a "bind this layer to this tag" feature (in 
preferences, where selecting layer groups?) would solve your mixed 
situation with only VCC/GND tagged.

Regards,

Tibor

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019