Re: gEDA-user: New layer selector to play with (git preview)
On Fri, 2011-08-26 at 22:32 -0700, Andrew Poelstra wrote: Fixed. The new behavior should now be the same as the old. Awesome. I've pushed my PCB+GL branch(s) rebased onto git HEAD now. There are a few bugs lurking in my branch regarding postscript export of solder mask layers though, and I've not updated the pours branch in a while. Both of those need work on the drawing APIs, which I've not sorted out yet. Best wishes, -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New layer selector to play with (git preview)
I've pushed my PCB+GL branch(s) rebased onto git HEAD now. There are a few bugs lurking in my branch regarding postscript export of solder mask layers though, and I've not updated the pours branch in a while. Both of those need work on the drawing APIs, which I've not sorted out yet. Is it isolated enough that I could try adding it to the lesstif hid? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New layer selector to play with (git preview)
On Sat, 2011-08-27 at 11:32 -0400, DJ Delorie wrote: I've pushed my PCB+GL branch(s) rebased onto git HEAD now. There are a few bugs lurking in my branch regarding postscript export of solder mask layers though, and I've not updated the pours branch in a while. Both of those need work on the drawing APIs, which I've not sorted out yet. Is it isolated enough that I could try adding it to the lesstif hid? There was that patch I came up with to prove it can be done. I've not revamped that recently though. There is a lot of code which would be duplicated if we were to put it into the lesstif HID in its current state. Assuming that you wish to keep the X11 rendering as well as GL, we will have to figure out how to manage two renderers in Lesstif as well as GTK. I'm still trying to juggle how to manage two different rendering engines in the GTK HID - it gets more complex when you go 3D, as even the rendering agnostic parts of the GTK HID are a little tangled with the coordinate systems being used by the renderer. (I'm working on that now). Realistically, I would suggest waiting a little until I've split the drawing API out a more. Currently it is only the very low level GL routines which are separate from the GTK HID. Everything apart from the toolkit specific GL setup should in theory be shareable. Finally, the more advanced rendering techniques required to get high-speed rendering (my branches, not git HEAD) require work to the drawing APIs though. I'm procrastinating that, as finding the right way is hard. The idea is that any changes here would make it easier to slot in the new renderer. It is side-effects of those changes which are currently breaking some aspects of postscript (and perhaps other) output in my PCB+GL branches though. -- 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) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: This patch is breaking compile
Am 25.08.2011 um 21:57 schrieb Felix Ruoff:
(wenn ich das richtig rausgefunden habe, bist du/sie (blöde
deutsche Sprache) bei dem Projekt auch aktiv, oder?).
Yupp. I maintain the PCB Milling page in the wiki and created
Generation 7 Electronics, which is designed to be millable.
- 0001 let the system library allocate the temporyary file: Alberto
Maccioni wrote in his mail of 1. May 2011 that the temporary file
is sometimes needed for checking the result. He suggested to add a
switch weather the file should be removed or not. My suggestion:
Don't use tmpfile(), but use the new function gcode_get_filename()
from patch 0004 with an additional suffix for the filename '.png'.
Good idea. While I don't think looking at the PNG gives a reliable
measure wether the produced G-code is usable, the PNG is at least
always next to the file it refers to in a file browser.
- 0004 create better file names: Why should the default file-suffix
be changed to '.cnc'? I suggest to apply this patch but let the
default file-suffix as it is ('.gcode') for compatibility with
probably existing scripts using this function.
The suffix doesn't really matter, as G-code compilers can't really
agree on a common one. Go for it!
- 0005 add a flag wether to procude advanced G-code: I will suggest
to set the switch 'produce advanced G-code' to ON by default
(backwards compatibility).
Backwards compatibility vs. machine compatibility? Perhaps. I hope
dialog settings survive relaunches of the application one day, so
this will become a non-issue.
- 0007 switch from tool-radius to tool-diameter in the user
interface: This patch breaks backwards compatibility, so have a
little headache with it. I think, there is a possibility to mark
the tool-radius setting as deprecated and support both options (for
using the gcode-export with scripts). I have not done something
like this - perhaps anyone have a hint? I would also prefer to have
the tool-diameter in the user interface (as Markus' patch would do).
If I see things correctly, names in the HID setup are used for
command line options as well. Can't see how to get a command-line-
only option there.
To be honest, I don't care too much about keeping backwards
compatibility, as the G-code exporter is apparently rarely used now
and the switch to diameter will give easy to fix errors. This
exporter is likely used mostly interactive anyways, as you have to
check for errors - with a G-code viewer.
Good suggestions, Felix.
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
Re: gEDA-user: gschem vs. PCB diode pin numbering
On 8/23/2011 8: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). It gets worse that this. The basic problem with a generic symbol like a diode or a transistor is that physically it may come in many different packages. So on one package, the cathode may be pin 1 and on a different package the cathode may be pin 2. But wait, it gets worse... Some packages, SOT-23 for example, sometimes have their physical pins numbered differently by different vendors. This problem goes beyond diodes and transistors. For example, the old 10H series of ECL parts came both in DIP packages as well as PLCC packages. Some of the parts though, would be in a 16 pin DIP or a 20 pin PLCC and so the pin numbers didn't agree between the two packages. There are multiple ways to solve this problem but the approach I use (on the rare occasion that I actually have time to do something like this) is I created a transistor symbol which is really just a template. The pins are numbered @b@, @c@, and @e@. Then I have an ASCII file that has a line for each complete vendor part number. By complete I mean the part number including package codes. On this line in the ASCII file, I call out the template name, the footprint name, and the mapping from symbol pin to package pin. Then I have a smallish awk program which creates all the different symbols with the footprints filled in and the pin outs are all correct. In my schematic, I don't instantiate an NPN, I instantiate a MMBT3904L or instead of just a MAX882, I'd use MAX882CPA (DIP8) or MAX882CSA (SO8). This has solved this issue for me. I've also noticed that gschem searches the older m4 library first ahead of the new pcblib. Is there a way to get PCB to use the newlib first? The reason I ask is because I swapped the pins on the diodes to match gschem in the newlib, but the change had no effect since the older m4 lib is being used when you import a schematic. You have to go back and manually replace the footprints if you want newlib. FWIW, the m4 generated library that ships with pcb has more and often times better footprints than the newlib one which ships with pcb. For example all of the surface mount resistors and capacitors and quite a number of surface mount IC packages. -Dan ___ 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 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: gschem vs. PCB diode pin numbering
On Aug 27, 2011, at 8:12 PM, Dan McMahill wrote: This problem goes beyond diodes and transistors. For example, the old 10H series of ECL parts came both in DIP packages as well as PLCC packages. Some of the parts though, would be in a 16 pin DIP or a 20 pin PLCC and so the pin numbers didn't agree between the two packages. Yep. I recently got bit by this with the LT1078 opamp (different pinouts in DIP8 and SO8). 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
