Mail Archives: geda-user/2012/12/14/05:28:22
On Fri, 14 Dec 2012, John Doty wrote:
>
> On Dec 14, 2012, at 2:15 AM, gedau AT igor2 DOT repo DOT hu wrote:
>
>> How do you _exactly_ define/calculate network affiliation? That was the original problem for the non-history case, so don't just assume it is solved, solve it.
>
> How about having the user affirmatively declare it before drawing? Touch a known object, or select from list, or type netname (could implement all of these). Prominently display the netname under construction in status somewhere.
Finally, after so many emails, an idea... Let the user tag each object
manually.
This would be a valid solution, but I don't see the benefits. First of
all, it would be very expensive (a single line in gschem often translates
to dozens of objects in PCB). At the end, it could help the user by
remembering user intentions. Unfortunately this leaves many of the
problematic quesitons unanswered. Corner cases:
1. The user loads a new netlist - copper areas totally valid for
connectivty are highlighted as shorts
2. Assume 3 networks, A, B and C; A and B has a long parallel pair of
traces and connects exactly the pins they should (no short); the copper of
C also connects what it should, but it crosses the long parallel lines of
A and B. What should be highlighted and how did the software decide to
get that result? More importantly, how would it be more useful than what
other proposes would highlight?
3. Two networks, A and B, parallel for a long time, then crossover, and
parallel again. Same questions as for 2.
4. How do you handle untagged objects?
By the way this method is already possible on single sided boards using
layers - each net can have its own layer. Most probably because of the
extra effort involved I can't recall seeing anyone doing this, except for
some of the most important/crowded nets (GND, VCC).
>
>> Just highlighting everything what is in short is possible with the old behaviour: press F over a shorted net. This is exactly what we want to refine, as it is not helpful on complex boards.
>
> But of course that doesn't work because there are no primitive objects with known net affinites, so F can't identify the specific points where the problem is. And part of that problem (and to me, a source of great confusion) is a lack of primitive objects in the first place.
Nope. You didn't understand what I said: highlighting too much (everything
that participates in the short), is not helpful, this is my main
statement. If you can put your hatred away for a moment, you will see this
is a theoretical statement, and does not do anything with the actual
software. It applies to your dream-pcb as well.
The second statement was that this theoretical solution, while does not
help, is possible to generate with the current software.
So you either attack the theoretical statement, but then you can't legally
mix in your anti-PCB propaganda, or you attack the second, but that means
you blame the design of the software _because_ it works.
Regards,
Tibor
- Raw text -