Re: gEDA-user: Random thoughts on the future interface of PCB
I've looked at various commercial boards recently, and it would appear that many use negative layers to draw tracking. High power stuff, where practically everything is copper, just with some isolation between regions. The complexity of the polygons which make up these traces would be too prohibitive to use PCB's normal polygon tool. They _look_ as if someone has drawn negagtive traces to split up a plane. should we support that? Negative layers would be awesome. Having the mask as an actual negative layer would also be great, and allow some custom things to be done on with the mask (e.g. exposing copper strips along the edge for chassis/shielding connections) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Random thoughts on the future interface of PCB
On Sat, 2010-12-04 at 11:15 +1100, Stephen Ecob wrote: hid/common/actions.c:269' - Can't see this one myself.. there is no exit path out of that function which fails to free that allocation! hid/common/actions.c:46' - Array of actions persistent over PCB's entire execution. Not a leak hid/common/flags.c:41' - Array of flags persistent over PCB's entire execution. Not a leak hid/common/flags.c:71' - Array of flags persistent over PCB's entire execution. Not a leak hid/common/hidinit.c:171' - Array of hids persistent over PCB's entire execution. Not a leak hid/common/hidinit.c:250' - Array of hid attributes persistent over PCB's entire execution. Not a leak hid/common/hidinit.c:659' - Not a leak as far as I can tell.. returned value should be cached / free'd elsewhere. Seems ok. hid/common/hidinit.c:688' - Think this is ok hid/gtk/gtkhid-gdk.c:352' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-log-window.c:150' - Cached memory allocated for log messages. Not really a leak. hid/gtk/gui-top-window.c:266' - Cached memory allocated for accelerators. Not really a leak. hid/gtk/gui-top-window.c:2997' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-top-window.c:3005' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-top-window.c:3034' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-top-window.c:3042' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-top-window.c:3306' - ??? (Doesn't line up with code in my checkout out branch.. sorry). hid/gtk/gui-top-window.c:3695' - ??? (Doesn't line up with code in my checkout out branch.. sorry). main.c:780' -- Global variable. Not a leak. main.c:790' -- Global variable. Not a leak. main.c:800' -- Global variable. Not a leak. main.c:810' -- Global variable. Not a leak. main.c:820' -- Global variable. Not a leak. misc.c:1704' -- Just a returned value - some caller might be leaking though mymem.c:663' -- Just a returned value - some caller might be leaking though mymem.c:707' -- Just a returned value - some caller might be leaking though parse_l.c:2232' -- Leak in the parser? (Source file: parse_l.l) res_lex.c:1857' -- Leak in the parser? (Source file: res_lex.l) rtree.c:453' -- MIGHT be something leaking r-trees, but could also just be rtree.c:455' some allocated rtrees which are not free'd. Would need to see rtree.c:762' _increasing_ memory usage from these points to be worried. rtree.c:835' rtree.c:992' Would need a back-trace of which code caused the allocation. strflags.c:169' -- Just a returned value - some caller might be leaking though strflags.c:169' -- Just a returned value - some caller might be leaking though strflags.c:171' -- Just a returned value - some caller might be leaking though So, a mix of NOT LEAKS, and might be leaks. We need back-traces of the cases where callers are allocating things repeatedly and not freeing them. Because these are showing up in your DMalloc output as being where memory is allocated (pretty generic routines), we would need a back-trace to see which code caused the allocation before any could be fixed. I believe valgrind is good at detecting leaks! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Random thoughts on the future interface of PCB
Bob Paddock wrote: Rick, I got line breaks. . On Thu, Dec 2, 2010 at 3:02 PM, Peter Clifton pc...@cam.ac.uk wrote: Just thought I'd write some of this down and put it out there. I've spent some time recently thinking way into the future about the GUI / usability for an advanced PCB editing program. Peter, while all of this sounds great, could we fix the collective problems that we have now first? To many of us PCB is used to ship products, preferably today. The Creeping Feature Creacher is a powerful task master. +1 What we really need is good documentation for the Meta Data that contains what a pcb really is. Once MD is documented and abstracted then it should become easy to add any kind of new GUI, Router, Scripting, or just scrap the whole thing and start over. +1 PCB design is a real hybrid of art, precision engineering and black magic. It is only magic for those without documentation, or initiation. +1 Scrap straight line rats in favour of using the topological auto-router? Appology in advance - Peter, so far I thought you are bright ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Random thoughts on the future interface of PCB
On Thu, 2010-12-02 at 16:13 -0500, Bob Paddock wrote: Peter, while all of this sounds great, could we fix the collective problems that we have now first? To many of us PCB is used to ship products, preferably today. Fixing problems is not always fun, especially if one is not really suffering from these problems oneself. So if we can not fix it ourself, we may consider paying other people to do that, in particular if we ship boards and earn money with it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Clearance in fiducials blocking solder paste
I am trying to place down some fiducials with a 40mil round copper center with 88mills of clearance (from the center of the fiducial) and 80 mils of solder mask. I am doing it by using the following command inside my footprint file. Pad [-13188 -15000 -13188 -15000 4000 4800 8000 f1 ] Now when I run the autorouter it only respects the clearance I give for the net type, and not for the fiducials. The other problem is when I generate the gerbers for my file, I get solder paste on my fiducials which is not what I want. Is there a good way of doing this in gEDA? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Clearance in fiducials blocking solder paste
Two notes: 1. Clearance is clearance in polygons, not the line/space rule. 2. Add the nopaste flag to the pad. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Clearance in fiducials blocking solder paste
Is there a way to protect the fiducial? For example I could attempt to ring it with copper. Oliver __ From: DJ Delorie d...@delorie.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Sat, December 4, 2010 11:29:28 PM Subject: Re: gEDA-user: Clearance in fiducials blocking solder paste Two notes: 1. Clearance is clearance in polygons, not the line/space rule. 2. Add the nopaste flag to the pad. ___ geda-user mailing list [1]geda-u...@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Clearance in fiducials blocking solder paste
Ringing it with copper certainly would work. PCB doesn't have a generic keep out feature yet. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
