Re: gEDA-user: windows testers wanted
Using HP G72 notebook, intel I3, Intel graphics On Thu, Sep 15, 2011 at 12:13 PM, DJ Delorie [1]d...@delorie.com wrote: We're trying to track down the zoom bug. If you have access to a windows machine, please try this PCB snapshot: [2]ftp://ftp.delorie.com/pub/geda-windows/snapshots/pcb-20110915-dj .exe The key thing we're trying to find out is if the zoom bug is XP-specific and/or hardware-specific. Please try zooming and report back: * Version of Windows (xp, vista, 7; 32 vs 64 bit) and mouse type Windows 7, 64 bit, Logitech optical mouse (LX3) * Whether Z/z keys work, and if you have to first click in the work area to get them to work Works fine without clicking first * Whether your mouse scroll wheel zooms (if you have a real scroll wheel) scrolls fine * If zoom/pan bars on your trackpad work (and if it's synaptics - we know that's broken) pans w/ right mouse button. Has a synaptics pad, but no scroll bars so N/A. Pad works like mouse (pan, etc. ok) * If zooming doesn't work, can you still zoom in via the menu (remember to click on the pcb after choosing this) and pan with the scrollbars? Zooms fine from menu One observation. On first run after install, the board outline is centered well past the upper left corner of viewport. Appears to be scaled correctly. Only about 1 cm^2 was accessible until I zoomed and panned it to the center. Joe T Thanks! DJ ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. ftp://ftp.delorie.com/pub/geda-windows/snapshots/pcb-20110915-dj.exe 3. mailto:geda-user@moria.seul.org 4. 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: coordinate systems [was: pcb crooked traces]
...and pcb is the only CAD program I know of, that does like this I've run across other PC layout tools which do this. Mechanical CAD tools usually have (by default) Y+ pointing up, but for some reason PC design tools occasionally have Y+ facing down. I don't remember any of these tools justifying their (less common) choice of convention however. :) Joe T On Wed, Oct 13, 2010 at 3:35 AM, Armin Faltl [1]armin.fa...@aon.at wrote: Andrew Poelstra wrote: On Tue, Oct 12, 2010 at 10:12:41PM +0200, Armin Faltl wrote: Btw. while being a different topic, how about getting rid of the lefthanded coordinate system, when all numeric computations have to be checked anyway? This should make the cs consistent with trigonometric functions. What does lefthanded coordinate system mean? It means, that positive coordinate axes can be generated as follows: looking from Z+ to the center X+ moves into Y+ by a clockwise rotation (for lefthand). Z+ is your extended thumb, then form your fingers to a hook; the finger tips point into the direction of rotation around the thumb. With cyclic permutation look along: Z+: X - Y X+: Y - Z Y+: Z - X A lefthanded coordnate system is the mirror image of a righthanded one, the later being the norm for mathematical formulations, esp. vector notation of rotation. E.g. in polar coordinates P = P(r, phi) the angle phi has to be measured counterclockwise from the X-axis to make the transformation to cartesian coordinates look like: P = P(x, y) = P(r*cos(phi), r*sin(phi)) with X+ pointing right an Y+ pointing up (and Z+ pointing out of screen). This is a convention. One can argue, to define the the sense of rotation clockwise and have Y+ look downward, but this is against the mathematical standard and pcb is the only CAD program I know of, that does like this. It's incompatible with any CAM file format, plotter language, OpenGL etc. Many raster devices and -image formats are lefthanded, probably the reason, why pcb is. Sorry for (partly) repeating myself. ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:armin.fa...@aon.at 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: Color silk layers in pcb
On Sun, Sep 5, 2010 at 2:19 PM, Peter Clifton [1]pc...@cam.ac.uk wrote: On Sun, 2010-09-05 at 00:18 +0200, Levente Kovacs wrote: On Sat, 4 Sep 2010 11:24:38 + Ineiev [2]ine...@gmail.com wrote: Probably this patch may be used as a workaround. Why don't we just push this patch to HEAD? This works just great. One minor nit.. I'd keep the non-copper / skip-drc ideas separate. We might (at some point) have DRC rules for non-copper layers (not that I can think of them at the moment, perhaps apart from silk layer(s)). Otherwise, seems good. 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 [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user If PCB had the concept of a part/element body outline layer (separate from the silk), it could be used as a guide for part placement, not interfere with pads like the silk would, and could be checked with the DRC. Another vote for general, non-copper layers I guess. Joe T. References 1. mailto:pc...@cam.ac.uk 2. mailto:ine...@gmail.com 3. mailto:geda-user@moria.seul.org 4. 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: Sub schematic power rails
On Tue, Aug 17, 2010 at 5:05 PM, kai-martin knaak [1]...@familieknaak.de wrote: Oliver King-Smith wrote: 1) It is useful for seeing the decoupling caps on various components and checking they have been done to spec. 2) Often there are multiple power rails in the schematic, and it is important to see which components are using which power rails both for load and isolation. ack. Maybe my view is tilted because I am an analog guy who sometimes preaches his schematics to newbies :-) ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: [2]http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I completely agree. Most designs nowadays require careful attention to power distribution. Make it obvious where your power is coming from. Joe T References 1. mailto:k...@familieknaak.de 2. http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 3. mailto:geda-user@moria.seul.org 4. 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: gsch2pcb (gnetlist) generates corrupted pcb output
May be unrelated, but I had a problem years ago running from a (samba) SMB share and having the files corrupted. One thing I recall that made a difference was to alter (reduce or turn off) the caching that is normally engaged to improve performance. You may want to experiment with that. Unfortunately, I don't recall which of the (many) config values I played with. Joe T On Fri, Jun 11, 2010 at 3:42 AM, Stefan Salewski [1]m...@ssalewski.de wrote: On Thu, 2010-06-10 at 21:24 -0700, Matthew Lai wrote: Fixed. Sort of. This is very strange. My files were on a SMB share (on another Linux box). Copied it to /tmp, didn't change anything, and both the test case and my original board worked. No idea why... May some automatic character conversion by SMB be a problem, i.e. end-of-line or unicode transformation? You have compiled your gEDA suite yourself -- maybe there is old stuff/ old libs/ old configuration files from earlier versions of gEDA still on your disk? Sorry, I have no better idea. ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:m...@ssalewski.de 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: More flexible rotated text for 1.6.0, font-sizes etc..
Flipping the anchor at 180 degrees rotation is IMHO unwanted and unexpected magic. I think I remember being annoyed by this in the past. What happens when you do this in a batch mode? Can it be reversed? It would be better if the on-screen font size matched the printed size. Legibility of silkscreen would be more predictable. I'm surprised the font is bigger than it claims to be. My experience is the other way around because the font size sometimes defines the cell size that the character fits into (accounting for pitch etc.) rather than the size of the character itself. I'd be leery of automatically bumping the font size if it would make a schematic composed if new and old symbols look inconsistent. If (2) addresses this then it may be ok. Joe T On Mon, Jun 8, 2009 at 6:32 PM, Peter Clifton [1]pc...@cam.ac.uk wrote: Any objections to removing the 0,90,180,270 limits to rotated text? [2]http://www2.eng.cam.ac.uk/~pcjc2/geda/screenshots/gschem_rotated _text.png Need to teach the print output to handle it of course, but that shouldn't be too hard. The only grief comes with the currently magic behaviour at 180 degrees, which basically resets to 0 degrees rotation, and flips the anchor point to the opposite corner of the text box. I'm thinking that it should be possible to seamlessly transform any old schematic which used a 180 degree rotation on load (based on file-format version number). Font sizes give some grief as well. It would be nice if the on-screen font size matched the print font - which means that I drop the magic constant in o_text.c to 1.0 - matching the font's size in points to the requested font size in the file-format. (The old gEDA font is about 1.3x taller than it claims to be). Since auto-magically bumping people's text sizes on load (which will no doubt include some rounding), seems like an evil thing to do, I'm considering the idea of adding a couple of adjustment processes: 1. Within gschem - possibly via some nasty popup dialog / wizard when you load an old file. 2. Command line based - so old designs can be (if desired) batch updated. Or.. we could just declare that we don't really care about updating users' schematics. In any case, I'm tempted to bump the shipped symbol library font sizes - to give consistent before/after on-screen rendering. Or.. do we accept the on-screen shrinkage, and place greater value on consistency of .ps printed output from existing schematics? 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!) ___ geda-user mailing list [3]geda-u...@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:pc...@cam.ac.uk 2. http://www2.eng.cam.ac.uk/%7Epcjc2/geda/screenshots/gschem_rotated_text.png 3. mailto:geda-user@moria.seul.org 4. 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: OT: soldering QFN packages with exposed bottom pad?
I think a few small holes are better than one large one. What you are trying to achieve is a path for heat and maybe flux, but not solder. To get solder to the part, either pre-tin the pad or use paste. Then you are just heating the pad to re-flow the solder. Trying to apply solder from the back risks shorting other pins. You should be able to come up with a footprint (w/vias) that works for hand soldering and doesn't annoy the production soldering process too much. Joe T On Tue, Apr 28, 2009 at 5:33 AM, Stefan Salewski [1]m...@ssalewski.de wrote: On Mon, 2009-04-27 at 22:55 -0500, Bill Gatliff wrote: Guys: Got any recommendations for how to hand-solder a QFN package that has an exposed bottom pad? At the moment, all I have is a soldering iron. Do you think I could just put a plated-through via underneath the pad, and then flow solder through that from the back side? b.g. Hello, I will have the same problem soon, when the layout of my DSO board is finished. Your suggestion plated-through via underneath the pad should work (indeed is does, some people did it). I am not sure if I should make a large hole so that the tip of the soldering fits in it, or only a smaller, which I may fill with a piece of copper wire to conduct heat. The problem is to control/see when the solder flows -- to prevent heating to long. And one problem may be that too much solder may flow in making connections to other pins. And of course fixing the device at the right position is difficult when soldering from the backside. For cheap, small PCB boards heating the whole PCB with a heating plate may be fine, but I do not like to do this with my expensive board. I think I will have to do some experiments... Best regards Stefan Salewski ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:m...@ssalewski.de 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: OT: soldering QFN packages with exposed bottom pad?
Be careful mounting a part like this upside down. If the back side pad on the part is critical to grounding or heat removal (like some switching power supply controllers) you could easily cause the part to malfunction or worse yet, fail altogether. Joe T On Tue, Apr 28, 2009 at 12:15 PM, William Estrada [1]mrumun...@popdial.com wrote: Use a plcc adapter. Or use the dead bug design, glue it upside down to a piece of plastic then solder the wires to the chip. Message: 11 Date: Mon, 27 Apr 2009 22:55:17 -0500 From: Bill Gatliff [2]b...@billgatliff.com Subject: gEDA-user: OT: soldering QFN packages with exposed bottom pad? To: gEDA user mailing list [3]geda-u...@moria.seul.org Message-ID: [4]49f67e25.1010...@billgatliff.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Guys: Got any recommendations for how to hand-solder a QFN package that has an exposed bottom pad? At the moment, all I have is a soldering iron. Do you think I could just put a plated-through via underneath the pad, and then flow solder through that from the back side? b.g. -- Bill Gatliff [5]b...@billgatliff.com -- William Estrada [6]mrumun...@popdial.com Mt-Umunhum-Wireless.net ( [7]http://64.124.13.3 ) Ymessenger: MrUmunhum ___ geda-user mailing list [8]geda-u...@moria.seul.org [9]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:mrumun...@popdial.com 2. mailto:b...@billgatliff.com 3. mailto:geda-user@moria.seul.org 4. mailto:49f67e25.1010...@billgatliff.com 5. mailto:b...@billgatliff.com 6. mailto:mrumun...@popdial.com 7. http://64.124.13.3/ 8. mailto:geda-user@moria.seul.org 9. 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: OT: soldering QFN packages with exposed bottom pad?
If the balls haven't been deformed, the surface tension of the solder does help the part align. It's interesting to see the part get pulled into position as the solder melts. I've seen a switcher chip (can't remember the p/n at the moment) that has on the order of 80 balls, most of which are ground. Both for current and heat sinking. It's a small part, but is able to get rid of whatever heat it needs to as it is switching about 30W @ ~ 400 kHz as I recall. Joe T On Tue, Apr 28, 2009 at 12:58 PM, John Griessen [1]j...@ecosensory.com wrote: I'm going to look into methods of dealing with BGAs in prototypes since Bob's tech says they're less trouble after a learning curve. I've heard and can imagine the way they pull themselves to alignment by surface tension between the grid of chip balls and the grid of lands on the pcb. Do BGAs use zones of balls to dissipate heat? John ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:j...@ecosensory.com 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: OT: soldering QFN packages with exposed bottom pad?
I've done this, but not always with success. First, get some fine solder paste and a flux pen. When you do the layout, put a pad on the other side of the board, connect with a few vias to the part's bottom pad. Be sure to have a solder resist opening on the back side pad. Apply flux to the large pad only, on both sides of the board. Then paste the pad, both sides. Then place the part. When you heat the back with the iron, the part may want to move. It often helps to tack-solder a couple of the other pads on the QFN (farthest away from the large pad) to keep it from moving. Solder the remaining small pins last. Good luck - Joe T On Mon, Apr 27, 2009 at 8:59 PM, DJ Delorie [1...@delorie.com wrote: Got any recommendations for how to hand-solder a QFN package that has an exposed bottom pad? At the moment, all I have is a soldering iron. Spend $20 and buy a cheap hotplate :-) Not sure what you'd do about solder paste; perhaps put solder dots on the pcb with your iron, add flux, and reflow it. Do you think I could just put a plated-through via underneath the pad, and then flow solder through that from the back side? I've done that as well, but beware you need a pretty hefty iron to generate enough heat to melt the solder. ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 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: more board fab discussion (was Re: Interesting board defect)
I just sent out a board which I had quoted on FR4 and Rogers 4350. The Rogers material was more expensive, but for sure not 4x more. I won't get the boards back for a couple days yet, but I've seen other proto's they did for us (on .031 Rogers 4350 w/ immersion silver plating) and they looked good. The shop we used is Prototron. They have fabs in Redmond WA and Tucson, but I think maybe only the Tucson shop has the Rogers material in stock. I know for sure that it is only the Tucson shop that can do the immersion silver. Joe T On Tue, Feb 17, 2009 at 7:11 AM, Larry Doolittle [1]ldool...@recycle.lbl.gov wrote: Gabriel - On Tue, Feb 17, 2009 at 03:47:10PM +0100, Gabriel Paubert wrote: Did not nee for this, and my RF designs use Rogers' substrates which are much more reproducible than FR4 at frequencies above 2GHz. I'm currently searching for a U.S. fab for prototype quantity of Rogers' boards that doesn't charge 4X what I'm used to for FR4. I have some leads, but a lot of places I expected to be reasonable are not. Have you or others on this list found such a place? - Larry ___ geda-user mailing list [2]geda-u...@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:ldool...@recycle.lbl.gov 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: Trace impedance calculations in PCB
I generally do this kind of analysis separate from my layout tool (PCB or whatever) because many of the other parameters needed for the calculation are not usually tracked or updated by the layout tool (dielectric constant, dielectric thickness, stackup, copper thickness, distance from external conductors, etc.). What would help would be a easy and readable way to extract trace lengths and spacings from PCB, like a distance tool that returns the width and length of a trace section and spacing from another trace section (for differential or CPW lines). Joe T. On 2/12/09, Jeffrey Gregory jagre...@umich.edu wrote: Are there any plans to add trace impedance calculations to PCB? If not, is there an argument against it or just that no one has time and interest? What alternatives do people use? Best Regards, Jeff ___ 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: Newbie -- How to properly associate DNI or Do Not Populate to component
I took a different approach which is a little more work. I added a field to my symbols called loadstatus which I mark for no load, through hole, or blank. Blank is the default, and means a SMT part that is loaded. It's not hard to use gnetlist -g bom2 (if I remember correctly) to slice out this field on your report to the board stuffer. Sort the resulting list to put the no-load parts at the bottom so that they're easy to ignore. I don't like the idea of stepping on the value field since then the schematic loses it's knowledge of what you might want to load at a later date. Be sure to include this field in your attib file so gnetlist grabs it as desired. Joe T On Mon, Oct 20, 2008 at 10:26 PM, Duncan Drennan [EMAIL PROTECTED] wrote: OTOH, if you're just looking for a NO FIT type instruction, where I _do_ want the footprint on the PCB board - just empty, I typically just add the attribute value=NO FIT to that component. The assembly house I use seem to understand what I mean, and didn't complain that it appeared in the XY file used for programing the pick'n'place machine. Or you can just set value=NO FIT (or DNP, DNI, etc.) and delete the relevant lines from the XY file by searching for that termor write a script which post-processes the XY file and removes the DNP lines. ___ geda-user mailing list [EMAIL PROTECTED] [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:[EMAIL PROTECTED] 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: pcb, question to crosshair to grid snapping
On Tue, Oct 21, 2008 at 9:02 AM, Stefan Salewski [EMAIL PROTECTED] wrote: Sometimes the crosshair snaps to center of grid, overlapping grid points, which are in inverse video in this case. But sometimes crosshair snaps to a position close to grid points, but not overlapping. Seems to be not related to mm grid only, similar behavior with mil. For me this is irritating -- but maybe its a feature? Best regards Stefan Salewski Is the crosshair inside of a pad when you notice this snapping behavior? Joe T References 1. mailto:[EMAIL PROTECTED] ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: sot23 diode symbol
I've always handled this by making the symbol and footprint match. In other words - you need a 3-pin symbol to match your 3-pin footprint. There is a NC gschem symbol in the library for this purpose. You do have to be careful of how gnetlist handles the NC net. It should not appear in the netlist given to PCB. Joe T On Tue, Aug 5, 2008 at 9:42 PM, Ed Angie S. [EMAIL PROTECTED] wrote: I know through the years there has been a lot of discussion on this issue but I haven't been able to find the answer to my problem after searching the archives. I'm wondering how to refer to a 3 pin footprint with a two pin schematic symbol as is the case for a sot23 diode. My actual question is probably simple for the experts out there. I've already created a special symbol for a sot23 diode. The actual symbol graphic is a normal diode that has 2 pins, pin 1 and pin3. I believe I need to specify a pin 2 in the symbol textually somehow so that PCB layout software will match its 3 pin footprint to a schematically defined 3 pin device. How do I annotate the gschem symbol for a pin 2 without a graphical entity to assign the pin to. It's a no connect or unused pin so it needs no graphic but the symbol does need to have 3 pins when the netlist is generated for layout. Thanks Ed ___ 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: Ground +5V confusion
How many +5 and gound net connections are there in your design? Joe T On Sat, Jun 14, 2008 at 11:45 PM, Ben Jackson [EMAIL PROTECTED] wrote: On Sat, Jun 14, 2008 at 12:34:55PM -0400, Ian Chapman wrote: I have a ground plane and I keep connecting 5V to it because the rats show up as an orange ring on both. I'm not sure I understand your question. The default color scheme includes a light brownish color for rats, and a true orange for shorted nets so I can't tell which you are referring to. Here's how I route power/gnd: Mouse over a known net (ends of a polarized cap are often easy) and then hit 'F'. This 'finds' the matching nets and turns them bright green. This includes the matching rats. This makes it easy to see which ones to route. If you have the netlist window up, the 'f'ind will also highlight the net in that window. -- Ben Jackson AD7GD [EMAIL PROTECTED] http://www.ben.com/ ___ 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: gschem, selecting multiple symbols problem
I think it has always worked this way. However, it would be nice if there was a filter for the area selection rectangle. Having it default to grabbing only instances of symbols would solve your problem, but there are often times when you might want to grab a bunch of text or attributes and that default would be undesirable. Joe T On Fri, Jun 13, 2008 at 7:54 PM, Stefan Salewski [EMAIL PROTECTED] wrote: I think there is a little problem with multi-selection in gschem 1.4.0: When I do multi-selection by drawing a selection rectangle (holding down left mouse button) it may occur that I get selection of a few symbols (as desired) and get additional, undesired selection of a text attribute of an other symbol. Now I may move the selected symbols, and with a side effect I move the text attribute away. So it may occur that text attributes are moved far away from symbols. I think similar results can occur if one selects a group of some symbols in order to delete them. When I started with gschem I had sometimes symbols with missing value or refdes attributes -- I think this was a result of the above behavior. My suggestion: Multi-Selection-Rectangle should not select a combination of whole symbols and attributes of unselected symbols. Comments? Stefan Salewski ___ 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: Converting RS274D to RS274X
Some gerber generators and viewers have a means to specify the number of significant digits past the decimal point in their co-ordinates (e.g. X.XXX or something like it). Check to see if that is set correctly. Regarding the hpgl reference - is this a means to convert to the HPGL vector format that many plotters used to use? I've used devices that plot on a resist film as you mention, and also convert to the path programming that a milling machine would use. Filling large copper areas this way can be a little tedious, but it can be really handy for prototyping RF circuits. Joe T On Sun, Apr 13, 2008 at 3:45 PM, Ormund Williams [EMAIL PROTECTED] wrote: On Sun, 2008-04-13 at 17:53 -0400, Dan McMahill wrote: ok, it was easier to find than I thought. google for 'pads-d2x' and you'll find a post to this list from our very own Larry Doolittle. Note that as others have mentioned, there doesn't seem to be a standard aperture list format used with RS274-D. The primary thing you need to do to convert from RS274-D to RS274-X is to take the aperture list that goes with your RS274-D files and turn that into the codes which define the apertures in RS274-X. The other differences between D and X don't really matter because I believe X has all the features of D and then some. First thank you, but needs work. After adding two more aperture types to the script and concatenating the plot data, gerbv loaded it but all I get is a large blob, it seems that the scale of the apertures and the plot data are orders of magnitude different. I also have other files with very different aperture report formats, Oh well... I'll play with it later, thanks again. __ Ormund ___ 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: mainstream GUI guidelines to consider for gEDA tools
On Fri, Mar 14, 2008 at 7:16 AM, John Griessen [EMAIL PROTECTED] wrote: I came across this in a trade magazine, Chip Design, and copy excerpts that suggest what the best of breed tools can do. The author sees the collection of abilities as most valuable, and it seems not to be a copyright conflict to use a similar collection of features, just common sense. The parts in quotes are from Clive (Max) Maxfield's article about Agilent's Advanced Design System 2008 software release: http://www.chipdesignmag.com/display.php?articleId=2011issueId=26 -- Does this sound familiar?, However, the part that really grabbed my attention was the fact that they've completely revamped the ADS graphical user interface (GUI). The reason I'm so interested in this area is that I spend so much of my time fighting with interfaces for other tools that appear to have been created by someone from another planet (or at least, someone who has never actually used the tool themselves). He likes integration and the new three-dimensional (3D) representation, both of which we see GPL methods for on the horizon. By integration, I'm pretty sure he means interprocess communication, (IPC). He says, you control it using the same highly-intuitive usage model as for Google Earth, which confuses me -- I thought it was flat only...but I'm thinking the blender 3D mouse GUI is what he is talking about. He says, Designs can be stretched in the vertical dimension as an aid to seeing what's going on inside the various planes. I like the stretch idea for PCB stackup viewing. He notes, visualization engine also supports the ability to define and manipulate cut-planes. That's a thing that might be tough to code, but if any of the 3D code/toolkits used to make the view supported that, it would be valuable for quickly getting inputs for use by a two-D field solver. I've often wanted the ability to unstack and cut through a PCB design like this. As the article points out, it is only in the last few years that graphics horsepower has allowed the 3D manipulation that this kind of display requires. If PCB could do this (some day) it would be great. So, that's all it takes today to be 5th ranked in EDA. Lest we loose sight of the larger picture... I think it takes a bit more than this. The main strength of ADS has (in my opinion) been its ability to accurately model complex RF an u-wave circuits. It's biggest drawback has been the UI and to some extent the documentation. I'm pleased to see they finally addressed this shortcoming. So, it's not as if making a fancy UI allows you to be 5th ranked but rather that when you make the UI as good as the rest of the tool you can have a 5th ranked solution. (Full disclosure - I've used this program quite a bit in the past as a former HP and Agilent employee.) Joe T John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [pcb] overlapping pin/pad -- won't form thermal
On Mon, Mar 10, 2008 at 5:16 PM, Dave N6NZ [EMAIL PROTECTED] wrote: DJ Delorie wrote: PCB needs first class support for oblong through-holes. Yup. I've talked about a multi-pin before; this is a pin with arbitrary shaped copper/soldermask/etc on each layer. Yes, when you get to multi layer boards you often want a different annulus on inner layers. I think it's time to think about an expansion to the footprint grammar to support more sophisticated pins and also more sophisticated paste specs. -dave Without piling on too much - Expanding the grammar to support inner layer pad outer layer pad would be great. (Would one geometry definition apply to all inner layers?) - Also consider whatever would allow pins (and vias) with no connection to some layers (maybe supporting blind and buried vias in the process?) - Taking this too the limit, consider a shift to a more heirarchical approach which would allow pad definitions to be included in a footprint by reference rather than direct inclusion. (My ignorance of the data structures now used by PCB may be evident here - I don't know how difficult this would be). Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB refdes selection problems... solved
I've seen the same behavior going back several revisions. At some point certain refdes text becomes unselectable. Sometimes restarting the program helps, sometimes I can get it back by turning layers off and on as you describe. A related issue I've seen is that pcb sometimes has a preference for selecting text on the opposite side of the board from the one I'm working on. And having silkscreen text in the area that is not a refdes can also make the selection problem worse. Joe T On Fri, Mar 7, 2008 at 10:31 AM, Traylor Roger [EMAIL PROTECTED] wrote: Guys, Thanks for the ideas and hints. I apparently bumped into something that starting everything to work again. It seems that turning off all visible layers and then silk only enabled me to grab the text. I moved a few refdes, then enabled the other usual visible layers and it now works like before. Strange. Surely there is some subtle bug under this, but characterizing or replicating it would be tough. Whatever, for now, back to work. Thanks for the help. Roger ___ 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: stack overflow with gnetlist -g drc
If your netlist gets large enough you will hit this problem with several of the scheme back-ends. It has been discussed in the list before. I don't remember the exact syntax to fix it, but search the archives for stack overflow 20 and I'll bet you find it. Joe T On Fri, Mar 7, 2008 at 7:13 PM, Kai-Martin Knaak [EMAIL PROTECTED] wrote: An attempt to do a gnetlist -g drc on my current project yields a stack overflow error: /- [EMAIL PROTECTED]:~/geda/DL-strom$ gnetlist -g drc2 strom_0_master.sch -o drc_output.txt gEDA/gnetlist version 1.5.0.20080127 gEDA/gnetlist comes with ABSOLUTELY NO WARRANTY; see COPYING for more details. This is free software, and you are welcome to redistribute it under certain conditions; please see the COPYING file for more details. Remember to check that your schematic has no errors using the drc2 backend. You can do it running 'gnetlist -g drc2 your_schematic.sch -o drc_output.txt' and seeing the contents of the file drc_output.txt. Loading schematic [/home/kmk/lilalaser/geda/DL-strom/strom_0_master.sch] WARNING: Trying to rename something twice: +Ub and +Ub are both a src and dest name This warning is okay if you have multiple levels of hierarchy! WARNING: Trying to rename something twice: -Ub and -Ub are both a src and dest name This warning is okay if you have multiple levels of hierarchy! Backtrace: In /usr/local/geda/share/gEDA/scheme/gnet-drc2.scm: 518: 883 (if (null? list) 0 (let ((comparison #)) (if comparison (+ 1 #) (+ 0 # ... 525: 884 [+ 0 ... 525: 885* [drc2:count-reference-in-list H1 (1C101 1U105 1U104 ...)] 518: 886 (if (null? list) 0 ...) ... 525: 887 [+ 0 ... 525: 888* [drc2:count-reference-in-list H1 (1U105 1U104 1R120 ...)] 518: 889(if (null? list) 0 ...) ... 525: 890[+ 0 ... 525: 891*[drc2:count-reference-in-list H1 (1U104 1R120 1R117 1C108)] 518: 892 (if (null? list) 0 ...) ... 525: 893 [+ 0 ... 525: 894* [drc2:count-reference-in-list H1 (1R120 1R117 1C108)] 518: 895 (if (null? list) 0 ...) ... 525: 896 [+ 0 ... 525: 897* [drc2:count-reference-in-list H1 (1R117 1C108)] 518: 898 (if (null? list) 0 ...) 520: 899 (let ((comparison #)) (if comparison (+ 1 #) (+ 0 #))) 520: 900* (if (defined? #) (string-ci=? refdes #) (string=? refdes #)) 520: 901* [defined? ... 520: 902* (quote case_insensitive) /usr/local/geda/share/gEDA/scheme/gnet-drc2.scm:520:58: In expression (quote case_insensitive): /usr/local/geda/share/gEDA/scheme/gnet-drc2.scm:520:58: Stack overflow \ A run of gsch2pcb on the same schematic is successful. So I suspect it is a bug in gnetlist rather than in my schematic. Anything I can do to help diagnose this illness? ---(kaimartin)--- -- Kai-Martin Knaak http://lilalaser.de/blog ___ 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: pads net list problem
The netlist output is fairly simple and is probably fields separated by spaces, tabs, or commas. What format is he using to read in the file? Is he writing it our as the same format? (.CSV?) I've run into something like this and found that Excel was filtering out extra spaces or putting quote marks around every field that it read in that looked like text. Look at the file in a real text editor if you can, and the filtering or formatting that Excel is doing will probably be obvious. Joe T On Mon, Feb 25, 2008 at 8:05 AM, Steven Taylor [EMAIL PROTECTED] wrote: I have designed a circuit and created a pads netlist to send to the person who is doing my layout. He said that PADS will not accept the netlist file directly. He can get around the problem by first opening the file with Excel and then re-saving it. Then PADS will read it just fine. I will try to get more details about this, but for now, I was wondering if anybody else has run into this problem. Steve -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ 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: sot-23 pin numbers
My recollection is that pins (1) an (2) are on the same side of the package. Number CCW when viewed from top. As DJ said, this seems to be consistent for BJT and FET parts. Diodes are another matter - when the part contains a pair all arrangements are possible :). Joe T On Feb 6, 2008 8:21 AM, DJ Delorie [EMAIL PROTECTED] wrote: Based on my limited experience, I've found that the control (base, gate), power (emitter, source) and output (collector, drain) are always on the same pins on sot-shaped devices, regardless of fet/bjt or p/n. The spec sheets always seem to number those pins the same too, but that doesn't mean that gschem/pcb does. ___ 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: Anybody had luck with QFN64 at PCBExpress et al?
On Feb 2, 2008 11:23 AM, Jeffrey Baker [EMAIL PROTECTED] wrote: Nearly every major part I need for my latest project is packaged in a QFN (or LFCSP as they call it over at Analog Devices). I'm worried because the parts have round leads and Sunstone, the PCB prototype shop, says they can't make radiused SMD pads. Has anyone run into trouble with this, or are square pads OK? Generally speaking the .5mm-pitch QFN seems to be on the edge of or beyond the capabilities of a proto shop like Sunstone, but Sunstone has the best tolerances I've been able to find. -jwb ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I have had one of the Sunstone shops build boards with QFN32 and QFN48 as I recall. Results were pretty good. They had square-ended pads. -Be careful of solder resist floaters due to the little pieces between the leads. Best bet is to remove all resist between pads. -You may want to check your gerber files to see how much solder paste will be applied and check with Sunstone to see if it is sufficient (or too much). Does your pad have a large heat sink pad on the back? If so, you must carefully construct this pad in the footprint (possibly out of multiple squares). Again, check the paste layer. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Silkscreen over pads again
On Jan 17, 2008 11:01 AM, Levente [EMAIL PROTECTED] wrote: On Thu, 17 Jan 2008 12:38:08 -0500 Dan McMahill [EMAIL PROTECTED] wrote: DJ Delorie wrote: This was fixed at one point, such that pcb itself would remove the silk over pins and pads, but I haven't migrated that code into the HID version yet. We changed our minds about this. We changed PCB so that it showed silk over pads if that's what your design calls for, so if you see silk over pads on the screen, you'll get silk over pads on the board. The magic we chose to go with to deal with the fabs that can't handle cuts is to convert all cuts to multiple polygons instead, so that we never have to use cuts or negative layers. That was what we used to remove the silk, and too many fabs didn't like it. Which fab is it? Are they unable to fix the problem themselves? A DRC check for silk on pads would probably be good. In my past life, we always had in house reviews of the gerbers and weren't allowed to send them to a board vendor until there was no silk on the pads Yes. In the other hand however, it may be good to have code in PCB that optionally removes silkscreen from pads. For an example, please see this photo. What you can see is a power transistor, and a thermo-resistor. http://logonex.eu/gallery/tns/c4.html Best wishes, -- Levente http://web.interware.hu/lekovacs I also believe that it would be good if PCB could remove overlapping silkscreen although the fab house I've used seems to be able to do it themselves. I don't get the picture. It looks like a power transistor and a diode, and I don't see obvious silkscreen overlap. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Electronic tube assembly
On Jan 12, 2008 10:18 AM, Dave McGuire [EMAIL PROTECTED] wrote: On Jan 12, 2008, at 10:11 AM, Dan McMahill wrote: This is very off topic, but I think one who likes tubes should visit this site. http://paillard.claude.free.fr/ I don't speak french, but that video is really cool! That is BEYOND cool. I so want to be able to do that! Building simple tubes isn't that difficult, but that guy really does it at a professional level! -Dave -- Dave McGuire Port Charlotte, FL It also appears that he builds a lot of his other components (inductors, housings, etc.), fixtures and jigs, while still allowing for modern components (like good electrolytic caps, and computer fans). Forget the tubes - I jealous of the machine shop! Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: anyone using PCB .xy files?
On Jan 2, 2008 6:31 PM, Dan McMahill [EMAIL PROTECTED] wrote: Is anyone using or has anyone used the centroid files (.xy files) that pcb exports? I'm asking because I just fixed a bug which has been there since the code was first written that flipped everything about the x-axis and also translated it in the y direction by the height of the board. I just fixed that bug, but it makes me wonder if anyone has ever actually used the output. This came up while one of the gerbv developers was fixing up the code for displaying pcb .xy files. If anyone is or has used these files, were there other issues that should be fixed? Thanks, -Dan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I've supplied the .xy files to our board stuffer, in some cases also supplying them hints as to the orientation and origin of the data (especially if the gerber files have a different orientation). They have always figured it out. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Thermal finger width
On Dec 11, 2007 1:43 PM, DJ Delorie [EMAIL PROTECTED] wrote: It currently uses the clearance. I'm not sure which it *should* use, or if we should redesign it to be independently adjustable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Since annulus often scales roughly with the size of the pad/hole, the thermal trace width should be independant of annulus width to give the user the desired level of control. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerbv - not reading format
On Dec 2, 2007 9:08 PM, Julian [EMAIL PROTECTED] wrote: Frank, It looks like the RS274x manual has sloppy code in it. The G04 code in line 1 is supposed to end with a * at the end of the line to signal it is finished (see section on G-codes in the manual). gerbv keeps reading until it finds a *, which made it advance past the FS statement in the next line. If you add a final * to line 1, it should work. Maybe we'll look into adding a fix for this problem and let a carriage return also work to finish out a G code, just to make sure we handle this type of malformed code. Thanks for pointing this problem out. Cheers, Julian You may want to check before allowing a CR/LF to end a command. I recall seeing gerber files many years ago that used fixed length records (80 char or 255 char lines). Hitting a CR/LF before a command was finished wold happen all the time - and be legal syntax. Joe T ___ 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: gEDA for mass production?
... If the industry has its act together enough to make that fully automated, I'd be surprised and pleased. I think that small-quantity prototype assembly doesn't even bother with all that and uses manually-guided pick and place machines. Those would presumably zoom to the coordinates provided in the xy file but then the operator finishes the job with a joystick. Very often they use a vision system that can detect the package boundary and sometimes the pins locations as well. As someone mentioned earlier, the placement origin is usually the part centroid. When the part is not symmetric (e.g. D-PAK) then manual intervention is more likely. Boards that we have had built lately (in runs of 4 to ~ 100) were done in a time frame that would have been impossible if the precess were not mostly automated. Joe T I will know early next year what it takes to actually go beyond the quoting step. ... -- Randall ___ 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 needs alternate grid
On 10/23/07, DJ Delorie [EMAIL PROTECTED] wrote: Only if snap to pin/pad is selected. Otherwise just snap to the nearest grid point. Well, yeah. Are you saying if we're within one grid spacing of one of the defining points for the pin/pad...? I'm just trying to be sure I understand how the current grid snapping works. Specifically, the crosshair snaps to a grid point or the pin center, whichever is closer to the X cursor. No, that was one of the points I was trying to make earlier: The crosshair snaps to a grid point or pin center whichever is closer, but it will snap to a grid point or the nearest defining endpoint of a pad. It will not snap to a *pad* center. (I wish it still did :( .) Joe T So, on average, you have to be within half a grid unit of the pin center to snap to it, but it depends on where the pin center is relative to the grid points. ___ 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 needs alternate grid
On 10/24/07, Kai-Martin Knaak [EMAIL PROTECTED] wrote: On Tue, 23 Oct 2007 19:00:27 -0700, joe tarantino wrote: A subtle point is that the snap to to pins/pads mode used to snap to the center point (midpoint of the line between the two defining points of the pad). Ouups. I was just about to add a feature request. Please add snaping to the middle of lines (in addition to the end points). Was the loss deliberate? As I recall at the time I noticed the change, it was (according to Harry) indeed deliberate. Joe T ---(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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: sloppy rupper band mode
On 10/20/07, Ben Jackson [EMAIL PROTECTED] wrote: On Fri, Oct 19, 2007 at 02:26:49PM +, Kai-Martin Knaak wrote: On Wed, 17 Oct 2007 16:16:23 -0700, Ben Jackson wrote: File a SF bug and point me at it and I'll see about fixing it. done. (ID 1816572) Looking forward to fix for this crippling non-feature, There are a few things going on here: 1) If you move a line or its endpoint: For purposes of rubberbanding, it is considered connected to all of the line segments whose ends overlap the moving line's end(s). The specific issue you report is due to the short diagonal segment being so short that the end lines overlap each other. In fact, a line where both endpoints overlap the moving point (the joining line in your case) won't even necessarily pick the right end of the line. That's easy to fix, but doesn't address the real problem. That appears to be the problem: Either that it is picking the wrong segment or that it is leaving one of the endpoints behind (unpicked) that belongs to the short segment. In the case that Kai-Martin showed earlier in this thread, there are three segments and 4 endpoints in the pick region that must be sorted through. It seems as if one of the endpoints gets dropped. I think you've found the issue with the lines overlapping (i.e. adjacent vertices being closer together than the line width). What about ignoring the line width while choosing the proper endpoint in the case when the endpoints are closer together than one or two line widths? 2) If you move an element and one of the pads touches both ends of a line (easy to do if your line is narrower than the pad and you don't control where it jumps back onto the grid), only one end of the line will move. Now both of these things would be solved if touching both ends of a line just moved the whole segment. Your tiny segment would not stretch, but instead it would remain in the same shape and the other long segment would stretch. Not terrible, not fabulous. For the pad case (or polygon case), this is probably the right thing. Actually, there are many cases (most?) where I think this solution would work quite well. Having an easier way in general to move a segment (or group of segments) while keeping the end points connected would be very handy. Maybe you pick the approach like this: If the endpoints are farther apart than one line width, then pick the nearest one (easy case) If the the pick point is closer to a grid point that lies on the line (or within one grid spacing to a point on the line) and more than one grid point away from both end points, pick up the whole segment. If the line segment is very short (less than one line width and less than 2 grid point spacings long and the pick point is closer to one endpoint than the other by at least one grid spacing then pick the nearest one. (This is the case that fails most often now when it picks up the endpoint on the wrong line or doesn't move all the endpoints). You might have to differentiate between a tiny segment that is shorter than one grid spacing vs. one that is longer than one grid spacing. Quite often I generate these short lines by routing with snap to pins/pads turned on. Then you are almost always guaranteed to cause a tiny segment to occur right at the end (often inside the pad). In this case, if there is a point that is exactly on the pin or pad and the pin or pad is moved, only the line endpoint exactly on the pin or pad should move. (Yes, I realize that this may be difficult to do given the way the data is stored.) For the line case, another alternative would be to restrict the rubberbanding to exactly-connected lines. However, it currently works in your favor if you make a hand-drawn line on-grid to an off-grid line and only overlap without joining using an explicit segment. Does the data structure end up with an entry for the segment that covers the short distance between the on-grid and off-grid point? My preference in this case would be to move the segment (the segment endpoints really) and not any nearby points that are not on grid. This would allow you to stretch the short segment into one that you could later modify. If both endpoints move, you can't modify this intersection without deleting and re-adding things. (This is really a lot like the case I outlined above.) It could also pick one BEST endpoint to connect to (closest eg, although the data structures are not really set up for this), but perhaps someone really cares about a 3+ line intersection case. It could ignore points that are (perhaps exactly) connected to segments that are already going to rubberband, on the theory that one continuous line should only move one point. This is also tricky because we don't know what order we'll see the lines (and the data structures are again not helpful). The 3+ line intersection case would be farther down my list. I don't encounter that too often unless I'm building up
Re: gEDA-user: [pcb] query about move to other side
On 7/31/07, DJ Delorie [EMAIL PROTECTED] wrote: When an two-pin element is mirrored to the other side, it would be nice if the pins stay in the same spot on the board, regardless of the element's orientation (currently, the pins get swapped if the element is vertically-oriented). Does this mean that the mirroring is about the x-axis by default? Likewise, when a selection is mirrored to the other side, it's mirrored around the midline of the board, not the location of the cursor. I'm thinking we can try to apply some smarts to the mirroring code, but only if we redesign it all to keep track of the mirror point instead of just some Y offset. But exactly how does the user expect it to work? 'm' - mirror element under cursor. 2-pins (or N inline pins) are an easy guess, but what about DIP packages? Should packages mirror about their centroids (i.e. the pins end up in the same exact spots for N-inline), or mirror about the cursor location? If you are mirroring one element, use it's origin. This is *usually* pin 1 for through hole elements, or centroid for surface mount. If the mark is displayed at the part origin, the user will know exactly where the mirror point is. I would not, for example, want the mirror point to be the centroid if the origin was somewhere else. (Consider the case where you want to mirror more than one part and maintain the positional relationship between them.) If you are mirroring a selection of elements, have it work like it does for a copy buffer operation where the reference point for the copy is set by the user. mirror selection (i.e. multiple elements, traces, etc) - how to guess between Y flip and X flip? Does it always mirror around the cursor point, or around the midpoint of the selection? How do we guess between X and Y flips? You don't. Other packages I worked with in the past allow mirroring about either axis. You add a command but remove lots of ambiguity. Joe T So PCB users, let me know how you think mirror to other side should work! ___ 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] bucket o' patches
DJ, Good stuff! I can see a use for thindraw with ps output. For gerber output however, it makes little sense. Joe T On 7/31/07, DJ Delorie [EMAIL PROTECTED] wrote: Just checked these in, some of them correspond to sourceforge tracker bugs, but I haven't annotated those yet. Feedback on the new drill helper and the swap active when swap board, even when both visible change (before, it only swapped if the back side layer was invisible). ps, gerber - don't honor thindraw ps - fix bug when layer draws arcs first (i.e. drill) ps - change drill helper to be simply a smaller hole. lesstif - when flip, scroll bars flip also. lesstif - protect against empty :command. lesstif - when flip, always swap comp/solder active, even if both visible. When boards are loaded, the component layer is brought to the top and made active. When boards are loaded, the first route style is automatically selected if the old style doesn't happen to match any styles. Fix references to RouteStyleChanged (it's RouteStylesChanged). Call it when :RouteStyle is called. Fixed a bug in flags_to_string where the LOCALREF pcb flag (use local reference for moves) would be discarded. ___ 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: Bug in cvs pcb concerning polygons
On 7/24/07, DJ Delorie [EMAIL PROTECTED] wrote: http://www-nw.uni-regensburg.de/~.grr06742.back.physik.uni-regensburg.de/PCB/GPS_BUG.PCB I reproduced it. If I try to draw a copper rectangle on GND-comp it either doesn't draw one at all or scrambles it in the lower left corner. Smaller areas work fine though. When zooming it sometimes appears again but in the printout it's never right. I get the messages : I've reported this before, but Harry hasn't offered a fix for it. He's the only one who really knows how the clipper works. With sufficient zooming/scrolling, you can make pcb segfault too. I just ran into this same issue when I was displaying a plane layer where a polygon covers most of the board. When there are a lot of perforations in the polygon due to vias and pins I get a segfault after sufficient scrolling. Joe T ___ 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 zoom/panning slow when using copper pour
I've noticed the same thing. Any time planes are shown, the redraw is ~ 10x slower than it used to be. Is this a consequence of the new polygon clipping code? If so, is there a way to turn it off or configure/build so that it isn't being used? What would I lose? I've also seen warning messages from a gerber file viewer (ViewMaster) that complains about malformed polygons. Presumably this due to a polygon which is folded over on itself. Joe T On 7/9/07, DJ Delorie [EMAIL PROTECTED] wrote: Beware that this also affects export, including gerbers. Yeah, not sure if that's a good thing or not ;-) But I was mostly interested in hearing if it were faster, that will help narrow down where the slowdown is. ___ 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
gEDA-user: Stack Overflow in gnetlist
Per the instructions, I often run gnetlist -g drc2 to check my schematics. I've noticed recently that I get a stack overflow message shortly after it has read in all the files. It still produces the drc output, but without any clue as to what caused the stack overflow. The overflow seems to be tied to the size of the input data. My design covers 7 schematic pages. If I load only 3 or 4 of them there is no stack overflow message (although I'll get errors about unconnected nets - as expected). Loading all 7 pages produces the error. Running gnetlist with -g PCB or any of the other back end processing options I've tried does not produce the message. The netlists I get out appear to be correct. Any hints as to where this is occurring? Thanks - Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How's my footprint?
I've used this part and several others in the same package. My $.02 worth... - I would also recommend using the .01 mil resolution co-ordinate syntax. - My experience is that most shops like the part co-ordinate origin to be the centroid, not on pin 1. I've also had problems setting the mark or at least always seeing it, but you should place the origin at the centroid regardless. - Regarding the copper clearance - you can probably default it - especially if there is no outside layer ground plane. I would not default the solder mask opening however. These leads are close together. If your pin spacing would result in thin slivers of resist between pins you should explicitly set the solder mask openings to that they overlap. Having no resist between pins is actually preferred over having a sliver of mask floating around and landing on some other pad where it doesn't belong. (I've heard this from several fab shops.) - Another hint. Consider connecting Vin to a really large trace or piece of copper. This will help in reducing the temperature rise of the part - this package has very high thermal resistance. Joe T On 6/2/07, Steve Meier [EMAIL PROTECTED] wrote: Bert, A high end (Diamond Quality) fab and assembly shop uses the ascii file to program their flying probe tester. There is an existing standard which I have an example off at the office which is based upon the pads file format. If you are interested I can probably get you an example early next week. Steve Meier L.J.H. Timmerman wrote: Hi Steve and all, So if I understand this correctly, you are asking for someone to write an exporter for pcb which outputs a file with XY-values of pads(pins) with an ID-reference to be able to check for copper conductivity etc. and maybe even frequency related impedance/capacitance (nelma ?). Something like (a csv file): example #Id X Y top/bottom C1-1,100.50,50.20,top C1-2,100.50,50.25,top /example or example #refdes pad X Y top/bottom C1,1,100.50,50.20,top C1,2,100.50,50.25,top /example Or does a defacto standard format already exist ? Together with a netlist of connecting traces this would give enough information for testing conductity in an automated fashion. I think the BOM/XY exporter would be a good candidate to be extended for this functionality, as it already calculates all the XY values of pins/pads in some fashion. Hmm, I should probably X-post this one to geda-dev. Just my EUR 0.02 Kind regards, bert Timmerman. On Fri, 2007-06-01 at 21:54 -0700, Steve Meier wrote: [snip] This is an issue that we need to address as board shops that have the ability to do point to point probing are asking for files that define the locations of each pad. Steve M. ___ 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: thermal vias in pcb
On 3/7/07, Peter Baxendale [EMAIL PROTECTED] wrote: On Tue, 2007-03-06 at 22:02 -0800, Dave N6NZ wrote: What is the easiest way to create thermal vias? Not a via with a thermal relief -- I can do that :) .. but a via with no thermal relief punched into polygons on both sides of the board that ends up getting filled with solder to help create a large thermal mass to be used as a heat sink. I thought you just put a thermal relief on the via and then shift clicked on it to cycle through to the one with no relief. Or isn't that what you meant? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Depends on how new your version of PCB is. Peter's suggestion is appropriate for recent releases since this feature was added not too long ago. I'm running 20060822. If Dave is using an older version, then my suggestion is appropriate. Joe T ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: thermal vias in pcb
I use a number of parts with backside thermal pads. Draw the rectangle as you describe to comfortably surround the vias. Then with the mouse over the rectangle hit 's'. This will flood the thermal reliefs on the vias. If you want to ever de-solder the part from the back, make sure the pad on the opposite side has the solder resist cleared. Joe T On 3/6/07, Dave N6NZ [EMAIL PROTECTED] wrote: What is the easiest way to create thermal vias? Not a via with a thermal relief -- I can do that :) .. but a via with no thermal relief punched into polygons on both sides of the board that ends up getting filled with solder to help create a large thermal mass to be used as a heat sink. The application I am targeting is surface mount motor control and voltage regulator IC's. So, a typical part will have a large bottom contact that is to be connected to large pad in the footprint. Then, on the front and the back, as convenient, there are polygons that are also part of the ground plane, the top one overlaps and contacts the footprint pad. Now, the trick: there is a field of small holes drilled into the polygons, with *no* thermal reliefs. Drill size is chosen such that the vias wick up lots of solder and you end up with a nice metal mass. See Freescale Ap-Note AN4005. So, anyway, should I specify some kind of pin with clearance smaller than the pad? How can I keep pcb's DRC from whining? I'm sure the answer is simple but I'm not sure how to approach it. TIA, dave ___ 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 missing grid on far side?
Werner, Dan, ..Seems like the original issue I asked about got lost in this thread...What I see is that the problem with the grid not being drawn is repeatable. Any clue as to where this might be happening? Werner asked if this should be submitted as a bug so it can be tracked. Should it?Thanks,JoeOn 9/26/06, Werner Hoch [EMAIL PROTECTED] wrote:Hi Dan,it compiles now. See below.On Tuesday 26 September 2006 18:04, Dan McMahill wrote: Werner Hoch wrote: unfortunatly not: checking for gdlib-config... /usr/bin/gdlib-config checking for libgd cflags... -I/usr/include checking for libgd libs... -L/usr/lib64 -Wl,-rpath,/usr/lib64 -L/usr/X11R6/lib64 -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -lgd checking gd.h usability... yes checking gd.h presence... yes checking for gd.h... yes checking if GIF output from the png HID is desired... no checking if JPEG output from the png HID is desired... no checking if PNG output from the png HID is desired... yes checking for gdImagePng... no configure: error: Your gd installation does not appear to include PNG support. You may need to update your installation of gd or disable PNG export with --disable-png error: Bad exit status from /var/tmp/rpm-tmp.38962 (%build) could you send me the complete config.log (either to the list or privately)? here is the relevant section of config.log:--configure:8681: $? = 0configure:8684: test -s conftest.oconfigure:8687: $? = 0configure:8697: result: yesconfigure:8701: checking gd.h presenceconfigure:8711: gcc -E -march=i586 -mtune=i686 -fmessage-length=0-D_FORTIFY_SOURCE=2 -O2-I/usr/X11R6/include -I/usr/include conftest.cconfigure:8717: $? = 0configure:8737: result: yesconfigure:8772: checking for gd.hconfigure:8779: result: yesconfigure:8813: checking if GIF output from the png HID is desiredconfigure:8824: result: noconfigure:8950: checking if JPEG output from the png HID is desiredconfigure:8961: result: no configure:9088: checking if PNG output from the png HID is desiredconfigure:9106: result: yesconfigure:9116: checking for gdImagePngconfigure:9173: gcc -o conftest -march=i586 -mtune=i686-fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -I/usr/include -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2-I/usr/X11R6/include -I/usr/includeconftest.c -lfl -lm-L/usr/lib-Wl,-rpath,/usr/lib -L/usr/X11R6/lib -lXpm -lX11 -ljpeg -lfontconfig-lfreetype -lpng12 -lz -lm -lgd-L/usr/X11R6/lib 5 /usr/lib/gcc/i586-suse-linux/4.0.2/../../../../i586-suse-linux/bin/ld:cannot find -ljpegcollect2: ld returned 1 exit statusconfigure:9179: $? = 1--The checking for gdImage... requires the libjpeg-devel rpm which was not in the buildrequires of the rpmspec-file yet.The compilation works now.Thanks for pushing me into the right direction.regardsWerner___ geda-user mailing listgeda-user@moria.seul.orghttp://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: Duplicate pull-down menu buttons in gschem
Ales,I didn't make a copy of the system-gschemrc file, but a previous installation did - and this was indeed the cause (good call!). This of course leads to the obvious question: How do I customize settings for the gschemrc file? If duplicating (some of) the initialization from system-gschemrc breaks things, what is the recommended approach? Is there any guidance regarding which keywords I can safely re-define in my local rc file? On a related note, the checking of GEDADATA and GEDADATARC could be more robust. If GEDADATA is defined but empty, gschem won't start.Thanks,JoeOn 9/26/06, Ales Hvezda [EMAIL PROTECTED] wrote: [snip]Across the top of my gschem main window I see two sets of labels for thepull-down menus:File Edit . Options Help File Edit .. Options HelpOnly the right hand set is sctive.The left hand set just brings up a little box which brings up a tiny X window when I click it.That doesn't sound/look good.Could you post a gschem.log filethat is created when you run gschem?Running on SuSe 9.3, gEDA/gschem version 20060906How did you install this?You don't by chance copy system-gschemrcfile to ~/.gEDA/gschemrc or a local gschemrc file?-Ales ___geda-user mailing listgeda-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
gEDA-user: PCB missing grid on far side?
I don't recall seeing anyone mention this...The grid disappears when I view the back side of the board. Changing the grid size, color, or toggling it on and off don't seem to help.I'm using the 20060822 snapshot under SuSe 9.3Thanks,Joe ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB missing grid on far side?
DJ,I picked up the rpm that Werner put together a few weeks ago. I presume that it is the gtk hid based on where it came from and it's similarity to what I was running (which was gtk). Any hints for a non-developer such as myself how to tell for sure? Thanks,JoeOn 9/25/06, DJ Delorie [EMAIL PROTECTED] wrote: The grid disappears when I view the back side of the board.Changing the grid size, color, or toggling it on and off don't seem to help.Which hid?Lesstif or gtk?___ geda-user mailing listgeda-user@moria.seul.orghttp://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 missing grid on far side?
With this install, the binary landed in /usr/bin. It used to be in /usr/local/bin (when I built the previous version from source). And ldd says:... libgtk-x11-2.0.so.0 = /opt/gnome/lib/libgtk-x11-2.0.so.0
(0x40055000)libgdk-x11-2.0.so.0 = /opt/gnome/lib/libgdk-x11-2.0.so.0 (0x4031d000)...(among other things)So is the missing grid related to what exporters are config'd? The problem is not printing - it's on-screen.
JoeOn 9/25/06, Werner Hoch [EMAIL PROTECTED] wrote:
Hi Joe and all,On Monday 25 September 2006 21:27, joe tarantino wrote: I picked up the rpm that Werner put together a few weeks ago.I presume that it is the gtk hid based on where it came from and it's
similarity to what I was running (which was gtk).Any hints for a non-developer such as myself how to tell for sure?The compile options are:%build%configure --with-exporters=bom gerber ps
%{__make}I've disabled only the bitmap export (png, ...) of pcb due to thecrashes on SuSE 10.1 and build problems on 9.3 and 10.0.As the default hid is gtk, Joe has the gtk version.regards
Werner___geda-user mailing listgeda-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: Fiducial
Another version you might try - uses the newer pcb file format:--Element[ Fiducial mark, no drill, .050 diameter pad FID 116000 354000 2000 2000 0 80 ] ( Pad[-1 0 1 0 5000 5000 1 1 ] ElementArc [0 0 7500 7500 0 360 1000] )-- This one has a silkscreen circle around it. Put this part (which I call FID) in whatever directory you use for local symbols, which may be something like:pcb-install-directory/newlib/your-local-symbols/FIDJoe On 9/12/06, Xtian Xultz [EMAIL PROTECTED] wrote: Well, I am still using the last Xaw version of pcb, but here is my symbol forfiducial:Element[0x715000 634500 6500 2000 0 100 0x](Pad[0 0 0 0 6000 2000 12800 F1 1 0x] )Works fine... I use the dimensions from a document that a assembler firm sentto me, I checked out some other documents explaining about fiducialdimensions, and all was about the same.I think this one would help. ___geda-user mailing listgeda-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
