Re: gEDA-user: Foss-pcb Proposed plan from CERN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.08.2011 15:50, schrieb John Doty: On Aug 25, 2011, at 6:33 PM, Dietmar Schmunkamp wrote: - From my point of view the major thing is to have one design source (even with a multitude of attributes e.g. net_group = g1, net_length(g1) = xxx mm, tolerance(g1) = 1 mm, ...etc) and drive simulation and board layout from this single source. That also requires feedback of electrical properties of the board wires back into the design source (and by this into the simulation model). I think the back-annotation approach is complex, messy, and has lots of problems. For my ASIC design work, the layout contractor generates the final simulation netlists using the layout software (Calibre). I then compare simulations of that netlist with simulations of the (enormously simpler) netlist derived directly from the gEDA schematics. An actual schematic derived from the layout would be incomprehensible: all hierarchy is flattened and parasitic components vastly outnumber the intended ones. I think the same considerations apply to boards: it would be good for the layout tools to be capable of generating simulation netlists. It doesn't make sense to me to to run the layout data back through schematic capture tools to get to simulation. 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 John, I think we share a common goal and want to achieve that by different means: You want to put the generation of the simulation input deck to the layout tool while I prefer having it closer to the beginning of the design, in the schematics. I think there are pros and cons for both options, I'm in favour for having much as information as possible in the design entry because there it eases reuse if applied correctly. Let me give an example: In the 'original' schematic a net between 2 or more points is a solid connection. on the pcb it gets a (tapped) lossy transmission line (of course depending on the operating frequency). With repect to reuse I prefer having that information attached to net attributes and generate a simulation (gnucap) input deck as well as establish constraints to the board layout tool. PS: In my day job I'm working on ASICs, too, but the logic input is purely vhdl. To verify that a pre-PD netlist matches a post-PD netlist we use boolean eqivalence check (works also for vhdl to synthesized netlist comparison). Timing is verifed by statical timing analysis (no simulation). That's possible because the wire length is far from transmission line effects (length vs. max freq) Cross coupling between nets is taken into account, too. - -- Mit freundlichen Gruessen / Best regards Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ZYkEACgkQn22l+QvEah1lzwCdENj33c/Ud4DX7DDDu1ZiB9cR E2EAoIJjVM1LqSR7ddMR4yMrQtVKPzra =PNVw -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Foss-pcb Proposed plan from CERN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.08.2011 22:46, schrieb John Hudak: ummm, I think citing and expounding on the philosophical differences of one approach (integrated) versus another (multiple tool kits) is a nice amorphous description and somewhat akin to mental masturbation. I somehow agree, but the flexibility to insert other (maybe hand-written own) tools into the entire design flow is essential. The philosophy of gEDA has already been established. What is more important is that the tool suite *flawlessly* supports a small subset of generally accepted design-fabrication paradigms, eg workflow from schematic to completed populated board, and a subset of potential offshoot efforts such as circuit simulation, head modeling,symbol creation and package creation and management, etc. I disagree with this point: You treat circuit simulation as an offshoot, that's pretty dangerous: If board costs are in the range of 100$ you're right, but if the board cosst increases to 10k$ it's very dangerous to give simulation a low priority. My premise is that if you put 100 design engineers in a room who have done circuit design to board fab and ask them to produce a scenario of their work flow, at least 40% of them would have a common scenario. That's the wrong audience for your question: Ask architects what it takes to put their ideas into a shippable product instead of asking the frogs about drying the swamp :-) . You overestimate one part of the entire design flow. - From my point of view the major thing is to have one design source (even with a multitude of attributes e.g. net_group = g1, net_length(g1) = xxx mm, tolerance(g1) = 1 mm, ...etc) and drive simulation and board layout from this single source. That also requires feedback of electrical properties of the board wires back into the design source (and by this into the simulation model). I admit, as a hobbyist I'm happy with the current gschem-pcb flow as of today but for upcoming RF designs I'd like to have an easy generation of netlists including electrical parameters ... deleted the rest ... - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk5W6dQACgkQn22l+QvEah0UowCeM7lvV+gSkRZ1vkvs9Psv57S0 F4sAn0fBPALS76Wob52Cy13A7e5Nhv4X =SgkS -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Alternate Platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.01.2011 15:42, schrieb Peter Clifton: On Sun, 2011-01-30 at 09:37 -0500, Bob Paddock wrote: On Sun, Jan 30, 2011 at 9:12 AM, Peter Clifton pc...@cam.ac.uk wrote: Perhaps I'm being short-sighted, but I don't see a great potential for serious EDA work on phone sized devices. Even if they get the screen-resolution high enough, the size is very small for design work, and the input problematic. Actual design work probably not all that useful do to small size. The place where it wold great is in being a trouble shooting tool in the field. (As I said ;)). Still - most places I went to do a repair, I'd want to take a laptop or at least a tablet. Getting out that remote without a computer seems like as well thought out as going to do said repair and forgetting to pack your soldering iron. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user As I said in my original post the screen is a bit tiny, for me that implied that no one is going to do serious work on a phone size device, but that's going to be different for tablets. On the phone it's nice to show some schematics / layouts to friends (if you don't have your laptop with you :-) ) and using a stylus to draw lines in pcb works well. So lets wait for affordable tablets with sufficient size, at least the processor architecture is no concern. There were rumors in a german newsticker that Intel is going to announce a tablet with MeeGo in June with availability 3Q. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1FpfEACgkQn22l+QvEah3g4wCfeWyKzkCMMubkp6Iz7RLoyTT8 ZLwAn0WfL+eR+0xoeFo99YPZEMEMAxLR =a07B -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Alternate Platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.01.2011 06:13, schrieb Dave McGuire: On 1/26/11 11:59 PM, rickman wrote: BTW, is Android multitasking or is it single tasking like the iPad OS? Android is layered atop Linux. The iPad OS (also the iPhone OS, called iOS) is multitasking as of release 4.0. Incidentally, it too is a UNIX-based platform...only its user interface (pre-4.0 anyway) prevented user-visible multitasking. -Dave I don't know about Android, but I have a Nokia N900 running Maemo and there you can install a debian and get binaries for the armel architecture via the package manager. So at least the processor architecture is supported. I have gschem (1.6.1.20100214) and pcb (20091103) installed, the screen is a bit tiny, but thinking of Tablets runnig Meego that seems to a a viable option. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1B7XIACgkQn22l+QvEah03JwCgjU09jeDnTHeoyjUQp4Y1LNND jL4Anig6b6jSApn/pMWQeOp6sUiKZyIO =2BoL -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.01.2011 01:33, schrieb John Griessen: On 01/19/2011 06:23 PM, Markus Hitter wrote: One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. In chip layout, where you do have layout sub-cells definable by the tools, all you do for for the route through tracks is put them in the sub-cell as a floating unconnected trace that you do LVS on only at a higher level of completeness -- when it's with the surroundings. Floating tracks might trigger a DRC, but I think they are perfectly valid and I'd rewrite the DRC. I can't remember if DRC2 or anything else complains about floating tracks... John @John, it's interesting that you give an example for collaboration that's in chip design. Chip design is closer to my (professional) home turf than board design (just a hobbyist :-) ), but I always saw the limitation about what I can do in my basement (and limited myself somehow). The chip design floe I know reserves the lower level metal layers to sub-cells and the higher level metal layers to global wiring in reserved to connect the sub-cells (with some simplification). @all on a board level collaboration I see basically two different approaches: 1. time slicing 2. area slicing 1. time slicing One person owns the board for a given period of time, the workflow is: checkout -- work on the board -- chaeckin and the next person takes over. This is the approach to use if the contributors are in different time zones and it really requires godd communication. I think this is supported by geda out of the box as it boils down to a communication problem. 2. area slicing This is far more challenging than the work flow described above The design needs to be partioned into sub-cells, process them independently, and do the connections between thte sub-cells on reserved layers. There are some requirements that the gaf design flow can't fulfill (yet). Net: the question is how you define collaboration that defines your infrastructure sequential or concurrent updates to the desing library. - From my experience the time slicing approach is easier to handl and better supported by tools (cvs, svn...) - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk06OCoACgkQn22l+QvEah2qNACdF+rzHCg2/yeEgfwMs1jeEV4w wsoAnA8+SB1rilTObZvzmI13y7gFqGVV =giNs -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.01.2011 20:21, schrieb Kai-Martin Knaak: Colin D Bennett wrote: The orthogonality of these three pieces (schematic, footprint mapping, and PCB layout) is pleasing to me, but I have to admit that you would rarely find a need to create different PCBs from the exact same schematic. ack. Up to now, I _never_ had this situation in real projects. Some aspect of the schematic beyond footprints and packages always needs to be changed. On the other hand: Almost all projects need debugging and/or service. For this task, footprints printed on the schematic help to locate the part in the layout. Still, by separating the footprint mapping entirely from schematic capture, you can stay focused on one task at a time. If this is your preferred way to work, you can already do it, even with heavy symbols: Just ignore the footprint attribute while placing symbols. Use gattrib, a text editor or a script to replace dummy values of the footprints in a separate step. The mere fact that the footprint information is contained in the schematic does not imply, you have to set it during schematic capture. ---)kaimartin(--- Hi, maybe a little off topic and sorry to say, but I fear the discussion about soft/hard/light/heavy symbols is going to over-optimize a certain step in the design flow, the overall objective should be a working product. And to achieve that we need to put some feedback into the design loop. Start a design with gschem -- simulate it -- get it thru pcb -- extract physical paramaters from the layout -- OPTIMIZE* -- feedback to gschem -- restart the loop. I'm aware that this can't be done by one person (unless there you have infinte time), but each process step should propagate all knowledge/implications to the next step (wire impedance, shielding ...). I haven't pushed gaf/pcb to these limits yet, but ... my message is: Use any kind of inforamtion regardless where it has been gathered to be better next time. BTW: In my day job (chip design, and I am in a close loop with all pro's and con's :-) ) I had an example of just changing physical footprints: We had a ceramic module ($$$ and a huge manufacuring turn around time) with 4 silicon chips on it that was attached to a pcb. The footprint of each of hte 4 chips was fixed and the board layout was fixed, too. But to debug the 4 chips there were 2 flavours of the ceramic carrier: One ver y costly for the engineering hardware being capable of probing all chip interconnects and another costreuced (smaller) without exploiting all chip to chip interconnects. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nok4ACgkQn22l+QvEah13uQCeM0GxhA91GPX+EdURdEvZ7obv VDMAni08Zv/8nnQ5+S53QCxngYKQI0cC =vcPr -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 19.12.2010 17:59, schrieb Rick Collins: At 11:20 AM 12/19/2010, you wrote: Rick Collins wrote: If I understand correctly how subsheets work, I can see where you might want to display to the user a given subsheet only once rather than separately each time the sheet is referenced. Not sure, if I understand what you are aiming at. One of my current projects involves a subcircuit that needs to be repeated 69 times. With subsheets I don't need to have 69 times the same schematic in the documentation. If I have to change some aspect of the subcircuit, I don't have to apply the change 69 times. So for this particular project the way geda treats subsheets is a real work saver. :-) But it is a problem with documentation. You have one page in your schematic and each part has a ref des. In your example, on the board each part in the subsheet has 69 instances, all with unique ref des. If your ref des is hierarchical (subsheet/refdes), then the ref des tells you what instance of the sheet to consider. But if the tools generate new ref des that are not hierarchical, then you need to at least be able to view each subsheet separately, with each instance having its own ref des. This does not mean you have to edit 69 pages when you make a change. If the tool actually understands subsheets as hierarchy to be instanced, then it should allow you to edit the original subsheet once, but allow you to view it N times, each with the component ref des that will be used in layout. It may make it hard to figure out which subsheet instance to view in the schematic. With the hierarchical ref des it tells you which instance. With component renumbering you have to search to find the right sheet... the same as non-hierarchical schematics. Does it make sense to let the schematic package reassign ref des in multiple instances of a subsheet? IMHO, this is the job of gnetlist. On schematic level multiple instances should be exactly the same. That's why they are instances rather than copies. There is more than one way to view instantiation. You don't have to see it as the exact same, single sheet. If you do, there is no way to have your documentation in step with the actual board produced... The way you are viewing subsheets, they are macros and the schematic is a programming language. A schematic is intended to be documentation and each page has to show the ref des that appears on the final product. If you push this off to gnetlist, you no longer have a one to one correspondence between the schematic and the board. It just requires a smart schematic package that knows how to assign ref des. The only fly in the ointment is back annotation. It is common for layouts to dictate ref des based on location to allow finding parts easily. I guess there is no reason that back annotation should be hard, but in a hierarchical schematic it may require special attention. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Hi, let me add an order of complexity here: Assume you have a bandpass consitsting of 2 OPAMPS, 4 resistors and 2 caps that you want to use (instantiate) multiple times on your board. There are multiple instances of that bandpass having different values for the R's and the C's. In addition to this, you want to use quad opamps and share these between 2 instantiations of your bandpass. To me it looks that you need to pass parameters to any instantiation of that bandpass (=subcircuit, hierarchical circuit) including a slotting parameter (share circuit with instantion n-1)). So from my point of view if you create a hierarchy symbol you need to be able to 'attach' component values and slotting to it for each instance. (There may be hierarchy symbols not requiring that at all and symbols that have 'fixe value' components and variable components in a mix). - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0OrKoACgkQn22l+QvEah3TIACcCWPCYNPJ2h7t/p9PHfQNtUAk x/IAn3T2Vh3XTis08QsgZ+HX6nIgrMt6 =aq90 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Restrict facility?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.11.2010 19:06, schrieb Colin D Bennett: On Wed, 10 Nov 2010 00:09:50 -0500 DJ Delorie d...@delorie.com wrote: a) There is no such facility. This one. We've been talking about a redesign to pcb's internals that would allow support for this, but at the moment, we don't have it. Could you emulate it in the current version of pcb by drawing a rectangle/polygon on the area you wish to become the keep-out region? Would the autorouter then avoid it? Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user The trick with the rectangle works, I used it on my board to separate the control section (TTL) of a solid state relais from the 220 V section. The autorouter kept the digital signals on one side and the 220 V signals on the other side. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzbB+AACgkQn22l+QvEah3MugCghCsdYvPuowtxObIPsupQt3se 8ycAn0o43HmLRSSjdT8hsxNbYfTYDjYW =Ao4b -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2010 18:18, schrieb DJ Delorie: How do you know PCB won't ever run on cell phones, or over a slow network link, or on an embedded device or network PC or overtaxed virtual machine? iPcb . . . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I showd a geda schematic and the pcb board layout on my Nokia N900 (debian based) to my colleagues at work and they were impressed. I'm not saying that it's useful to do EDA work on a smartphone, in my case it was more or less a fun project raising the question Can you do that with your iPhone?. Nevertheless I was really impressed how easy it was to install the geda + pcb suite to my smartphone. The other valid question would be Can you do this with your $$$ eda application :-) . - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyCvZoACgkQn22l+QvEah3fxQCeO84y3Cuz83Hev3cYp1YJZndL awsAn1xalA6/rivS4bUKPSjjQj2EIIws =fMqF -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2010 01:44, schrieb Andrew Poelstra: Hey all, I am working on the structuring PCB files in terms of functional blocks, and generalizing/extending the DRC rule format. (Things have slowed down as summer is ending but I am still working on this.) Mostly I am doing GUI work, since that is more-or-less stateless; I can spend 20 minutes reading docs or GTK code and not worry about making it work with PCB. But for the underlying logic: Naturally, I want to avoid any breaking changes to the PCB format, both to increase the chances of my code being accepted, as well as the obvious compatibility reasons. So I have a few thoughts: 1. Initially my plan was to tag every object in the PCB with a functional block. This would make attaching multiple tags easy, though it might bloat the file, and would be slow to initially parse and search. 2. Another idea would be to create functional blocks as recursive PCBs. This has been mentioned a few times on the list, and creates all sorts of exciting possibilities - from importing recursive schematics to reusing layout parts to clearer source control of PCBs. However, this also brings the ability to edit PCB components individually, which means that some parts could have different layers than others, for example. And then you have to deal with layer mappings and stuff and it's a huge complicated mess, both for the user and in the code. What do you guys think I should do? What would require the fewest changes to the PCB format, if any? Generalized DRC rules at least could be tacked on anywhere and would be quietly ignored by old versions of pcb, right? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Andrew, here are my thoughts about DRC: There are (at least) 2 contributors to what should be checked by DRC: 1. The obvious one: The capabilities of the manufaturer, e.g. min trace width = 4 mil, min distance = 4 mil, min drill . 2. The usage pattern: Traces where you expect high current (Vdd, GND, ...) can't use the minimum trace width, while traces that carry high voltages (and need to meet UL, VDE specs) can't have the minimum distance. A conclusion of the above is that the DRC rules are on a net base (potentially on a layer base, if you forece nets with a similiar DRC requirement to the same layer (sharing the copper with otherlayers). I see 4 roout styles in the defualt PCB, they could be used to work around a net specific definition. - From my point of view, there should be a way of defining net attributes from geda (see thread wishful UI). If you want to exetend the DRC capabilites things like handling of differenatial pairs, comparing netlenghs of busses comes to my mind. Going slightly off-topic, one goal would be to extract all physical parameters of a board (RLC for each net segment) and feed that back into a simulation (spice, gnucap, ...). - -- Mit freundlichen Gruessen Dietmar Schmunkamp PS: I won't have internet access for ht next 2 days, I'll comment responses on Tuesday. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk =Y576 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: discussion on what busses *mean*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.08.2010 22:25, schrieb DJ Delorie: D[15:0],A[1:16] with a branch called A[1:16] I was thinking the above renames the wires but perhaps that's a bad idea. Yeah, I guess it would have to create a bundle of 32 wires. No reason you couldn't attach some random attribute to the bus that's just to give it a mnemonic name :-) DJ, in general I don't like having 2 names for the same net, Maybe I'm biased with my experience of vhdl synthesis, normally the name that you don't expect survives synthesis and the other one gets lost (and that even may vary between two releases of the same tool). So having only one name has advantages. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxoYpkACgkQn22l+QvEah3cQACfZ/XHL0UmkWJxrS/lwtHPRRm0 c+4AmwfMeef/Gl/GmC4/m3J6WR1BqD+i =5sp3 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: discussion on what busses *mean*
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.08.2010 00:07, schrieb DJ Delorie: in general I don't like having 2 names for the same net, Maybe I'm biased with my experience of vhdl synthesis, normally the name that you don't expect survives synthesis and the other one gets lost (and that even may vary between two releases of the same tool). So having only one name has advantages. It's not the same NET. Each NET has a name. A *BUS* is a group of nets, you can refer to the names of the nets inside it or give the bus its own name. For example: Nets A0 to A15, D0 to D7, RD, WR, and EN are grouped into a bus. You can refer to the nets within the bus when you pull them out for a connection: A[0:15],D[0:7],RD,WR,EN - all the nets A[0:1],RD,EN - some of the nets A15,D[0:7],WR,EN - some of the nets but we could also give the *grouping* a name, like CONTROL_BUS. So, for example, you could give a bus a netname to enumerate the nets contained therein (just like we do for single-signal nets), as well as a busname to name the grouping. DJ, I agree, and I don't have a problem with it as long that name is used consistently thruout the entire design, so your CONTROL_BUS on the first sheet is the same from there on to the last sheet. As soon as you only want to use a subset you have use the individual net names (at least in my opinion). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxocQkACgkQn22l+QvEah22YwCfS7BMY2/WWH5Th9Hx+3PhYyTo ebYAn091KtEaeVvWYNdOEVLcQQ/+HTs9 =fvtL -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.08.2010 23:23, schrieb Stefan Salewski: On Mon, 2010-08-09 at 10:59 -0600, John Doty wrote: Remember, pcb isn't the only layout path we support. Yes. But I think the addition of net classes will not really break something. Of course it will increase the code size, which is not really nice. And it may decrease the working speed of PCB program. I have written a short summary of this idea: http://ssalewski.de/gEDA-Netclass.html.en ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Stefan, I looked at your suggestions about netclasses and I like them. What I would like to add (and this adds complexity, too), is the notion of differential pair (two wires should be same length, but the actual length basically is a don't care) or busses and control signals (industry standard SDRAM's etc where you have delay constraints of an entire bus vs. a single control signal). Furthermore I have a little objection towards No chance for unskilled people or autorouters, I agree with unskilled people, but at least a subset of the requirements can be translated to autorouter attributes, e.g. impedance easily translates to geometry for a defined layer stack (including base material, copper width ... ) while other attributes you suggest (short) would only be applicable to an autoplacer (or skilled people). I know that the target to add net classes AND to support them with auto[route|place|...] is very challenging, but nevertheless I think that it's worth a try/start a discusssion. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxly8wACgkQn22l+QvEah1zVACfQP5orxgMpJCvjbT3bPuxJUjZ UFYAn3//FoLemiNGwqa75SmMw4HZYn3H =qvlC -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.08.2010 01:13, schrieb Stefan Salewski: Indeed currently I am still looking for a good reason against that proposal. My best candidates: It is not too useful for small projects, and it is some work to implement. I don't think that this is a good argument against it as long as you don't force small projects to use it. I would see it as an extension to the current gschem - pcb flow. If you don't specify anything, you get the default net attributes as defined in PCB. I have to admit that I do not know much about differential pairs now, but it is very important... If you go high frequency it's getting important. Related to that are termination requirements of a given net, carefully select whether the termination needs to be close to the driver or close to the receiver. Typically this is a problem a tool can't handle. I guess it would be no great deal for smart (but very busy) people like Peter C. and DJ, to implement the basic concept. For people not familiar with the internals of gschem and PCB like me it may take very long... I second that, and I read the response from DJ: You don't know how hard it can be to teach a hardware guy software concepts :-) . Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkxl47UACgkQn22l+QvEah0pJwCgjcFzsqJqGpl0/vcJ99+HThne brUAn35r4OvjEO8a1TdakafoPPw8l4/A =xfvV -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: soldermask via caps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.05.2010 18:26, schrieb Bob Paddock: Like all things in this field the answer is usually it depends... Bob, I second that. My first attempt was to implement the circuit I designed without 'professional help' (== provide a receipe for homebrew circuits), and I failed. But discussing my problems with people providing professional help I learned a lot: Do not use solder paste in conjunction with hand soldering for 'standard footprints' (= 0603, SOT23 ). Putiing some solder on one pad and then do a kind of reflow with the iron, soldering all pins (remove excess solder withsolder wick) gives better results (at least for prototypes / low volume products). The question of exposed pads remained open (I wasn't aware of DJ's hot plate stuff at that time). Nevertheless I (hope to) get professionally solderd boards next week, - -- Mit freundlichen Gruessen / Best regards Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkv4XPAACgkQn22l+QvEah3UMgCdGOhHtFQuiQwbpX3WmLe+m/E1 PmoAnRtBvVQ8zGNZknKdsehBQUrQ5OGU =j5IA -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: soldermask via caps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 16:52, schrieb Stefan Salewski: On Fri, 2010-05-21 at 12:55 +0100, andrew whyte wrote: There is a known problem in layouts with vias inside pads, where solder wicks down into vias and causes the joint to be poorly soldered. I found this link about how to avoid this problem: I have absolutely no experience with this problem... I know that open vias in small pads can give problems -- solder can flow by capillary forces from the pad into the via. I have never heard about this problem for large pads. For that case the amount of solder on the pad should be large compared to the volume of the vias, so there is no problem if some solder flows in the via hole. And you have a large area for electrical and thermal contact, so soldering should be not too critical. Capillary forces should move the fluid from width to narrow areas, so I do not really believe that all solder will propagate from the contact area of your device into large vias. Just a guess of someone with no experience but physical background. My next task, coming soon, is to solder a few of such thermal pads with a soldering iron: My plan: have some open 0.3 mm vias in the thermal pad, fill them with 0.2mm copper wire to improve thermal conductivity. Put some soldering past on the pad and via, mechanical fixate the device and heat the vias from backside with a really hot iron. Ok, that may fail, but gives me at least some experience... Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I tried this approach on my last board (the exposed pad of the IC I choose is the only GND connection) and I failed miserably. My intention was to reflow the paste from the bottom side via a via in the pad from the bottom side of the board. It turned out that I used too much paste and got shorts between the pins and the exposed pad. I finally asked for professional help and will get a 2nd board back some time next week. The people I tlaked to ensured me that without reflow your yield will be close to 0 to solder an exposed pad from the reverse side. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkv26HYACgkQn22l+QvEah06HgCfQa0CrdE/FPoVgkqeOTnL1NT1 UzIAn0RjC+/vqfPcUezbmbVYMEqK4YEk =wcbx -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: soldermask via caps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 23:46, schrieb Stefan Salewski: ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Stefan, I fear we go off-topic here, nevertheless I think it's an interesting topic how to solder ICs with an exposed pad with homebrew equipment. Basically there is a contradiction to create a footprint with an exposed pad for reflow soldering and manual soldering. Manual soldering requires a via hole of a decent size that sucks all the solder when doing reflow soldering. Soldering a few outer pad of the device to fix it is not really good, because so I can not check if the center thermal pad is really soldered. This was my very first try before using too much soldr paste --- I had soldered some outer pins and tried to solder the exposed pad from the reverse side (the IC on the bottom side, and IC fell off the board, so my next try was to use too much paste. And as a hobbyist for me every board is a prototype :-) . - -- Mit freundlichen Gruessen / Best regards Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkv3FdsACgkQn22l+QvEah21fwCfb5OsiD68ih/cKX2Hu8/F5elw g8cAoJfp2uSuKVI3lhGiF5rA15QAq2RN =GZBx -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: soldermask via caps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.05.2010 01:28, schrieb DJ Delorie: For soldering QFNs at home, I think the easiest way (i.e. the least amount of stuff to buy) is to pre-solder all the pads (center and outside) on the pcb, so you know you have just the right amount of solder on all of them. Then put some flux on them and the part, put the part on the solder, and reflow it with a $20 hotplate from Target. No paste, no funny vias, no special soldering irons. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user DJ, thanks a lot. That sounds interesting, does this work for a 12-Lead Plastic MSOP, Exposed Die Pad which has conventional pins (the exposed die may be up to 10 mil above the board) as well? One option for me may be to change to a DFN package where all pins are under the IC in one plane. I choose the MSOP to only have 1 problem (exposed pad only), not 13 (for all of the pins, including the exposed pad), but now I think it was the wrong decision. It's easier to deal with 13 similiar problems compared to 1 big problem. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkv3JTsACgkQn22l+QvEah1SDgCgmKBNe3Y8kgVByPz/a02H/1bG 0F4AnR85n7vB0ogYcyJFGEqhPpi/LYMr =k88Y -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: thermals on layer groups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 15:49, schrieb Harry Eaton: With my setting of having the polygons on an extra layer I'm not able to place thermals. When trying this, the command is simply ignored. The thermal tool places thermals to the active layer. You need to have the layer that the polygon is actually on as the active layer in order to place a thermal.The thermal is a feature of the polygon, not of the pin/via. If the command is being ignored, it is because the polygon is not on the actual layer (not just group) that is active for drawing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Harry, thanks, that was it. In the meantime I moved the polygons to the solder / component layer based on Peters comment, moving them to an extra layer would be very useful if you could remove that layer from the visible layers regardless of the layer groups. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvre8ACgkQn22l+QvEah1XGACcD70EemW7l0AEtCAuMN0T9lfb mBcAmwYeadbcVXwY6zzCTIKfirO/kiU7 =iSp1 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: thermals on layer groups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 21:28, schrieb Dietmar Schmunkamp: Am 28.03.2010 15:49, schrieb Harry Eaton: With my setting of having the polygons on an extra layer I'm not able to place thermals. When trying this, the command is simply ignored. The thermal tool places thermals to the active layer. You need to have the layer that the polygon is actually on as the active layer in order to place a thermal.The thermal is a feature of the polygon, not of the pin/via. If the command is being ignored, it is because the polygon is not on the actual layer (not just group) that is active for drawing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Harry, thanks, that was it. In the meantime I moved the polygons to the solder / component layer based on Peters comment, moving them to an extra layer would be very useful if you could remove that layer from the visible layers regardless of the layer groups. ... in the last sentence pls. replace if you could remove with if one could remove, that was kind of a translation error on my side. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvsfQACgkQn22l+QvEah2wtgCdFLoSoMqqWwOO2aqMeLZRe0O9 aUwAn1nmorsfXJR2MKSllP5OyDKUmhIW =yRKX -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb DRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 13:13, schrieb Peter Clifton: Peter, thanks again, I'm ha [snip] The solid polygon will connect to everything it touches. I tried it and it cuased much more problems than it solved. So I leave it as is. [snip] I believe there are some fab's who run a DRC check with a web interface as you upload the design files. I doubt this will be available until you've committed to fabrication though. I'll release my board and let the list know if I get any feedback or whether the manufacturing process went smooth. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvtsAACgkQn22l+QvEah07EACdGVmAoVG/y7sKPbjF2F7+HerD CiYAn3ldnnSGTvY6NAedJQRV3Gl3T8jZ =QV3d -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb DRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 28.03.2010 13:17, schrieb timecop: [snip] if you're at the point where you need to rely on web-based DRC for gerbers (thus you don't trust the tools you use) its time to move on It's not the tools I do not trust, but the current process is that the manufacturer publishes the basic design rules on his webpage, I have to translate it to DRC rules for pcb (that's the error-prone part :-) ) and run DRC. Ideally there is an open source tool that checks gerber files (the file format I'm communicating with the manufacturer) and the manufacturer publishes a set of parametere that this tool can read. So I can improve the DRC rules for pcb without having the manufacturer in the loop. Btw, in my day job, I'm doing chip designs, and when we release chips to manufacturing (within the same company), manufacturing checks every mask again, though the release process does this on an input file to mask build. To make my point clear: I'm very happy with the geda tools-suite (compared to some crippled (extremely stripped down) versions of $$$ programs doing the same job). I continue using the geda suite and hope I can do my share to improve it. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvu8IACgkQn22l+QvEah34XgCggQVc9U5GZGPAJcKQPgYIajDS lMUAn1fjmLsuAovLA+tcn4rBxehzuytu =lpfl -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb DRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.03.2010 20:33, schrieb kai-martin knaak: Stephan Boettcher wrote: http://www.ieap.uni-kiel.de/et/people/stephan/solo/eda/erena/erena.pcb ^ We should found a geda chapter of Germany! :-) There is Stefan near Hamburg, you in Kiel and me in Hannover. Who else? ---)kaiamrtin(--- Dietmar near Stuttgart (unfortunately a little bit too south to meet in person :-( ). - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuukWMACgkQn22l+QvEah0TcwCeIh+EDq8qLeZ7QualPjt25Ec7 qG0An0uz9YZM5iTcWpWG2VTnpWs9H53u =+/YU -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb DRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.03.2010 12:21, schrieb Peter Clifton: On Sat, 2010-03-27 at 01:34 +0100, Dietmar Schmunkamp wrote: I think I have a similiar problem of false error indications The attached board shows 1 DRC error: Pad with insufficient clearance inside polygon. The pad and the polygon are in different layers withein the same layer group, so they will show up on the same 'physical layer' (same plane of the board), where I do not see an insufficient clearance. Related to that, I'm not able to put a thermal to any pad (pad is on component layer, polygon is on power layer, both are in the same layer group). What is a good suggestion to create power / gnd polygons on a double sided board? Use the power/GND layers and assign them to a layer group or create power/GND polygons on the component / solder layers? Personally, I don't use layer groups, as I don't really see the point. It usually means yet more colours on an already complex design, it is harder to visualise what copper is on what layer.. And you can't even turn the sub-layers within a layer group on/off, so it isn't even useful to hide polygons temporarily. It is possible there is a bug in the DRC relating to layer groups.. if you can identify something with a minimal test case (showing how it fails with multi-layers in a layer group, but passes DRC on a single layer), please file it on Sourceforge so it doesn't get forgotten. Peter, thanks for your answer. I think I got to the root cause of my problem: The pad has a width of ~16 mil and I used the autorouter to connect it. I set the trace width to 8mil with 8 mil gap. So I got a trace to the pad with 8 mil width on the north side of the pad (not in the center of the pad). As this particular pad is the power pad I wanted to connect it with a wider trace (for cases where the trace is centered, I simply widened the trace), so I tried to (ab)use a polygon for that. While I'm able to connect a net to a polygon (using the join command), this is not possible for connecting a pad to a polygon. I have a circumvention for this: create the polygon with the correct gaps and use a parallel wire to connect the pad to the polygon. To make a long story short: I stumbled over a feature of the DRC. I have a circumvention for that. Fixing my particular problem of detecting a false positive would hide possible real errors (my problem was a DRC error to a plane the pad was already connected to, but in general the DRC check is valid for any I'll change my board to have all shapes (nets and polygons) on the same layer. With my setting of having the polygons on an extra layer I'm not able to place thermals. When trying this, the command is simply ignored. I remember previos versions of the DRC to highlight one net in the found colour and the offending net in the selected colour. I'm missing that for the latest version. I'm going to send out the board to manufacturing monday or tuesday, I'll post here if the manufacturer (www.haka-lp.de) has problems with the generated gerbers. The manufacturer seems to be Eagle-centric, but accepts RS274-X as well. I like the DRC within PCB very much, but as a final check I'd like to have a DRC check on gerber data (that's all the manufacturer gets), so does anybody know whether there is a tool that's provides such a check? I loaded the gerber files into gerbv and did a manual check, but an automated check would be better, There must be some (possibly $$$) programs to do that, or how do the manufacturers provide feedback to theier customers? - -- Mit freundlichen Gruessen / Best regards Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuunfMACgkQn22l+QvEah0KQACgmO1i6XydxO45X9ibhgtyjQFq /dsAnAlDEqYX9tCgdtYL5rPL1BAf55ac =VnG5 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Make net lines invisible
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Link schrieb: On 05/09/09 13:16, Kai-Martin Knaak wrote: On Sat, 05 Sep 2009 11:30:09 +0200, Link wrote: At the moment all I can think of is duplicating the pins, mirroring them horizontally and overlaying them onto the existing pins so that drawing a net to pin 1 connects to pins 1 _and_ 2, but that seems rather hacky to me. Hiding a net is even more hacky. Are there any better ways? I'd modify the footprint, so that two pads are associated with one pin of the symbol. Just attach the same pin number to the two pads. So the symbol contains 11 pins that connect to 22 pads of the footprint. This approach keeps the notion that the schematic handles nets while the layout deals with the shapes of components. ---(kaimartin)--- I guess that works. Thanks. :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Hi, here is a symbol and a footprint I used for a similar problem, It's for a rework area with 6 1206 slots and a pin connected to each pad of the 1206 pads. The symbol has to slotdefs so that I can use 2 of them in the schematic and place them so that they look like the footprint. Each pin in the symbol is represented by 2 pads and a pin with the same netnumber in the footprint (the clearance in the footprint needs to be fixed). - -- Mit freundlichen Gruessen / Best regards Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkqivJ0ACgkQn22l+QvEah2rYwCdFfUWPH+6lWs8cLGqhuUL7iRw Am4An0jYXV4fztEsw1/rBVTZzgdgn3tc =DJGF -END PGP SIGNATURE- rework_6x1206.sym Description: application/sym-geda # Footprint for 6 * 1206 parts (each pad consists of a pin, the SMD pad and a pa as connection between both # Author: Dietmar Schmunkamp # Element[0x Rework Area rework_6x1206 0 0 -3150 -3150 0 100 ] ( # section #1 the pads Pad[-21500 -11900 -21500 -12100 6800 800 6800 1 1 square] Pad[-21500100 -21500 -100 6800 800 6800 2 2 square] Pad[-21500 12100 -21500 11900 6800 800 6800 3 3 square] Pad[ -9500 -11900 -9500 -12100 6800 800 6800 4 4 square] Pad[ -9500100 -9500 -100 6800 800 6800 5 5 square] Pad[ -9500 12100 -9500 11900 6800 800 6800 6 6 square] Pad[ 9500 -11900 9500 -12100 6800 800 6800 7 7 square] Pad[ 9500100 9500 -100 6800 800 6800 8 8 square] Pad[ 9500 12100 9500 11900 6800 800 6800 9 9 square] Pad[ 21500 -11900 21500 -12100 6800 800 6800 10 10 square] Pad[ 21500100 21500 -100 6800 800 6800 11 11 square] Pad[ 21500 12100 21500 11900 6800 800 6800 12 12 square] # section #2 the pins Pin[-27500 -12000 4800 800 6800 2800 1 1 0x02004001] Pin[-27500 0 4800 800 6800 2800 2 2 0x02004001] Pin[-27500 12000 4800 800 6800 2800 3 3 0x02004001] Pin[ -3500 -12000 4800 800 6800 2800 4 4 0x02004001] Pin[ -3500 0 4800 800 6800 2800 5 5 0x02004001] Pin[ -3500 12000 4800 800 6800 2800 6 6 0x02004001] Pin[ 3500 -12000 4800 800 6800 2800 7 7 0x02004001] Pin[ 3500 0 4800 800 6800 2800 8 8 0x02004001] Pin[ 3500 12000 4800 800 6800 2800 9 9 0x02004001] Pin[ 27500 -12000 4800 800 6800 2800 10 10 0x02004001] Pin[ 27500 0 4800 800 6800 2800 11 11 0x02004001] Pin[ 27500 12000 4800 800 6800 2800 12 12 0x02004001] # section #3 connect previous pin and pad by another pad Pad[-25100 -12000 -24900 -12000 1000 800 1500 1 1 sqare] Pad[-25100 0 -24900 0 1000 800 1500 2 2 sqare] Pad[-25100 12000 -24900 12000 1000 800 1500 3 3 sqare] Pad[ -5900 -12000 -6100 -12000 1000 800 1500 4 4 sqare] Pad[ -5900 0 -6100 0 1000 800 1500 5 5 sqare] Pad[ -5900 12000 -6100 12000 1000 800 1500 6 6 sqare] Pad[ 5900 -120006100 -12000 1000 800 1500 7 7 sqare] Pad[ 5900 06100 0 1000 800 1500 8 8 sqare] Pad[ 5900 120006100 12000 1000 800 1500 9 9 sqare] Pad[ 25100 -12000 24900 -12000 1000 800 1500 10 10 sqare] Pad[ 25100 0 24900 0 1000 800 1500 11 11 sqare] Pad[ 25100 12000 24900 12000 1000 800 1500 12 12 sqare] # draw an outline ElementLine[-31000 -16500 31000 -16500 1000] ElementLine[ 31000 -16500 31000 16500 1000] ElementLine[ 31000 16500 -31000 16500 1000] ElementLine[-31000 16500 -31000 -16500 1000] ) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
