Re: gEDA-user: "revert" vs "reload"
On Sep 5, 2011, at 10:49 AM, Peter Clifton wrote: > On Mon, 2011-09-05 at 10:38 -0700, Steven Michalske wrote: >> On Sep 5, 2011, at 9:34 AM, DJ Delorie wrote: > >>> Er, what gtk do the Mac builds use? >>> >> Macports is at 2.24.5 >> Fink is at 2.18.9 >> Homebrew is at 2.24.6 > > Do you happen to know if there are any builds of GTK 3.0 out there yet? > Macports has 3.0.5 Fink and homebrew do not. > -- > 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: "revert" vs "reload"
On Sep 5, 2011, at 9:34 AM, DJ Delorie wrote: > >> I'm also planning on implementing the same behavior in gschem which >> currently depends on GTK 2.10. Any arguments to upping this to 2.18 too? > > Even the Windows builds use 2.20. I'd say, bump configure.ac to need > 2.18 - and do nothing else - and see if anyone trips over it. Then > we'll know if we need to work around it. > > Er, what gtk do the Mac builds use? > Macports is at 2.24.5 Fink is at 2.18.9 Homebrew is at 2.24.6 > > ___ > 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: Fwd: Re: [OH Updates] How can you help solve the proprietary tool problem?
On Sep 2, 2011, at 12:45 PM, Colin D Bennett wrote: > On Fri, 02 Sep 2011 10:18:20 -0500 > John Griessen wrote: > >> Does the category low end bother you? > > Well, I think low-end is not very specific in reality. Does gEDA > really belong in the category of EAGLE, or is it much more powerful? > > Maybe the “low-end” attitude toward gEDA is based on the fact that pcb > doesn't support important features for large and complex boards such as > > - trace length matching, Important in high speed. I recall a serpentine plugin for pcb. +1 to bundling plugins with pcb sources.. > - constraints/routing styles defined at the net level, Important for high speed and power applications > - pushing/pulling PCB traces and better support for moving parts with > traces routed, Nifty, aids layout but often you can't shove those length matched sets anyhow. > - ability to select a component on the PCB by clicking it in the > schematic view, Novice feature Layout engineers have paper schematics with notes taken on them when they met with the EEs who drew the schematics. > - back-annotation to schematic from the PCB editor. Again, back annotation comes from yelling at the EE and telling them that they can't break physics no mater how hard they try! On the other hand for FPGAs and other high pin count devices I suspect that this would be more welcome. Though I think that a tool that mapped the ports and I/Os an stored them in a table. With an option to render to graphical symbols would be better. Nets in schematic assigned to layout placement. Then layout is assisted by assignment tool, kinda like a reverse fanout tool. Then The table in the design is updated. Then graphics and pinmap file get generated. This would cut the iterative process from the desiring of large FPGA parts. > > Just a few things that sound important to me, a novice PCB designer. What is really missing is the support contracts from the high end tools. We need the equivalent of what RedHat is for Linux to be considered a high end tool. > > Regards, > Colin > > > ___ > 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: Fwd: Re: [OH Updates] How can you help solve the proprietary tool problem?
I rarely see my own posts, I turned on post acks. On Sep 2, 2011, at 12:45 PM, Bob Paddock wrote: >> Just for the record, I'm not sure what our moderation policy is. Are any >> of your posts being rejected by moderation? (If so - just what kind of >> emails are you sending? ;)). > > One of the things that changed when the list went moderated, is that I > no longer see my own posts, so I really never know if the reached the > list. Before moderation I'd see my own posts. I assume this applies > to everyone, or at least everyone using gmail maybe? > > > ___ > 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 vs. PCB diode pin numbering
On Aug 24, 2011, at 5:21 AM, Ethan Swint wrote: > On 08/23/2011 08:47 PM, Matthew Lewis wrote: >> I was double checking a pcb layout today and I discovered a rather nasty >> gotcha. It seems that gschem and PCB don't agree on which end of a diode >> should be pin 1. Gschem views pin 1 as the anode and PCB considers pin 1 to >> be the cathode. It doesn't prevent you from laying out a board correctly, >> but it does cause the silkscreen polarity to be printed backwards (for the >> SOD devices at least). > I've defined my own symbols and footprints to use 'A' and 'K' instead of 1 > and 2. > > This is what we do at my work as well. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb HID GUI options: gtk, lesstif?
On Aug 23, 2011, at 5:14 PM, Peter Clifton wrote: > On Tue, 2011-08-23 at 16:06 -0400, Mark Anderson wrote: >> I'm still planning on an OSX Cocoa HID. I haven't gotten very far, but >> I do have the very, very beginning. If any one else is interested, let >> me know. I'd like to do the same for gschem, but that isn't as modular >> just yet. >> Mark > > OSX supports GL rendering quite well doesn't it... I guess I'll have to > make sure I split out as much of the platform / toolkit independent > parts of the GTK HID's GL rendering setup code as I can so other HIDs > can share. > I use the GTK GL on my OSX machines quite nicely. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Layer button backgrounds - summary
On Aug 19, 2011, at 1:39 PM, Vanessa Ezekowitz wrote: >> On Fri, Aug 19, 2011 at 12:41:58PM -0400, DJ Delorie wrote: > [...] >> Though, I am still unsure how to indicate that the last 4 >> layers can't be used for drawing. > > Put the item names in parenthesis. > A little padlock icon is universal as a locked thingy. (name) can mean anything.. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Layer button backgrounds
On Aug 18, 2011, at 12:52 AM, Andrew Poelstra wrote: > On Thu, Aug 18, 2011 at 12:08:34AM +0200, Kai-Martin Knaak wrote: >> >> This advantage wears off as the user uses the feature more often. >> Using layers is very basic to PCB. Typical use switches layers >> very often in a session. Because of this, long term aspects become >> more important, like efficient use of screen real estate and good >> visibility of important aspects. >> >> Eye icons would demand an additional share of space that cannot be >> used for the canvas. Greyed out buttons buttons are a very intuitive >> and obvious way to signal invisibility. >> > > Kai (and others), what do you think of this mockup?: > > http://wpsoftware.net/andrew/dump/mockup.png > I really like this one. Bonus points for setting layer color by clicking on the colored rectangle. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Layer button backgrounds
On Wed, Aug 17, 2011 at 7:00 PM, Andrew Poelstra wrote: > > Hey all, > > I am working on moving the Gtk layer-selector into its > own widget (see bug 699482, for example), and cleaning > up the code. > > A question I have for the group is: why are the backgrounds > of the layer buttons in little rectangles? Is there > opposition to making the background fill the whole buttons, > like so?: > > http://wpsoftware.net/andrew/dump/buttons.png Looks great, I like it much better than the rectangles. One request, please make the text recognize a light backdrop and change to black. e.g. far side is not contrasty enough. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB opengl?
On Aug 13, 2011, at 4:37 PM, Peter Clifton wrote: > There is also the 3D board view stuff and "SpaceNavigator" 6-DOF > controller support, which has not made it to git HEAD. Please make sure this is properly protected in an autoconfig option. I have to apply a patch to rip it out on mac OS X Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Linux Desktop für gEDA
On Aug 5, 2011, at 11:21 AM, Josh Jordan wrote: >I've had the same trouble with recent ubuntu release looking like osx. >Debian sounds like a good alternative to ubuntu even without the window >manager issues. >Does anyone use geda on osx? I have given osx a good try and found it >lacks basic features such as expanding a window to take up half the >screen, you have to buy an app for that! > I use gEDA on Mac OSX, it is great. A base os that I don't have to configure, or worry about upgrades and such. And all of the Unix goodness that I come to expect from a computer. macports has earlier releases of gEDA, but I run from git head. Using macports to install the dependencies. As for dividing up the screen, the window management is a different mind set, the maximize button is really "Make the window the optimal size" button. When I want to have exact control of window sizes I use an application called divvy. It has hot keys that I use to place windows where is want them. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power relay question
> Agreed. The majority of my parts come from curbside salvage, I've yet to > find any programmers in the trash, but maybe someday I will? > I have found some in the trash. For old Cypress chips, and I think some 8051s But who needs programmers when chips have USB mass storage and RS-232 bootloaders. My NXP LPC1114 programmer is a TTL level uart and the chips aren't terribly expensive. > And my programming skills are weak. When I was in tech. school, the > closest we came to programming was making LEDs blink with a Z-80 CPU, > and some machine code. > > Since then I've managed to create (plagiarize and paste) some Basic > programs, and I took and passed a PERL/CGI on-line course, a decade ago. > An Arduino is a very good starting point for working with Atmel AVR systems and reasonable cost. I also like the LPC1343 Quick start board from embedded artists, no programmer the chip in bootloader mode is a USB mass storage drive. > So my approach to this problem would have the latching relays, or an > SCR/Triac solution. Triacs are meant for AC systems and the kickback can keep them from shutting off. Triacs that are designed as snubberless are often back to back SCRs. SCRs will not shut off once triggered until the current goes to zero, Same for TRIACs so tripping small limit switches won't turn off the motors unless the switches block the current. MOSFETs would probably be the best. If your currents are low you could even use H-bridge mosfet chips to drive each motor. The TB6612FNG is a dual motor controller at 1.2 Amps average, 3.2A peak The added benefit is that it is designed to cope with the kickback of motors. Steve > > -- > Darryl Gibson N2DIY > Linux, free software, for the people, by the people. > > > > ___ > 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: Design Nark
On Tue, Jul 19, 2011 at 11:24 AM, John Doty wrote: > > On Jul 19, 2011, at 12:15 PM, Steven Michalske wrote: > >> We can do better. :-). On a side note Are there features that would be nice >> to have? > > It would be nice to *remove* features like hierarchy expansion and slotting, > while leaving the *capability* to put them back with scripts. These are > things that *cannot* be done correctly with a single approach for every case, > so the flexibility offered by scripting is needed. > Agreed, but to remove them we need to make the script that replaces current functionality. It would be nice to see the hierarchy expander open up the pins to gschem file for a large connector, on say an "auto symbol." Where "auto symbol" means a symbol that is defined by a script not by a static file. > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: Design Nark
On Jul 19, 2011, at 10:59 AM, John Doty wrote: > > On Jul 19, 2011, at 11:53 AM, Josh Jordan wrote: > >> We could spite them by implementing all of their features. > > Shudder. A powerful toolkit should not be copying features from consumer > software. > We can do better. :-). On a side note Are there features that would be nice to have? > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: verilog -> gschem
Will the gentlest backend for verilog accept symbols with the source attribute set, like hierarchy symbols, but making them point to Verilog source not a sch source? Steve On Jul 8, 2011, at 1:29 PM, wrote: >> Original Message >> Subject: Re: gEDA-user: verilog -> gschem >> From: John Griessen >> Date: Fri, July 08, 2011 9:27 am >> To: gEDA user mailing list >> >> On 07/07/11 17:31, fr...@frankthomson.net wrote: >>> I just need to get it into gschem format to run through >>> gnetlist to a different netlist format. >> >> There is a gnetlist backend for verilog-ams. >> You don't need to make schematics, just learn >> enough scheme/guile to fix up the exiting >> gnetlist backends for verilog. > > I do not need to generate a verilog netlist, they are already in > verilog, I need to combine circuits from differnt sources for the final > design and as gnetlist doesn't read verilog I need to get everything > into gscheme format. This is basically the path: > > Circuit elements are coming from different sources, software, etc. The > common format we can all use is verilog so we are using that and use > icarus verilog for logic simulation. If we can get the verilog into > gscheme format files I can use gscheme to combine the blocks at the top > level (which also gives us a nice top level drawing) and run the design > through gnetlist to create a bdnet format netllist (I've got the > gnetlist backend mostly working to generate the bdnet format netlist). > > I don't care what the schematics of the files created from the verilog > files looks like, I can create symbols for the top level and we never > need to decend into them. I do have a library of symbols for the > standard cells that will be used in the verilog files and can generate > flat verilog files so I was hoping someone had or had started a script > that can read in a flat verilog file, refer to a directory of symbols to > reference pin locations and create a gscheme file that is correct from a > netlist perspective. I could try to write this but am a h/w guy and only > fair at s/w (which is real obvious when you look at my gnetlist bdnet > backend). > > > > ___ > 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 saving symbols
On Jun 16, 2011, at 9:37 PM, Colin D Bennett wrote: > On Thu, 16 Jun 2011 20:55:57 -0700 (PDT) > Josh Jordan wrote: > >> I could implement a save-symbol-as capability. Can anyone familiar >> with gschem code outline a 'right' way to this? Should I add another >> option to Hierarchy "down modified symbol" and change the other to >> "down original symbol"? Or would it be better to add a 'save symbol >> as' function to the right-click menu that operates on selected >> objects? Should I try not to change libgeda? Thanks,Josh Jordan > > Maybe it is useful to make the distinction between a _symbol_, and the > _instance_ of that symbol in your schematic to which you have attached > new attributes. (I think these are the terms I've heard the gschem > devs use...) > > Then you could have a “Save Symbol Instance As...” to create a new > symbol file on disk containing the original symbol with your > modifications applied. > +1 > Regards, > Colin > > > ___ > 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: Water proof panel connectors
Looking at connectors for this in the past has lead me to circular connectors. A search on digikey brings up a selection matrix including ingress protection. If your going to be connecting and disconnecting this alot, look into push pull circular connectors. Lemo makes really nice ones. www.lemo.com As for ratings. http://en.m.wikipedia.org/wiki/IP_Code IP65 should be enough even IP54 And you might want to take your wheelchair and make it into a scuba submersible too! Then you might wand really good underwater connectors. :-) Steve On Jun 8, 2011, at 1:58 PM, Rob Butts wrote: > I have a water proof box with two volage sources inside. I need a > power connector to be water proof that I can in the box and be water > proof. It doesn't have to be submersible because it will be on the > back of my wheelchair but the more water proof the better. > > > > Can anyone recommend one? > > > > Thanks > > > ___ > 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: Jumpers on single layer PCBs
Can you still get single sided FR2? On May 31, 2011, at 2:26 PM, Thomas Oldbury wrote: > Double sided boards are great, but not so great when the product is > supposed to cost only $3/each, after an MSP430, mains power supply, > heatsink, triac etc. > > On 31 May 2011 22:09, Levente Kovacs <[1]leventel...@gmail.com> wrote: > > On Tue, 31 May 2011 21:59:04 +0100 > Thomas Oldbury <[2]toldb...@gmail.com> wrote: >> Oh. Thanks anyway. Any hack-ish way to add this in? (Because I'd like >> each jumper to have a refdes and BOM entry if possible.) > > What I'd do is define a copper layer. Draw your jumpers on the that > layer. > Don't send the layer data to the fab house. Make sure you have mask > openings > on vias. Solder jumpers in the vias. > I recommend using double sided boards. > Levente > -- > Levente Kovacs > [3]http://levente.logonex.eu > > ___ > geda-user mailing list > [4]geda-user@moria.seul.org > [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > References > > 1. mailto:leventel...@gmail.com > 2. mailto:toldb...@gmail.com > 3. http://levente.logonex.eu/ > 4. mailto:geda-user@moria.seul.org > 5. 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: gnetlist (was: Perl)
I was thinking of how to represent all of the connections and relationships. Then thought of sqlite3, as a database of connections. a table of symbols, a table of pins This table maps the pins to a net and a symbol. a table of nets This is a rather simple database, of connections. To compensate for complexities we want to add. a table of symbol attributes, a table of pin attributes. a table of net attributes to extend the ability of buses a table of busses a table of bus taps - This would contain a bus, bus net, and the individual net. The making a net list (no busses) would be something of the sort. In pseudo code. for each net in the sql query "select net from net_table" do print "net: " for each pin and symbol in sql query "select pin_number, refdes from net_table join symbol_table using symbol_id where net_table.net = net" do print refdes and pin_number end loop print "\n" end loop aliasing nets would be similarly simple, with it's own table. that would map the nets together. Since the data structure is a sqlite3 database any programming language. The database can be held in either memory or in file. Steve On Mon, May 30, 2011 at 6:13 PM, John Doty wrote: > > On May 31, 2011, at 1:55 AM, DJ Delorie wrote: > >> >> One thought I had for gnetlist backends, is to recode gnetlist as a >> set of libraries. > > Now you're talking. > >> The Core would only load the design files >> (schematics, spreadsheets, databases, back-annotation info, etc) as >> raw data; the backend would be required to call at least one library >> function that said "I want data in this format". > > Why have a core at all? One of the issues with the current gnetlist is that > it cannot be ported to a different Scheme implementation, because the core is > Guile-specific. Why not start from Scheme functions for reading/writing .sch > format? > >> The "formats" could >> be layered in the library, with each layer distilling the data even >> further, so that each backend could choose how much the data is >> pre-digested. > > This is already present, in shallow form, in gnetlist.scm and > gnetlist-post.scm, but much of the digestion happens unconditionally in the > core. The foundation for the fix for the attribute censorship bug involved > just a little refactoring, to move just a tiny bit of this digestion from the > core to gnetlist.scm. > >> >> Something like PCB's current backend, for example, would ask for a >> fully flattened design with all connectivity resolved and reduced to >> pin-level netlists. A Verilog backend might want busses not reduced >> to pin-level, or the heirarchy left intact. A BOM might not bother >> with connectivity, but ask for additional attribute processing. Etc. >> >> This way, we can centralize a lot of the common tasks, without forcing >> those decisions on the backends. > > Yes! Put plugins and back ends in control. > > OK, I think we now have a nice creative rivalry between Schemers and > Pythonians. Let's see some code! > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: This morning's treat
Cool, Got photos? Steve On May 22, 2011, at 6:57 PM, John Doty wrote: > Well, here I am in Osaka. It's Monday morning, and I just saw the prototype > Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the > electronics, a large, complex circuit board and some mixed-signal ASICs, is > of my design, using gEDA. I've been working on this for six years, now, and > it's wonderful to see it all built and plugged together. > > So, thank you to all who made this possible. It's a beautiful morning. > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: chip data directories in a library ( library packages )
On Sat, May 21, 2011 at 7:53 PM, John Griessen wrote: > On 05/21/2011 08:09 AM, Kai-Martin Knaak wrote: >> >> The notion of packages can be seen as a means to isolate dependencies. >> Pins in symbols must match pins in footprints. Simulation models are >> specific to components. Packages provide a way to keep comments, notes >> and all kinds of meta data attached. > > I like the idea of creating a library group containing all info related > to a manufactured part or part range. I think the name package could create > confusion > with layout package used to implement a circuit, some of which have > different > numbers of pins, so what do you all think of this name for a library group: > > In the context of a library call them chip data directories, or chips for > short. > > The chip data directories could also be compressed > a standard way for ease of distribution. > Some library elements don't match the word "chip" perfectly, such as > resistor capacitor > terminal block, etc, but people can figure from the context what was meant. > > On 05/21/2011 08:37 AM, DJ Delorie wrote: >> I don't think we've come to a consensus on how to ease the >> heavyification step yet, though, which may require a great deal of >> coding and redesign. > > The data dir in a library concept seems to make heavification easier. > > I'd always want to be able to heavify the symbol or footprint first, then > use a script to make them all consistent, not have to do symbol > then footprint in that order only. > > Names keep coming up as I think about relating symbols and footprints and > adding > heavy data to them. If symbols are not necessarily files, I'm used to the > file name being > the symbol name or footprint name -- it just seems "normal". If a symbols > or footprint was just a > text section in a larger file, I'd be OK with that, and it would need tags > like symbolname="some-kinda-name" > or footprintname=some-kinda-name". We could easily agree to shorten that > down to tags like: > symbol="some-kinda-sym-name", footprint=some-kinda-fp" without even needing > filenames with suffixes .sym .fp. I'd like to see that there is a many to many relationship. Example: You need a SO-8 footprint. With the footprint storage the relationships are a type of footprint backed by many footprints capable to fill the role. If it is directory and files there is a SO-8 directory with the x pcb footprint files that could be used to be a SO-8, like most, nominal, least, hand-solder, and etc. In a relational database plugin it could query for a footprint that provides SO-8 in the footprint table. This helps if you are say making a base schematic that may be made on many different types of boards, or purposes. When purposed it would get flattened and weighted with the particular process applied to it. Next example. For models in simulation. It is a mosfet, a 2n7002, there is a 2n7002 directory with a list of models for say guncap and spice. They also happen to be for different manufacture parts. In the "package" part it has a variety of parts that you may use, from lets say 4 vendors. The data store can let you simulate the circuit with each vendor, leading to confidence that your alternate parts are good. In lightening a resistor, I'd have the base parameters part of the symbol. Ohmic value, tolerance, power dissipation. This can then let the method of hevifying query a data store to help find your preferred parts. My thoughts on the interaction. Lets say that you draw out the topology of a circuit it has a micro controller and support parts. The uC is a medium weight part, it has the first variant chosen. The uC package is 33 pin or 64 pin part is not yet chosen, but the 33 pin symbol is the first variant, so it is displayed. A heavy part that is the connector that the board will use, every parameter is chosen when the connecter's symbol is placed. The rest of the parts are a bunch of light parts consisting of resistors, capacitors, and LEDs Now that the parts are placed and wired up. We then select the tool/wizzard/script that makes parts heavy, pretend were in the GUI mode and using the tool. So you click on the LED(s) that you want to assign parameters to. The tool knows that it is a LED, so it pulls up the dialog for making that part heavy. It has a interface into the datastore that we are using and I can start drilling down on the values. Kinda like digikey/mouser narrowing down parts. (To DJ's idea) this script might just be an interface to a CGI that is on a part vendors server. Now that the LEDs are taken care of, lets run the script that will make a schematic heavy to take care of the resistors and capacitors. In the schematic you specified the values and tolerances, so the script will take you preferred parts and assign them. The script might generate questions like you do not have a preferred resistor for value 100k at 10% tolerance, would you like to use the 5% tolerance you prefer? or automatically impro
Re: gEDA-user: Solving the light/heavy symbol problem
Metadata can be a parallel task. In gschem you pick your resistor. You have two buttons, place lite, place heavy. Place heavy brings up a second wizard to populate the heavy symbol, probably from your database. Then place your symbol. In pcb, when you import a schematic. Any parts without footprints gets listed. Then you can populate the right footprint. And a back annotation mechanism to update upstream schematics. As a third tool for series workflows sch in to output updated sch, bom, and netlist. Perhaps with features like, general remapping of footprints to the smallest package in your library. Or to your preferred hand soldering size for that type of component. Like ranking 0603 first, 0805 second, and 0402 third. Based on parameters like value and tolerance. Option to use only the heavy part specified, i.e. Don't change out this part. Steve On May 20, 2011, at 6:34 PM, Cullen Newsom wrote: > On Fri, May 20, 2011 at 4:09 PM, DJ Delorie <[1]d...@delorie.com> wrote: > >> I would love an easier way to generate footprints. > > Now that we're pre-parsing all the M4 footprints anyway, perhaps we > could allow for a range of scripting options in the Makefiles that > generate the library? There have been a few footprint-specific > languages developed over the years. > >>> In all cases, one key problem is that there are so many potential >>> heavy symbols that we cannot possibly have "all" of them. >> >> Nobody needs all possible heavy symbols, and disk space is cheap. > > No, but if we choose a subset, we pretty much guarantee that there > will be users who need something we left out. I don't want to be > replicating Digikey's database, for example, but any part I leave > out > is a part someone else might need. > > You could collect users' statistics anonymously and let it be a > popularity contest. Especially if the databases were centralized. > >>> defer the problem to the user, who only puts effort intothe >>> symbols they needed. >> >> Which puts many (often novice users) to the task of creating their >> own symbol/footprints, and probably doing it wrong. > > Hmm... but does this mean we should do the work for them, or does > this > mean we need to come up with a better way for them to do the work? > > I'm hoping for "a better way for them to do the work" or even, > "machine does most of the work" Teach them to fish and all that. > >>> * New users should find it easy to make their first PCB. >> >> Yes! New users, casual users, experienced users, all users. > > This is why I see no clear win between "just heavy" and "just light" > - > different users at different levels need different solutions. A new > (to geda) user should be able to pick common parts from a list and > make *something* that works, but an experienced user will eventually > need to make their own. > >> Don't ship gSchem or PCB with any. At first run, and in preferences, >> and in config files, give users the ability to choose their own >> poison. Use git to > > If we go with the idea of "more than one library", we can ship a > starter library (like, Radio Shack 500-in-1 parts list, or "Spice > 101" > with examples) and let the user import libraries from, say, > gedasymbols. > With my scheme, that would be a "starter database" instead, but > similar results. > > Actually, with gedasymbols, *anyone* can make a small self-contained > heavy symbol library. The problem happens when you want to make a > self-contained *light* symbol library, then you need more logic in > the > tools to heavyify them. > >> synchronize with a (set of) master symbol and or footprints, and or >> something else databases. Include options to use others' symbols / >> parts (gedasymbols, luciani, etc). Include options for users to >> share their own symbols via git. Create online symbol and footprint >> generators that create standard footprints (at least for JEDEC >> standard stuff) properly (according to best practices). > > hmmm... think about how a simple http:// changed the way we share > information across the Internet. Think of how Facebook changed the > way people manage their social lives. Are we prepared to put the > effort into making something of *that* scale, for EDA? It would be > cool if we got it right, but a pain if we didn't. > > > Here's some pie-in-the sky for you. I can imagine a database with which > a small number of users has full commit privileges, others' symbols / > footprints (perhaps even by default / automatically) will be submitted, > which would in turn generate a vetting request whereby a user with full > access could approve or deny the new or modified files. Some effort > would also be spent getting a machine to look for common mistakes and > automatically reject them. I'd love to see it get all Web2.0-ish, and I >
Re: gEDA-user: Reinventing the wheel
hit send too soon On May 16, 2011, at 4:30 PM, Kai-Martin Knaak wrote: > Steven Michalske wrote: > >> In a perfect world this would not be an issue. But lawyers can use that >> clause as a loophole to invalidate legitimate patents. > > The notion of software patents is by no means obvious. In fact, it is > subject to serous doubt. See the undulating tale of conflicting judgments > by the (European) Court of Justice. > > > >> Big point here, I was talking to some of the google compilier guys >> and finding out that most of the big compiler guys around consider >> gcc to be a dead man walking, largely due to GPLv3 issues. This is >> not limited to Google either, but includes Apple > > Neither of them is notorious for their contributions to the gcc > code base. They both have the resources to roll their own compiler > from scratch. Why don't they? > It is used as an argument for the gpl. With quotes of, without the gpl gcc would not have c++ or the objective c compiler. But I can't stand behind that statement, because it assumes the worst out of everybody. Apple has released lots of core technologies without the demands of gpl distribution rules. Launchd, clang and llvm, libdispach, blocks(closures) for c code, part of clang, Webkit. And many others. > >> and many of the other players. > > like the FSF? > > > >> The latest revision of the gpl threatens input from companies. > > smells like FUD > It's from lawyers, that are paid to protect patents. Where I work we had big review processes to protect ourselvs from violating the v2 license, now we have an explicit ban. > >> Not the only reason, I am more than willing to share code, even >> at no cost. Although, I'm not selfish enough to demand that all >> of their work must be given freely to me. > This is not in the gpl, but often with the users/developers perception. "How dare you make money off of my code, and not give the changes back to me." > There is no such clause in GPL3 > > The cases of openoffice shows how important the absence of loopholes > in the GPL is to the continuous freedom of open sources software is. > Oracle demonstrated how big players try to chain software written by > others to their legal stronghold. And not having loopholes is a good thing, no disagreement. But here the gpl did the same thing, put in a patent, and everyone gets free access to it and your related patents. That put a loophole in the patent system. Realistically there should be no patented material in the code. > > ---<)kaimartin(>--- > -- > Kai-Martin Knaak > Email: k...@familieknaak.de > Öffentlicher PGP-Schlüssel: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 > > > > ___ > 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: Reinventing the wheel
On May 16, 2011, at 4:30 PM, Kai-Martin Knaak wrote: > Steven Michalske wrote: > >> In a perfect world this would not be an issue. But lawyers can use that >> clause as a loophole to invalidate legitimate patents. > > The notion of software patents is by no means obvious. In fact, it is > subject to serous doubt. See the undulating tale of conflicting judgments > by the (European) Court of Justice. > The clauses are not limited to just software patents. Imagine building hardware with gschem, 100% legal and your design is yours. Now, you accidentally included a symbol with a gpl licence. Now I know we release the bulk of our symbols with explicitly free use licenes. But I may have used tom's that was pure gpl. And Tom saw my > >> Big point here, I was talking to some of the google compilier guys >> and finding out that most of the big compiler guys around consider >> gcc to be a dead man walking, largely due to GPLv3 issues. This is >> not limited to Google either, but includes Apple > > Neither of them is notorious for their contributions to the gcc > code base. They both have the resources to roll their own compiler > from scratch. Why don't they? > > >> and many of the other players. > > like the FSF? > > > >> The latest revision of the gpl threatens input from companies. > > smells like FUD > > >> Not the only reason, I am more than willing to share code, even >> at no cost. Although, I'm not selfish enough to demand that all >> of their work must be given freely to me. > > There is no such clause in GPL3 > > The cases of openoffice shows how important the absence of loopholes > in the GPL is to the continuous freedom of open sources software is. > Oracle demonstrated how big players try to chain software written by > others to their legal stronghold. > > ---<)kaimartin(>--- > -- > Kai-Martin Knaak > Email: k...@familieknaak.de > Öffentlicher PGP-Schlüssel: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 > > > > ___ > 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: Reinventing the wheel
On May 16, 2011, at 4:25 PM, al davis wrote: > On Monday 16 May 2011, Steven Michalske wrote: >> But lawyers can use that clause as a loophole to invalidate >> legitimate patents. > > Minor side effect of "lawyers can use that clause as a loophole > to invalidate ILLegitimate patents" ... which outnumber the > ligitimate ones a million to one. > A software licence should not be used for this purpose... As a person with patents, I can't afford to contribute substantual code back, but I can use all the code I want. Because my patents are legitimate. But this is straying from this lists topic. I wish the best of luck to those that wish to reinvent this wheel, a gpl compatible library with a less restrictive licence bsd, MIT, etc... Could be used to extend pcb and gschem. And allow commercial interests to support us. > ___ > 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: Reinventing the wheel
On May 16, 2011, at 2:45 PM, DJ Delorie wrote: > >> Biggest determent to the open source is now GPLv3 > > OT here, since our stuff is still GPLv2 > > Sorry for the OT bit, but v2 got a black eye from v3, commercially that is. I know of two companies shying away from all gpl, because of the "or later" clause in v2 and how you can apply v3 to it. Is that still in our gpl v2 license? But the whole bit countering your issues with reinventing the wheel, was on your topic. > ___ > 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: Reinventing the wheel
On May 16, 2011, at 10:21 AM, DJ Delorie wrote: > >>> Why not start with the existing >>> tools and just rewrite the parts you're interested in? >> >> License? > > True. One of the benefits of the GPL is that people can bsae their > work off existing work, but not everyone wants to offer that benefit > to others. > Biggest determent to the open source is now GPLv3 Private companies are now turned away from GPLv3. As it has some nasty clauses in it for their IP. In a perfect world this would not be an issue. But lawyers can use that clause as a loophole to invalidate legitimate patents. Big point here, I was talking to some of the google compilier guys and finding out that most of the big compiler guys around consider gcc to be a dead man walking, largely due to GPLv3 issues. This is not limited to Google either, but includes Apple and many of the other players. The latest revision of the gpl threatens input from companies. Another reason to reinvent the wheel is when the wheel is not exactly what you need. http://www.youtube.com/watch?v=CjcyHicm3NA&feature=youtube_gdata_player http://www.rotacaster.com.au/ > I really don't feel bad for people who need to start from scratch due > to a desire not to share their code, though. Their choice, their > pain. > Not the only reason, I am more than willing to share code, even at no cost. Although, I'm not selfish enough to demand that all of their work must be given freely to me. > > ___ > 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: GL not found compiling pcb on OS X
I have a recipe, I'll send on over when I get to my computer. On May 4, 2011, at 4:16 AM, Peter Clifton wrote: > On Wed, 2011-05-04 at 05:23 -0500, Craig Niederberger wrote: >> Does anyone have experience compiling PCB on OS X? I've been able to >> do it in the past, but am now getting this error on configure: >> >> ./configure --prefix=/opt/geda --with-gui=gtk --enable-maintainer-mode >> --enable-doc --disable-update-desktop-database > > > I've no idea sorry, but I'd love someone to figure it out! > > If you just wanted to build PCB (and not test the new bits of GL > rendering code), add --disable-gl to the configure options. > > -- > 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Can i use geda for electric indoor installation?
One part you will be missing is routing of the true wires. So if your expecting it to make a list of the wires lengths for you you would need to integrate it into a 3D mechanical cad package too. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Origami Flex Circuits Take Shape at All Flex
On Apr 22, 2011, at 9:28 AM, Andrew Miner wrote: > /*xx > > I'm going to go out on a limb and state that I refuse to support > non-flat layers :-) > > [1]http://www.allflexinc.com/origamiflex.shtml > Supported or not these things are worth taking a look at just for > the > strangeness if noting else: > " Origami Flex Circuits Take Shape at All Flex > > Ok, that's just too damn cool. It looks like lots of fun. :) > > */xxx > There is not much to support, and they are easy to work with. I worked > at a Flexible PCB hose for a couple of years, and all of the ones shown > are single or double sided boards. > You design it like a normal PCB, other than you make a much more > intricate route pattern for the outline layer than a rectangle. > You leave areas to make the folds or bends (don't place vias or > components in those areas), and then you can crease them after assembly > for a tight permanent bend, or leave them as is for an open/close > movement (like the display cable on a laptop lid). > If you need certain areas of the board to be rigid, you can mount it > onto a sheet of Aluminum (adds stiffness and thermal dissipation) or > take some FR4 hardboard to make a stiffener that is glued onto a small > area (non conductive). > Really the only layers you would need to add to your project are: > A layer to indicate fold lines for bend locations (if needed) > A layer for stiffeners (If needed) > A layer for internal cutouts, made moments before the outline route (if > needed) > > The only real challenge is for you to design a 2D object that will bend > and flex to fit your 3D application ;-) Any sheet metal cad package can make your outline and fold bend areas. > Andy Miner > > References > > 1. http://www.allflexinc.com/origamiflex.shtml > > > ___ > 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: Attribute Net (without pin assignment) - for Power and Port Symbols
Snip.
I agree that we should not special case it. I would prefer varibles that
refered to other attributes.
This example: value = 3v3
net = $value:1
where the default scope is the local symbol and no lookups to higher scopes.
A resistor divider:
R1
Value= 1000
R2
Value = ${r1.value} / 2
See how I snuck in math!
This is flexible and is not special casing anything.
Just imagining having a feedback resistor formula in a voltage regulator used
to adding values for the two feedback resistors.
Steve
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC using SVG with semantic markup as an EDA format
On Apr 12, 2011, at 2:55 AM, Kai-Martin Knaak wrote: > Peter Clifton wrote: > >> TBH, I've not seen SVG anywhere on the main-stream internet. > > Wikipedia prefers SVG for anything that is not a photograph. The servers > render SVG graphics to PNG as needed before handing it out to the browser. > > >> Linux >> desktops use SVG a lot for desktop graphics, but it really isn't as >> prevalent as it should be. > > Microsoft and Apple do not like > > Safari has supported SVG for a while now? Why doesn't apple like SVG? >> What excuse is there for OpenOffice / LibreOffice being so appallingly >> bad at working with SVG files? > > Actually, SVG import is among the first features of libreoffice beyond > openoffice: > http://www.libreoffice.org/download/new-features-and-fixes/ > > >> Why can't we paste them right into TeX, LaTeX or whatever? They are all >> open source, yet this open format is not supported. > > IMHO, latex development reached a state of virtual feature freeze before > SVG became a viable alternative. > > >> Whilst SVG is an obvious open vector standard to support - not a lot of >> things actually work well with it sadly. > > The number one open source vector drawing application, inkscape uses SVG > as its native file format. This alone would be reason enough to seriously > consider SVG as an import/export file format. > > ---<)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+kmk&op=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: default pcb stackup change?
On Mon, Apr 11, 2011 at 11:35 PM, DJ Delorie wrote: > > Now we just need to figure out how to enforce it :-) > With a stick! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC using SVG with semantic markup as an EDA format
On Tue, Apr 12, 2011 at 12:28 AM, Stefan Salewski wrote: > On Mon, 2011-04-11 at 23:18 +0800, Steven Michalske wrote: >> This is what I see as a benefit. If you go to a vendor's website you >> will find one or two EDA footprint and symbol files. But nothing that >> was a bell ringer for commonality. It would be nice to have a >> universal starting point. >> >> There is EDIF but I see EDIF as not being so useful, i think they >> tried to do too many things, and failed to get them all correct. As >> one file format to rule them all. >> >> I rather see svg symbol format, svg footprint format, and svg format. >> >> Steve > > For svg footprints we have two problems: We always have to convert it to > old gerber format before sending to manufacturer. (Or to another format > which manufacturers support, I think no one currently supports svg.) And > if we scale footprints, we should not to forget to scale our (real word) > components with the same factor. Of course, would be fine: If our case > is too small for our device, just scale the whole thing down. :-) > > Same exists for out current footprints, they need to be converted to gerbers via pcb. basically svg -> converter -> pcb fp format -> pcb -> gerber --or-- pcb fp -> svg --or-- vendor x -> converter -> svg -> converter -> pcb fp It would be nice to scale the solder masks and the solder paste layers. for process dependencies. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OFF: capacitors for RF power amplifier
http://www.avx.com/SpiApps/default.asp Some cool capacitor tools, like spicap3 Steve On Mon, Apr 11, 2011 at 11:19 PM, Kovacs Levente wrote: > On Mon, 11 Apr 2011 16:58:37 +0200 > Uwe Bonnes > > wrote: > >> What value do you need? Try NP0/COG type, even if substantial more > > 120pf ... 1.5nF > >> expensive. I guess the X ceramic will introduce more harmonics than >> it will filter out... > > Thanx for the hint. > > -- > Kovacs Levente > Voice: +36705071002 > > > > > ___ > 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: RFC using SVG with semantic markup as an EDA format
This is what I see as a benefit. If you go to a vendor's website you will find one or two EDA footprint and symbol files. But nothing that was a bell ringer for commonality. It would be nice to have a universal starting point. There is EDIF but I see EDIF as not being so useful, i think they tried to do too many things, and failed to get them all correct. As one file format to rule them all. I rather see svg symbol format, svg footprint format, and svg format. Steve On Mon, Apr 11, 2011 at 9:43 PM, Andrew Seddon wrote: >> On Sun, 2011-04-10 at 21:55 +0100, Andrew Seddon wrote: >>> I am exploring the idea of using the Scalable Vector Graphics standard >>> as an EDA format. >>> >>> https://github.com/seddona/svgparts >>> >>> Would be interested in your thoughts, there's a little more >>> explanation on my blog. >>> >> >> What would be the benefit of SVG? >> >> Arbitrary symbol sizes? We can scale our current symbols already, but a >> schematic with very many different symbol sizes will look strange. >> Indeed limited scaling may be fine, ie. scaling our 900 units long >> resistor to 800 or 1000 units length -- but pins should always end on a >> 100 grid multiple. (no that is not really needed to connect nets, but >> for ordered look.) >> >> Currently SVG export should be a trivial task due to cairo -- similar to >> PS and PDF export. >> >> Filled SVG paths are fine, we have it, still without editing support. >> >> Do we need other fancy graphics? I do not think so. Schematics design is >> not really art work. >> >> If we really want full SVG, we may consider a "Schematic" Mode for >> Inkscape. But Inkscape is really a large, complex tool. >> >> If it is possible to embedd all the "elelectronics stuff" like >> attributes, net connection, slots, ... in SVG file, then it may be OK. >> But the effort -- it is similar to a complete rewrite of gschem. And a >> rewrite -- again C and guile and GTK? >> >> PS: >> We may consider using inkscapes svg icon set for geda/pcb. Inkspape is >> GPL, so it should be OK. You may look at files >> >> /usr/share/inkscape/icons/icons.svg >> /usr/share/inkscape/icons/tango_icons.svg >> >> Very nice icon set, I intend using it for my plain ruby gschem clone. >> >> Best regards, >> >> Stefan Salewski >> >> >> >> >> ___ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> > > So I think it might help to limit the scope of my intent initially to > library parts. I'd like to create a truly vendor neutral, widely > supported EDA library format, and the only way I see to do that is to > piggy back on a format much larger than anything the EDA industry > could ever create in isolation. > > I'm actually thinking more of a direct convert from the gEDA library > files so as to maintain design intent, rather than ripping from the > graphics layer. > > > ___ > 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: default pcb stackup change?
Pci cards call them A and B sides. But that too is odd. It seems that, like it or not, top and bottom are the industry standard. On Apr 11, 2011, at 11:24 AM, John Griessen wrote: > On 04/10/2011 08:26 PM, Bob Paddock wrote: >> Sometimes the outer layers are called Primary and Secondary. > > Main and Second are shorter and might convey similar meaning and be more > usable... > > JG > > > ___ > 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: RFC using SVG with semantic markup as an EDA format
On Apr 11, 2011, at 8:51 AM, Peter Clifton <[1]pc...@cam.ac.uk> wrote: On Sun, 2011-04-10 at 21:55 +0100, Andrew Seddon wrote: I am exploring the idea of using the Scalable Vector Graphics standard as an EDA format. [2]https://github.com/seddona/svgparts Would be interested in your thoughts, there's a little more explanation on my blog. p.s this is probably a topic for -dev but I don't access... The idea of basing future formats on SVG has been thought of, floated, and discussed before now. I don't recall whether any conclusions were reached. I personally have mixed feelings, but am leaning towards the the thought that it is a good idea - but with a healthy dose of uneasiness about it as well. My thoughts on this topic are that SVG should be the common format and that converters are made. The converters job would be to map the standardized SVG to the symbols. I propose that there be levels of the svg symbols. Level one only has lines and arcs, level 2 adds text, level three adds polygons and circles... And so on. It would be the converters job to map the symbols and footprints to the EDA package you are using. I'm not as convinced of the idea for PCB layouts / footprints. I'm just not certain the drawing model is constrained enough. to match real world geometry demands. The main niggle is that SVG is more expressive than a generic PCB layer. Things like colours and gradient fills are just not meaningful in copper. That means we need to act intelligently if something adds those. Supporting complex geometry primitives which SVG would bring also means internal processing in PCB might get more difficult. Hence the job of the exporter to map properly to layers. Ignoring or erring on higher level constructs. -- 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-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:pc...@cam.ac.uk 2. https://github.com/seddona/svgparts 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: Split ground planes and zero ohm jumpers
> > In theory, we could support that flag in *any* object, but I'm not > sure how to manage the relationship between, say, a non-net trace on > an inner plane and the schematic/netlist. I asked someone who used a > BigName EDA package how they did it, and they had a completely > different class of object for these - a net-linking object in the > schematics, netlist, and layout. > We use two objects for net and connectivity manipulation in schematics. Shorts, that map to a special class of footprints that can be placed on inner layers. Aliases, these map two net names to the same net and an attribute on the primary net marks it as the name it should use. Where the highest primary name in the hierarchy is used. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
On Apr 8, 2011, at 1:13 AM, Stephan Boettcher wrote: > rickman writes: > >> I have to say I am philosophically opposed to any feature that allows >> a design to pass DRC when the layout differs from the schematic. > > Just to get the terminology right: > > DRC has no business to care about the schematics at all. There shall be > a tool to check if the layout implements the schematics netlist, but > that is a different issue. > DRC vs ERC. A while back I proposed that there were object attributes that allowed for a single connection from a net. If the ERC caught more than one connection from that net. > PCB implements this distiction properly. DRC checks consider coper > structures as layed out when evaluating the rules, without regard to the > netlist. > > The Rat's-nest (O-key) ignores DRC rules when checking connectivity. > > -- > Stephan > > > ___ > 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: SC70-6, which is pin 1?
On Apr 2, 2011, at 12:35 AM, yamazakir2 wrote: > The datasheet is pretty ambiguous, take a look and let me know what > you guys think: > > http://focus.ti.com/lit/ds/symlink/sn74lvc1g3157.pdf Page 1 and 18 show dip ordering. And the index mark refers to the bar on the top. So placing the component top side up and the bar to the left. Pin 1 is the left most pin closest to you. The bar in fact is adjacent to pin6 as well but apply the dip ordering and you'll be safe. > > On Fri, Apr 1, 2011 at 5:21 AM, Cullen Newsom wrote: >> Have you got a part number for it? What's inside? You could use a DMM >> to confirm, if you consider its internals. Your guess of bottom left >> seems reasonable. >> -CN >> >> On Fri, Apr 1, 2011 at 4:13 AM, yamazakir2 <[1]yamazak...@gmail.com> >> wrote: >> >> I'm guessing based off that mark the bottom left pin is pin 1. The >> datasheet isn't clear. Does anybody know for sure if thats pin 1? >> ___ >> geda-user mailing list >> [2]geda-user@moria.seul.org >> [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> >> References >> >> 1. mailto:yamazak...@gmail.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 >> >> > > > ___ > 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: Multi-Select with SHIFT, CTRL...
On Mar 19, 2011, at 2:38 PM, Stefan Salewski wrote: > On Sat, 2011-03-19 at 13:14 -0700, Steven Michalske wrote: > >>> Scroll wheel: rotate selection or element under mouse pointer >>> If nothing is selected and mouse pointer is over unpopulated area >>> or SHIFT modifier is used: Zoom in/out >>> >> Track pad users may want scroll to be scrolling >> > > So we should have an option to ignore the scroll wheel for rotate/zoom. > Of course for zooming we should have additional keyboard and button > support. And for zooming into a selection rectangle I currently consider > using the middle mouse button. For rotating elements again we will have > keyboard and button support -- but I think using the scroll wheel would > be really fun, i.e for rotating text. > >> If your toolkit allows for the apple trackpad gestures... That could >> add a few options into the mix > > PCB or gschem, one of them, has gesture support by a library -- once I > have asked on this list about it, but it seem that nobody uses that. I > have currently no idea about gestures, so I do not intend supporting it > now. > >> >> In net mode double left click ends the current net. >> > > Yes -- not a true double click (in a small time interval) but simple > adding a net segment of length 0. As supported by gschem. ESC and maybe > another key will also end net segments. > >> >>> LMBD + LMBU over hot pin end: start new net segment >> >> You added net end, but starting at the middle of a net segment is >> valuable too. >>> > > Yes, but grabbing an element in the middle is used generally for moving > or selecting, so we may have a conflict. We may try to resolve it, or > have a "Start new net" button for that case. > > I consider a "only onces" mode beside real modal operation: For example, > it may occur that we intend only a single mirror operation without > leaving the current mode (comming back after one mirror operation) or we > want a real mirror mode, where each click on an element will mirror that > one. My current idea: If an element is selected/highlighted then > "mirror" button or key will mirror that selected element. If noting is > selected, then we will enter a permanent mirror mode. > > Additional, I will support highlight of elements, when the mouse pointer > is hovering over it. Current highlight method is making colors brighter, > move the element a few pixel to upper right, and draw a shadow, > generating the impression of lifting the elements. Problem: We can not > use white (pin) color, because there is no brighter shade of white, and > shadow works not good for dark backgrounds. Of course we can always use > fallback to a plain monochrome highlight color. Another method is > drawing highlighted elements with thicker lines -- I have not tested > that yet. Make shadow a glow on dark backgrounds > > Best regards, > > 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: Multi-Select with SHIFT, CTRL...
On Mar 18, 2011, at 4:41 PM, Stefan Salewski wrote: > On Fri, 2011-03-18 at 19:17 -0400, DJ Delorie wrote: >>> shift-leftclick on object >> >> Don't forget about select-region, select-touching, >> select-touching-line, etc. >> > > I guess that is not too common in schematics? > > Here is my current draft for my gschem clone: > > Peted intended user interface behaviour -- first draft > -- > > LMBD: Left mouse button down (press) action > LMBU: Left mouse button up (release) action > MMBD: Middle mouse button down (press) action > MMBU: Middle mouse button up (release) action > RMBD: Right mouse button down (press) action > > > Our intention is to have a smart AUTO mode which will allow to do the > most common actions fast with minimal effort (beside traditional special > modes like > "Move", "Net", "Erase", "Line", "Arc", "Text", ...) > > > These action include: Select, move, copy, delete, rotate, start new net. > > LMBD over element: Start moving element, LMBU will terminate action, element > is unselected > LMBD + LMBU over element (no motion): select element, unselect all other > SHIFT + LMBD + LMBU over element: add element to selection > CTRL + LMBD + LMBU over element: toggle element, leave other unchanged > LMBD over unpopulated area: start selection rectangle > No modilier: elements in rectangle will become selected, other unselected > SHIFT modifier: add elements in rectangle to selection, other unchanged > CTRL modifier: toggle state of elements in rectangle, other unchanged > MMBD: put a copy of selected element(s) to position of mouse pointer > special case: MMBD over selected element: detete it > if nothing is selected or SHIFT modifier is used: panning > RMBD: Context sensitive menu open > > Scroll wheel: rotate selection or element under mouse pointer > If nothing is selected and mouse pointer is over unpopulated area > or SHIFT modifier is used: Zoom in/out > Track pad users may want scroll to be scrolling So consider that, although I rarely edit layouts by trackpad there are times that I do and hate zooming in and out. But when using a mouse I do want zoom in and out on the scroll wheel. If your toolkit allows for the apple trackpad gestures... That could add a few options into the mix In net mode double left click ends the current net. > LMBD + LMBU over hot pin end: start new net segment You added net end, but starting at the middle of a net segment is valuable too. > > Missing: Zoom into rectangle > > For element properties we will not use a popup window opened by double click, > but a > separate area at the left or right of the main window. Properties of selected > elements > are displayed in this area and can be modified. This area can be used for > various other > purposes, i.e. symbol library preview, color selections, ...It should be > possible to fully > shrink this area. > > At the bottom of the main window we may have an area for log messages. > > We should try to allow multiple instances of our GUI window, showing > different or the same > content. For the last case, we can display an overview in one window, while > we work on details > in a different window, maybe both windows can reside on different monitors. > Of course it should > be possible to use only one window, and switch between different content. > > Have I forgotten common important actions? > > > > > ___ > 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: General Layers questions
On Mar 19, 2011, at 12:33 PM, John Doty wrote: > > On Mar 19, 2011, at 1:20 PM, Steven Michalske wrote: > >> This is what bothers me about a hole layer, un plated vs plated, the holes >> do not define electrical contact, the plating does. >> >> Or, rivits, or the soldered wires on hand assembled multilayer boards. >> >> Well with silver ink circuit printing. The hole in the sprayed on insulators >> does define the connectivity >> > > This demonstrates a flaw in the "hole layer" concept. It doesn't actually > capture the geometry. But if the layers are physical, the objects in them > might have different properties. So a plated-through hole is geometrically a > place in a layer that is mostly insulator, but has a conductive annulus at a > particular place. > Oh my! You can draw The plating on the insulator layer. Thus making the plating a real object of conductor This is more 3d cad leaking through. That would mean that drawing on a insulator/separator would define some material to replace the seperator with, and they would need properties. Plated through hole, conductive epoxy filled, thermal epoxy filled. The drawn shapes would need properties The exporter would see a hole and it's anulis and drill a hole the size of the anulis or hole based on a flag in the exporter about the fab shop's preference on finished or drill sizes. Edge plating would be a line drawn at the egge of the board that moved in the outline of the pcb by the plating thickness. A plating tool could be made to draw the required shapes on each layer through the board. Like the copper trace on the copper layers to plate to and the plating on the insulator. > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: General Layers questions
On Mar 19, 2011, at 9:50 AM, Martin Kupec wrote: > On Sat, Mar 19, 2011 at 10:14:54AM -0600, John Doty wrote: >> >> On Mar 18, 2011, at 2:23 PM, Martin Kupec wrote: >> >>> If layers types would be defined by attributes, someone would be able to >>> declare one layer both as conductive and as silk for example. That could >>> cause me a nighmares. That is why I insist on 'typed' layers, not >>> 'tagged' layer. >> >> No. The nightmare is classification. >> >> It's perfectly possible to put conductive ink on a board with a silkscreen >> process. > No problem here. Just define that conductive ink as copper or conductive > type layer. I don't care how that layer happens to be manufactured. > Simulation! As long as the parameters can be specified then were good. And when I say simulation it can be either a exporter to a field solver for antennas, or a trace width calculator for current limits used while specifying line widths. i.e. Not an exporter. Imagine drawing a trace with a width of 50 ohms single ended to ground. When you move layers it would make the correct via with the proper clearances to the plane. The realtime DRC prevents you from crossing the edge of your reference plane. And when your top layer is separated from the ground plane by .2 mm of FR4 it know the width, and when it dropped to layer 3 between 2 planes it asked how to calculate the trace. Referenced to one or both. Or it could have Known that the separation of 1mm from layer 4 plane was enough not to consider it. Ahh, that would be fantastic! >Martin Kupec > > > > ___ > 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: General Layers questions
On Mar 19, 2011, at 8:13 AM, John Doty wrote: > > On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote: > >> BTW., there were electronic circuitries before PCBs were invented and the >> future of electronics manufacturing is most likely something >> three-dimensional, arbitrarily shaped. > > Yes. I'm now working with two groups that are fabricating parts with 3-D > "printers". I've been wondering when the technology will reach the point > where the printing could include conductors, with components placed during > the build-up, and then buried. > Put in a conductive silver epoxy nozzle and a pick and place head, bam your done! :-) > But I suppose describing this is beyond what we can conceptualize here at > this time. Planes are difficult enough. You would add this capability to something like solid works. > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: General Layers questions
This message makes me think that COW should remember what master it was copied from and an edited flag. On Mar 18, 2011, at 5:16 PM, Stephan Boettcher wrote: > DJ Delorie writes: > Except gerbers have special cases for thermals and pads, for example. >>> >>> So there need to be attributes on shapes. >> >> No, the exporters really need to have access to the whole collection >> of shapes that means "pin" so they can do pin-specific things. If the >> exporter doesn't need that high-level access, then the default action >> breaks it down into shapes and exports them individually. >> >> The gerber exporter needs to be given a whole "pin" because it has a >> command that means "put pin here, with this aperture and thermal >> settings". If you wait until the core descends to "circle, arc, >> line", it's too late to look at the attributes and figure out what's >> happening. CAM tools know about this, and can adjust thermals and >> pins as needed, but in PCB's case they can't do it because we break >> pins down into raw shapes. > > I do not understand this. The gerber exporter exports each layer > separately, no? On some layer it finds a circle with a thermal > attribute surounded by a polygon. What else does in need? > and containing other layers as sub-layouts. I have never disagreed with this! >>> >>> Oh. My understanding of composites is different. I assume a composite >>> contains shapes that go on a global set of layers. >> >> This is part of the communication problem we're having, yes ;-) >> >> Consider these: >> >> * A footprint is a global resource, but an instance of a footprint (an >> element) must be mapped to the physical layout. When do you manage >> the footprint as an element (indivisible) and when do you access its >> parts (changing pad size)? > > Is the footprint still part of the layout? Wouldn't it's genereic > layers (top,inner,bottom) be mapped to the layout layers > (oben,innen1,innen2,unten) when imported? > >> * A sub-circuit that's replicated N times on a board. > > composites instances are objects inside other composites, next to > shapes. You can do most operations to composites, that you do to shapes > (move, rotate, mirror, delete, ...). Vias and elements are special in > the memory representation, as there are methods, or callback hooks that > allow access to some internals without explicitly decending into the > composit. It should be possible to flag any composit as Element or vise > versa, to turn on and off this special access. If you exlicitly decend > into an element, you can move its pins and pads. But pads size, text > positions e.t.c. are still directly accessible for elements. Maybe it > is not even necessary to have any special treatment and treat all > composites the same. > >> * A flex cable that has 4 layers at each end, but only 2 layers in the >> middle. The extra layers on the end are on opposite sides of the >> cable. > > You want to describe the rigid ends as outlines of a composite? That > attaches high-level semantics to a low level concept in an inapropriate > way. > > Here you need outline layers with attributes that tell the autorouters > not to cross the lines on certain layers. > >> * buried vias are limited to certain pairs of layers because of the >> way the fab is assembling the board. > > A DRC problem. With hole layers, the GUI tool to add/manipulate these > hole layers can provide a view on the layer stack that represents the > stacking and drilling order, just like you once proposed as an > underlying data structure. The tool would refuse to configure holes > layers that cannot be drilled, unless you say "please". > >> * 400 instances of a standard via, but the user needs to modify the >> pad stack on just one of them, and only for one layer. > > Vias may be COW by default, like they are now. But you can decend in > non-copy mode into the composite, so they all change. That composit is > also the master copy in the Via menu, so that future vias of that type > are affected by the edit. When you edit the via definition in the Via > menu, you may need to answer a question if you want all existing > instances to change, of only new vias. > >> These are all examples of a need for both a semantic and data >> heirarchy, where parts of your design are grouped together and treated >> as a single object, sometimes replicated, sometimes customized. What >> we call them is not important. >> >>> Well, yes, it can, except that a via is not sufficiently special to >>> justify the distiction. What would we have in a composite, the layout >>> being the top-level composite? >>> >>> Vias >>> Elements >>> Composits that are not Vias or Elements >>> Lines >>> Shapes outside of composits that are not Lines >> >> Consider: you can move a via, but for lines, you can move either the >> line or its endpoints. For a polygon you can move its corners. Ah, >> but a via can include polygons and
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 4:39 PM, DJ Delorie wrote: > >> It is the exporter's job to understand drilling. For geometry >> capture, all you need to know is the shape. Modules with no "need to >> know" should not know. > > The autorouter needs to know not to run traces across unplated > holes... > This is what bothers me about a hole layer, un plated vs plated, the holes do not define electrical contact, the plating does. Or, rivits, or the soldered wires on hand assembled multilayer boards. Well with silver ink circuit printing. The hole in the sprayed on insulators does define the connectivity > > ___ > 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: General Layers questions
On Mar 18, 2011, at 4:37 PM, DJ Delorie wrote: > >> Still, I do not see a need for outline layers anywhere, except as an >> attribute on a graphical layer that tells an exporter where to stop >> drawing. > > Hmmm... so you think PCB should let the user place an element in a > physically impossible location, because it doesn't care about the > outlines? > Yes, I hate how pcb used to limit moving footprints silk off the edge of a board. Yes easily solved by adding the outline layer. It is also useful for staging your placement. Perhaps color portion off of the outline of it's base layer? In other words, if you place an element over a transition from rigid to flex, where the rigid or flex that has the most pins is defined as the base layer, I have used flexes where components are on the flex portion. Avoid resistors and ceramic caps, they tend to get their end caps ripped off, bit a sc-70 works fine usually. > > ___ > 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: General Layers questions
On Mar 18, 2011, at 4:17 PM, Stephan Boettcher wrote: > DJ Delorie writes: > I expect the plugin mechanism to be the way to write *all* the core bits, though. >>> >>> The more important it is, that what is below the plugin mechanism is as >>> general as necessary, and since that is difficult to judge up front: as >>> general as possible, without compromising the final goals. >> >> As general as neccessary, but not as general as *possible*. > > But we cannot know what is necessary. > >>> On top of that is a memory representation, that introduces the concepts >>> of elements, vias, surface-layers (layer sets: copper, mask, silk, >>> courtyard, keepout), connectivity, >> >> This is the part I wish we were discussing. > > As John said, bottom up works better in the long term :-) > >>> It provides basic operations on these concepts. The implementation of >>> these concepts builds on the objects of the storage data layers. It >>> must not be an error if a via has two holes, a polygon shaped hole or >>> silk in it. DRC may flag such things, but it must not be an error. >> >> There must be *some* limits, however, or the tools cannot be written. >> Defining a "hole" in a silk layer is nonsensical, if you wish to >> support it, we cannot define what the tools would do with it. > > Why not? The tool can move it arount and not much else, like with all > objects on a sliklayer. > > But that's why I argue for hole layers. A hole is a shape on a hole > layer. The layers attributes define what needs to be drilled. > Actually, they only define to which layers they electrically conduct. > That is all the tools needs to know until checkout. DRC checks if all > shapes are circles, unless the shape has a DRC overide attribute. > > There would be one hole layer for each drill pattern, i.e., one, unless > there are partial vias. John's insulating layers will be mentioned in > the attributes, so they get drilled too. > What you call a hole layer is what I consider the insulating layer. Or do your hole layers span physical layers? Mimicking the ability of the process. (required to make the blind and burried vias your design dictates) Side note, the full stackup is a core part of the pcb design and should be chosen at an early stage. Meaning that all the materials are chosen and dimensioned. An example is: a four layer board is two double sided boards with prepreg between. Such that the top copper, fr4, and second layer are a hole layer. The bottom copper, fr4, and third copper layer are the next hole layer. And the third hole layer is the top copper all the way to the bottom copper? > A via with variable hole size for different layers must be built as a > composit with multiple holes on as many hole layers. Inefficient but > appropriate for such an obscure case. > >>> The attributes that this memory representation and it methods >>> understand shall be in namespace "pcb:" and unknown attributes in >>> that namespace shall emit warnings. >> >> You assume that attributes are the way to organize groups of things. >> Why? > > So that everything is just shapes on layers. Very simple, very powerful. > >>> Higher level parts of the concepts "element", "via", "surface layer" >>> may be implemented in plugins. >> >> How does a move tool plugin interact with an element plugin, then? > > The memory core representation provides methods to move, rotate, mirror > shapes and composits. (Element composits may have an attribute that > forbids mirroring.) To bring an element to the other side od the board > is method of the Element plugin, relying on attributes of the relevant > layers how they map to the other side. > > I don't think that the concept of vias and elements shall be fully > implemented in plugins, for efficiency, and since most other plugings > may need refer to these concepts. At least some callback hooks need to > be specific to elements or vias, that a plugin can register. So that a > plugin can intercept composite methods (e.g., move) for elements or > vias. > > > -- > Stephan > > > ___ > 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: General Layers questions
On Mar 18, 2011, at 4:02 PM, DJ Delorie wrote: > >>> Except gerbers have special cases for thermals and pads, for example. >> >> So there need to be attributes on shapes. > > No, the exporters really need to have access to the whole collection > of shapes that means "pin" so they can do pin-specific things. If the > exporter doesn't need that high-level access, then the default action > breaks it down into shapes and exports them individually. > > The gerber exporter needs to be given a whole "pin" because it has a > command that means "put pin here, with this aperture and thermal > settings". If you wait until the core descends to "circle, arc, > line", it's too late to look at the attributes and figure out what's > happening. CAM tools know about this, and can adjust thermals and > pins as needed, but in PCB's case they can't do it because we break > pins down into raw shapes. > >>> and containing other layers as sub-layouts. I have never disagreed >>> with this! >> >> Oh. My understanding of composites is different. I assume a composite >> contains shapes that go on a global set of layers. > > This is part of the communication problem we're having, yes ;-) > > Consider these: > > * A footprint is a global resource, but an instance of a footprint (an > element) must be mapped to the physical layout. When do you manage > the footprint as an element (indivisible) and when do you access its > parts (changing pad size)? > > * A sub-circuit that's replicated N times on a board. > > * A flex cable that has 4 layers at each end, but only 2 layers in the > middle. The extra layers on the end are on opposite sides of the > cable. > > * buried vias are limited to certain pairs of layers because of the > way the fab is assembling the board. > > * 400 instances of a standard via, but the user needs to modify the > pad stack on just one of them, and only for one layer. > > These are all examples of a need for both a semantic and data > heirarchy, where parts of your design are grouped together and treated > as a single object, sometimes replicated, sometimes customized. What > we call them is not important. > >> Well, yes, it can, except that a via is not sufficiently special to >> justify the distiction. What would we have in a composite, the layout >> being the top-level composite? >> >> Vias >> Elements >> Composits that are not Vias or Elements >> Lines >> Shapes outside of composits that are not Lines > > Consider: you can move a via, but for lines, you can move either the > line or its endpoints. For a polygon you can move its corners. Ah, > but a via can include polygons and lines - but when it's a via, you > *don't* move their endpoints and corners, unless you specifically edit > the via. A pin is just like a via, except you *don't* move it - you > move the element it's in. > > Now consider a differential pair. It's a line but you *don't* move > the *line* endpoints, you move the *pair* control points. > > So yes, a via is special. Many other composite objects will be > special too, because the tools need to know what the appropriate way > of interacting with them are. PCB layout is *not* a paint program, > it's a design tool. It *must* understand "the design" if it's to be > the most useful to the user. > I read this as groups in the memory model should have a sort of locked flag, so that tools like move don't dig deeper to move the individual parts of a group, unless forced (unlocked). And that groups need group control point(s) >> When an how to map generic element layers to layout layers is >> another good question. > > Yup. > >> Global layers can be mapped at load time. Local layers inside >> composits must be mapped a runtime, don't they? > > The mapping can be computed at load time, and just stored. I suspect > there'll be lots of "recurse through the data heirarchy" code. > I see a load time generated list of objects in a layer. That gets added to and removed from doubly linked to the composites the objects belong to. This would allow the object to manipulate the list and for the list to get right to the object. > > ___ > 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: General Layers questions
On Mar 18, 2011, at 3:43 PM, DJ Delorie wrote: > >>> I expect the plugin mechanism to be the way to write *all* the core >>> bits, though. >> >> The more important it is, that what is below the plugin mechanism is as >> general as necessary, and since that is difficult to judge up front: as >> general as possible, without compromising the final goals. > > As general as neccessary, but not as general as *possible*. > >> On top of that is a memory representation, that introduces the concepts >> of elements, vias, surface-layers (layer sets: copper, mask, silk, >> courtyard, keepout), connectivity, > > This is the part I wish we were discussing. > >> It provides basic operations on these concepts. The implementation of >> these concepts builds on the objects of the storage data layers. It >> must not be an error if a via has two holes, a polygon shaped hole or >> silk in it. DRC may flag such things, but it must not be an error. > > There must be *some* limits, however, or the tools cannot be written. > Defining a "hole" in a silk layer is nonsensical, if you wish to > support it, we cannot define what the tools would do with it. > I would make it mask out the area that is defined as the hole. Can't put silk on a hole. ( in the gerber exporter ) >> The attributes that this memory representation and it methods >> understand shall be in namespace "pcb:" and unknown attributes in >> that namespace shall emit warnings. > > You assume that attributes are the way to organize groups of things. > Why? > >> Higher level parts of the concepts "element", "via", "surface layer" >> may be implemented in plugins. > > How does a move tool plugin interact with an element plugin, then? > > > ___ > 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: General Layers questions
On Mar 18, 2011, at 3:22 PM, Stephan Boettcher wrote: > DJ Delorie writes: > >>> ... I think the tool we have is pretty good already. Very good. Thanks! >> >> The tool we have already is nearly impossible to maintain, though. >> >>> Please do not expect that users write plugins. The tool is already too >>> good as it is to make is worth the effort to learn how to do that. >> >> I expect the plugin mechanism to be the way to write *all* the core >> bits, though. > > The more important it is, that what is below the plugin mechanism is as > general as necessary, and since that is difficult to judge up front: as > general as possible, without compromising the final goals. > > I'd propose a very basic, very general storage data representation. > Just layers, shapes, and arbitray levels of composites, the layout > implicitly being the top level composit. Everything with arbitrary > attributes. > > On top of that is a memory representation, that introduces the concepts > of elements, vias, surface-layers (layer sets: copper, mask, silk, > courtyard, keepout), connectivity, > > It provides basic operations on these concepts. The implementation of > these concepts builds on the objects of the storage data layers. It > must not be an error if a via has two holes, a polygon shaped hole or > silk in it. DRC may flag such things, but it must not be an error. Ahh, dreaming of a via that is untented, circled automatically, and net named. Instant testpoint! Perhaps by a testpoint tool, that would make pads centered on a trace with the same properties. > The attributes that this memory representation and it methods understand > shall be in namespace "pcb:" and unknown attributes in that namespace > shall emit warnings. > > The plugins define their own attributes. Attributes shall not be > overloaded. If a plugin operates on attributes of the memory > representation, it shall do that via methods of that representation, if > possible. > > Higher level parts of the concepts "element", "via", "surface layer" > may be implemented in plugins. > > > > > I cannot keep up, there are 15 new messages in my inbox, lets see what > what new arguments come up :-) > > I cannot make up my mind if I should continue to argue for hole layers, > or if holes shall be shapes with hole attribute on layers. > >> The fact that the *user* can write them *also* is a side-effect :-) >> >> >> ___ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > -- > Stephan Böttcher FAX: +49-431-85660 > Extraterrestrische PhysikTel: +49-431-880-2508 > I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de > Leibnizstr. 11, 24118 Kiel, Germany > > > ___ > 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: General Layers questions
On Mar 18, 2011, at 3:07 PM, DJ Delorie wrote: > >> That's the kind of "top down" design that produces a tool that meets >> today's requirements in the minimum amount of time, but produces an >> inflexible tool limited to those requirements. > > And your kind of bottom-up design never gets done at all, because of > impossible-to-meet requirements for unlimited flexibility. > Wow all my bottom up designs in shipping products must not exist A few million users disagree. Top down and bottom up are a preference, not set in stone. FWIW I use both methods. My diagnostic tools start by me normally building small useful functions that get then assembled into larger functions. The team working on the top down diagnostics gave up after my bottom up design for lab testing was doing all that they planned and more. To top the cake, they implemented a feature that they were expecting to take two weeks in about 45 minutes because my bottoms up design had functions that were the bulk of what they needed. >> But if you start from a data representation that spans the space of >> the possible, it drives you toward flexibility and extensibility in >> the upper layers. > > The problem is, "the space of the possible" is infinitely large, and > we have a very small finite set of developers. Unless we know how the > tool is going to be used, we don't even know what "the space of the > possible" *is*. > > Being an engineer is partly knowing when enough is ready to ship. Bottom up designs do have high level goals, it's our job to keep feature creep at a minimum. As far as I know I have only asked for file format requirements that are used in current technology mass-produced boards and for extra data to allow the manufacturing and simulation to be enhanced. Layer materials and diamentions to allow impedance measurement in object reports Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 2:19 PM, DJ Delorie wrote: > >> I don't want to end up with the current state that some 'specialy >> named' layers receive special treatment. > > From a practical standpoint, I think it makes sense to have a fast way > to scan for layers of some high-level type, as well as further typing > them by name. > > My original design had an enumerated type for each drawing layer, that > was one of (for example) "copper, silk, soldermask, paste, outline, > other" with flags for "normal, inverted" and an assignment to a > physical layer (1..N). > > That way, when you're doing something compute-intensive like > connectivity checks for "auto-enforce drc clearance" you aren't doing > a bazillion string compares. > You can build a hash for storage in ram, the file format uses strings. This way you get fast integer math with flexibility of not needing to pre ordain types. The cost is on import. Where everything is string compairasons. This is a kind of premature optimization. Steve > Actions that are performed less often, like mapping a footprint to an > element, can use a more open-ended string-attribute with more complex > rules. > > > ___ > 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: General Layers questions
On Mar 18, 2011, at 1:32 PM, DJ Delorie wrote: > >> But at the core, they work all just the same. > > The "core" includes the autorouters, optimizers, DRC, exporters, > reports, and even simple editing - we have a "hide vias" button. How > does that work if you no longer have "vias" as an inherent type? > Via the via tag attached to the generic composite that the via tool made. Sorry had to use the pun. > PCB has a lot of tools that know a lot about how PCBs are designed. > These tools are essential to making PCB a viable layout editor. The > input we need at this stage is from people who design a lot of PCBs, > so we know what kinds of abstractions make sense to expose and what > kinds need to be hidden behind other data structures. > > Maybe to the rendering engines they all work the same, but saying > "they all work the same" *in general* just isn't applicable here. > They don'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: General Layers questions
On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher wrote: > DJ Delorie writes: > >>> Why single out "via" and "footprint" when they are merely members of >>> an open-ended list of possible composite objects? >> >> Because a tool that doesn't deal with real-world concepts in a >> user-friendly way is unusable. > > Yes. The real world concepts must exist, in a higher level. In the > attributes. The HIDs must implement them in a user-friendly way. At > the lowest level, there shall be abstractions. > > The GUI must present footprints, vias, and hierachical sublayouts, both > in copy on write and in truly hierachical fashion. But at the core, > they work all just the same. Then there will be no more question if some > feature is supported in elements or not, or how convoluted a via may be. > I have had some convoluted vias for high speed signals. different diameters on different layers, with different clearances from the surrounding planes. And we really could have udes a DRC that checked if the blind via ended on top of another signal trace. High speed noise coupled on to that trace. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote: > On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote: >> >> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: >> >> >> Ok. So "via" should be a circle element on "hole" typed layer. >> > >> > No. A Via is a composit, consisting of a circle on the hole layer, and >> > various circles on copper layers, and circles on mask layes, and >> > thermals. >> >> The "layer" concept should be physical, not a metaphysical abstraction. >> Objects in a layer may contain holes, but a "hole layer" is nonsensical, a >> toxic conceptual shortcut. An "outline" layer is similarly bad: the >> insulating layers may all have the same shape sometimes, but not always. > > The outline layer will be part of 'physical' layer. So if you have 2 > 'physical' layers with different shape, it will play nicely. > > What I am prosposing is 2 level concept. There will be 'physical' > layers, so you can add properties to them. And than there will be > 'drawing' surfaces. And 'outline' is just drawing suface telling the > 'physical' layer it's edges. > > But I am not convinced that we need special 'hole' typed layer. Maybe we > can things like 'holes' which are not part of any specific layer just > float in space. I thing that it would work. >> >> Trying to model things that aren't layers as if they were layers is one >> common mistake in this kind of tool. Equally common is leaving out layers: >> the insulating layers in a PCB are just as important as the copper, and have >> their own properties (shape, thickness, material, etc.). They're a critical >> part of the layer stack. > > The problem I see with the insulating layers is that there is nothing on > them...So you don't need them as 'drawing' layers. But I agree that > there should be a way how to add some attributes to them. Embedded resistor and capacitors are in holes in the separating layers. Some separating layers are more like a solder mask and sprayed down rather than FR4 and prepreg. Just because standard FR4 Fabs don't usually use any drawings on that layer, should not preclude it. Now the exporter may barf if it finds something it can't cope with, like a line drawn on a separator layer. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:08 PM, DJ Delorie wrote: > >> I agree here, that a via and a footprint are essentially the same >> thing. > > Except the user doesn't interact with them the same way. > This is a UI representation, not a layer geometry issue. A via tool that makes the proper composite object and stamps it at a coordinate, is the via tool. Even if the UI is a script interface, a via macro in the layers file, or a GUI window and mouse pointer. A footprint tool takes the composite from a library and stamps it down. In the underpinnings the layers now has two composite objects, groups, or what ever you want to call it at two locations on the layout. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:53 PM, DJ Delorie wrote: > >> Why single out "via" and "footprint" when they are merely members of >> an open-ended list of possible composite objects? > > Because a tool that doesn't deal with real-world concepts in a > user-friendly way is unusable. > User friendly is a subjective qualifier. IMHO: free rotate buffer is not user friendly. Where a group(collection) that has a specific rotation parameter 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
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:52 PM, John Doty wrote: > > On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: > >> Generaly you are proposing that there should be a special type of >> footpring called 'via' and it should receive extra care. > > Why single out "via" and "footprint" when they are merely members of an > open-ended list of possible composite objects? > >> >> I am ok with that, I just need to figure out how to handle mapping from >> footprint layers to layout layers. I don't want concept of 'top', >> 'inner', 'bottom' layer at all...that is too naive for me. > > A general mechanism for describing composite objects is needed. > I agree here, that a via and a footprint are essentially the same thing. A via is a hole through some layers of the board and some copper bits on those layers, also known as a pad stack in some board packages. A footprint is traditionally a grouping of many pad stacks and additional layers. No real special treatment in the descriptions of the geometry. A group that origin is at x,y,rotation,layer Make a generic group (sub layout) concept and your good to go. A round via should have a rotation, it allows easy control of the thermals orientation. This is not to say that a special via macro could not be setup that makes the simplest traditional via or blind/buried vias. These groups should not be flattened into the layout until export, thus we loose the free rotate issue that we have today (lossy rotations). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Looking at the layers I would like to propose that the copper layer be made not specific to copper, but a conductor. Some common alternatives are silver ink traces, embedded resistors, or even more exotics like ITO (used for touch screens). For the footprints, They should have a routing keepout, different than a placement courtyard. That is don't rout on these layers in these regions. Pins and pads should have antipads that is when the pin goes through a plane this antipad is the area in the plane that is cut out for the pad on that layer. High speed signals often have the ground plane under the pad removed to minimize the capacitance/impedance change from the pad's greater area. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
As for mask and paste layers, we may want to have a way for an object in one layer be a transformed version of another layer. Example, clearing solder mask for a line, or pad, or whatever would create a linked object in the adjacent mask layer with a growth in size of size X. Where X can be 10% or could be +10mil. Just a basic transform. On a side note, how could we make special track parameters available? Meaning differential and single ended impedance. Like drawing a uber trace that is really a matched diff pair. That is a composite trace that is drawn as a virtual trace. Steve On Wed, Mar 16, 2011 at 12:51 AM, Martin Kupec wrote: > On Tue, Mar 15, 2011 at 06:50:01PM -0400, DJ Delorie wrote: >> >> Our current way is that copper objects have implied mask openings. I >> suppose we could continue that, as well as adding some paste metrics >> there too. This is *in addition to* a separate paste layer for >> user-defined paste, or for footprint-defined custom paste, of course. > > Right now (as looking to the core) LineType has only "Clearance" > attribute. No Mask/Paste. Pads has in addition "Mask" attribute. > > And to be clear. There will be "mask layer". So you can draw anything > there and it will be masked/unmasked. But it will not be "in addition > to" some implicit mask attributes in some objects. > > What I am trying to figure out is how we want to draw some "additional" > object on that layer according to an object in some copper layer. But > it seems that we don't have to. Footprints will have its own mask layer > which will be drawn in our mask layer. And normal lines usualy don't > have mask/paste so we don't have to worry about. > > Martin Kupec > > > > ___ > 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 very slow on new laptop
Can you up the ram available to the graphics? I recall that had a large impact on performance in prior Email threads. Steve On Mar 12, 2011, at 4:07 PM, Thomas Oldbury wrote: > I have recently got a new laptop, a Lenovo ThinkPad X201. However, I'm > having a rather annoying problem with pcb. When trying to zoom in or > scroll, it is incredibly slow - taking a second or more to do any > action. I'm running pcb on another laptop and it doesn't have any > problems, it's very fast, and I'm testing them with the same pcb file. > I suspect that it has something to do with the Intel integrated > graphics, as the other laptop has ATI. Has anyone encountered these > problems? btw, new one is running 32-bit Ubuntu 10.10 (soon to upgrade > to 64-bit), the other is running 64-bit 10.04. PCB version is the same: > 20091103, plucked from the Ubuntu repos. > Many thanks. > > > ___ > 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: automatic pon button
relays and computers http://www.youtube.com/watch?v=n3wPBcmSb2U On Mar 10, 2011, at 2:52 PM, Joe Chisolm - Gmail wrote: > > > On 03/10/2011 04:10 PM, Karl Hammar wrote: >> Balogh: >>> http://www.robotika.sk/projects/virtuallab/atxswitch/images/ATXswitch.png >> I see, you "press" the button as soon there is +5VSB, but in my >> case I need power on the +12V rail, else the motherboard is totally >> powerless. So I have to start the power supply first. >> > If the motherboard power is really dead (no V standby) until you power the > 12V rail then your only source of power to do the power on circuit is off the > mains unless you can pull Vsb out of the power supply. If, however, you see > +5 on the WOL connector when the 12V rail is off then that is your source. > You can do this many ways. A simple way is 2 relays. A couple of DPST will > do the trick. Take the +5 off the WOL, through the NC side of relay1 and to > the coil of relay2. The NO side of relay 2 is connected to the power switch. > The coil of relay1 is driven by the 12V rail. When the 12V rail is off +5 > will energize relay2 that will attempt to turn power on. As soon as the 12V > rail comes up relay1 will energize and stop the coil power to relay2 thus > "releasing" the power push button. This is a always on type of setup. The > only way to turn the unit off and keep it off is to unplug the power cord. >> Back to your picture. I have not found any spec for the wol connector >> but it seems that the wol pin is +5V active high. So, in your case >> wouldn't it be simpler just to momentarly short the +5V and wol pins >> of the wol connector to start the pc? >> >> Regards, >> /Karl Hammar >> >> --- >> Aspö Data >> Lilla Aspö 148 >> S-742 94 Östhammar >> Sweden >> +46 173 140 57 >> >> >> >> >> ___ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> > > -- > Joe Chisolm > Marble Falls, Tx. > > > > > ___ > 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: Google Summer of Code 2011
At work we use odb++ valor files. But I would not suggest removing gerber file exports. Every board house understands them. Steve On Mar 6, 2011, at 9:11 AM, John Griessen wrote: > On 03/05/2011 02:41 PM, Markus Hitter wrote: >> it might be less work to replace or complement the current track drawing >> stuff with a generic SVG drawing library. Then every >> layout is also a valid SVG file and can be edited with other applications >> as well. The tricky part is keeping the connection to >> the schematic, of course. > > You need connection to the fabbers too. What direction is fabbing going? > Outlines? > I've heard some mild rumoring about RS-274X being passe, but not what is > proposed to replace it. > > Anyone? > > > ___ > 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: Google Summer of Code 2011
PCB supports polygons. Filled paths yield a polygon. and PCB can cope with outputting to RS-274X The point is that I wanted something not PCB centric. RS-274X can support polygons as well, it is RS-274D that can't and must be vector filled (painted). But footprint to RS-274X translation is not important, you would need many files to support all the required layers in a footprint. It is conversion between pcb and the open format that is important, kicad and the format, mentor and the format, or the list goes on. The converters will have to cope with the shapes that are not supported in the format that they need. Such as making a stipple pattern of small circles. (not a good design but effective) If the open format supports fancy bézier curves, well then adding that to pcb might be a nice thing, especially if users find it useful. The idea of this is to support future needs and desires. You can make complexity levels in the footprints. Level 1: Only simple lines, rectangles, and circles. Level 2: Adds polygon support Level 3: Add Arc support Level 4: Adds ellipse support Level 5: Fancy bézier curve support Well I guess that I would really use a list of required features, not a rigid level structure. Steve On Sat, Mar 5, 2011 at 11:17 PM, John Griessen wrote: > On 03/05/2011 05:04 AM, Peter Clifton wrote: >> >> It depends on the primitives used - but I expect it is not too hard >> either way. SVG does of course support a lot of things which RS-274X >> cannot though. > > OK. YOU can make SVG that is easily translatable, but if you had a > footprint tool that used it because so much content is available from other > sources, > you might get the outlined content very often and have to convert it > to stroked lines. Having a translator would enable using SVG, but > using SVG would not allow importing-to-PCB of any kind of drawn trace > until you created an outline-filling-in routine so you have the > RS-274X compatible stroked line primitives. > > So, the essence of what's needed to get more easy use of existing > drawing tools like inkscape is a SVG<-->PCB translator with an > outline-filling-in routine. > > Then you could make a stand alone tool based on inkscape if coding seemed > easier that way. > Otherwise basing it on PCB, (requiring scheme and maybe C to do it), is it. > > John > > > ___ > 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: Google Summer of Code 2011
On Mar 5, 2011, at 5:55 AM, John Griessen wrote: > On 03/02/2011 06:49 AM, Stefan Tauner wrote: >> my idea is some combination of the existing propsals: >> - Gschem parts manager or parts database (glue) >> - IPC Footprint Calculator (pcb) >> and my own idea: a stand-alone pcb footprint editor. > > A footprint calculator that uses IPC guidelines plus an editor > as a standalone would be great! > > John > -- > Ecosensory Austin TX > > My thoughts on this were to have an intermediary format meant to be open. I thought basing it on svg with layers defined to be each layer in a layout. This way the svg footprint has some major benefits. Mostly a pre defined standard. Svg with some attributes added. Viewable directly in modern web browsers. Raw svg editors exist. Such as inkscape. More folks would be willing to contribute to an open non tool centric footprint. Converters can be made to and from other formats for exchange, Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Please test new grids for GTK PCB
> Steven Michalske wrote: >>Did not apply cleanly against git head at > 359a02cfe25e32aec7d2985c8f368fbfdcd954fa > > Sorry i can't get it, but i check patch for errors on latest git tree > available > on time of post. (p.s. i'm too novice in git, can you give me exactly > commands > to set git head to your hash code and reproduce error?) > > If it applies to top of tree then great, FYI git checkout 359a02cfe25e32aec7d2985c8f368fbfdcd954fa This command will create a "Detached head" at that checksum. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Feb 24, 2011, at 7:39 PM, Kai-Martin Knaak wrote: > Colin D Bennett wrote: > >>> ^__ Properties of the view, not the underlying data - I'd prefer to >>> abstract this to the renderer. >> >> I agree that color does not belong in the layout file. I may keep >> changing my preferences on my pcb color theme, but I don't want to >> update all my layout files to take advantage of an updated color theme >> -- UI preferences like color theme should definitely not be included in >> the .pcb layout file itself. > > I partly disagree. Some information on color should be in the layout. > > Real world use cases: > > 1) Footprints only use the first two copper layers. Convert buffer > to element converts tracks on the first layer to pads on top. Tracks > on the second layer get pads on bottom layer. Consequently, a pcb meant > as a work sheet for footprint creation needs different colors than a regular > layout. > > 2) Four layer layouts have different demands on colors than two layers. > If I switch between projects with four layers and two layers, it is a > hassle to manually load the fitting color scheme. > > 3) If I add some layers in the middle of the layer stack, colors of > layers below shift to other layers. So this new layer stack clearly > needs a special color treatment. > 4: setup so that ground and power nets are hilighted with different colors. I guess that this is storing hilighted colors. I don't care where the color is stored but mapping to a palet sounds good. > The layout may not contain the whole explicit color information. Just > a name of a color scheme may be enough. If no matching color scheme > can be found in $HOME/.pcb/.color, or in the project dir, some default > scheme would be used. > That way you can have both. Central color config files and layout chosen > color schemes. As a bonus, my color blind colleague can keep a > palette adjusted to his needs and we can still both work with the > same layout files. > > ---<)kaimartin(>--- > -- > Kai-Martin Knaak > Email: k...@familieknaak.de > Öffentlicher PGP-Schlüssel: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 > > > > ___ > 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: Metric, Imperial, Rounding, DRC, and board houses
I use mil grids, as many boards houses expect mil units, like yours. PCB layout is engineering, engineering involves tolerances... I start my traces from off grid components so that the stub going from the pin/pad is off grid byt quickly becomes on grid after the first 45 degree bend. Steve On Mon, Feb 21, 2011 at 2:44 PM, Stefan Salewski wrote: > On Mon, 2011-02-21 at 15:23 -0700, Russell Dill wrote: >> I'm starting a new design and all my components are metric based, >> including a few 1mm pitch BGA components. I'd really like to do the >> layout in metric, but I'm worried about two factors. The first of >> which is that PCB does not yet have the option to store things >> internally in metric (at least from what I understand) so rounding may >> occur on that end. In addition, my board house rounds everything to >> 2.4 format (0.1 mil). I can envision several scenarios where my design >> meets DRC in PCB, but fails when I send it to the board house. >> >> What is my best option? >> >> Just use imperial units and cope with weird grids? >> >> Use metric spacing, but recalculate DRC based on worst case rounding? >> >> Some other option? >> > > Use metric grid/unit, I guess most of us use that. > Internal resolution is 0.01 mil, which is good. Of course nm would be > better. One problem for me was, that a few 0.01 mil garbage lines were > generated for the layout. Not a big problem. Some not really smart > people have tried to use a very very fine grid, 0.01 mm or so. That is > like using no grid at all, I call that silly. Try to use a useful basic > grid like 0.25mm grid if most of your parts have 0.5mm pitch -- I think > that was what I did, I am not sure. Important: Enable snap to pads/pins, > so you can make good connections to imperial parts which are not on the > metric grid. > >>my board house rounds everything to >> 2.4 format (0.1 mil). > > Strange -- so pitch of metric parts may vary from pad to pad a bit. That > was a problem in very old days of PCB, when 1mil internal units was > used. > > > > > ___ > 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: polygon regression in pcb+gl
Woo Hoo! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
Safari and Firefox, on OS X is quite fast, nice smooth scrolling. Steve On Sun, Feb 20, 2011 at 6:59 PM, Felipe De la Puente Christen wrote: > On Mon, 2011-02-21 at 03:32 +0100, Kai-Martin Knaak wrote: >> Ethan Swint wrote: >> >> > I was expecting just to get back "git >> > clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git" or some such, but in >> > response Peter has posted what looks to be an excellent guide to his >> > blog at >> > >> > http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html >> >> Is it just me, or is anyone else also having a speed issue with Peters >> blog? Scrolling takes about two seconds to jump by a screen... >> (My browser is epiphany, the default with debian) > > I can confirm with firefox(gecko) 3.6.12 and midori(webkit). I think > it's something related to the background. Full CPU usage for the wait > time. > > Best Regards, Felipe. > > -- > Felipe De la Puente Christen > MSN/GTalk : fdelapue...@gmail.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: General Layers questions
Trashing the spam Layers should get attributes. Conductive Thickness Resistivity Material Dieletric constant Are a few I can think of off the top of my head So a way to attach arbitrary attributes is a good plan for flexibility. Need for other kinds of layers. Like keepouts and part outline. Perhaps a layer plugin concept. A layer that says it wants to be processed by a drc plugin of type foo. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: High Temperature Connector
Or 1/4 inch quick disconnects. On Feb 12, 2011, at 12:52 PM, John Luciani wrote: > Thanks to everyone for the suggestions. > > The Phoenix style are a bit too tall. > The Omnetics are too expensive but the Omnetics site did mention the materials > that the 125degC and 200degC rated were made of so I was able to find parts > at Tyco and Molex with the high temp materials. > > I had originally specified the Zierick 1245 IDC. Mfg is requesting a tool-less > option at final assembly so we started to look at different options. > The majority > of the low cost connectors have 85degC or 105degC operating ratings. > > The AVX looks similar to the Zierick (as far as function and installation). > The Zierick is probably less expensive. I will search the AVX site for > other options. > > I did not see operating temperature ranges for the Zierick so I have a call > into the Zierick salesman. > > Thanks again for the suggestions. > > (* jcl *) > > > ___ > 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: OT: High Temperature Connector
What about just soldering the wires? On Feb 12, 2011, at 12:52 PM, John Luciani wrote: > Thanks to everyone for the suggestions. > > The Phoenix style are a bit too tall. > The Omnetics are too expensive but the Omnetics site did mention the materials > that the 125degC and 200degC rated were made of so I was able to find parts > at Tyco and Molex with the high temp materials. > > I had originally specified the Zierick 1245 IDC. Mfg is requesting a tool-less > option at final assembly so we started to look at different options. > The majority > of the low cost connectors have 85degC or 105degC operating ratings. > > The AVX looks similar to the Zierick (as far as function and installation). > The Zierick is probably less expensive. I will search the AVX site for > other options. > > I did not see operating temperature ranges for the Zierick so I have a call > into the Zierick salesman. > > Thanks again for the suggestions. > > (* jcl *) > > > ___ > 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: OT: High Temperature Connector
Might look into Phoenix contact and their reflow capable parts. On Feb 11, 2011, at 6:30 PM, John Luciani wrote: > I am looking for a low profile wire to board connector - either two > contacts 5A per contact or four > contacts 2.5A per contact. I need a temperature rating of at least > 110degC (preferable >> 120degC). UL recognized is required. > > Being able to remove the wires would be nice but is not a requirement. We have > been able to find 105degC rated connectors but nothing higher yet. > > Thanks. > > (* jcl *) > > > ___ > 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: Status of gEDA - gschm, pcb?
On Feb 10, 2011, at 10:09 AM, three_jeeps wrote: > Hello: > I am considering using gEDA suite to do some design. Is the tool suite > currently actively supported and worked on? > Based on google searches, very little traffic wrt the suite has occurred over > the last 2-3 years. > > Where can I find the most up to date symbol library for gschem? (Do ppl > actively > contribute to it? For example, are there libraries for Atmel and TI > processors?) > We have default libraries, you will find that default libraries end up getting overridden and augmented more often than they are just used. What gEDA gives You here are many ways to Make symbols with symbol generators such as djboxsym. This is posable because of out plain text formatted library. Don't let a library make a decision for you. We use cadence at work and never touch the default library. I now have two friends that chose eagle because of it's library and now don't even use its library. For the microcontrollers. I think geda would be a winner because I would write a script that took in the publishing from the data sheet and then made a symbol. Then since datasheeta don't vary much for a particular company and series of uC then you have access to use them all Steve > Can PCB support multilayer boards? (4,6,8?) > > Thanks > John > > > > > ___ > 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: Soldering iron tip turns black
On Feb 5, 2011, at 6:47 AM, Peter Clifton wrote: > On Sat, 2011-02-05 at 15:07 +0100, Kai-Martin Knaak wrote: > >>> (I personally try to use Leaded solder as much as I can). >> >> Did you ever try a quality no-lead solder like Balver SN100C, or Felder >> SN100+ ? Unlike the cheaper SAC alloys, these solders feel comparable to >> leaded solder. > > Yes, good Lead free solder is not so bad. Most of the time though, when > I'm soldering - I'm repairing existing equipment made with a leaded > process, so I tend to keep leaded solder. Since I'm not doing production > work, I can also get away with leaded solder for new work as well. > > I understand it is important to keep leaded and lead-free process stuff > separate to avoid contamination - I'm not sure if that is a legislatory > or process requirement though. Solders are alloys, if you change their ratios you change their properties, like melting point and strength. > >> I had good experience with steel wool. If the tip repels the solder, give >> it a decent rub. Our new soldering stations by OKi come with a bunch of >> brass wool. Due to their heater concept, the tip temperature does not >> overshoot. In addition, they detect when the tip is in the cradle and >> reduce the temperature. > > I use Metcal (Now OKI) irons. I own two SP-200 units, and really swear > by them - even if you can't get truly tiny tip cartridges in that > series. They are AMAZING irons for heavy work, as they are really > powerful. The PSUs and irons sell for about £70-80 on Ebay second hand. > >> My only objection: You use leaded solder. ;-) > > I guess we've got to live lead-free in this industry eventually, but I > will hang on to Leaded whilst I can. > > -- > 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soldering iron tip turns black
Some tips about tips. Remember to always store your iron tips with a ball of solder on them, this helps prevent the tip from corroding in storage. Don't wipe the tip before putting it back in the holder, your wipes on the moist sponge should be when you take the tip out of the holder. Again the molten solder on the tip helps keep the tip from oxidizing while hot. Steve On Fri, Feb 4, 2011 at 3:03 PM, Rob Butts wrote: > I found it. 60/40 solder's melting point is about 188 degrees C so I > had my iron way too hot; up around 320 degrees C. I'll try turning it > down quite a bit. > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soldering minute smt
A good pair of tweezers works for me. note a good pair, not garden variety, I curse when I get to a lab that has bad/cheap tweezers. http://www.techni-toolcatalog.com/lg_display.cfm/catalog/128/page/243 I have a set of their ceramic tipped tweezers that are fantastic. Steve On Fri, Jan 28, 2011 at 9:09 AM, DJ Delorie wrote: > >> I don't suppose anyone has made one? > > http://dammitcoetzee.com/2009/07/how-to-make-soldering-fine-pitch-surface-mount-rediculously-easy/ > > > ___ > 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: Soldering minute smt
I can't say enough about using flux for soldering. I often use the no clean flux with a metal tip dispenser. like mouser 577-SF-01 Although it seems that if you don't want to buy a gallon of liquid flux your getting a pen, which I dislike over the dispenser. It is a matter of taste. The other tip I have is that you have to use solder to desolder. Steve On Thu, Jan 27, 2011 at 2:55 PM, Stephen Ecob wrote: >> Flux is the secret... Applying flux is the crucial step to success. > > +1 > > Get yourself some good quality flux, it makes this sort of problem disappear. > I've used Electrolube SMFL (aerosol with dispenser tube) with good > results, but there are many good options. Look for something with > "surface mount rework solder flux" or similar in its description. > > > ___ > 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: directly connecting two nets?
On Sun, Jan 23, 2011 at 6:30 PM, John Doty wrote: > > On Jan 24, 2011, at 5:51 AM, Kai-Martin Knaak wrote: > >> Stephan Boettcher wrote: >> >>> You need to invent some 2-pin symbol with some special attributes, and >>> teach the pcb gnetlist backend(s) to interpret those attributes >> ^^^ >> >> If there is a way to mark two net-names as physically the same net, >> then each and every backend should act accordingly. > > By default, yes, I agree completely. > >> It would be an >> invitation for nasty surprises if some back-ends would support the >> fusion and others don't. This calls for an interpretation by the >> frontend. > > The problem is that each downstream tool potentially has its own model of > connectivity, so the default model in gnetlist must address the "lowest > common denominator" here. I think that would require that gnetlist simply > merge the nets, choosing a common name. But that's probably not good enough > for users of specific tools with advanced capabilities. > > Therefore, these semantics should not be in the front-end. They should be in > the middle layer (gnetlist.scm), where a plug-in or back-end can modify the > semantics as needed for the downstream tool. Putting them in the front-end > will case trouble similar to that we now experience with slotting, where the > front-end model doesn't fit simulation flows. > We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? Steve > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: Soft and Hard symbols
On Jan 19, 2011, at 12:10 PM, DJ Delorie <[1]d...@delorie.com> wrote: gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. gEDA is more like a design suite, a collection of tools and related stuff. And before you said it was a tool. Not the computer science meaning of toolkit like GTK. We're doing computer science, we have to use the CS meanings of things. A toolkit in CS is primarily a library. Not quite, a library is a component of a toolkit, but there are many other components of a toolkit. Taking qt as an example. There is the ui designer application, the core libraries, and documentation. Naming the few top level components. gEDA is more than just a library. See above, a toolkit is much more than just a library. Would you call libpng a toolkit? No it is a library. Would you call OpenOffice a toolkit? No, it produces documents that are largely independent. Each application stands on it's own. It has a library. What about Firefox? A single application. It has a library. gEDA? It has a library. And a few other libraries (libgeda, symbols, scheme, ...) Assistant applications that manage those libraries to design circuits. Gschem, gattrib, xgschem2pcb, djboxsym, and many others. Documentation like your excellent tutorials for pcb. Guides on how to do simulation. Just because we are not compiling c code, does not mean that we are not a toolkit. I have now determined that my original statement that not in a computer science meaning is wrong, gEDA meets the compsci meaning of toolkit very nicely. The argument you are using to decrease the value of John's opinion is purely based on semantics. Our users could not care less about the term toolkit verses tool suite vs many applications in a folder. The gEDA developers are doing computer science but our users are not. The gimp toolkit allows it's users to make gimp like applications, the geda toolkit allows it's users to make electronic designs. It's all semantics and context. But in John's defense if geda was treated just as a tool ( note the singular unified meaning of tool ). Then a huge portion of flexibility is lost. And it would become as limited as many of the other tools out there. Such as eagle, kicad, or, other printed circuit design tools. I have seen this in many different projects and designs. An I work at a company with arguably the cream of the crop user interface and user experience designers, Apple. Yet we often drive away power users because things were made too simple, for one flow. Steve ___ geda-user mailing list [2]geda-user@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: Soft and Hard symbols
Dj you own a tool box, I've seen you build mechanical things. gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. If I want to clean up the cylinder an engine block I get out an engine block hone, I do not get out a wire brush. Now in gEDA terms. When you want to edit a schematic, you break out gschem, and when you want bulk changes to attributes you get out gattrib. and when you doing something crazy you make a new tool, say in your favorite language for the job. 100% agreement with John; gEDA is a toolkit, not a single tool. being through, Kit: 1. A set of articles or equipment needed for a specific purpose : a first-aid kit. Not the computer science meaning of toolkit like GTK. Steve On Wed, Jan 19, 2011 at 6:08 AM, DJ Delorie wrote: > >> But gEDA isn't a tool: it's a toolkit. > > I consider gEDA to be a tool. gschem, gattrib, gnetlist - all tools. > Thier job is to help engineers automate the design process, to do > that, they have to know a lot about electronics design. > >> The less a tool knows about . . . > > You just said it wasn't a tool. > > > ___ > 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: Bugs, warts and feature requests (5)
On Tue, Jan 11, 2011 at 4:03 PM, Kai-Martin Knaak wrote: > • gerbv feature request: Add a view mode that shows only the difference > of two layers. This would be handy when I have to asses the changes that > I made to an existing design. Make the layers XOR logically but not the colors. i.e. old layer red, new layer green, deleted portions would show up in red, new portions would be green. Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bug triage
> > Maybe we are targetting the "wrong" OS ;-( > Nope, I like my mac os install, and engineering colleges are seeing a large uptick in mac usage in colleges. It is a perk to have a computer that can OS X, Linux, and Windows. > Maybe the unofficial windows ports are more important than we think ;-) It is important to have easy to install packages. I find installing source packages trivial, but I am not the average user. My colleges that want an install for OSX dislike need to install xcode, mac ports and compiling the whole deal. One of these days I will study how Inkscape makes their OS X package and make one for gschem and pcb. > > I will look into these statistics this evening, to have an informed opinion. We can't have that ;-P only uninformed conjecture! Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: European symbols?
On Jan 2, 2011, at 11:12 AM, "Johnny Rosenberg" wrote:
> Den 2011-01-02 13:13:55 skrev kai-martin knaak :
>
>> Johnny Rosenberg wrote:
>>
>>> I didn't add or modify any invisible text except those very
>>> unnecessary (?) author- and license lines. I guess I should
>>> remove them entirely.
>>
>> License lines are a necessity for sharing. Else, you'd have to
>> put some license information in the environment of the share.
>>
* the footprint attribute is invisible
>>>
>>> Didn't change that either. Why would you like them visible?
>>
>> Because the footprint information can be scanned at a glance
>> in the schematic. The footprint needs attention just like the
>> value or the refdes. So it is convenient to have it visible
>> by default. If I don't want to see the footprint attributes in
>> finished design I can still hide them with "Hide specific text"
>> in the attributes menu.
>
> But if it is invisible, won't it show up with ”Show specific text” in the
> same menu?
>
>> In addition, the footprint provides a
>> hint what to look for in the layout when I read the schematic.
>> Else, a SO23 transistor looks the same in the schematic as a
>> TO247 with cooler.
>>
>>
>>> 200? Strange. Strange. Looks like 300 to me, except the output pin,
>>> which indeed is 200. I didn't change that from the original symbol
>>> either, though.
>>
>> "200" was just a typo by me...
>> Somewhere in the documentation pin length 300 is recommended. However,
>> nobody could give a reason for this value when I asked on this list.
>> Since pins cannot be differentiated in print from nets, I decided to
>> opt for short pins in my symbols. That is, 100 units, or sometimes even
>> zero.
>
> Well, I agree that short pins are better, I will change them in all the
> symbols.
>>
>>> If it's not too much work, could you modify the 7400 symbol to your
>>> likings and then send it back so I can modify the other symbols
>>> accordingly?
>>>
>>
>> See below.
>
> Thanks.
>
>> Except for the license, the symbol would fit into my collection of
>> symbols in gedasymbols.org. I prefer the GPL as distribution license.
>
> Maybe off topic, but really, why a license at all, when I really don't care
> what people do with the symbols anyway?
Mostly because in some countries authors rights are reserved, and must be
declined.
>
>> As John Doty already pointed out, there is no hard right or wrong
>> with many design decisions. I am, of course, biased :-)
>
> Well, I asked for suggestions and I got suggestions. So far so good. :)
>
> By the way, I was searching for information about the sym file format, but I
> didn't find much. I would like to know what all the numbers mean, for example
> in lines like this:
> ”V 850 500 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1”
>
> The four first is of course coordinates, and there seems to be numbers for
> thickness and colour, but I changed a few of them with no result at all as
> far as I could see. Can anyone point me to some place where I can learn
> everything about this?
>
>
>>
>> /
>> v 20100214 2
>> B 200 200 600 600 3 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
>> T 500 500 9 20 1 0 0 4 1
>> &
>> T 400 4100 5 8 0 0 0 0 1
>> device=7400
>> T 700 0 8 8 0 0 0 0 1
>> slot=1
>> T 400 2400 5 8 0 0 0 0 1
>> numslots=4
>> T 400 1600 5 8 0 0 0 0 1
>> slotdef=1:1,2,3
>> T 400 1800 5 8 0 0 0 0 1
>> slotdef=2:4,5,6
>> T 400 2000 5 8 0 0 0 0 1
>> slotdef=3:9,10,8
>> T 400 2200 5 8 0 0 0 0 1
>> slotdef=4:12,13,11
>> V 850 500 50 6 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
>> P 900 500 900 500 1 0 1
>> {
>> T 850 600 5 8 1 1 0 0 1
>> pinnumber=3
>> T 850 600 5 8 0 1 0 0 1
>> pinseq=3
>> T 750 500 9 8 0 1 0 7 1
>> pinlabel=Y
>> T 850 450 5 8 0 1 0 2 1
>> pintype=out
>> }
>> P 200 300 100 300 1 0 1
>> {
>> T 150 350 5 8 1 1 0 6 1
>> pinnumber=2
>> T 150 350 5 8 0 1 0 6 1
>> pinseq=2
>> T 250 300 9 8 0 1 0 1 1
>> pinlabel=B
>> T 150 250 5 8 0 1 0 8 1
>> pintype=in
>> }
>> P 200 700 100 700 1 0 1
>> {
>> T 150 750 5 8 1 1 0 6 1
>> pinnumber=1
>> T 150 750 5 8 0 1 0 6 1
>> pinseq=1
>> T 250 700 9 8 0 1 0 1 1
>> pinlabel=A
>> T 150 650 5 8 0 1 0 8 1
>> pintype=in
>> }
>> T 200 1100 8 10 1 1 0 0 1
>> refdes=U?
>> T 200 0 8 8 1 1 0 0 1
>> footprint=DIP14
>> T 400 3900 5 8 0 0 0 0 1
>> description=4 NAND gates with 2 inputs
>> T 400 3700 5 8 0 0 0 0 1
>> documentation=http://www-s.ti.com/sc/ds/sn74hc00.pdf
>> T 400 3100 5 8 0 0 0 0 1
>> author=Johnny Rosenberg – johnny.a.rosenb...@gmail.com
>> T 400 2900 5 8 0 0 0 0 1
>> dist-license=None – do whatever you want, I don't care
>> T 400 2700 5 8 0 0 0 0 1
>> use-license=unlimited
>> T 200 900 8 10 1 1 0 0 1
>> value=7400
>> T 400 3500 5 8 0 0 0 0 1
>> comment=use 74_pwr.sym for supply
>> T 400 3300 5 8 0 0 0 0 1
>> comment=this symbol was designed according to IEC-(INSERT SPECIFIC NORM)
>> \
>>
>
> Thanks for all your inputs!
>
> --
> Kind regards
>
> Johnny Rosenberg
>
>
> __
Re: gEDA-user: Resistor values…
On Mon, Dec 27, 2010 at 3:56 AM, Vanessa Ezekowitz wrote: > On Sun, 26 Dec 2010 23:55:04 -0500 > al davis wrote: > >> On Saturday 25 December 2010, Vanessa Ezekowitz wrote: >> > * If the part in question can usually be described by a >> > single value, for the purposes of the signal flow in the >> > schematic that is, then give it a default of "value=0". >> >> No. Zero is almost always wrong. > > Exactly my point - it is *supposed* to be wrong. > > I chose zero here because anyone who sees it in their schematic file should > instantly think, "Oops, I forgot to set the value of that part". From my own > experience, it is easier to spot something that is visibly flat out wrong > than to look for something that is just not there. > > Setting it to zero by default could even be used to signal Gschem to add an > extra highlight to those symbols bearing it. Perhaps the default, > highlight-sensitive string should be exactly "0.0" or some variation of that, > since no sane user would type anything but a single "0" when they mean "zero". > No valid number should be used for a "default" in such a generic symbol. I use 0 ohm resistors often, they are stuffing shorts. a default of ? is obvious, it clearly shows a value that has not been assigned. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
>> >> Setting it to zero by default could even be used to signal Gschem to add an >> extra highlight to those symbols bearing it. > > Yuck. Keep tools simple and clean. Agreed, but if you wanted a DRC highlighter, a ? highlighted would be a great thing to highlight. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Working on a tiny schematics editor
On Dec 26, 2010, at 5:41 PM, Stephan Boettcher wrote: > Stefan Salewski writes: > >> OK, shame on me for missing that option. But I do not think that this >> really proves that a gschem rewrite is obsolete. > > I may believe that writing a second gschem editor is worse use of your > time than improving the existing one, but it is not up to me to judge > how you use your time. > > For your stated purpose, writing this graphical editor seems wrong, but > now that it exists, it is interesing to try to put it to good use. It > may start as a new netlister with integrated graphical viewer. The > viewer may be the best verification that your parser works correctly. > >> There are so many similar problems, wishful improvements. All big task >> currently, no one really does it. Such an improvement should take at >> most some hours in Ruby. > > A really useful result will be a parser with a clean, documented > netlisting API, that people can use to write netlisters who do not want > to use/learn guile. Maybe I should try to do the same for python :-) > I would work on a python netlister in geda. Yes I could pick up scheme again, but I didn't enjoy it when I used it before. >> And this example unfortunately shows one weak point of gEDA: The initial >> authors and experts have retired, functionality may be already there, >> but most of us do not know or understand it. > > ... documentation, again. > > -- > Stephan > > > ___ > 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: rotate refdes in pcb?
There used to be a bug in older versions of pcb where you had to move the component before you could manipulate the refdes. This also was helped by a save and reopen of the pcb file. On Dec 25, 2010, at 3:36 PM, Frank wrote: > Hello, > > I've tried everything I can think of to rotate a refdes in pcb, but I cannot > get it to work. I can rotate components just fine, and the refdes rotates > with it, but I just want to rotate the refdes and not the component. I've > tried selecting the "only names" option. Moving it is not a problem. How can > I rotate it? > > Thanks, > Frank > > > ___ > 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: Resistor values…
I see the need for something akin to a preferred default positioning, where when a symbol is rotated there is a place where your prefer your attributes to be placed. Have geschem do the auto place template not part of the symbols at all Steve On Dec 25, 2010, at 4:48 PM, John Doty wrote: > > On Dec 25, 2010, at 4:01 PM, Johnny Rosenberg wrote: > >> Hm… I start to regret that I asked the question in the first place… > > No need to regret it. It was a good question. > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.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: gEDA Wikibook ?
lyx Make LaTeX even easier! On Fri, Dec 24, 2010 at 5:23 AM, Peter TB Brett wrote: > On Friday 24 December 2010 10:12:42 timecop wrote: >> > But why not a real book, that is written in LaTeX? >> >> Because you just ruled out the remaining 1% of people who even wanted >> to help with writing any kinda documentation. >> > > Wrong. I much prefer writing LaTeX to writing wiki syntax. Also, diagrams > are so much nicer (thank you TikZ!) > > Peter > > -- > Peter Brett > Remote Sensing Research Group > Surrey Space Centre > > > > ___ > 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: Rotating components in 45 degree
See FAQ for pcb On Dec 18, 2010, at 12:01 PM, jeffrey antony wrote: >Hello, >Is there a functionality in PCB to rotate a component in 45 degree >instead of 90 degree which is available at present? >Thanks and Best Regards >Jeffrey >W: http://jeffrey.co.in/ >M: +918148490036 > > > ___ > 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: Toporouter VERY slow?
Anthony, I look forward to your hard work, it is very impressive, and reminds me of the layouts from years ago, where they were taped out and pretty. None of this manhattan grid. I know that Adding via's are non trivial for an auto router, with your topological auto router, will it use a via that I manually place? As a side note, outsourced layout routing costs the same as they were paid in the 70's, let their bosses know. :-) Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Clearance in fiducials & blocking solder paste
This is in the silkscreen of the footprint. Steve On Sun, Dec 5, 2010 at 10:29 AM, Markus Hitter wrote: > > Am 05.12.2010 um 18:54 schrieb John Luciani: > >> Arcs aren't allowed in footprints. > > D'oh. Neither me nor my copy of PCB knew that so this rectangle with rounded > corners worked fine: > > ElementLine [-46000 -12450 46000 -12450 1000] > ElementLine [-46000 12450 46000 12450 1000] > ElementLine [-5 -8450 -5 8450 1000] > ElementLine [ 5 -8450 5 8450 1000] > ElementArc [-46000 -8450 4000 4000 270 90 1000] > ElementArc [ 46000 -8450 4000 4000 180 90 1000] > ElementArc [-46000 8450 4000 4000 0 90 1000] > ElementArc [ 46000 8450 4000 4000 90 90 1000] > > > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. (FH) Markus Hitter > http://www.jump-ing.de/ > > > > > > > > ___ > 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: mirrored footprint
On Nov 26, 2010, at 5:06 AM, Rick Collins wrote: > At 05:05 PM 11/25/2010, you wrote: >> On Nov 25, 2010, at 4:05 PM, Rick Collins 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: mirrored footprint
On Nov 25, 2010, at 4:05 PM, Rick Collins 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. Steve > > ___ > 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: mirrored footprint
On Nov 25, 2010, at 11:01 AM, Jan Martinek 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. > You did not have to mirror the footprints. Think of it as side A and side B. You could have placed the parts on the solder side. The tab key switches the side you are working on. But the "dead bug" parts do need mirroring of the footprints. As the parts are mounted top side towered the board. I do agree that they should be a externally mirrored footprint though. Steve > regards, > Jan > > > ___ > 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
