On 03.02.2016 07:33, Jeff Barlow wrote:
Actually I have intentionally located two footprints so they overlap.
Only one or the other (not both) are stuffed on a given board. One
board, two different BOMs, two different assembles. Very common trick.
Not really a DRC error. There needs to be a
On 02/01/2016 08:18 PM, jp charras wrote:
> Le 01/02/2016 19:33, Andrew Zonenberg a écrit :
>> Pads on the same net overlapping should not necessarily be a DRC
>> error, consider the case of someone trying to make a D-shaped pad
>> by putting a round one on top of a rectangle. Maybe if they're
Thank you Andrew, that was a good catch!
Regards,
Orson
On 02/01/2016 07:33 PM, Andrew Zonenberg wrote:
> Pads on the same net overlapping should not necessarily be a DRC
> error, consider the case of someone trying to make a D-shaped pad by
> putting a round one on top of a rectangle. Maybe if
Checking for overlapping courtyard areas should be the first task of DRC,
as there is no point checking for any other type of error if parts overlap
(non manufacturable).
But that feature will also need a switch to turn it off on very specific
instances.
Just my $0.02,
Jean-Paul
N1JPL
> On Feb
On 02/02/2016 01:29 AM, Maciej Sumiński wrote:
Ok, then alternatively we should check the courtyard layers for
overlapping. Otherwise it is possible to put two components in the same
place, and that is an error as you will not able to solder both.
Actually I have intentionally located two
On 03/02/16 01:19, Jean-Paul Louis wrote:
> Checking for overlapping courtyard areas should be the first task of DRC,
> as there is no point checking for any other type of error if parts overlap
> (non manufacturable).
> But that feature will also need a switch to turn it off on very specific
>
Le 01/02/2016 19:33, Andrew Zonenberg a écrit :
> Pads on the same net overlapping should not necessarily be a DRC
> error, consider the case of someone trying to make a D-shaped pad
> by putting a round one on top of a rectangle. Maybe if they're not
> part of the same component?
>
Pads on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Apparently most of the run time in processPads() was caused by copying
the RN_NODE_SET "candidates".
I have a one-line patch in my branch
(https://code.launchpad.net/~azonenberg/kicad/drc-patches/+merge/284682)
that changes this copy to a const
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pads on the same net overlapping should not necessarily be a DRC
error, consider the case of someone trying to make a D-shaped pad by
putting a round one on top of a rectangle. Maybe if they're not part
of the same component?
Here's some quick
Apparently the most expensive part is RN_DATA::processPads() that does
collision checks for pads. It handles cases when tracks do not end in
the middle of a pad, or when pads overlap (IMHO this should be caught by
DRC as an error instead, as pointed out at FOSDEM).
If you do not care about mini
On 31.01.2016 21:27, Andrew Zonenberg wrote:
> When working on a board with a lot of pads, terminating a trace on
> a high-fanout net results in a significant (a second or more) hang
> of the entire UI. I haven't yet attempted to figure out what part
> of the code this hang is in.
>
> Steps to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When working on a board with a lot of pads, terminating a trace on a
high-fanout net results in a significant (a second or more) hang of
the entire UI. I haven't yet attempted to figure out what part of the
code this hang is in.
Steps to reproduce:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sounds good. What file/function is that code in? Maybe I can help take
a look at it.
The board is the Ethernet switch module for the MARBLEWALRUS FPGA
cluster (http://redmine.drawersteak.com/projects/marblewalrus/wiki).
Nine 1000base-KX interfaces on
13 matches
Mail list logo
