On 27 January 2011 00:00, Stephen Ecob silicon.on.inspirat...@gmail.com wrote:
So there are several use cases for treating copper as non-connecting:
* low value resistors
* fuses
* low value inductors
* aerials
* contacts for solder switches (eg SPDT in solder)
* Transmission lines
On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote:
The special symbols is supposed to fuse netnames as issued on the
netlist,
not labels on the schematic.
---
If you are also fusing the copper on the board then I would kind of
I was thinking it would be easy to add a notcopper or ignore_me
flag to element pads, but it wouldn't be as easy to make everything
else work nicely with it. Tedious, mostly.
___
geda-user mailing list
geda-user@moria.seul.org
Peter Clifton pc...@cam.ac.uk writes:
On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote:
The special symbols is supposed to fuse netnames as issued on the
netlist,
not labels on the schematic.
---
If you are also fusing the
On 1/26/2011 12:34 PM, Stephan Boettcher wrote:
Peter Cliftonpc...@cam.ac.uk writes:
On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote:
The special symbols is supposed to fuse netnames as issued on the
netlist,
not labels on the schematic.
the footprint defined for the component would be the copper
DRC sees that as a short circuit, not an element.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On 1/26/2011 1:42 PM, DJ Delorie wrote:
the footprint defined for the component would be the copper
DRC sees that as a short circuit, not an element
DRC will complain if pads are touching? Can you create arbitrary shaped
pads? But they can't touch each other
Do you have a way of
Sure, you can use pads to make arbitrary traces in your element. But,
you must also connect the two pins in the schematic, or DRC will
complain about a short circuit. Once the nets are shorted in the
netlist, it's not always easy to figure out which connections go to
which side of your antenna.
On 1/26/2011 1:55 PM, DJ Delorie wrote:
Sure, you can use pads to make arbitrary traces in your element. But,
you must also connect the two pins in the schematic, or DRC will
complain about a short circuit. Once the nets are shorted in the
netlist, it's not always easy to figure out which
I would think the pads of a footprint would not be checked against
one another with the same rules as traces. Is that what you are
saying?
No, I'm saying some pads in a footprint can be marked to be ignored
just for connectivity checking. You still want to do the rest of the
DRC checks to
you must also connect the two pins in the schematic, or DRC will
complain about a short circuit.
Ive had good luck giving multiple coppper pins and pads the same number in the
footprint file.
This only works for pins/pads that overlap. If not PCB will only enforce a
connection to one
On Wed, 2011-01-26 at 18:34 +0100, Stephan Boettcher wrote:
The inductor will end up as a shaped piece of copper tracking, and at
this point, you realise that net is a very DC term!
The inductor could be a subschematic with shorted pins via two short
symbols, with a net in between that
On Wed, 2011-01-26 at 13:33 -0500, rickman wrote:
I guess I am missing something significant with this. Why wouldn't the
inductor just be a component on the schematic and a component in layout
just like any other inductor? The only difference is that the footprint
defined for the
Perhaps I was going a bit far to suggest full DRC for the actual antenna
design. What I really meant was not loosing information for net
connectivity checking leading up the antenna.
Thinking longer term, why not support DRC checking of inductance and
resistance for specially tagged traces ?
On Thu, 2011-01-27 at 08:32 +1100, Stephen Ecob wrote:
Perhaps I was going a bit far to suggest full DRC for the actual antenna
design. What I really meant was not loosing information for net
connectivity checking leading up the antenna.
Thinking longer term, why not support DRC checking
A similar track is component scenario:
PCB fuse track - a dirty trick I've seen in some Honywell boiler
controllers.. where a deliberately thin trace is used to act as a fuse.
That certainly is a dirty trick! (But on a very tight budget it could
make sense).
So there are several use cases
On 1/26/2011 7:00 PM, Stephen Ecob wrote:
A similar track is component scenario:
PCB fuse track - a dirty trick I've seen in some Honywell boiler
controllers.. where a deliberately thin trace is used to act as a fuse.
That certainly is a dirty trick! (But on a very tight budget it could
make
Similar to the last is a jumper location that is connected by copper by
default to be cut if an open is needed. Consider this to be a 1 bit PROM.
Rick
Yes, they're useful. I use them a lot on early revision boards when
the design is still subject to change in some areas.
On 1/26/2011 3:50 PM, Peter Clifton wrote:
On Wed, 2011-01-26 at 13:33 -0500, rickman wrote:
I guess I am missing something significant with this. Why wouldn't the
inductor just be a component on the schematic and a component in layout
just like any other inductor? The only difference is
2011/1/24 DJ Delorie d...@delorie.com:
Perhaps we need a concept of net with more than one name ?
We'd have to define rules for DRC to follow.
Multiple names for a single wire - this sounds like a good solution.
Each gnetlist backend could then provide a net-unification function
to map
I like the multiple names solution. I hadn't run into this issue until
I came across gEDA symbols with hardcoded nets. Not a big issue, I
tend to modify symbols now on a per project basis - so the need to
have two net names for a single wire is much reduced.
John Doty j...@noqsi.com writes:
On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote:
Steven Michalske wrote:
We would also need a way to force the chosen name of the net to choose
when merging nets. e.g. When you merge a net named power with a net
named 3v3_power, who wins?
If a
The special symbols is supposed to fuse netnames as issued on the
netlist,
not labels on the schematic.
---
If you are also fusing the copper on the board then I would kind of
like to see that when I am viewing the schematic.
You want to
Ouabache Designworks z3qmt...@gmail.com writes:
The special symbols is supposed to fuse netnames as issued on the netlist,
not labels on the schematic.
---
If you are also fusing the copper on the board then I would kind of like to
see that when I am
Sometimes I would like to directly connect two nets. There are a
number of different specific cases in which I would like to do this for
simplicity in the schematic. For instance, I might have an input port
component (e.g., input-1.sym) on a connector pin with net VLCD, and
then somewhere else
Colin D Bennett co...@gibibit.com writes:
Sometimes I would like to directly connect two nets. There are a
number of different specific cases in which I would like to do this for
simplicity in the schematic. For instance, I might have an input port
component (e.g., input-1.sym) on a
On Sun, Jan 23, 2011 at 09:25:53AM -0800, Colin D Bennett wrote:
However, after some investigation as to why I wasn't getting the right
rats in 'pcb' after a gsch2pcb import, I realized that connecting two
nets in gschem (using a power symbol and/or an I/O port symbol
connected with a net
On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote:
Stephan Boettcher wrote:
You need to invent some 2-pin symbol with some special attributes, and
teach the pcb gnetlist backend(s) to interpret those attributes
^^^
If there is a way to mark two net-names
On Sun, Jan 23, 2011 at 6:30 PM, John Doty j...@noqsi.com wrote:
On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote:
Stephan Boettcher wrote:
You need to invent some 2-pin symbol with some special attributes, and
teach the pcb gnetlist backend(s) to interpret those attributes
Steven Michalske wrote:
We would also need a way to force the chosen name of the net to choose
when merging nets. e.g. When you merge a net named power with a net
named 3v3_power, who wins?
If a two pin symbol mediates the fusion, this would be determined
by the connections to the symbol.
We would also need a way to force the chosen name of the net to
choose
when merging nets. e.g. When you merge a net named power with a
net
named 3v3_power, who wins?
Steve
The worst thing that you can do is to simply pick one and change all
the others names
On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote:
Steven Michalske wrote:
We would also need a way to force the chosen name of the net to choose
when merging nets. e.g. When you merge a net named power with a net
named 3v3_power, who wins?
If a two pin symbol mediates the fusion,
Ouabache Designworks wrote:
The worst thing that you can do is to simply pick one and change all the
others names to match. Imagine accidently connecting net FOO to a power
grid and having every one of the power labels turn to FOO.
The special symbols is supposed to fuse netnames as issued
John Doty wrote:
But a little more complicated:
net1 net2 net3
---(WP,LP)(LP,WP)-
Is this net1 or net3?
Or an even more pathological case where nets are fused in
a circle...
I'd say, take whatever comes first and issue a warning
On Mon, Jan 24, 2011 at 3:56 AM, Stephan Boettcher
boettc...@physik.uni-kiel.de wrote:
You need to invent some 2-pin symbol with some special attributes, and
teach the pcb gnetlist backend(s) to interpret those attributes as a
net-unification bridge. There should also be a convention how that
On Mon, 24 Jan 2011 13:31:28 +0900
John Doty j...@noqsi.com wrote:
On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote:
Steven Michalske wrote:
We would also need a way to force the chosen name of the net to choose
when merging nets. e.g. When you merge a net named power with a
Perhaps we need a concept of net with more than one name ?
We'd have to define rules for DRC to follow.
I'm thinking the connector net (net with more than one name) can
connect to any of the singleton nets with the same names as one of its
names, but cannot be considered when checking
37 matches
Mail list logo
