Re: gEDA-user: Soft and Hard symbols
On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. On Saturday 15 January 2011, Peter Clifton wrote: Not done. Would be nice though - but I'd rate it of similar complexity to a board auto-router. (Not as rigidly constrained topologically, but to do well would require a decent auto-place, and a decent auto-router - even if the rules are different to that used with a PCB). Ah .. but I said and rendering info. Generating a schematic from a netlist without the rendering info, you are absolutely correct. But that's where the rendering info comes in. It tells where to place and route in a portable way. Where does the rendering info come from? Mostly, it would be saved when you convert a schematic to a netlist. That way it is available when you convert it back, so when you make a round trip you get the same schematic you had before. Or, if you made some changes in the netlist you get the schematic with the changes. You might need to move the new stuff for looks, but it would at least be functional. Or, convert one kind of schematic, saving the rendering info in a portable way, and write it out as another kind of schematic. That's the translation facility. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: How to set the margin for printing?
On Mon, 17 Jan 2011 17:43:13 -0600 John Griessen j...@ecosensory.com wrote: On 01/17/2011 12:47 AM, Colin D Bennett wrote: It seems bad to force the drawing to be designed for a specific printer and page (thus margin in paper space units) size. It also seems bad for printers to not print all they are given, when they are given a standard page size they are advertised to print on. You are right; it's unfortunate that printers are usually not physically capable of printing on the entire page for the intended paper size. However, given that this is a widespread restriction, there are really only two options for the printer when you ask it to print a document on a particular size page - it has to scale the image or it has to crop it to the printable area. I think that scaling the document without asking the user's permission first is the worst possible option since many documents must be printed at the scale that the application generates them, and a user might not notice a slightly altered scale until too late (i.e., a PCB layout printed with scale off by 5%... it would be bad to find this out after fabricating the boards and applying solder paste...). So that is my work around. Sorry, I do appreciate you sharing your workaround. I just wanted to point out that this is a serious bug and tailoring drawings to particular paper/margin sizes isn't something that we should have to use long-term. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Tuesday 18 January 2011 01:00:32 John Doty wrote: Example: Create square with solid background. Create smaller circle with hashed background, set to a different colour. Move circle on top of square. Obviously, if z-order is not preserved through save and load, this will be rendered incorrectly. See attached schematic. OK, that's a good point. But there's no easy way to control this in gschem. Is it a feature, or merely accident? Should there be pull forward and push backward commands? Yes, along with to back and to front commands. These are missing features, just like path drawing commands. To me, this is one of those capabilities that's totally utterly useless 99.9% of the time, but can't-finish-drawing-without-it the other 0.1%. If an alternative and obviously-superior algorithm for choosing drawing order was suggested, it wouldn't be a big deal to me. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: .sch primitive ordering [was: Collaborative Development of Boards]
On Tue, 2011-01-18 at 10:00 +0900, John Doty wrote: OK, that's a good point. But there's no easy way to control this in gschem. Is it a feature, or merely accident? Should there be pull forward and push backward commands? It is half and half. It became more useful with the addition of filled paths, and as you suggest - we ought to introduce some user control over the z-order. (Goes to file a feature request about that now). -- 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: .sch primitive ordering [was: Collaborative Development of Boards]
On Tue, 2011-01-18 at 13:03 +, Peter Clifton wrote: On Tue, 2011-01-18 at 10:00 +0900, John Doty wrote: (Goes to file a feature request about that now). https://bugs.launchpad.net/geda/+bug/704407 -- 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: Embedded polygon
On Tue, 2011-01-18 at 00:41 -0500, George M. Gallant, Jr. wrote: The git/compile went fine. Using the newly built pcb gets a segfault [ggallant@firefly pcb]$ pcb phm.pcb Something strange here Segmentation fault (core dumped) Some other pcb projects were able to get loaded but their existing polygons did not display. Creating a new rectangle on the empty ground layer segfaults. System is up to date 64-bit Fedora 13. George On 01/17/2011 03:19 PM, Kai-Martin Knaak wrote: George M. Gallant, Jr. wrote: Is phm.pcb a file you can send me off list? cd into the pcb checkout you made, and type: git rev-parse HEAD Please past\e the returned string, so I know exactly what version you're trying with. -- 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: Collaborative Development of Boards
On Mon, 2011-01-17 at 18:56 -0600, John Griessen wrote: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto-merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... tag for this concept: zone-diff That is a good idea indeed. Could you file a feature request for it please? https://launchpad.net/pcb/+filebug I would have called it spatial-merge ;) John -- 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: Soft and Hard symbols
Peter Clifton pc...@cam.ac.uk writes: On Tue, 2011-01-18 at 16:05 +0900, John Doty wrote: Note that there's a bit of terminology confusion. gschem actually manipulates segments of nets (other tools sometimes call these wires), while net in EE theory is usually a topological whole, where the connection is assumed to be structureless. wires is a useful distinction here, although it sounds like it implies something physical. I'll try to call them net segments from now on. Sometimes a gnetlist backend might wish to request the connectivity of a net (the topological whole). IMO libgeda should be able to provide that. (A library or convenience function if you will). It does not happen very often, but in this point my opinion disagrees with John's, I think. The whole point of libgeda and gnetlist is to express connectivity between pins. Machine-interpreting meaning into the details of the individual net segments is a confusing concept, that should not be encouraged by the tools. If such things need to be expressed, I'd introduce a new type of symbol, and teach the gnetlist backend that needs those semantics to treat both/all connections to that symbol as the same net, but with different attributes. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On Tue, 2011-01-18 at 09:32 -0500, George M. Gallant, Jr. wrote: Peter, I started to remove items until it succeeded. Removed all trace vias. Deleted various components. Attached version segfaults. Remove one more item and it does not segfault but reports: Error while clipping PBO_SUB: 3 [ggallant@firefly ~]$ git rev-parse HEAD fatal: Not a git repository (or any parent up to mount parent ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). You would need to change into the directory where the PCB sources were git clone'd. I got the impression this was the latest development version which was failing for you. -- 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: Embedded polygon
Peter, I got the git development version about 12 hours ago. I would like the embedded polygons. George On 01/18/2011 10:47 AM, Peter Clifton wrote: On Tue, 2011-01-18 at 09:32 -0500, George M. Gallant, Jr. wrote: Peter, I started to remove items until it succeeded. Removed all trace vias. Deleted various components. Attached version segfaults. Remove one more item and it does not segfault but reports: Error while clipping PBO_SUB: 3 [ggallant@firefly ~]$ git rev-parse HEAD fatal: Not a git repository (or any parent up to mount parent ) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). You would need to change into the directory where the PCB sources were git clone'd. I got the impression this was the latest development version which was failing for you. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On Tue, 2011-01-18 at 10:56 -0500, George M. Gallant, Jr. wrote: Peter, I got the git development version about 12 hours ago. Could you cd into the directory where you checked that out and try the git rev-parse HEAD command again please. I would like the embedded polygons. The branch I run doesn't segfault, but I can reproduce the fact that something odd is going on. I'll get back to you if I discover any short-term fix. -- 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: Embedded polygon
On Tue, 2011-01-18 at 10:56 -0500, George M. Gallant, Jr. wrote: Peter, I got the git development version about 12 hours ago. I would like the embedded polygons. I've attached a more minimal test-case, and I suspect it relates to bad clearances / thermals on the headers in that file. If you wish, I could try to reconstruct your design in a way which doesn't break PCB. I also need to file the minimal test-case in order to solve the underlying bug. (PCB should never segfault). -- 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) pcb_polygon_crash.pcb Description: application/pcb-layout ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
Peter, I just redid the git, rebuilt pcb, same results. [ggallant@firefly pcb]$ git rev-parse HEAD 13de8601a39f2ed2a18aca814598f3ebe17ff506 George ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On Tue, 2011-01-18 at 11:17 -0500, George M. Gallant, Jr. wrote: Peter, I just redid the git, rebuilt pcb, same results. I wasn't expecting the result to change (I'm not running git HEAD here, I'm running my OpenGL port, which has different drawing code for polygons, and hence doesn't crash). [ggallant@firefly pcb]$ git rev-parse HEAD 13de8601a39f2ed2a18aca814598f3ebe17ff506 Thanks. I've identified the problem. Basically, the thermal shape around some of your through-hole pins is causing it to crash. PCB's themal shape is producing some horrible illegal geometry for the clearance you have set around the pins. As a quick hack to get you up and running again, search for lines with thermal([0-9]X) in the flags. Make an edit similar to the one here: - Pin[1 0 6000 3000 6600 3800 2 2 edge2,thermal(1X)] + Pin[1 0 6000 2000 6600 3800 2 2 edge2,thermal(1X)] ^__ clearance I think. The problem is that the thermal shape becomes broken for certain large clearance sizes, and that caused PCB to explode. Make a backup of your original work before attempting this! Once you've got it loading correctly, you can determine what sort of clearance you need to give an appropriate looking thermal relief. Notes for developers (should go into a launchpad bug if I can't fix this soon). A fix for this belongs: 1. In src/thermal.c (to avoid producing BROKEN polygons) 2. Wherever the clearance modified - to avoid choosing a bad clearance. 3. Possibly some warning function to note the mistake when loading a PCB with bad clearances. 4. Longer term - do we need to revisit the maths used to create thermal shapes? How do we fix this without risking breaking old designs? -- 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: Embedded polygon
Peter, A clearance of 2731 passes, 2732 crashes. Attached is a more minimalist file. What is required to run the OpenGL port? George On 01/18/2011 11:31 AM, Peter Clifton wrote: On Tue, 2011-01-18 at 11:17 -0500, George M. Gallant, Jr. wrote: Peter, I just redid the git, rebuilt pcb, same results. I wasn't expecting the result to change (I'm not running git HEAD here, I'm running my OpenGL port, which has different drawing code for polygons, and hence doesn't crash). [ggallant@firefly pcb]$ git rev-parse HEAD 13de8601a39f2ed2a18aca814598f3ebe17ff506 Thanks. I've identified the problem. Basically, the thermal shape around some of your through-hole pins is causing it to crash. PCB's themal shape is producing some horrible illegal geometry for the clearance you have set around the pins. As a quick hack to get you up and running again, search for lines with thermal([0-9]X) in the flags. Make an edit similar to the one here: - Pin[1 0 6000 3000 6600 3800 2 2 edge2,thermal(1X)] + Pin[1 0 6000 2000 6600 3800 2 2 edge2,thermal(1X)] ^__ clearance I think. The problem is that the thermal shape becomes broken for certain large clearance sizes, and that caused PCB to explode. Make a backup of your original work before attempting this! Once you've got it loading correctly, you can determine what sort of clearance you need to give an appropriate looking thermal relief. Notes for developers (should go into a launchpad bug if I can't fix this soon). A fix for this belongs: 1. In src/thermal.c (to avoid producing BROKEN polygons) 2. Wherever the clearance modified - to avoid choosing a bad clearance. 3. Possibly some warning function to note the mistake when loading a PCB with bad clearances. 4. Longer term - do we need to revisit the maths used to create thermal shapes? How do we fix this without risking breaking old designs? gg2.pcb Description: application/pcb-layout ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On 01/17/2011 03:19 PM, Kai-Martin Knaak wrote: George M. Gallant, Jr. wrote: I would like to embed a polygon within a polygon keeping clearance between the inner an outer. So far I have succeeded by creating the inner shape first and then applying multiple shapes around it. (..snip..) Is there a better technique that lends itself to easy adjustment? The current development version of pcb includes a new feature polygon holes :-) See the attached screenshot. To get this version of pcb you'd have to download the current source from git and compile it locally. This page describes how to download the source from the git repository [1]http://geda.seul.org/wiki/geda:scm?s[]=git Compile is straight forward: /- git clone git://git.gpleda.org/pcb.git cd pcb ./autogen.sh ./configure --enable-toporouter-output make sudo make install \ If you do this for the first time, you most probably have to install some additional packages from your distro. When in doubt, also install the package that contains the header files, too. On debian/testing I recently needed these additional packages for pcb: autogen autopoint intltool (draws autoconf, automake and autotools-dev ) libdbus-1-dev libgtk2.0-dev (draws 15 more packagesh) x-ttcidfont-conf libgd2-xpm-dev Hope, this gets you started. ---)kaimartin(--- ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user How do I activate the polygon holes? George References 1. http://geda.seul.org/wiki/geda:scm?s 2. mailto:geda-user@moria.seul.org 3. 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: Embedded polygon
On Tue, 2011-01-18 at 11:49 -0500, George M. Gallant, Jr. wrote: Peter, A clearance of 2731 passes, 2732 crashes. Attached is a more minimalist file. What is required to run the OpenGL port? Just a working (and not ancient) OpenGL driver. If glxgears runs, it will probably run. git clone -b pcb+gl git://repo.or.cz/geda-pcb/pcjc2.git More likely to have bugs, but faster: git clone -b pcb+gl_experimental git://repo.or.cz/geda-pcb/pcjc2.git NB: It doesn't crash, but it doesn't render correctly either. You still need to fix the clearances in your design. -- 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: Embedded polygon
On Tue, 2011-01-18 at 11:56 -0500, George M. Gallant, Jr. wrote: See the attached screenshot. Mailing list has scrapped the attachment I think. I don't think there is a better technique for now. Perhaps you could explain what the polygons are to be used for? -- 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: Embedded polygon
On Tue, 2011-01-18 at 16:31 +, Peter Clifton wrote: A fix for this belongs: 1. In src/thermal.c (to avoid producing BROKEN polygons) Actually, it seems ArcPoly () is also producing bad polygons for small angles. (As well as thermal.c asking it to produce some negative sweep arc segments in the extreme case). -- 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: OpenGL branch
On Tue, 18 Jan 2011 18:10:11 + Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2011-01-18 at 11:49 -0500, George M. Gallant, Jr. wrote: What is required to run the OpenGL port? Just a working (and not ancient) OpenGL driver. If glxgears runs, it will probably run. git clone -b pcb+gl git://repo.or.cz/geda-pcb/pcjc2.git More likely to have bugs, but faster: git clone -b pcb+gl_experimental git://repo.or.cz/geda-pcb/pcjc2.git How does the OpenGL branch track with mainline git HEAD? Do you frequently merge from mainline and keep up to date with bug fixes, etc.? I assume if I use the GL branch pcb, any files I work on will still be fully compatible with mainline pcb, right? (i.e., no file format changes, only UI changes) Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OpenGL branch
On Tue, 2011-01-18 at 10:35 -0800, Colin D Bennett wrote: On Tue, 18 Jan 2011 18:10:11 + Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2011-01-18 at 11:49 -0500, George M. Gallant, Jr. wrote: What is required to run the OpenGL port? Just a working (and not ancient) OpenGL driver. If glxgears runs, it will probably run. git clone -b pcb+gl git://repo.or.cz/geda-pcb/pcjc2.git More likely to have bugs, but faster: git clone -b pcb+gl_experimental git://repo.or.cz/geda-pcb/pcjc2.git How does the OpenGL branch track with mainline git HEAD? Do you frequently merge from mainline and keep up to date with bug fixes, etc.? I rebase it fairly regularly. (Rebase, not merge - so you will have to be careful when re-fetching it) I assume if I use the GL branch pcb, any files I work on will still be fully compatible with mainline pcb, right? (i.e., no file format changes, only UI changes) Not for the pcb+gl and pcb+gl_experimental branches. Anything with pours in the branch name is not compatible. Nice features there, but nothing ready to land. -- 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: Embedded polygon
On 01/18/2011 01:13 PM, Peter Clifton wrote: On Tue, 2011-01-18 at 11:56 -0500, George M. Gallant, Jr. wrote: See the attached screenshot. Mailing list has scrapped the attachment I think. I don't think there is a better technique for now. Perhaps you could explain what the polygons are to be used for? I have an analog front end and I would like to isolate the return paths. It does need a direct connect to digital ground (min current) so I put a 10mil bridge between the 2. Also put thru holes so I can cut and repair the bridge as necessary. BTW, my analog design skills are poor so feel free to comment. The board needs to be finished this week. George ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On Tue, 2011-01-18 at 14:15 -0500, George M. Gallant, Jr. wrote: On 01/18/2011 01:13 PM, Peter Clifton wrote: On Tue, 2011-01-18 at 11:56 -0500, George M. Gallant, Jr. wrote: See the attached screenshot. Mailing list has scrapped the attachment I think. I don't think there is a better technique for now. Perhaps you could explain what the polygons are to be used for? I have an analog front end and I would like to isolate the return paths. It does need a direct connect to digital ground (min current) so I put a 10mil bridge between the 2. Also put thru holes so I can cut and repair the bridge as necessary. BTW, my analog design skills are poor so feel free to comment. The board needs to be finished this week. I think the way you've done it is probably the best we can do for now. -- 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: Embedded polygon
On Tue, Jan 18, 2011 at 04:31:15PM +, Peter Clifton wrote: A fix for this belongs: 1. In src/thermal.c (to avoid producing BROKEN polygons) 2. Wherever the clearance modified - to avoid choosing a bad clearance. 3. Possibly some warning function to note the mistake when loading a PCB with bad clearances. Actualy from my experience the OpenGL branch handles this 'correctly' as it renders something and doesn't segfault. 4. Longer term - do we need to revisit the maths used to create thermal shapes? How do we fix this without risking breaking old designs? IMHO there is a glitch in calculating some arcs. And also there is a problem with calculating intersections, but it seems to be fixed in the OpenGL branch. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Embedded polygon
On Tue, 2011-01-18 at 21:19 +0100, Martin Kupec wrote:
4. Longer term - do we need to revisit the maths used to create thermal
shapes? How do we fix this without risking breaking old designs?
IMHO there is a glitch in calculating some arcs. And also there is a
problem with calculating intersections, but it seems to be fixed in the
OpenGL branch.
Here is the crux of the problem for me.
Up until we merged Harry Eaton's clipper branch, thermals were simple
little things like + or X, with square edged fingers.
commit 38f21ae8ac1d1fc673f579f52aa2d5febfa6f9d9
Date: Mon Oct 9 00:35:24 2006 +
The finger width was related to the width of the copper annulus by a
factor specified in the file's Thermal[0.5] directive.
That default of 0.5, sets the width of the thermal finger equal to the
copper annulus.
After the clipper branch, thermal finger width related only to the
clearance of the pin. For many cases, this causes a problem. In
addition, the rounded thermal styles appear to have computed the finger
width incorrectly.
Aside from this, there are still some problems - the ArcPoly function
doesn't appear to do very well for geometries where the hemispherical
caps around the end of the arc intersect with each other.
Also, for some geometries, the thermal cutout (for want of a better
word) ceases to be an arc wrapping around the pin or via, but should
become some radially extending shape.
Perhaps both approaches are wrong. What is the _correct_ (if there is
such a thing) calculation to determine a thermal shape for a given pin
or via?
I've attached my work in progress.
--
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)
From 9e7859fcb7e607602f6d015dd2333ab5ac362191 Mon Sep 17 00:00:00 2001
From: Peter Clifton pc...@cam.ac.uk
Date: Tue, 18 Jan 2011 20:35:08 +
Subject: [PATCH] Fix thermal generation
---
src/change.c | 17 -
src/thermal.c | 38 ++
2 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/src/change.c b/src/change.c
index 9a2e80b..8e6ea63 100644
--- a/src/change.c
+++ b/src/change.c
@@ -440,21 +440,20 @@ ChangeVia2ndSize (PinTypePtr Via)
{
AddObjectTo2ndSizeUndoList (VIA_TYPE, Via, Via, Via);
EraseVia (Via);
+ RestoreToPolygon (PCB-Data, VIA_TYPE, Via, Via);
Via-DrillingHole = value;
if (TEST_FLAG (HOLEFLAG, Via))
{
- RestoreToPolygon (PCB-Data, VIA_TYPE, Via, Via);
AddObjectToSizeUndoList (VIA_TYPE, Via, Via, Via);
Via-Thickness = value;
- ClearFromPolygon (PCB-Data, VIA_TYPE, Via, Via);
}
+ ClearFromPolygon (PCB-Data, VIA_TYPE, Via, Via);
DrawVia (Via, 0);
return (Via);
}
return (NULL);
}
-
/* ---
* changes the clearance size of a via
* returns TRUE if changed
@@ -639,15 +638,15 @@ ChangeElement2ndSize (ElementTypePtr Element)
changed = true;
AddObjectTo2ndSizeUndoList (PIN_TYPE, Element, pin, pin);
ErasePin (pin);
+ RestoreToPolygon (PCB-Data, PIN_TYPE, Element, pin);
pin-DrillingHole = value;
- DrawPin (pin, 0);
if (TEST_FLAG (HOLEFLAG, pin))
{
- RestoreToPolygon (PCB-Data, PIN_TYPE, Element, pin);
AddObjectToSizeUndoList (PIN_TYPE, Element, pin, pin);
pin-Thickness = value;
- ClearFromPolygon (PCB-Data, PIN_TYPE, Element, pin);
}
+ ClearFromPolygon (PCB-Data, PIN_TYPE, Element, pin);
+ DrawPin (pin, 0);
}
}
END_LOOP;
@@ -676,15 +675,15 @@ ChangePin2ndSize (ElementTypePtr Element, PinTypePtr Pin)
{
AddObjectTo2ndSizeUndoList (PIN_TYPE, Element, Pin, Pin);
ErasePin (Pin);
+ RestoreToPolygon (PCB-Data, PIN_TYPE, Element, Pin);
Pin-DrillingHole = value;
- DrawPin (Pin, 0);
if (TEST_FLAG (HOLEFLAG, Pin))
{
- RestoreToPolygon (PCB-Data, PIN_TYPE, Element, Pin);
AddObjectToSizeUndoList (PIN_TYPE, Element, Pin, Pin);
Pin-Thickness = value;
- ClearFromPolygon (PCB-Data, PIN_TYPE, Element, Pin);
}
+ ClearFromPolygon (PCB-Data, PIN_TYPE, Element, Pin);
+ DrawPin (Pin, 0);
return (Pin);
}
return (NULL);
diff --git a/src/thermal.c b/src/thermal.c
index f9dd369..93064f4 100644
--- a/src/thermal.c
+++ b/src/thermal.c
@@ -428,7 +428,7 @@ ThermPoly (PCBTypePtr p, PinTypePtr pin, Cardinal laynum)
{
POLYAREA *m;
BDimension t = (pin-Thickness + pin-Clearance) / 2;
-BDimension w = 0.5 * pcb-ThermScale * pin-Clearance;
+BDimension w = pcb-ThermScale * (pin-Thickness - pin-DrillingHole);
pa = CirclePoly (pin-X, pin-Y, t);
arc = CirclePoly (pin-X, pin-Y, pin-Thickness / 2);
/* create a thin ring */
@@ -436,15 +436,25 @@ ThermPoly (PCBTypePtr p, PinTypePtr pin, Cardinal laynum)
Re: gEDA-user: Embedded polygon
On Tue, Jan 18, 2011 at 08:35:42PM +, Peter Clifton wrote: Up until we merged Harry Eaton's clipper branch, thermals were simple little things like + or X, with square edged fingers. I arrived after that, so I had no knowleadge about previous state. After the clipper branch, thermal finger width related only to the clearance of the pin. For many cases, this causes a problem. In addition, the rounded thermal styles appear to have computed the finger width incorrectly. I think that the current state for non-rounded thermals is OK. It keep the ratio between cooper and empty space the same with growing clearance. There is completly different story with the rounded ones..those get worser with growing clearance. But I have no idea how to do the math correctly(I am into discrete math, not geometry :-(( ). Aside from this, there are still some problems - the ArcPoly function doesn't appear to do very well for geometries where the hemispherical caps around the end of the arc intersect with each other. I don't remember exactly, but when I was investigating the crash I found problem in some function calculating intersections. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
