Re: gEDA-user: reasons for wikibook (was: plugins)
Am 12.09.2011 um 16:43 schrieb DJ Delorie: 1. The easier it is to contribute, the more likely you are to be vandalized. Wikipedia has seen plenty of this problem. You need some method of authorizing trusted contributors and approving changes by others. As a heavy user of another technical wiki I can report this doesn't happen there. Wikipedia is a special thing in that matter, because it's a lot about opinions and politics. In a technical wiki you're glad to get a few edits each day and as typically the page creator maintains a page, it's easy to review edits. The only difficult thing here is to accept edits, even if you'd have it written differently. Heavy re-editing and deleting contributions makes people go away quickly, so don't do this but add your view as well. 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: why some skip KiCAD and gEDA
Am 10.09.2011 um 13:35 schrieb Stefan Salewski: A lot of documentation can be bad. Ha! Now that's exactly the right answer to somebody offering writing documentation. Consider the toys from the big company with the damaged fruit: A reason for the success of the toys is that documentations seems to be not needed. That's possible for an EDA tool as well, of course. It requires an intuitive design. Self-explaining features, pure technical relations being hidden and automatic, everything connected so you can't miss something or do something wrong, perhaps integrated tutorials (SolidWorks does that). But how close is gEDA here? To be honest, I think gEDA couldn't be farther away. It can't even agree on an equivalent GUI design for both major tools, gschem and pcb. Instead of doing something about that, lots of discussions about picky details on keyboard accelerators. Using a keyboard to do anything but writing text is a thing of the past, to start with. To get an idea of a fairly intuitive tool, have a look at Fritzing. Abhijit, please go ahead. Fresh tutorials and HowTos are most welcome. And please let me know when it's time to put the G-code exporter HowTo there. In case you don't want to do this yourself. 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: 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: This patch is breaking compile
Am 25.08.2011 um 17:28 schrieb Markus Hitter: Am 23.08.2011 um 07:50 schrieb Felix Ruoff: as you can see, some of the patches failed to get applied. The reason for this are some changes in git head (the nanometer- conversion). I have worked to get this fixed yesterday but did not fully complete. Ganz unerwartete Unterstützung, vielen Dank. :-) ... ... O-oh, that wasn't meant to go to the list. Now I've got a red face. 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: This patch is breaking compile
Am 23.08.2011 um 07:50 schrieb Felix Ruoff: as you can see, some of the patches failed to get applied. The reason for this are some changes in git head (the nanometer- conversion). I have worked to get this fixed yesterday but did not fully complete. Ganz unerwartete Unterstützung, vielen Dank. :-) Das letzte Mal hat es gut funktioniert, ein Rebase für jeden einzelnen neuen Schritt aus master zu machen. Also erst die Version auschecken, zu der der Patchset passt, dann die Zahl der neuen Schritte zählen, dann git rebase master~38 autogen.sh make clean make git rebase master~37 autogen.sh make clean make git rebase master~36 autogen.sh make clean make git rebase master~35 autogen.sh make clean make ... bis man wieder bei master ist. Dann fallen die manuellen Korrekturen entweder ganz weg oder bleiben zumindest übersichtlich. Wenn ich da lese, dass ein Patch für nicht durchgehende Vias schon seit mehreren Jahren existiert, aber immer noch nicht eingebracht ist, dann bekomme ich das Gefühl, dass gEDA so eine Art Aufstand der Nicht-Developer braucht. Diese konsequente Verweigerung neuer Features ist zu nichts zu gebrauchen, gEDA könnte bereits sehr viel weiter sein. Gruss, 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: This patch is breaking compile
Am 10.08.2011 um 23:01 schrieb kqt4a...@comcast.net: On Wed, 10 Aug 2011, Andrew Poelstra wrote: On Wed, Aug 10, 2011 at 01:25:35PM -0500, kqt4a...@comcast.net wrote: [Jun 25 patches from https://bugs.launchpad.net/pcb/+bug/699497] [compilation error in gcode.c] Other than 'Don't do that' any suggestions? Ask Traumflug nicely to rebase his patches on current git again? If you can tell me how to contact him I will ask, nicely I'm here, just can't catch up the list daily. For a quick result, you might want to go back to around 2011-06-25 in the git repository. For a new patchset, I can't promise a point in time. gEDA/PCB receives quite fundamental changes these days, but I'll work on it. 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: This patch is breaking compile
Am 13.08.2011 um 00:45 schrieb Markus Hitter: For a new patchset, I can't promise a point in time. I had luck! No surprises, just rebasing commit for commit was sufficient. New patchset available: https://bugs.launchpad.net/pcb/+bug/699497/comments/44 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: Migration form eagle to gEDA
Am 26.07.2011 um 07:33 schrieb bsali...@gmail.com: 1. Schematic board are decoupled so any changes to schematic need to be re-synced to the board. I haven't figured out the way yet. Look up and use xgsch2pcb. Everything else is too complex for beginners. Emphasis on the x at the first letter. 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: Migration form eagle to gEDA
Am 27.07.2011 um 15:49 schrieb Colin D Bennett: However, I want to know how clicking File | Import Schematics is “too complex for beginners”. Perhaps I still had this multi-page tutorial in mind and forgot about this relative recent function. 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: Design Nark
Am 19.07.2011 um 20:15 schrieb Steven Michalske: On a side note Are there features that would be nice to have? Coming from Eagle, the thing I'm missing most is a simple object editor. There's Menu - Tools - Generate object report, but the result isn't editable. 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: Advanced G-code exporter updated.
For those milling PCBs, I've just updated the patchset for the more advanced G-code exporter to match current git: https://bugs.launchpad.net/pcb/+bug/699497/comments/43 For those not yet familiar with it, please find a screenshot of it's GUI attached, which shows the available features pretty well. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ attachment: G-code Exporter UI.png ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Current git master doesn't build
Hi all, just tried to compile PCB from freshly updated git sources on a current Ubuntu, but it won't let me: : git checkout master : git pull : ./configure --disable-doc ... : make clean ... : make ... make(2): no rule to create target hid/gtk/gui-render-pixmap.c, needed by hid/gtk/gtk_lists.h. Exit. (wording translated from german.) Any clues? Thanks, 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: Current git master doesn't build
Am 11.06.2011 um 23:39 schrieb Colin D Bennett: Try re-running 'sh autogen.sh' before configure. Thanks, Colin, this was it. Now I get disabling 3D rasterization segmentation fault when running the resulting binary and loading a layout, but that's a different issue. Also Ubuntu 11.04 AMD64, with Intel internal graphics. I'll fire up the debugger. 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: Reinventing the wheel
Am 18.05.2011 um 04:25 schrieb Kai-Martin Knaak: kicad is the EDA chosen by some high profile open hardware projects: * reprap (http://reprap.org/wiki/KiCad) As a RepRapper I can say, there is no such thing like a choosen EDA. People use what they like most and that's Eagle for some 90% of the RepRap electronics sets (there exist many in parallel). BTW, what are the show cases for geda/pcb? http://reprap.org/wiki/Generation_7_Electronics ? At least worth mentioning :-) 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: Rounding vs. truncating in gcode exporter
Am 17.05.2011 um 23:36 schrieb Andrew Poelstra: does it matter whether we use truncation or rounding in this calculation? If so, which should be used? I can't think of a situation where truncating is more accurate than rounding, so rounding is always better, IMHO. If you work on the gcode exporter, please consider these: https://bugs.launchpad.net/pcb/+bug/699497 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: Where is pcb-20100929 for Win32 ?
Am 10.05.2011 um 19:39 schrieb DJ Delorie: If we distribute the GTK dll, we must distribute the GTK sources. Not if you use the sources unmodified, because they're distributed elsewhere, then. 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: PCB gcode generation
Am 01.05.2011 um 03:18 schrieb Peter Clifton: As a feature request which came from that discussion, it seems that it might be nice to provide the option of special casing the handling of outline layers. The expected convention is to put a narrow series of lines around the boards to denote their outline, the path of these lines forms the the centre-line of the finished board. The problem we were addressing is that the gcode export (not unreasonably) treated this as a track to be isolation routed. See patches 0018 ... 0020: https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786373/ +files/0018-HID-gcode-don-t-do-isolation-milling-on-the-outline-.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786374/ +files/0019-HID-gcode-fetch-the-board-s-extents-from-the-outline.patch https://bugs.launchpad.net/pcb/+bug/699497/+attachment/1786375/ +files/0020-HIG-gcode-limit-the-produced-G-code-to-the-outline.patch 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: PCB gcode generation
Am 30.04.2011 um 09:14 schrieb Alberto Maccioni: At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. Your message was clearly a don't touch anything. You had objections with about any of the enhancements, couldn't propose solutions and didn't bother to recognize adjustments made for your single use-case. Of course none of the developers will ever commit a patch that breaks functionality for any of the users. OK, let's one user be happy and cripple all others. This is at least a strategy. It whouldn't bother me to leave the patchset where it is if I hadn't difficulties to convince people to use gEDA. Which leads to the question: is there a way to compile exporters as a plug-in? 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: PCB gcode generation
Am 29.04.2011 um 08:47 schrieb Alberto Maccioni: ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Probably you didn't notice that it is still boken, as I wrote again. Probably we won't agree on that ever. The patchset is there, do with it what you think is the best thing to do. 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: PCB gcode generation
Am 28.04.2011 um 11:14 schrieb Alberto Maccioni: There was a patch that did something like that, ... You probably mean this set of patches: https://bugs.launchpad.net/pcb/+bug/699497 ... but it broke the minimum distance path optimization, This was fixed the day you mentioned it. Perhaps a day later :-) Am 26.04.2011 um 21:26 schrieb Mikey Sklar: - Is there a way to break up the drill file so that I can switch bits? I'm getting by with using one bit for all vias, but it is not ideal. With the above patchset, drills are sorted by diameter and marked with comments, so it isn't too difficult to hand-edit the G-Code file. You can get G81 drill cycles with advanced g-code or a replacement using G0/G1 by default. - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. The patchset also introduces milling the outline layer, if only a rectangle one for now. Holes can be drill-milled, so the most common cases go automatically. For more complex cases, make one layer for each type of milling, then export with only that layer visible. Layers in the solder/bottom group are mirrord, others not. Repeat for each milling case. Not exactly ideal, but a more general approach quickly becomes pretty complex. Oh, and I hope the patchset still applies, it was last adjusted on march 7th. 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: RFC using SVG with semantic markup as an EDA format
Am 11.04.2011 um 23:34 schrieb Peter Clifton: Inkscape. I don't think there is anything available which is remotely comparable which doesn't cost serious money. Scribus/ScribusNG. Better suited for desktop publishing and not so CorelDraw-like. But that's off topic :-) - - - - - - - - - - - - - - - - - - - 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: Request for patch-review (and commiting to git head)
Am 28.03.2011 um 21:58 schrieb Felix Ruoff: - 699476 G-CODE export GUI (just documentation-changes, patch by albmcc, git-formatted by me) Does that take the substantial set of new features in the G-Code exporter into account? https://bugs.launchpad.net/pcb/+bug/699497 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: xgsch2pcb couldn't find pcb gsch2pcb executables
Am 26.03.2011 um 11:57 schrieb Bob: I'm pretty sure it does not matter, but I'm running 64 bit Ubuntu 10.10. The OS always matters. If you can live with a gEDA version a bit over a year old, Ubuntu features the packages: sudo apt-get install geda geda-tools geda-xgsch2pcb This works out of the box, you can even double-click files. 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: General Layers questions
Am 19.03.2011 um 02:29 schrieb John Doty: ... comparison to the C language snipped ... Proper bottom-up design *never* results in impossible-to-meet requirements because it starts from capabilities. Nice description, John. What can a layered description of tame plane geometries (no fractals ;-) actually represent? To some extents I can't get rid of the feeling layouts shouldn't be considered as layers with components on them, but as tracks, holes, pads and components which happen to be manufactured on layers. For example you have holes, which happen to be plated or unplated, which happen to connect to pads, which happen to connect to layer 2-4, and so on. Low level data representation describes those elements with their properties, higher level functionality provides functions ensuring this makes sense in a layered design. Currently, components are handled this way; resistors, ICs, and that stuff are listed as parts in a .pcb file. The lacking part is, there is no clear description of all their properties, e.g. to which tracks or layers they connect. Tracks should be handled the like components. BTW., there were electronic circuitries before PCBs were invented and the future of electronics manufacturing is most likely something three-dimensional, arbitrarily shaped. my $0.02, 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: Google Summer of Code 2011
Am 05.03.2011 um 16:17 schrieb John Griessen: 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. Going down that road further, 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. 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: Google Summer of Code 2011
Am 02.03.2011 um 05:40 schrieb Anthony Blake: Well if you want to do an ambitious project, you have to commit long term to the project, and I didn't do that.but Kai-Martin's attitude is a good example of why I'm no longer a gEDA developer. Kai-Martin: As well as using me as a counter-example, could you provide some good examples of the sorts of projects you would like to see? Well, I'm not Kai-Martin, but these two sentences ring a bell here. If I unterstand you correctly you feel disencouraged, because some people tried to cut your project ideas into a realistic frame - _their_ frame - except of letting you hack away on gEDA for the year 2030. Yes, I can understand such frustration. It's a major challenge to be attractive for people with new ideas and - more important - get new things rolling on one side, while keeping existing stuff in a usable state. For example, you'll never get something into the repositories which cuts away some functionality with the promise to provide an alternative solution later. If you remove even tiny bits, undoublty somebody cries out loudly I use that all the time and can't live without it. Best example: gEDA's three different footprint formats (lib, newlib with mil, newlib with 1/100 mil). One plan would be to build a derivative from scratch. A fork or a rewrite. Be assured: _that_ is a lot of work. You'll have to be a lot better than the established counterpart, have to reach a similar level of maturity and even then, people will change over only slowly. The IMHO much more promising plan to deal with this situation, which is very common in matured software suites, is to lay out a future plan. Tell the people what they can reach and why dropping this or that doesn't limit them, but will make them faster, more productive. Lay them out a transition plan, like keeping read-only functionality for the old format. That's how Windows and Mac OS X are done, and both are successful. Then, follow this plan in achievable steps. Only working stuff matters. Get the bricks of your bright plan built. Once you do smaller steps successfully, people will start to trust you. Drum up marketing for your shiny new bricks, because even the most brilliant piece of code will go unnoticed if nobody tries it. Even if you don't want to be committed to the project long term, you'll feel more satisfied with a few new bricks in place, instead of having worked half a year on a shiny new picture, which is damned to collect dust on some rarely visited web site. Ouch. Now I've probably confirmed all your received fun-stoppers. Biting through some granite can be even more fun, if you see the success afterwards. Cheers, 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: Advanced grids in GTK Pcb
Am 14.02.2011 um 07:37 schrieb jpka: Now i know my work is welcomed, so i will try to do it according to your suggestions. Does the grid still change in case you swap the measurement unit? This behaviour should probably go away. Switching to mm doesn't neccessarily mean you want a mm-related grid. For the more general target, I think it would be a good idea to have a grid-free future in mind. It's not neccessary to do that immediately, but one day the grid-based approach might be replaced with one using alignment functions, similar to how general drawing applications work these days. 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: General Layers questions
Am 13.02.2011 um 22:32 schrieb Martin Kupec: My question is: What is impossible to achive with the current implementation and what would one like to achive? So far I couldn't find a select by layer function. Now, if layers could be hidden individually, and not only in groups, that would almost equal a select all. Perhaps I missed something, but that enforced hiding in groups should probably be optional. 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: transition of pcb internal units to metric (SI, mm)
Am 08.02.2011 um 08:44 schrieb rickman: Do you expect these tools to be used to design chips costing far, far over $3 Million just for the mask set? I'm trying to think 20 years into the future. Especially if it's only a matter of allowing a compile time flag or not. 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: transition of pcb internal units to metric (SI, mm)
Am 07.02.2011 um 19:37 schrieb Colin D Bennett: This has been discussed on the list before and the proper answer is to use 64-bit integers representing length in nanometers. Isn't a nanometer pretty big when doing chip design? Others might have more/any experience in this area. I believe the solution is to make the standard internal representation a 64-bit integers but provide a compile-time configuration option to use 32-bit integer representation Now _that's_ asking for trouble. Essentially, you have to code all the maths twice, and in a compatible manner. You have to compile twice to run tests - or to continue to develop in pure 32-bit. Seeing about any serious desktop or server CPU has a 64-bit maths unit these days, it's probably not worth this trouble. My $0.02 suggestion would be to use picometers with 64-bit only. That's still +-9000 km possible board size. Am 07.02.2011 um 19:41 schrieb DJ Delorie: Please don't start the discussion again; Sorry, DJ, just trying to get PCB out of the habit to change units every few years. 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: New Column: From the CAD Library
Am 06.02.2011 um 16:24 schrieb Peter Clifton: Imperial parts are not a problem for a sufficiently fine metric grid. I don't think we should remove the option of working on a Mil grid though. I'm wondering what's the advantage of having an internal grid at all. Why not just use doubles, describing a position in meter or millimeter? About all mechanical CAD and picture drawing applications do it that way. 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: Fluky Fluky layout printing problem!
Am 25.01.2011 um 20:10 schrieb DJ Delorie: (ok, someone add a feature request for ability to tag footprints for re-import - it just needs to tweak the footprint name string) Plus, try to place the reviewed footprint in the same place. Well, ideally. 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: Collaborative Development of Boards
Am 20.01.2011 um 02:24 schrieb Stephan Boettcher: If everybody sticks to a sublayout, at least the VCS merges will not conflict. If the drawn copper conflicts, that's what needs to be cleaned up after the merge. For efficient collaboration there should be some aggrement about who draws where, but technically there should not be any limits how sublayouts overlap. That's back to square one. The purpose of collaboration with a VCS isn't to get something initially done - you could easily use copy paste for that - but to refine things over and over again. 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: How to set the margin for printing?
Am 18.01.2011 um 09:42 schrieb Colin D Bennett: it's unfortunate that printers are usually not physically capable of printing on the entire page for the intended paper size. However, given that this is a widespread restriction, there are really only two options for the printer when you ask it to print a document on a particular size page - it has to scale the image or it has to crop it to the printable area. Third option is to simply ignore that restriction and let the printer do the cropping. Actually, that's the easiest one to code, and the one least confusing to the user. What you guys are probably talking about is the imaginable area of a print. That's = paper area, of course, and advertised by the printer. A small excerpt from my printer's PPD: *PaperDimension A4/A4: 595 842 *ImageableArea A4/A4: 12 12 583 830 There's also the term PageRegion - same values as PaperDimension -, but I'm not deep enough into the matter to know the difference between PaperDimension and PageRegion. 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: Collaborative Development of Boards
Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. 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. 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: Collaborative Development of Boards
Am 19.01.2011 um 22:27 schrieb Stephan Boettcher: Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. 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. Why do you need that limitation? Without that limitation, a zone is no longer a zone and conflicts can happen. Doesn't apply for tracks drawn to the main layout, of course. Also doesn't apply to sub-layouts of undefined size, but then the idea of sectoring a board for different contributors becomes a bit limited. That said, I could use such sub-layouts right now, and they'd save quite a bit of work :-) 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: Collaborative Development of Boards
John, Stephan, Rick, Tibor, many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear. Am 16.01.2011 um 22:37 schrieb Rick: To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level. Am 17.01.2011 um 06:28 schrieb ge...@igor2.repo.hu: While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. I've filed a bug for this: https://bugs.launchpad.net/pcb/+bug/703914 As I'm not aware of a use case for this data, I suggest to get rid of it entirely. If somebody has a use case, please speak up there. The other problem is diff. Again, I don't think there is anessential difference between team work and VCS in software development and in using the same methods/tools on other fields; at least we have the same methods, but some tools are partially missing. As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) However, your point is totally valid on the other hand: these little fixes, getting the silk layer look nicer for example, does not make any sense if you will move half of the elements in the near future, for example because you don't even have a decision on the connectors yet. The point isn't about refusing cleanup, it's more about doing such cleanups and all those small changes in seperate commits. Each change in it's own commit, so it can be reviewed or cherry-picked easily. I know, the temptation to do it all in one batch is big, as all the current shortcomings are right in front of your eyes. But you loose a lot later. Probably a matter of demonstration the advantages ;-) 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: Collaborative Development of Boards
Hi all, having run an open source electronics project with the intention of collaborative development for a few months now, the experience is less than inspiring. So I'm looking for opinions on how to do better. http://reprap.org/wiki/Generation_7_Electronics http://github.com/Traumflug/Generation_7_Electronics Looking at what happened in these few months, I think the essence can be described in 3 topics: 1. Files aren't mergeable. While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. One can store a design's files in a Git repository, of course, but always only in a linear fashion. As soon as one collaborator works on something, all others have to wait until he's done. The versioning system would actually need a locking mechanism, like good ol' CVS had. 2. Agreements on design decisions are impossible For example connectors: Some use connectors with 4 mm spacing, others use 5.08 mm spacing, third people consider anything pluggable as stupid and use nothing but screw connectors. A project leader - y'know, open source tries to avoid such terms - can do a decision, of course, but single people will plainly refuse to manufacture or use anything without their favoured connector. Such design details are apparently hardcoded in electronics' people's brains. As a result, lots of incompatible designs exist, and there's nothing like a preprocessor, which could switch between different details on the fly. The same applies for FETs, diodes, jumpers, whatever. 3. No focus on the problem to solve If you look at the recent commits of this project you'll see enhancements always coming along with a plentitude of unrelated changes. Yes, make these pads a bit bigger, but also move a track here and change a text there. looks better. IMHO, doing such random changes is good for nothing but asking for trouble. Yet, none of the coworkers seems to see what I'm talking about. They do looks better all the time, making reviews a lot harder, and sometimes you even get regressions. Being more a mechanics and software guy, I'm astonished how things in the electronics world apparently work. Perhaps I'm exaggerating a bit. Is it even possible to do something in collaboration? I'd appreciate any answer. Cheers, Markus P.S.: Yes, I'm well aware of the Arduino project, and I see only single people results there. No collaboration. P.P.S.: The project's success isn't as bad as the above might imply. The design actually works. - - - - - - - - - - - - - - - - - - - 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: Rant about Make Inv Text Vis
Am 15.01.2011 um 09:47 schrieb Peter Clifton: On Sat, 2011-01-15 at 07:54 +, Peter TB Brett wrote: - Original message - What is the point of the command Make Inv Text Vis in gschem, other than aggravating me. Good question. I'm not aware of a use-case for it either. At the very least, it should be undo-able. Please file a bug report. Lets kill it with fire. One use-case would be to quickly inspect all of these attributes. It makes a difference wether you see attributes in a seperate sheet vs. you see them right next to each symbol. For making this use-case, this command should actually do what it says: make invisible text visible, i.e. leave everything stored in the schmatic's file untouched. Instead, it sets the visible flag on all texts, which is nonsense, of course. 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: Building PCB
Hello all,
first of all, thanks to the people helping me to set polygon
clearance. This works, at least for small clearances. Clearances
bigger than about 0.5 mm let pcb die or create very odd results,
though. As the PCB coming with Ubuntu 10.10 is pretty old, I tried to
build from source:
$ sudo apt-get install intltool flex libgd2-xpm-dev
$ git clone git://git.gpleda.org/pcb.git pcb
$ cd pcb
$ ./autogen.sh
Checking autopoint version...
./autogen.sh: 18: autopoint: not found
Running autopoint...
./autogen.sh: 33: autopoint: not found
(no configure created here)
$ autoconf # -- the INSTALL doc says so
configure.ac:6: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.ac:8: error: possibly undefined macro: AM_CONFIG_HEADER
(... and a few more ...)
$ ./configure --prefix=${PWD}/../pcb_Installation --disable-doc
./configure: line 2245: syntax error near unexpected token `1.9'
./configure: line 2245: `AM_INIT_AUTOMAKE(1.9)'
$ autoconf --version
autoconf (GNU Autoconf) 2.67
As you can see I'm undecided wether to use ./autogen.sh or autoconf.
Has somebody similar experiences? Perhaps a solution?
Thanks,
Markus
P.S.: Yes, I had the build process working on the previous version of
Ubuntu, but can't see what's different now.
- - - - - - - - - - - - - - - - - - -
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: Building PCB
Am 13.01.2011 um 16:46 schrieb DJ Delorie: Run autogen.sh; it runs everything else for you. Then run configure with the options you want. autopoint is in gettext autopoint is in a seperate package, but other than that, autogen.sh worked flawlessly. Thanks. Next problem is, there is no longer a dbus-1 package. Stuff is either in dbus or libdbus-1-3. I'll try to figure that on my own. 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: Bug triage
Am 10.01.2011 um 02:33 schrieb Peter Clifton: On Mon, 2011-01-10 at 02:18 +0100, Kai-Martin Knaak wrote: By the way, the download statistics is interesting: https://sourceforge.net/projects/pcb/files/stats/timeline? dates=2002-01-03+to+2011-01-10 Over the years, the download count integrated to an astonishing 150.000 To me, the interesting statistic is more: TOP OS * Windows 79% of downloaders https://sourceforge.net/projects/pcb/files//stats/os? dates=2003-02-11%20to%202011-01-10 ... and a minute later ... Look at the source downloads for the latest release though: https://sourceforge.net/projects/pcb/files/pcb/pcb-20100929/ pcb-20100929.tar.gz/stats/os Only 50% Linux downloads, 25% Windows again. These numbers are very biased, as about all Linux and *BSD distributions have some sort of package management system, so there's no need to download sources from SourceForge or build binaries by hand. Just doing some apt-get or emerge or whatever is much more convenient and reliable. For example, sites like the Ubuntu Popularity Contest show 11'000 installations with about 1'000 users: http://popcon2.net/package/geda.html#graph-0 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: Clearance of polygons around tracks/pins/pads
Sorry for the noise, but even extended googling didn't show me how to set the clearance around tracks, pins and pads. I've found the related DRC preference, I'm aware of the K key to change it for single elements, but what I want is a preference, setting the clearance for all elements. Is this possible? Thanks, 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: [pcb/lesstif] allow zoom out and pan more than board size
Am 31.12.2010 um 07:10 schrieb DJ Delorie: here's a patch that lets you zoom out more than the pcb size! Also lets you pan the board anywhere, not just to the edge of the window (i.e. you can position the edge of the board in the middle of the window now). Great idea! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: TRACKERS [was: Re: gEDA-dev: Dev list [was: Random thoughts onthe future interface of PCB]]
Am 10.12.2010 um 21:03 schrieb Peter TB Brett: My main objection to Launchpad in the past was that it was closed- source, but now that that has been changed... it's hard to find a reason not to use it for bug tracking instead of SF.net. I've commited a bunch of bugs against Ubuntu, the prestige-project of Launchpad. Finding similar bugs, or any related bug was almost impossible. The project's source code feels so far away I never got in touch with it. So, no engouragement to actually fix something. Another reason would be perhaps it's use of Bazaar instead of Git. This not-so enthusiastic experience might be Ubuntu specific, of course. Using Github, the experience was a lot better. Regarding the messenging system it's not as full featured as the others, but sufficiently featured. Everything on Github centers around the source code repository, so you almost have to run away to not start fixing the issue. Forks are still a fork, but pull requests and similar features make it more feel like a branch. Many people use this fork-and-pull-request thingy, so it's simple to review something or ask for refinements without worrying about the main repo. You can put comments right into the provided patches and they're picked up in the issue's tracker log. Very productive. my $0.02 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: Random thoughts on the future interface of PCB
Am 06.12.2010 um 12:55 schrieb Armin Faltl: Markus, did you realize by now, that drill file optimization is actually the NP-hard 'traveling salesman problem'? Tons of literature and algorithms exist for it ;-) Sure it is, and the original algorithm is back in place. Admittedly, I only had a look at the top of the algorithm, where a comment stated sort by distance from origin or something and didn't look what the function actually does. Now, do _such_ minor annoyances hold you back from changing source code to the better? I experience such sitations often and sometimes I loose, often I win. But always, discussing a detail topic and/or implementing alternatives improves the knowledge contained in the code. Just make sure you leave a comment in the code telling about the non-improvements with these alternative approaches. The unfortunate thing about such commodity issues is, some people built up a somewhat unfriendly attitude against any code changes at all. Perhaps because each code change sends the unseen, implicit message to the original author: you were wrong or could have done better. Another, often seen attitude is it works for me, so any change can do nothing but harm. Please get over such feelings. Nobody sits down and hacks away hours and days just to point a finger to anyone. Much less they try to harm or hobble anybody. It's a totally normal affair in evolution to find improvements later in time, and _that's_ the reason why programmers start submitting patches: improve something based on previous art. So any patch should give you the feeling: my code was great, because others could improve on it and the sum of both works wouldn't exist without my original. 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: Random thoughts on the future interface of PCB
Am 06.12.2010 um 16:32 schrieb Stefan Salewski: Sometimes there are some good reasons against code changes: - huge increase in complexity for minimal gain. gcc 4.x may be an example for this -- for some architectures there was not much gain from 3.x, for microcontrollers there was some regression. - sometimes the basic design of software is so bad (spagetti code) that each modification will introduce bugs. - with changes the code will not work any more with old hardware or libraries or architectures. - porting to other languages or hardware can become harder - licensing may be another issue, BSD/GNU/APACHE... At best, these are reasons to ask the commiter to review his code to match additional criteria. How would he know what traditinal gEDA developers consider to be well formatted code, a good strategy of conditionals, or what they consider to be a huge increase? In the two months I'm on this list I've almost never seen such such a request for matching additional criteria, despite of lots of no-no criticism. Even if the commiter doesn't want to review his work for whatever reason - likely he will, as he wants to see his code in the main trunk - there's always the chance somebody can learn from this, as it solves a particular problem. 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: Clearance in fiducials blocking solder paste
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
Re: gEDA-user: Random thoughts on the future interface of PCB
Am 03.12.2010 um 19:54 schrieb Bob Paddock: Sorry, I can't buy the its got to be a pain to use it argument in any manner at all. There's no need to buy this. A good example is simulation. The whole point of a simulation is to replace complex maths with a more pleasant experience. Undoubtly you could describe technical problems of any complexity with huge mathematical formulas, but doing a simulation is almost always much faster. 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: comments on gcode generation (was: Re: exportingsingle pcb layers)
Am 01.12.2010 um 21:47 schrieb Bert Timmerman: * no voronoi mode: all the other tools (see below) support a mode where they fill the unused area of the board with the closest net. this cuts the machining time down to less than 50%. Yes, this would be a very welcome addition. Is there a pure C library with this stuff available somewhere? Java or C++ isn't an option for inclusion with gEDA. http://www.qhull.org There happens to live a git repo here: git://gitorious.org/qhull/qhull.git Thanks for the link, Bert. I fear this is a bit too complex for me to justify putting it in the next few days. 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: comments on gcode generation (was: Re: exporting single pcb layers)
Am 30.11.2010 um 16:29 schrieb chrysn: On Mon, Nov 22, 2010 at 08:29:31AM +0100, Alberto Maccioni wrote: in the process of cnc-milling a pcb with a custom shape using pcb2gcode [1], i created a polygon on a separate layer... Have you ever tried the g-code exporter included in PCB? I've never been able to make pcb2gcode work with minimally complex boards. i just did so, and found out there are some reasons i'll -- at least for the time being -- will continue to use external tools: * no voronoi mode: all the other tools (see below) support a mode where they fill the unused area of the board with the closest net. this cuts the machining time down to less than 50%. Yes, this would be a very welcome addition. Is there a pure C library with this stuff available somewhere? Java or C++ isn't an option for inclusion with gEDA. * strange outline behavior: i'm not sure what the outline file is supposed to do, but for my testing example it cuts on the inside and the outside of the outline line, and additionally cuts in the drill holes. this might be a bug, depending on what it is supposed to do exactly. Without code patches, lines on the outline layer are handled just like any other traces. This is improved with some of these patches: http://sourceforge.net/tracker/? func=detailaid=3100354group_id=73743atid=538813 You can apply them all without loosing anything. Outline milling is still limited to rectangular boards without holes, though. * no mill drilling: if a milling head is used to cut out the board along its outline, the same tool can be used to drill arbitrarily large holes by moving in circles. that might be what is intended with the holes in the outline layer, but they don't really fit size- and shape-wise. Actually, this is on my today's work list. With some luck it'll appear in the above set of patches this week. * parameters: there are five tunable parameters in the gcode export, while there are roughly three times as many in pcb2gcode, most prominently the feed rates and speed settings. while of course the number of parameters is not an indicator of completeness or quality, i think it is roughly representative of the state of pcb's gcode support. User definable feedrates went into the patchset just yesterday :-) The unpatched exporter is more directed towards Emacs-savy people, replacing the single F command near the top of the G-code isn't that difficult. I had a look into brdtrace and, well, it's _very_ basic. Only one layer per run, no solder side flipping. Impressive for a weekend's worth of work, though. 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 16.11.2010 um 22:51 schrieb d...@umich.edu: However, the gcode export always crashes if I try to define the outline with a rectangle. It crashed also when the outline layer contains only a single vertical or horizontal line. Fixed in a new patchset: http://sourceforge.net/tracker/index.php? func=detailaid=3100354group_id=73743atid=538813 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 15.11.2010 um 06:55 schrieb d...@umich.edu: I tried to draw an outline in an 'outline' layer and 'pcb' just turned the trace lines into an isolation routing outline. Ouch. This shouldn't happen. Did you apply all 24 patches? If yes, could you send me (not to the list) the .pcb file showing this behaviour ? I must not be getting your explanation. Do I use a rectangle in the 'outline' layer to define the outline? Exactly. A rectangle, or any number of lines drawing another area. Milled is always a rectangle, though. 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 15.11.2010 um 18:06 schrieb Stephan Boettcher: Markus Hitter m...@jump-ing.de writes: Exactly. A rectangle, or any number of lines drawing another area. Milled is always a rectangle, though. Hmm, why? The outline layer is especially useful for boards that are not rectangular shaped. As I explained earlier, simply because nobody implemented it yet. The spot in the code is even marked with a comment. 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 13.11.2010 um 11:43 schrieb d...@umich.edu: I will keep R-ing the F-ing M's to try and figure out what git am 00xxx.patch means. It's a command to be typed in the command line. Replace the xxx with the corresponding name of the actual patch file, of course. To apply all patches without getting thick fingers, here's a small script, also to be typed in a terminal/bash shell: for F in 00*.patch; do git am $F done Before doing so, you have to download all of them, of course. 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 14.11.2010 um 10:38 schrieb d...@umich.edu: I have figured out how to add your 24 patches with git, I recompiled 'pcb', and I am trying out the new version. That's great. Just a second before I sent further comments :-) Adding a tool table might be cool. As far as I understand, this is done in pcb on a different level: http://pcb.gpleda.org/pcb-cvs/pcb.html#Vendor-drill-mapping Didn't test it yet, though. In regards to cutting the board outline: What I am noticing is that the global board dimensions set in Preferences get turned into a xxx-outline.cnc file. Correct? If there is no outline layer, yes. I think there should be an outline layer in the main window (along with the solder, component, and other layers in 'pcb') where you can draw your outline with a trace line. Sure, go ahead and create it. You create layers somewhere in preferences. I hope the exporter's behaviour is correct for both, adding the outline layer to the component side as well as adding it to the solder side. In the later case, general milling is mirrored, just like isolation milling. Not that mirroring an x-y-aligned rectangle changes anything, but with some luck somebody will find the time to implement milling of complex outlines one day. Also, a box to input the feed rate (F) would be nice. Yepp, that's on the to do list. Five feedrates: isolation milling approach, isolation milling work, drilling approach, general milling approach, general milling work. Many tools prefer different feedrates for vertical vs. horizontal movements. 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 11.11.2010 um 05:11 schrieb d...@umich.edu: I like that the gound plane outline is machined. The circular pads could use some more lines to round them out. Have you thought about programming g-code arcs (G02, G03) for them? HeeksCAD/CNC does this (see below). Using G02/G03 isn't trivial, as the isolation milling paths aren't calculated by offseting all the existing lines and pads by some geometric calculation, but by drawing all the traces, widened by the tool radius, to a pixel-based intermediate image, then figuring the required paths from there. All this algorithm was done by Alberto Maccioni and some research brought up the statement, this is the only reliable way for offseting all the traces. Doing exact offsets is said to fail in edge cases. If you want more precision, you can raise the accuracy, which is set to 600 dpi = 1.7 mil by default. Having a dxf file allows people to tweak all of the milling variables (depths of cut, jogs, feed rates, number of passes, pocketing, drilling, etc) in a CAM program, rather than go through the g-code by hand. Except for multiple passes and clearing out pockets completely, this functionality exists already. Feed rates have to be hand-edited in the resulting file currently - a single spot near the top of the file - but this is a subject to change soon. A few tests with Eagle's G-code exporter using multiple passes show results worse than with a single pass, but your mileage may vary here. You need a really stiff and precise machine for such things, as the typical engraving tips are more pressing the copper aside than really cutting it. An DXF exporter would be an entirely different exporter and good luck finding an algorithm to connect all the lines and circles together. That said, you can use the PostScript exporter and load that into Inkscape. Create an outline path for all the lines there, stitch everything together and export it to G-code with Inkscape's G-code functionality (an add-on) - and you'll soon be happy with pcb's G- code exporter als any attempt via the DXF route is a lot more work. :-) 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Am 11.11.2010 um 20:28 schrieb d...@umich.edu: The drill xxx.gcode.drill.cnc file goes through the board drilling all of the holes without differentiating the different drill sizes (found in the xxx.fab.gbr file). And, there are no tool change g- codes for changing between drill sizes. You have an old version of the G-code exporter. Ths sorting is done already, just the T command is missing. See: http://sourceforge.net/tracker/index.php? func=detailaid=3100354group_id=73743atid=538813 That said, I plan to mill bigger holes with the mill bit: drill with a 0.8 mm bit, do an outline mill with an 1.0 mm bit and everything is appropriate with just one tool change. 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: Restrict facility?
Am 10.11.2010 um 06:09 schrieb DJ Delorie: 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. Isn't there the route layer? I've seen special handling of this layer in many source code files, but didn't test yet, what it actually does. 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: Next step
Am 01.11.2010 um 23:12 schrieb John Griessen: Did you already get circuit prototyping results with that? I didn't actually send it to a milling machine yet, but the simulation in EMC2-sim looks fine. 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: Enhancements for gEDA/pcb G-code export
A new set of patches is out, addressing all the suggestions here: http://sourceforge.net/tracker/? func=detailaid=3100354group_id=73743atid=538813 New patches make G-code output respecting the outline layer if available. Enhancements planned include milling this outline with an end mill and using that end mill to drill bigger holes by milling a small circle. While I tried, I couldn't find any code in pcb's sources which would produce an offset of the path in the outline layer with proper relimiting of the lines in respect to each other. I'd be glad if somebody can point me to such a function without introducing new dependencies. Else I'd have to restrict this outline milling to rectangles, as the route used for isolation milling is difficult to handle either. 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: Next step
Am 01.11.2010 um 18:52 schrieb John Griessen: only worried about milling and drilling. We've not had anyone with a circuit mill talk here yet that I know. Didn't notice the Enhancements for gEDA/pcb G-code export thread? When building pcb from source, you get an G-code exporter, which produces isolation milling and drilling G-code. http://sourceforge.net/tracker/? func=detailaid=3100354group_id=73743atid=538813 tries to enhance this exporter. 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: Next step
Am 01.11.2010 um 22:03 schrieb Matthew Sager: if you plan to use the same size bit as the trace width and you just want to mill down the center of the trace. Huh? If you mill down the center of the trace you remove the copper there and get a negative of what you want. Did I miss something? 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: Ben mode feature request
Am 01.11.2010 um 19:35 schrieb John Doty: the GUI designer's necessarily limited horizon. You become offending. Please go ahead and implement the CLI interface. It won't go away when the GUI arrives. 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: Ben mode feature request
Am 31.10.2010 um 21:05 schrieb Stefan Salewski: There will not be much real benefit from Windows/Ubuntu-type of users. If they do not understand a line like cp xxx yyy -- can we really hope that these people will at some time do serious coding? Then, there are many people which know cp xxx yyy, but prefer to avoid it anyways. You want to catch these. 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: Enhancements for gEDA/pcb G-code export
Am 28.10.2010 um 20:48 schrieb Levente Kovacs: Could you please point me a g-code viewer for Linux? Preferably debian. I'm not aware of one, but EMC2 has a simulation mode: http://reprap.org/wiki/PCB_Milling#EMC2 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: Enhancements for gEDA/pcb G-code export
Am 28.10.2010 um 18:16 schrieb Steven Michalske: My suggestion is that the ability to specify settings predefined levels of machines. Either by making an addition to the current gcode exporter, (dropdown list) or by making a separate RepRap exporter. By factoring out common code and placing a clean API on it. For one, it's not only RepRap which doesn't understand the current advanced G-code, but many CNC machines in wide use. Tooling machines have a long life and 30 years ago the computing technology simply wasn't where it is today. That said, a general simple G-code vs. advanced G-code is a good idea. Simple works on all machines, advanced on modern machines only. Similar to PostScript level 2 vs. PostScript level 3. The actually machined result is always the same, the difference is in hand editing comfort of that G-code. 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: Enhancements for gEDA/pcb G-code export
Am 27.10.2010 um 22:57 schrieb Alberto Maccioni: Actually the code is already working; I'm glad the current code works for you, it doesn't for me. Please pick up what you think is useful, I'll maintain a patch for the remaining customisations in the RepRap Wiki. We need software working out of the box there, educating people about something is almost no option. 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: pcb outline clarification
Am 25.10.2010 um 03:43 schrieb gene glick: My outline layer was labeled Outline. Changing it to all lower case fixed it. I'm about to offer a patch to allow upper case characters as well, and allow the outline to be on the solder side. The later would allow to mill the outline on single sided boards. 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: pcb outline clarification
Am Montag, den 25.10.2010, 12:53 +0200 schrieb Markus Hitter: Am 25.10.2010 um 03:43 schrieb gene glick: My outline layer was labeled Outline. Changing it to all lower case fixed it. I'm about to offer a patch to allow upper case characters as well, and allow the outline to be on the solder side. The later would allow to mill the outline on single sided boards. Well, and then I found this in the Changelog: 2009-11-12 Peter Clifton * pcjc2 AT cam dot ac dot uk * * src/draw.c, src/hid/common/flags.c, src/hid/gerber/gerber.c, src/hid/png/png.c, src/hid/ps/ps.c, src/print.c: Use strcmp() for special layer names, rather than strcasecmp() Before commit 086aa491fae18f1ec72da047b772fa3510f72d0b, we were using strcmp() and strcasecmp() in different places. That commit changed to strcasecmp(). Lets choose to keep the more restrictive option for now, which reduces the number of magic layer names PCB supports. Looks like coding simplification is favoured over user friendliness. OK, scratch that idea of a patch. Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb outline clarification
Am 25.10.2010 um 13:13 schrieb Peter Clifton: I committed a change which made everything support mixed case, but after some discussion, reverted it and made everything consistently case sensitive. Found that in the ChangeLog and promtly raised the noise level of this list. :-/ and allow the outline to be on the solder side. The later would allow to mill the outline on single sided boards. Do you mean flipping the outline layer so the router is effectively working from the underside of the board? Sounds like a potentially useful flag. Presumably the G-code exporter already flips the solder side. Yes, yes and yes. It looks like it's sufficient to just not treat the outline layer when handling isolation milling, but in a then new feature of outline milling. If you want to mill the outline from the front side, add outline to the component side group, else add it to the solder side group. 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: Enhancements for gEDA/pcb G-code export
Am Freitag, den 22.10.2010, 23:54 +0200 schrieb Markus Hitter: https://sourceforge.net/tracker/?func=detailaid=3093302group_id=161080atid=818428 Traumflug's wishlist in the Patches section, in case this long link doesn't work. New patches today: HID-gcode: remove a leftover debug-printf. HID-gcode: provide info about drill diameters in G-code as well. While this is currently unsorted, it's helpful for hand-editing already. HID-gcode: sort drills not only by distance, but also by diameter. This should help greatly when using a tool changer. Next step would be to actual insert tool change commands and/or split G-code output files by drill diameter. The later is for manual tool changing, then. HID-gcode: report one drill diameter only once in the output file. Cheers, Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Enhancements for gEDA/pcb G-code export
Hi again :-) Hacking pcb is so much fun, I'm already close to the part where I want to implement milling of non-track stuff. Like the board's outline, like venting holes, like bigger bores. Likely the best idea would be to search for such geometry on a milling layer. I also think it's best to ignore line thicknesses for such tasks and to simply move the mill bit along the line's or arc's center. Set the line width to the mill bit's diameter and the display is accurate. One question arises is, how to decide wether to flip the geometry or not. Single-sided boards are manufactured from the bottom side only, so flipping would be undoubtly appropriate. Is there a need for milling from the top side, after all? If I put the milling layer into the solder side and component side groups for distinction, this disturbs all the tracks, right? Another one is, is there a GUI way to create lines outside the board? Milling the outer border of the board is always done from outside the board, after all. Any comments are welcome 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: Enhancements for gEDA/pcb G-code export
Hello all, much to my enjoyment I've seen very recent versions of pcb come along with an G-code exporter. It isn't perfect yet, but apparently quite usable already. To improve compatibility with more simplistic machine controllers, I've hacked the code a bit. The result is a patchset, which I've uploaded to the RepRap Wiki for the current lack of a better location: http://reprap.org/wiki/PCB_Milling#gEDA.2Fpcb_-.3E_G-code Where would be the best place to offer these files for inclusion into the official repository? While I tried to code quite carefully, there are likely questions, remarks or requests for review. Is this discussed somewhere? Cheers, 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: Enhancements for gEDA/pcb G-code export
Am 22.10.2010 um 20:55 schrieb Alberto Maccioni: Can you please describe the changes and the problems you experienced? There were no real problems other than the produced G-code is a bit too enhanced for primitive G-code interpreters. Most of the patches introduce enhancements, like optional usage of G-code variables or a pre-drilling feature. To make things simple for me, here are the subjects of the currently 15 patches, most of them have 20 to 30 line changes: HID-gcode: let the system library allocate the temporary file. HID-gcode: Avoid more than one G or M code per line. HID-gcode: make use of MAXPATHLEN. HID-gcode: get rid of tabulators in gcode.c. Pure whitespace change. HID-gcode: create better file names. HID-gcode: add a flag wether to use variables in G-code. HID-gcode: switch from tool-radius to tool-diameter in the user interface. HID-gcode: add a comment about the tool diameter into the G-code file. HID-gcode: simplify code a bit. HID-gcode: introduce a flag on wether to use a drill cycle for drilling. HID-gcode: don't close the mill file before the drill file is written. HID-gcode: postpone writing of the overall mill distance until the HID-gcode: split variable_depth. HID-gcode: finally, add predrilling. HID-gcode: enhance accuracy of the distance report for the drill file. I'll try to upload them to Sourceforge. Next features on my personal wishlist would be to add tool changes and/or file splits for different drill diameters, different feedrates for approach/isolation mill/drill, feedrate fields in the user dialog, and some option to mill outlines. 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: Enhancements for gEDA/pcb G-code export
Am Freitag, den 22.10.2010, 23:26 +0200 schrieb Markus Hitter: I'll try to upload them to Sourceforge. Done: https://sourceforge.net/tracker/?func=detailaid=3093302group_id=161080atid=818428 Traumflug's wishlist in the Patches section, in case this long link doesn't work. Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: How to connect pads to anything?
Hello all, yesterday I tried to replace a number of 2-pin jumpers (footprint JUMPER2) with solder jumpers. gschem2pcb does it's duty, removes the old footprints and provides the new ones. The rats nest is drawn correctly. However if I try to connect these new footprints with anything, the connection is simply ignored. Optimize the rats nest and the yellow lines don't vanish, the number of missing connections is kept. The autorouter doesn't do anything, als everything else is connected. Instead I even get DRC errors stating the track and the pad are too close *sigh* After googling and reading the pcb handbook for the better part of a day I'm stuck. Whatever I try, pads can't be connected to anything. Not on the solder side, not on the top side, not to vias. What's the secret? The most simple footprint I tried looks that: Element[ Solder Jumper on the solder side JUMPER_SOLDER 10 10 -5000 5000 0 100 ] ( Pad[2200 -1500 2200 1500 3600 3200 2000 1 1 square] Pad[-2200 -1500 -2200 1500 3600 3200 2000 2 2 square] ElementLine [ ... ) I'm using the software packaged with Ubuntu 10.04 on AMD64, which appears to be version 20091103. BTW., the reason I started using gEDA is to develop electronics for another open source project, RepRap. See http://reprap.org/wiki/Generation_7_Electronics . Thanks, Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to connect pads to anything?
Am 17.10.2010 um 15:47 schrieb Stefan Salewski: On Sun, 2010-10-17 at 14:50 +0200, Markus Hitter wrote: Hello all, yesterday I tried to replace a number of 2-pin jumpers (footprint JUMPER2) with solder jumpers. Of course, this should work fine, it does for me. gsch2pcb removes the old footprints, but for my 2009 snapshot it has not put the new ones, you have to do something like load element data to buffer to insert the new ones, and you may have to load the new netlist again. And you have to watch for the orientation of the new footprints, you may have to rotate them 180 degree. And press O key to update ratsnest. Did you make your layout with the autorouter? I have done all manually, so I am not sure if the autorouter needs special care when exchanging footprints. For replacing footprints there is a special mode which allows you to replace single footprints -- sorry can not remember currently. Thanks for the quick answer, Karl, Stefan. All what you suggest works fine already. The new pads appear, I route mostly manually and I can flip the pad The problem is, an overlap between a pad and a track isn't recognized as a connection. I'll try to show this with a screenshot, the rats nest is freshly optimized: inline: Bildschirmfoto.png Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to connect pads to anything?
Am 17.10.2010 um 16:17 schrieb gene glick: ElementLine [ ... is that a typo? It's an intentional cut to keep the message short. There are further ElementLines. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to connect pads to anything?
Am 17.10.2010 um 16:25 schrieb gene glick: If you are willing, send the .pcb file over. I can take a closer look. That would be greatly appreciated! Schematics and the board with the 2-pin jumpers are on Github, it's the Gen7Board.xxx: http://github.com/Traumflug/Generation_7_Electronics I've attached here my current version of the solder jumper, it's a bit different from what you see on the screenshot. JUMPER_SOLDER.fp Description: Binary data The jumpers I want to replace are J1 ... J12, placed horizontally in the upper half. Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: coordinate systems [was: pcb crooked traces]
Am 17.10.2010 um 17:16 schrieb Levente Kovacs: I think that is why X11 has its coordinate system as is; and that is why PCB developers went that way. But a CAD tool is not about CRT display or image processing. I think we should change it; it looks very awkward for a new user, who doesn't know the story. Being a new gEDA user and fairly experienced with other CAD applications I can tell I couldn't care less. If one ever has to enter or read coordinates manually, there's something incomplete or wrong with the GUI. another EUR 0.02 :-) 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: How to connect pads to anything?
Am 17.10.2010 um 17:44 schrieb Stefan Salewski: solder x GND-solder x VCC-solder x comonent x GND-component x Vcc-component x unused unused (bottom) x (top) x I set up layers stack when I start a new layout, but I think it will work if you change it now. Heck, adopting the last two lines of the scheme above worked like a charme. Thanks a lot for the help everybody! 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: coordinate systems
Am 17.10.2010 um 17:55 schrieb Stephan Boettcher: With gEDA, we do not use GUIs, we enter the schematics and the layout in emacs ... ... at least parts of it, sometimes. Ah, emacs people here. This explains a lot. Just for your entertainment: http://reprap.org/wiki/PCB_Milling#gerbv gEDA is yet another software suite with schematic and PCB layout editor. It wasn't included in the set of preferred choices here because it requires hand-coding of text files in between usage of the different GUI tools. Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: coordinate systems
Am 17.10.2010 um 20:28 schrieb kai-martin knaak: Markus Hitter wrote: http://reprap.org/wiki/PCB_Milling#gerbv gEDA is yet another software suite with schematic and PCB layout editor. It wasn't included in the set of preferred choices here because it requires hand-coding of text files in between usage of the different GUI tools. Actually, it does not. You can do the whole work-flow in GUI-mode only. You can use xgsch2pcb or the shiny new pull feature of pcb to eliminate the command line, too. That said, sometimes it is just easier to tweak the *.sch, or *.pcb files than use the GUIs. The reprap example shows how slightly misunderstood concepts may scare away potential new users/projects. As I wrote most of this RepRap Wiki page myself, I can also explain how this happened. When looking on how and wether to get away from the free but closed source Eagle I tried a small 8 elements electronics project on Eagle, KiCad, Fritzing and gEDA. All from creating schematics to the finished GCode needed for milling the PCB. RepRap is about machines replicating it's self, so getting boards from some industry company should be avoided as much as possible. Regarding gEDA, your home page recommends the gsch2pcb tutorial http://geda.seul.org/wiki/geda:gsch2pcb_tutorial for new users, so I started with that. If you look at this tutorial, it's full of command line stuff. Edit preferences files here, enter paths there, it even talks about manually fixing errors which occur ineviteably. Uh. I did the first steps successfully but when I messed up in either gschem or pcb the third time just because they use different mouse buttons for panning and zooming, I also started to wonder how I would explain all this stuff to these 16 year old schoolboys showing up at RepRap. I couldn't imagine that. Now it's a few weeks later and I use gEDA anyways, because I deviate from a part of the project done by an gEDA expert. I got accustomed somewhat to the inconsistent interfaces, found some spots of excellent GUI - DRC results or the layer setup editor, for example - and the suite starts to show it's bright side. Still it's difficult to explain this software to others. In case I'm allowed to write down my three biggest wishes, here they are: - Get that thing packaged as soon as a new release is done. Only software developers install from source these days. As far as I can see, Debian and the just released Ubuntu 10.10 still distribute the Nov 2009 release. - Get the interface, especially mouse button behaviour, consistent between all parts of the suite. At least for a default installation. It doesn't matter wether you have to use the middle or right mouse button to pan around, but having different buttons for applications you often switch in between is a non-starter. And no, pointing to the key bindings editor doesn't help, because people would have to learn that instead of learning how to get their project done. - Write a new tutorial. With a few pictures like before, and without any asking for editing text files. I've learned about xgsch2pcb and pull just with the email cited above, after reading many hours in various parts of the gEDA documentation. There is simply no hint such great features exist, so many users never find them. Yes, this type of public relations work is sometimes tedious, but it will undoubtly bring you a lot of new users as well. As far as I can tell gEDA is the most reliable and powerful choice of open source EDA. The text file format makes it attractive for experts. gEDA's GUI can be brought on par with Eagle or KiCad easily, so there's no reason to miss that opportunity. Thanks for listening, Markus ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
