Re: gEDA-user: New autorouter high effort mode
On Fri, Nov 26, 2010 at 6:10 PM, Hannu Vuolasaho vuo...@msn.com wrote: And yes, I'll make a change before my next commit so that optimisation for minimum vias is also possible. Beatiful. I so see how one takes all the PCB files, exports jpg and makes them video. Very hot stuff in product presentations for management what has been done before the prototype is given to hand. BTW Did autorouter its job finally and got all nets traced? Yes :) http://commons.wikimedia.org/wiki/File:HighEffortDemo3.ogv I've also pushed a new commit to git that adds the option to optimise for fewest vias instead of shortest tracks. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Peter Clifton wrote: So.. please fetch git HEAD PCB and play with things. Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia quadro, closed source driver. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. Also tried the same set of benchmark tests with other layouts. Thin draw poly is always at a comparable speed. Full poly mode is faster with the 2009 gtk version. For current pcb HEAD full polygon mode is significantly slower. For some boards only half the FPS. Others achieve 2/3 the frames of thin draw. ---)kaimartin(---(needs to do some real solderiung now...) (*): Still not comfortable with the git commands. How do I make absolutely sure to have the correct branch activated? -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Peter Clifton wrote: I wonder if I'm holding onto a resource of which the card only has a limited supply. Did this happen with the before_pours branch, or just the local_customisation_no_pours one? With before_pours. Something changed over night: Now I can run two instances of pcb-GL just fine. But if I load a third one, everything gets really sluggish. This happens with both before_pours and with no_pours. This was reproducible. Maybe, yesterday some graphics card resources were in use elsewhere. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: mirrored footprint
Rick Collins wrote: However, if you use an auto router, how do you tell it to ignore the bottom pads? switch off the bottom layer while auto routing. I guess you can edit the footprint to remove the bottom pads, just leaving the top pads, In pcb thru hole pads are complex objects called pins. These are hard coded to be holes with the same annulus on every copper layer. So you can't selectively remove the bottom pads from a thru hole pin. Currently, the notion of customizable pad stacks is unknown to pcb. Efforts to introduce them would surely be welcome by many users. ---)kaiamrtin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: mirrored footprint
On Tue, Nov 23, 2010 at 9:52 AM, Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Hi. I just hit a legitimate use case for mirrored footprints: Memory chips frequently come in mirrored/not-mirrored versions, needing mirrored foot prints to make high density memory cards. -- http://blog.softwaresafety.net/ http://www.designer-iii.com/ http://www.wearablesmartsensors.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 01:56 +0100, kai-martin knaak wrote: I tried multiple glxgears with closed source nvidia driver on my day job desktop and with the free radeon on my private desktop. Result: The FPS are roughly proportional to 1/n with n beeing the the number of instances. Looks like glxgears instances symmetrically share available resources. With pcb-GL I loose two orders of magnitude for two instances. You are right, with nvidia-drivers-260.19.21 and kernel 2.6.36 I get now about 1070 fps for one instance fullscreen, and for two instances, each occupying half of the screen, 500 fps each. But with two instances still only one of my two cores are working. This is for an 5 years old nvidia card. I think some years ago with older drivers the result for multiple instances was much worse, but I can not check to be sure, sorry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New autorouter high effort mode
On Fri, 2010-11-26 at 15:07 +1100, Stephen Ecob wrote: On Fri, Nov 26, 2010 at 1:50 AM, Hannu Vuolasaho vuo...@msn.com wrote: I'm waiting to see some screencasts (resistor pr0n again) how this is working but I was wondering is it possible to run HE autorouter to optimize vias? Since you ask! http://commons.wikimedia.org/wiki/File:HighEffortDemo1.ogv http://commons.wikimedia.org/wiki/File:HighEffortDemo2.ogv How to you get it to draw updates as the auto-router progresses? PCB's current auto-router does really evil things when you ask it to do that (drawing without the GUI necessarily being in an appropriate state). This is something I'll really need to fix before pushing the PCB+GL code, as we hit _all sorts_ of nasty errors / crashes in various GL libraries if we try drawing whilst the GL context isn't set up. What I'm saying - is that I'll probably end up breaking whatever method you use, but if we can cooperate, I'll try and do it in a way which isn't so hard to 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: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia quadro, closed source driver. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. I'd been developing polygon_speedup with the PCB+GL hid in mind, and that does not use the polgon dicer. (It uses a much faster algorithm to split the polygons up for rendering - although one perhaps not as suited for gerber output). I'm a little surprised that the frame-rate during benchmarking is affected though, as there ought to be a NoHoles cache. Try this. git fetch git checkout -b test_before_polygon_speedup 323a0c52f7dfdaae51fd7ead87373b3dac90be14 (And build that to compare). This should test whether it is my last committed changes polygon_speedup which slowed things down. If it was.. I'll have to take a look. When I built git HEAD PCB before I merged that code, I did notice how glacially slow the rendering was. It is just possible that some other changes since the 20091103 version have caused a performance regression. Not that I'm shouting too loudly, as it might well have been me which caused them ;) There have been 259 commits since 20091103 to today's git HEAD. Lots of regression potential. Might be any of these?: commit 7dc2d854f3e58680577b2bb71cd68b2b769e3025 Author: Peter Clifton pc...@cam.ac.uk Date: Thu Nov 12 23:54:07 2009 + hid/common: Clip no-holes polygon pieces before calling fill_contour This avoids integer overflow in some HIDs (GTK, Lesstif?) when drawing at high zoom level. Such overflow would lead to incorrectly drawn polygons. It is possible that a similar bug could effect thin-drawn polygons, but that has not manifested its-self so far. If we were to clip these in the future, we need to be careful to extend the clip region slightly off-screen, so the outlines are not drawn. Ideally we would clip these vertices using a Sutherland-Hodgman clipping algorithm, then we could simply discard edges which are clipped completely. commit ede7157be717b4cd22e1e51b6045a2ea5f28de26 Author: Peter Clifton pc...@cam.ac.uk Date: Fri Nov 13 01:14:08 2009 + hid/common: Control update of NoHoles cache based on clip region If at least 50% of the bounding box of a polygon is within the clip region, compute the whole NoHoles polygon and cache it for later rendering. If less of the polygon is within the clip region, just compute what we need to draw the piece we've been asked for. commit bbe5aa52e540171a08f905e38468623a0d3f2e1c Author: Peter Clifton pc...@cam.ac.uk Date: Mon May 10 17:40:15 2010 +0100 Fix poly_ContourInContour() test not to return TRUE for touching contours ... (This fix is required for correctness) commit 3d0a8bd1dae0816d364a774bf9b958faf2983ec7 Author: Peter Clifton pc...@cam.ac.uk Date: Tue May 11 15:55:37 2010 +0100 Speed up poly_ContourInContour() test by computing interior point ... (Attempt to mitigate performance impact of previous patch) commit af2f50d4fb838de13dfbb5243e2114c66fefba7b Author: Peter Clifton pc...@cam.ac.uk Date: Wed Jun 2 21:09:51 2010 +0100 Fix node_label() function to work with self-intersection (*): Still not comfortable with the git commands. How do I make absolutely sure to have the correct branch activated? If you do git log, you can confirm with me the git SHA1 of the commit you built from. gitk will show you the commit history graphically, if that helps. -- 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: mirrored footprint
On Nov 26, 2010, at 5:06 AM, Rick Collins gnuarm.2...@arius.com wrote: At 05:05 PM 11/25/2010, you wrote: On Nov 25, 2010, at 4:05 PM, Rick Collins gnuarm.2...@arius.com wrote: At 05:01 AM 11/25/2010, you wrote: I am missing the reason you must mirror the footprints, however. Aren't the pins still in the same orientation they would be with the standard footprint? Since your DIP packages are mounted in the normal-side-up orientation, it seems the pins should be in the right order, unless you have placed the IC on the component side of the board in pcb... ? Yes, the component is at the same position, but traces are on the opposite side of board so something must be mirrored. SMD traces are at component layer. Through hole components have traces on solder layer. Or both of them? Well, you confused me now :-) Maybe I did not have to mirror the footprints. regards, Jan Yes, of course you have to mirror the ICs that you are changing from through hole mount to surface mount. As you say they are on the opposite side of the board from the pads, so now the pads need to be mirrored, unless the software is capable of moving the pads from one layer to the other without changing how they look on the screen. But normally it treats this as moving the part from one side to the other and you have to mirror the footprint to keep pin one oriented correctly. Heck, if it wasn't needed to mirror the footprint, it wouldn't work correctly after you do mirror it. Rick Rick, Carefully look at an so8 and a dip 8 And really explain why you need to mirror a footprint. Because the top side of a dip footprint is identical pinout as so8. (At half of the pitch). Just remove the bottom pads. Another way to think of it, if you took an dip package and made it into a gullwing and soldered it to the dip footprint. You would have vias through the board to that mirrored footprint so that mirrored footprint was put on the wrong side of the board and you had to move it through the layers. Ok, I see that. I was thinking that if you designed a single sided board the component footprint pads would only be on the bottom so that when you flipped them to the top for the surface mount part, they would now be the wrong orientation. I see what you are saying. However, if you use an auto router, how do you tell it to ignore the bottom pads? I guess you can edit the footprint to remove the bottom pads, just leaving the top pads, but I wouldn't find it any harder to design a footprint from scratch that is actually intended for surface mount work. I think the round pad of a through hole part is not the best design for a surface mount part which should have oblong pads. But I guess this is all hand soldered and is likely hobby stuff, so it doesn't matter as much since it is labor intensive anyway. It was a thought experiment not an implementation. If your doing a single sided board put the surface mount components on the same side as the copper traces. In pcb you can flip the board to place components on the other side of the board. Steve Rick ___ geda-user mailing list geda-user@moria.seul.org 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: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: So.. please fetch git HEAD PCB and play with things. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. My favourite demo.pcb, has git HEAD @ 2.9fps, with 20091103 also @ 2.9fps. No change. I'll try yours... pidpeltier.pcb, has git HEAD @ 4.9, 5.5, 5.2 fps with 20091103 also @ 5.0, 5.4, 5.4 fps. I wonder if there is something different about the debian packages? Can you try building from the release tag in git? git checkout pcb-20091103-RELEASE (After your done, switch back to whatever branch you want: git branch (lists branches) git checkout branch_name Alternatively, let me know how you were testing. For consistency, I maximised to full screen and re-adjusted the view with the v key to fit the whole board on the screen. This is cheating slightly I guess, as it guarantees the NoHoles polygons for the whole board will be cached (in later versions), so benchmark will just be testing the rendering routines, and not really polygon computation. Best regards, -- 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: New autorouter high effort mode
On Fri, Nov 26, 2010 at 11:30 PM, Peter Clifton pc...@cam.ac.uk wrote: How to you get it to draw updates as the auto-router progresses? Actually, I disable draw updates during each individual run of the autorouter using the usual LIVEROUTEFLAG + HID_LIVE_DRAWING mechanism. I only update the display when a superior routing result arrives - so display updates are often minutes apart. I update the display from my high effort code in action.c by calling: DeleteRats (false /*all rats */ ); AddAllRats (false /*all rats */ , NULL); ClearAndRedrawOutput (); I also added an extra parameter to the autorouters to conditonally avoid refreshing the rats at the conclusion of each pass, as this results in a display update. PCB's current auto-router does really evil things when you ask it to do that (drawing without the GUI necessarily being in an appropriate state). Yes, but at least the autorouter provides an option to disable live updates. The trace optimiser and rip up all autorouted racks have no option like this, and they run orders of magnitude slower because of their live display updates. I find myself constantly hiding my copper and via layers - which allows them to run at full speed. This is something I'll really need to fix before pushing the PCB+GL code, as we hit _all sorts_ of nasty errors / crashes in various GL libraries if we try drawing whilst the GL context isn't set up. It would be great to have a uniform mechanism for handling display update disabling/enabling for all parts of the code that make lots of fast changes to the layout (the autorouters, trace optimiser, rip up all tracks, ...) What I'm saying - is that I'll probably end up breaking whatever method you use, but if we can cooperate, I'll try and do it in a way which isn't so hard to fix ;) Great! I'm looking forward to using PCB+GL - particularly transparency :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New autorouter high effort mode
Oh, BTW, what are your thoughts for processes threads with PCB+GL ? For my HE autorouter hack I have in mind to fork() off extra processes so that all of my CPU cores can run separate autorouter instances. As HE has an unbounded run time I'm thinking that the main PCB process should simply hang on to the UI to serve occasional display update requests from the other processes, and to kill off the auto routing processes on user command. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: vias clear soldermask
Hello List, I have an question about the vias in pcb. If i would make an area of vias for breakout stuff, and i want to keep the solder mask away from this vias. How can i make that ? is there an way in the gui? or can i add the clear mil in the pcb file with my text editor ? thanxs, Michael ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vias clear soldermask
On Sat, 2010-11-27 at 01:23 +0100, Stefan Salewski wrote: You can increase the solder mask clearance of vias/pins/pads in PCB program: Make the solder mask visible, use solder mask button of layers buttons on the left, then hover mouse over via/pin/pad and press s key multiple times. If you need larger rectangular areas free from solder mask, then you can use special footprints consisting of only one pad, and put that footprint where you want the free area. I did this for my DSO board to get free areas for thermal pads for hand soldering. Wait -- S key seems to be wrong. I have to test, will be back soon... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vias clear soldermask
On Sat, 2010-11-27 at 01:23 +0100, Stefan Salewski wrote: You can increase the solder mask clearance of vias/pins/pads in PCB program: Make the solder mask visible, use solder mask button of layers buttons on the left, then hover mouse over via/pin/pad and press s key multiple times. If you need larger rectangular areas free from solder mask, then you can use special footprints consisting of only one pad, and put that footprint where you want the free area. I did this for my DSO board to get free areas for thermal pads for hand soldering. Sorry, it is the K key. Do not forget to make the solder mask visible before. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
