Re: gEDA-user: PCB gcode generation
Probably we won't agree on that ever. The patchset is there, do with it what you think is the best thing to do. At the time I posted very specific objections to some of the patches; if you didn't bother to answer is your problem. Of course none of the developers will ever commit a patch that breaks functionality for any of the users. 2011/4/29 Markus Hitter m...@jump-ing.de: 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 ___ 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
Peter, my intention was not to start any war and I provided my review of the patches to improve them; you can check the archives and judge for yourself; in fact I agree 100% with what you said. Now I'll just list my objections trying to be more descriptive than before. An introduction to what the gcode exporter does: it prints a pcb like the png exporter, bloating the elements by some amount, then extracts the edges and prints them in a format that is understandable to CNC milling machines; also prints another file containing all drills. Now the patches that in my opinion cause problems: 1-HID-gcode: let the system library allocate the temporary file. Milling pcbs has one fundamental limit, which is the diameter of the milling tool; since you cannot cut anything smaller than that, all tracks and elements must have a minimum separation. But how would you check if this is the case? You can just look at the intermediate png file, the one that has the bloated elements; if you see that two distinct elements touch, it means that the chosen tool is too large so you can either use a smaller tool or move the elements further away. This is the reason why the intermediate file is needed and cannot be temporarily allocated. So I would advise to insert a configuration switch to remove or not the file. 5-HID-gcode: add a flag wether to produce advanced G-code. Gcode is a language, and as such there are many ways to do one thing; for example a drilling cycle can be done as the sum of single operations (go to the surface, drill, retract at various speeds) or as a single drilling cycle which has a code by itself. As you can imagine a file that uses the latter is more readable. The original exporter uses such enhancements, which by the way have been in the language from the beginning and are supported by the major interpreters (Mach and EMC2). The patch adds the possibility to produce a more basic gcode, which is longer and less readable but apparently can be digested by a larger amount of interpreters. My concern is that using the basic version by default makes the output files less readable and more bulky when in fact in 99% of the cases the advanced would be fine. I would do the opposite, produce basic code only when commanded to do so. 16-HID-gcode: sort drills not only by distance, but also by diameter. Currently all the drills are written in the same file, and the only ordering that is done is based on the minimum distance from the previous drill, starting from the one closest to the origin; this prevents the milling machine from jumping all around the board. This is a very crude way of operating, in fact some people requested to distinguish drills of different size. The patch does the following; drill = sort_drill_distance (drill, n_drill); qsort (drill, n_drill, sizeof (struct drill_struct), compare_drill_diameter); The result is that drills are sorted by size and is possible to insert a stop code to change the drill bit when needed; unfortunately the path minimization is not good any more, because it acted before. However the fix is fairly easy, just perform the path optimization for every set of drills that have the same size. One more important thing is that not everyone may like to sort by size, so I would add a configuration switch for that. I hope these comments won't be interpreted again as don't change my code. By the way, it seems that my original gcode patch is formally still uncommitted; since it has already made it to a release (ok, a real developer cleaned everything up) why not change its status? Or is it dependent on the documentation? Best regards, Alberto 2011/4/30 Peter Clifton pc...@cam.ac.uk: On Sat, 2011-04-30 at 12:24 +0200, Markus Hitter wrote: 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. I've not been following the technical details of this discussion, but I find the tone it is taking quite concerning. The gEDA and PCB projects very strongly aim to foster a friendly working environment and encourage contribution to the project. There is obviously a feature here that people have requested or required, and more importantly - that someone has taken the effort to implement. That merits effort in trying to constructively review and improve the patches if necessary. Without referring to each others answers (and starting a flame war!), I think it would be useful if Markus and Alberto both sent a brief summary email detailing the issue under debate, trying to objectively present BOTH points of view. I don't want to see any personal attacks, please remain diplomatic! I don't know enough of the gcode HID to know how to review or test effectiveness of patches, so someone needs to explain the issues for me. Finally.. It whouldn't bother me to leave the patchset where it is if I hadn't difficulties to convince people to use gEDA
Re: gEDA-user: PCB gcode generation
... 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. The point is that the above optimization has to be applied as the last operation on every set of drills (meaning a set of same size); and above all, if someone doesn't need the splitting by size there should be a switch to enable/disable it. 2011/4/29 Markus Hitter m...@jump-ing.de: 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 ___ 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
There was a patch that did something like that, but it broke the minimum distance path optimization, so your machine will do a great deal of jumps while drilling. I can write a new patch, hoping that someone will ever review and merge it; what G codes do you use for changing bits? Regarding the milling cuts I really don't know how it could be done; in principle it's possible to use different depths for different layers, but how would you choose which paths to mill? Some help will be needed from the ones that know how the png exporter works. A.M. 2011/4/28 John Griessen j...@ecosensory.com: On 04/26/2011 02:26 PM, Mikey Sklar wrote: 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. I've not used the Gcode export yet, but this sounds like something you can postprocess. grep or sed on the drill file should get you the separation you want... Nope. I ran export and it gives 387 G81 lines where I get a fab drawing with three different sizes totalling 387 holes on one of mine... - I'm struggling with cut lines. Specifically, cutting out the mounting holes and the circuit board edges. It would great if there was a way to select specific traces or vias for different mill-depths. Even better if I could control the order in which the cuts are made so I don't have a circuit board that has been cut free from it's clamping before the mount holes were cut. When I export Gcodes, I get a file, tek_7k_flex.gcode.outline.cnc that seems to be only about the outline, I get a sequence of 389 polygons that start and stop near eachother. Nothing is mentioned about the cutter size, but I guess they overlap so as to cut out the outline along the centerline of the outline trace. (My outline was defined by a layer called outline holding just a 10 mil wide trace, the center of which was the desired board edge.) tek_7k_flex.gcode.front.cnc contained 465 polygons, so it was different... John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Random thoughts on the future interface of PCB
However, if the goal is to attract users, there is a more powerful means: An installer of native windows versions that works with no caveats. Also a PCB frontpage with some screenshots. Appearence matters! ___ 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)
* 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%. Can you explain more? * 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. What do you mean with outline file? Can you provide an example? * 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. There is a patch on sourceforge that adds pre drilling, but a drillfile is needed anyways for those who wish to drill separately. * 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. Nobody has ever asked more (almost nobody uses this exporter); there is a patch to specify some more parameters, but you should request in detail what you need. please don't take that personally, i just think it's not quite there -- at least yet. No problem, at least you tried it; one thing I would ask you is to detail exactly what you need, so that I or somebody else can improve the code. BR Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: exporting single pcb layers
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. ___ 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
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. Actually the algorithm is not mine, it comes from potrace, a tracing program by Peter Selinger (as you can see in the source code copyright notice). Tracing involves a fair amount of mathematical analyses and his code gives excellent results with equally great efficiency. I just took the algorithm, stopped the tracing process before bezier curves extraction, and adapted it to the png exporter. HeeksCNC algorithm in comparison is extremely primitive and naive, and it doesn't even work in many conditions, for example very sharp edges cause it to crash completely. With a dxf file, in a CAM program, you can program your fine line cutting with a tiny v bit, then program a pocket operation with a larger bit to remove the remaining copper. Are you sure you want to do this? Is it for aesthetic reasons or because of better isolation? Besides thrashing large amounts of bits and requiring hours of work it won't make your pcb's work better; if you need good isolation it's better to insert several traces between the ones you want to isolate. Have you thought about programming g-code arcs (G02, G03) for them? HeeksCAD/CNC does this Once your resolution is high enough there's no difference between a line path and an arc. Detecting arcs would be extremely complicated; you can't describe a generic curve with arcs, so the original tracing algorithm uses bezier curves; you would need to check when a series of beziers are close enough to an arc. Does this make your end product better? Not at all, so it's not even worth to try, in my opinion. A dxf export could however be useful. 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. The drill file generation is being improved with separation between different sizes and better comments; if you have in mind a good sequence of commands for switching between drill bits please let us know. Best regards, Alberto ___ 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
Hello, here my comments about the patches: 1-HID-gcode: let the system library allocate the temporary file. The intermediate png file is necessary to check if the enlarged tracks touch and cannot be milled. 5-HID-gcode: add a flag wether to produce advanced G-code. please enable advanced gcode by default 16-HID-gcode: sort drills not only by distance, but also by diameter. drill = sort_drill_distance (drill, n_drill); qsort (drill, n_drill, sizeof (struct drill_struct), compare_drill_diameter); this breaks the path minimization algorithm: as already said sort_drill_distance HAS to be the last sort otherwise it doesn't have any effect; if you want to sort by diameter (which by the way is of no use without a tool changer command or a pause between different diameters) create a list for each diameter and use sort_drill_distance on all of them. Sort by diameter should be enabled by a flag. This is the third time I explain this so I'm starting have a doubt: am I not explaining well enough or are you not reading my comments? 19-HID-gcode: fetch the board's extents from the outline layer, if possible. what is this for? How is this better than the following? PCB-MaxWidth / pcb_unit; PCB-MaxHeight / pcb_unit; 21-HID-gcode: simplify and increase accuracy of a conversion a bit. How is this working? (pcb * gcode_dpi) / pcb_unit; vs. ((double)(pcb * gcode_dpi) + 0.5) / pcb_unit; 2010/11/1 Markus Hitter m...@jump-ing.de: 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 ___ 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
Hello, here some comments about your patches; I think most of them are good, but the gcode simplifications should not be enabled by default; in fact the most commonly used CNC controllers (EMC and MACH3) support all of the gcode features, it's RepRap that is behind an not standard. In detail: Avoid more than one G or M code per line. Please use a flag to enable this, as it tends to generate less readable files (esp. drilling with standard codes). Introduce a flag on whether to use a drill cycle for drilling. I would instead have a flag to disable M81 drill cycles, disabled by default. Add a flag whether to use variables in G-code. I would instead have a flag to disable variables, something like: avoid using G-code variables. Some non-standard machine controllers don't understand them switch from tool-radius to tool-diameter in the user interface. What is the reason for switching from tool radius to tool diameter? I think tool radius gives a better understanding of the effective distance between track and cut; in fact don't you find the following a little hard to read? Milling tool diameter, or twice the offset of the G-code track from the resulting copper track Simplify code a bit I don't understand what simplification is done here; the new code is longer and has more variables; is it easier to read? I find it less immediate. Sort drills not only by distance, but also by diameter. I probably didn't explain correctly the original feature: it doesn't really sort by distance from origin, it puts drills in the lowest relative distance sequence, starting from zero. This way the tool starts from zero and makes the least amount of movement to reach the new hole; now, I know that there is probably an entire class of very smart path minimization algorithms but this one proved to decrease the overall length quite a bit, so don't remove it. Regarding the hole diameter not everybody uses different bits for different hole sizes, so this feature should be enabled via a flag; and for every diameter I would run the path minimization as well. By the way, even without tool changer there's no need to split drills in different files, just insert M60 (pause) after every set of holes. Anyways it's good that somebody else is finally using the g-code exporter. Too bad the PCB documentation doesn't mention it; some time ago I did write a patch to update docs but it never went to the repository. Best regards, Alberto 2010/10/23 Markus Hitter m...@jump-ing.de: 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 ___ 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
Introduce a flag on whether to use a drill cycle for drilling. I would instead have a flag to disable M81 drill cycles, disabled by default. Well, the flag is supposed to do exactly this. Do you think there should be a better wording? All I was saying is that advanced features should be enabled by default, and I think it's better to have something like: Disable feature XX (unchecked by default) than: Enable feature XX (checked by default) Add a flag whether to use variables in G-code. I would instead have a flag to disable variables, something like: avoid using G-code variables. Some non-standard machine controllers don't understand them idem Sort drills not only by distance, but also by diameter. I probably didn't explain correctly the original feature: it doesn't really sort by distance from origin, it puts drills in the lowest relative distance sequence, starting from zero. This way the tool starts from zero and makes the least amount of movement to reach the new hole; now, I know that there is probably an entire class of very smart path minimization algorithms but this one proved to decrease the overall length quite a bit, so don't remove it. The sorting by distance is still there, just sorting by diameter takes precedence. Now, this is plain wrong: your replacement algorithm orders holes by distance from origin; the original algorithm does something very different: starting from the origin it builds a sequence of holes so that the path from one to the next is lowest. This has to be the last operation, because if you swap again the order you have the same problem you started with, i.e. the drill jumping all over the board wasting time. So I repeat that if you want to order also by size you should create a separate list of holes for every size you have, and for each list run my original algorithm. Try yourself the difference by visualizing the tool path in both cases. Regarding the hole diameter not everybody uses different bits for different hole sizes, so this feature should be enabled via a flag; Uh, yet another flag. And I consider at least three additional flags, e.g. feed rates for vertical vs. horizontal movement, as unavoidable. How many flags can be put into this dialog before it no longer fits onto the screen? Hmm. Looks a bit difficult to find an agreement. If there's hand-editing of the G-code needed, I'd consider this as a failure of the exporter. And I hate adding user-visible features, stuff should just work. Hence the tendency to switch flags on the safe, works everywhere side by default. This is not something that can be substituted by hand editing, it has to do with the equipment you have: how many people do you think will use a tool changer? Right now 0 out of 2 users, but I bet only a very small percentage will ever do it, so the most common drill operation will be done with only one drill. So I'd say that drill sorting definitely has to be optional. What you define safe features is just the set of features supported by a not yet mature particular machine (RepRap) which accounts for an extremely small percentage of hobby machines; G-code has been working with variables and multiple commands for tens of years, and probably your machine will be upgraded shortly. Also, hand editing is very common in the CNC world, due to the fact that you often adjust your codes on the field, based on what you equipment can do at the moment. Best regards, Alberto ___ 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
The G-code comes from the PNG exporter, so it doesn't care about the layer material. 2010/10/24 Markus Hitter m...@jump-ing.de: Am 24.10.2010 um 05:36 schrieb kai-martin knaak: 3) Add a layer outline and draw the borders of the board with a closed trail of lines. The width of the tracks does not matter. 4) draw lines outside the outline :-) http://geda.seul.org/wiki/geda:pcb_tips#how_do_i_make_a_board_outline_to_go_with_my_gerbers_to_the_board_maker Thanks for the explanation, Kai. Looks like there is more work coming in, as the G-code exporter treats the outline layer just like another copper layer, i.e. it mills the tracks there on both sides and doesn't care to offset coordinates to make them 0, 0 at one of the edges of the outline. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Enhancements for gEDA/pcb G-code export
Can you please describe the changes and the problems you experienced? 2010/10/22 Markus Hitter m...@jump-ing.de: 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Cygwin still supported?
You should have an X environment working and GTK 2.x. See if you can open nedit, it uses X. 2010/3/26 David MacQuigg macqu...@ece.arizona.edu: Alberto Maccioni wrote: I forgot to mention that you have to install an x-server (of course, otherwise how would it display anything?); I have libX11 and some other subpackages. I see in the current Cygwin distribution 5 packages with names starting libX11. I've installed libX11_6, the core library runtime, and a few other packages it brought in. Results are the same. Any others I should install. What .bin name are you talking about? The attachment is called setup.bin The setup.ini link at the bottom of your last message is actually a file with a cryptic name. Here is the HTML copied from your message: a href=bintih8V8jzr7.bin ttsetup.ini/tt/a -- Dave 2010/3/25 David MacQuigg macqu...@ece.arizona.edu: Alberto wrote: I currently use gEDA with Cygwin, it works perfectly. I even created a package and submitted it to Cygwin-apps to be included in the main list but so far it hasn't been accepted. You can dowload it manually at: http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/ Got it. Downloaded geda-gaf-1.6.1-1.tar.bz2 and setup.hint to ../cygwin/geda/geda-gaf/ Also put the setup.ini file at ../cygwin/geda/ Note: this file has a long cryptic name ending in .bin, which I tried to rename as setup.ini. This failed, so I left the filename as is. Create a directory of choice, copy the attached setup.ini in that, and put geda-gaf-1.6.1-1.tar.bz2 and setup.hint in a subdirectory named geda-gaf. Now execute cygwin setup and choose to install packets from the local directory where you put setup.ini. You should find gEDA as the only item in the list of packages and install it. The install finished without errors, and I see the geda hierarchy at /home/User/geda as expected. However, we still seem to have missing Cygwin packages! Looks like maybe gtk** is missing. $ gschem gschem:1036: Gtk-WARNING **: cannot open display: $ startx bash: startx: command not found There was no indication of missing dependencies from setup.exe. I'll try VirtualBox this weekend. -- Dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Cygwin still supported?
I currently use gEDA with Cygwin, it works perfectly. I even created a package and submitted it to Cygwin-apps to be included in the main list but so far it hasn't been accepted. You can dowload it manually at: http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/ Create a directory of choice, copy the attached setup.ini in that, and put geda-gaf-1.6.1-1.tar.bz2 and setup.hint in a subdirectory named geda-gaf. Now execute cygwin setup and choose to install packets from the local directory where you put setup.ini. You should find gEDA as the only item in the list of packages and install it. Alberto setup.ini Description: Binary data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Cygwin still supported?
What do you mean with once you have your package version 1.6.1? It compiles as in a linux system. Alberto 2010/3/25 John Griessen j...@ecosensory.com: Alberto Maccioni wrote: I currently use gEDA with Cygwin, it works perfectly. Thanks for telling us about this Alberto. What is it like to compile a new version for cygwin once you have your package version 1.6.1? John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Cygwin still supported?
I forgot to mention that you have to install an x-server (of course, otherwise how would it display anything?); I have libX11 and some other subpackages. What .bin name are you talking about? The attachment is called setup.bin Alberto 2010/3/25 David MacQuigg macqu...@ece.arizona.edu: Alberto wrote: I currently use gEDA with Cygwin, it works perfectly. I even created a package and submitted it to Cygwin-apps to be included in the main list but so far it hasn't been accepted. You can dowload it manually at: http://geda.seul.org/devel/cygwin/1.6.x/1.6.1/ Got it. Downloaded geda-gaf-1.6.1-1.tar.bz2 and setup.hint to ../cygwin/geda/geda-gaf/ Also put the setup.ini file at ../cygwin/geda/ Note: this file has a long cryptic name ending in .bin, which I tried to rename as setup.ini. This failed, so I left the filename as is. Create a directory of choice, copy the attached setup.ini in that, and put geda-gaf-1.6.1-1.tar.bz2 and setup.hint in a subdirectory named geda-gaf. Now execute cygwin setup and choose to install packets from the local directory where you put setup.ini. You should find gEDA as the only item in the list of packages and install it. The install finished without errors, and I see the geda hierarchy at /home/User/geda as expected. However, we still seem to have missing Cygwin packages! Looks like maybe gtk** is missing. $ gschem gschem:1036: Gtk-WARNING **: cannot open display: $ startx bash: startx: command not found There was no indication of missing dependencies from setup.exe. I'll try VirtualBox this weekend. -- Dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: GIT via HTTP
Hello, is there any way to use git via http? http://git.gpleda.org doesn't seem to have any .git file accessible. Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GIT via HTTP
It works! Thank you very much. Maybe it's worth mentioning in page: http://geda.seul.org/wiki/geda:scm and also in the official pages of each tool. For all the people behind a company proxy: add the htt_proxy environment variable before using git Alberto 2010/3/15 Peter TB Brett pe...@peter-b.co.uk: On Mon, 15 Mar 2010 08:59:41 +0100, Alberto Maccioni alberto.macci...@gmail.com wrote: Hello, is there any way to use git via http? http://git.gpleda.org doesn't seem to have any .git file accessible. git.gpleda.org doesn't publish an HTTP repository. However, you can access the repo.or.cz mirror using HTTP: http://repo.or.cz/r/geda-gaf.git Cheers, Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I submitted a patch for PCB about a month ago and it has been reviewed these days; is this too much delay? Probably not, but now I read that including tests would have made the reviewing job easier and possibly shorter. But I didn't even know of the existence of such tests: the point is that to the non-developers nothing is obvious; I had already posted the code on the mailing list, but it took me several months to discover the submit patch procedure. If only there was a quick tutorial on how to do these kind of operations I think the number of developers (or at least reviewers) would grow substantially. Do you lose time because people don't post links? Well, write it down so people will know how to correctly report a bug. Also some very basic document about the internal structure of PCB is needed; think about what it takes for a novice to locate the code that he needs to change; without advice he will probably desist, and that is a potential developer lost. No wonder there are only a handful of active developers. I know that writing documentation is not fun and takes time, but for a project of this complexity it is critical to attract more people, and I think in the long run it has even a better return than coding. Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
I called it a procedure, but it's the fact that there is a submit patch function; it's so obvious to any developer that it's not written anywhere. And I didn't notice it until very recently. 2010/3/10 Jared Casper jaredcas...@gmail.com: On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni alberto.macci...@gmail.com wrote: the code on the mailing list, but it took me several months to discover the submit patch procedure. What procedure did you find? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: rant: pcb print from command line
This: http://sourceforge.net/tracker/?group_id=73743atid=538813 which is also linked from: http://www.gpleda.org/developer.html 2010/3/10 Ethan Swint eswint.r...@verizon.net: Yes - but what is the function!?! (A,B,C; 1,2,3 please.) On 03/10/2010 03:07 PM, Alberto Maccioni wrote: I called it a procedure, but it's the fact that there is a submit patch function; it's so obvious to any developer that it's not written anywhere. And I didn't notice it until very recently. 2010/3/10 Jared Casperjaredcas...@gmail.com: On Wed, Mar 10, 2010 at 5:14 AM, Alberto Maccioni alberto.macci...@gmail.com wrote: the code on the mailing list, but it took me several months to discover the submit patch procedure. What procedure did you find? Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: right-mouse-click rotate
It's in the manual, I know, but to be precise it doesn't say that the gtk version looks at gpcb-menu instead of pcb-menu. I think the best way to solve this would be to create a gtk section in the same pcb-menu file. 2010/2/26 Dan McMahill d...@mcmahill.net: Alberto Maccioni wrote: There are 2 files in the src directory: pcb-menu.res and gpcb-menu.res; I think one is for gtk, the other for lesstif. But does this mean that you have to recompile to make changes to the key bindings? no. See the manual. Perhaps the key-binding has come from somewhere else?, Hmm, there are a few gpcb-menu.res files scattered on my hard disk. How does pcb decide which to pull in? see the manual. just to point out that they are customisable in gpcb-menu.res Is there some official info anywhere on the syntax? yes. see the manual :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Changing key bindings in PCB
If you're using gtk the file to change is gpcb-menu.res A little confusing and not documented, but it works. Probably the best thing to do would be to have separate sections in the same pcb-menu.res. 2010/2/21 Larry Battraw lbatt...@gmail.com: I see in a message here: http://www.mail-archive.com/geda-user@moria.seul.org/msg01523.html that it's supposedly possible to change the key bindings for gschem and pcb from the menus themselves by hovering over the menu option and pressing the keys that you want to associate with the action. I've changed the appropriate flag in gconf-editor (desktop/gnome/interface/can_change_accels) and it still doesn't work. Is there some other way to change the key bindings and add new ones that's not documented somewhere? I tried editing the ~/.pcb-menu.res as well with no changes either. Thanks- Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: right-mouse-click rotate
It seems that mouse actions are ignored in gtk mode. Also, trying some actions from command line, I found that the documentation is missing some of them in the gtk actions section; for example Export() and NetlistShow(). Is anyone working on implementing in gtk all of the lesstif action and vice-versa? 2010/2/18 DJ Delorie d...@delorie.com: There are 2 files in the src directory: pcb-menu.res and gpcb-menu.res; I think one is for gtk, the other for lesstif. But does this mean that you have to recompile to make changes to the key bindings? No, just put your modified copy in ~/.pcb/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: right-mouse-click rotate
There are 2 files in the src directory: pcb-menu.res and gpcb-menu.res; I think one is for gtk, the other for lesstif. But does this mean that you have to recompile to make changes to the key bindings? A.M. 2010/2/18 Kai-Martin Knaak k...@familieknaak.de: On Wed, 17 Feb 2010 17:52:50 +, Peter Clifton wrote: Perhaps the key-binding has come from somewhere else?, Hmm, there are a few gpcb-menu.res files scattered on my hard disk. How does pcb decide which to pull in? or you have a really really old checkout of my branch? Well, it is the version with the big black 3d knob on the left. Does this count as really, really old? Personally, I prefer middle click pan, right click rotate (I think), I'm not even sure I know what the stroke mode does. (Or perhaps the other way around). In gschem, when not placing components - middle click drag pans, but when placing components.. middle click rotates by 90. I don't really want to start a debate about what the best keybindings are... My two cents to this debate: The default bindings should include an immediate access to rotate when moving components or symbols around. The current default with pcb requires to change to the rotation mode. This is a bit awkward. just to point out that they are customisable in gpcb-menu.res Is there some official info anywhere on the syntax? ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB to G-CODE export GUI
The default resolution of 600 dpi is pretty good for pads too. Actually potrace just generates the best fit polygon, the offset is done as in ps and png with the bloat parameter. Unfortunately polygons are not bloated but they should not be part of the electrical connection anyways; and if they end up being a little smaller it doesn't matter. Alberto 2009/11/16 Peter Clifton pc...@cam.ac.uk: Doing it as a bitmap is basically how the OpenGL HID solves a similar problem - ie.. not drawing overlapping translucent geometry. For export, I guess that means you need a pretty high-resolution image to trace - otherwise you loose output precision. It wouldn't be that hard to get the contours using PCB's polygon routines, but that doesn't solve the need to offset your GCODE path inside our outside the outlines. Off the top of my head.. I don't know how to do that. I guess potrace takes care of it for you - in that it can only trace so close to your outline given the particular pen size of your router. Best wishes, Peter C. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB to G-CODE export GUI
Hello, I wrote a new exporter GUI to convert PCB drawings to G-CODE in order to mill pcbs directly; is anyone interested in testing it? Best regards, Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB adding exporter GUI
Sorry, I can't find any autogen.sh; I started with version 20081128. Best regards, Alberto 2009/10/29 Peter Clifton pc...@cam.ac.uk: On Thu, 2009-10-29 at 08:32 +0100, Alberto Maccioni wrote: Now I'm starting to understand: automake generates Makefile.in, then configure generates Makefile. No, I didn't run automake, but if I do I get the following: $ automake aclocal.m4:14: error: this file was generated for autoconf 2.61. You have another version of autoconf. If you want to use that, you should regenerate the build system entirely. Don't use automake directly. run the ./autogen.sh script in the top-level. That should in theory update the build-system to match the installed versions of autotools on your machine. Best wishes, Peter Clifton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB adding exporter GUI
I started again on a different system (previously I was working in cygwin, now ubuntu): I copied the png directory as gcode I renamed the files in there as gcode.* I substituted png with gcode in the sources I duplicated the sections in src/makefile.am as Peter said I run atogen.sh (downloaded from somewhere) this step didn't go well, as I read: Makefile.am:19: `:='-style assignments are not portable ./autogen.sh: 3: intltoolize: not found If I try with automake i get again: Makefile.am:19: `:='-style assignments are not portable Anyways, src/makefile.in is generated with references to the new gcode exporter, so I try configure but it ends with errors: ./configure: line 11936: syntax error near unexpected token `0.35.0' ./configure: line 11936: `IT_PROG_INTLTOOL(0.35.0)' Makefile is not regenerated so I can't compile (I had tried before all the modifications and it did work). Is this the right procedure? 2009/10/29 DJ Delorie d...@delorie.com: The list of hids to pull in ends up in hid/common/hidlist.h after you run configure/make. For each HID_DEF(foo) you need a hid_foo_init() in some hid. Your hid should also show up in pcb_LDADD in the Makefile, via HIDLIBS in configure (which builds it from HIDLIST). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB adding exporter GUI
I'm trying to write a modified version of png exporter gui, but I continue to get compilation errors; it seems that Make doesn't have a rule to build the new code (which is in a separate directory with a different name). I modified the .Po file in the .deps subdirectory but probably there's something to do to the configure script as well. Does anyone know how to do it? Thanks, Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB adding exporter GUI
I modified the Makefile.am but Make still complained, so I tried with
makefile.in and this time it went through compilation; now the linker
(I suppose) can't find hid_png_init reference in hidinit.o. This is
strange, as I didn't modify hidinit.c.
Maybe I should reconfigure with some magic parameter, but which one?
I'm making an exporter to gcode, so that I can mill my pcbs without
chemicals; I think it should be kept separate from the main png
exporter.
Thank you for your help,
Alberto
2009/10/28 Peter Clifton pc...@cam.ac.uk:
On Wed, 2009-10-28 at 09:02 +0100, Alberto Maccioni wrote:
I'm trying to write a modified version of png exporter gui, but I
continue to get compilation errors; it seems that Make doesn't have a
rule to build the new code (which is in a separate directory with a
different name).
I modified the .Po file in the .deps subdirectory but probably there's
something to do to the configure script as well.
Does anyone know how to do it?
Leave the .Po files alone.. they are auto-generated.. If you open up the
Makefile.am in src/, you will find the list of files to build:
For different exporters (which can be conditionally built), there are
separate sections, e.g.:
libpng_a_CPPFLAGS = -I./hid/png
LIBPNG_SRCS = \
dolists.h \
hid/hidint.h \
hid/png/png.c \
hid/png/png.h
libpng_a_SOURCES = ${LIBPNG_SRCS} hid/png/png_lists.h
hid/png/png_lists.h : ${LIBPNG_SRCS} Makefile
true $@
(for f in ${LIBPNG_SRCS} ; do cat $(srcdir)/$$f ; done) | grep
^REGISTER $...@.tmp
mv $...@.tmp $@
You'll probably want a copy of that block, but changing the name to your new
name.
Other blocks you might need to add to:
EXTRA_LIBRARIES = \
libgtk.a liblesstif.a libbatch.a \
liblpr.a libgerber.a libbom.a libpng.a libps.a libnelma.a libgts.a
BUILT_SOURCES = \
core_lists.h \
gpcb-menu.h \
hid/gtk/gtk_lists.h \
hid/lesstif/lesstif_lists.h \
hid/batch/batch_lists.h \
hid/png/png_lists.h \
hid/nelma/nelma_lists.h \
hid/ps/ps_lists.h \
parse_y.h \
pcb-menu.h \
res_parse.h \
hid/common/hidlist.h
EXTRA_DIST= \
check_icon.data \
default_font \
$(srcdir)/hid/batch/hid.conf \
$(srcdir)/hid/bom/hid.conf \
$(srcdir)/hid/gerber/hid.conf \
$(srcdir)/hid/gtk/gui-icons-misc.data \
$(srcdir)/hid/gtk/gui-icons-mode-buttons.data \
$(srcdir)/hid/gtk/hid.conf \
$(srcdir)/hid/gtk/pcb.rc \
$(srcdir)/hid/lesstif/hid.conf \
$(srcdir)/hid/lpr/hid.conf \
$(srcdir)/hid/png/hid.conf \
$(srcdir)/hid/nelma/hid.conf \
$(srcdir)/hid/ps/hid.conf \
gpcb-menu.res \
pcb-menu.res \
pcbtest.sh.in \
dbus.xml
DISTCLEANFILES= pcbtest.sh gpcb-menu.h pcb-menu.h \
hid/batch/batch_lists.h \
hid/common/hidlist.h \
hid/gtk/gtk_lists.h \
hid/lesstif/lesstif_lists.h \
hid/png/png_lists.h \
hid/nelma/nelma_lists.h \
hid/ps/ps_lists.h \
gts/gts_lists.h \
core_lists.h \
dbus-introspect.h
You will probably be able to get your code to compile even if you
haven't got _all_ of the above setup correctly. (They relate to creating
dist tarballs, and cleaning things up so make distcheck will pass).
Then.. open configure.ac in the top level directory. You'll find
configure tests for the PNG exporter. You might not need to modify
anything in confgure.ac, as it actually searches for HIDs to build:
for hid in `cd $srcdir/src/hid; echo *`; do
F=$srcdir/src/hid/$hid/hid.conf
if test -f $F
then
echo checking $F
. $F
case $type in
gui ) hid_guis=$hid_guis $hid ;;
printer ) hid_printers=$hid_printers $hid ;;
export ) hid_exporters=$hid_exporters $hid ;;
always ) hid_always=$hid_always $hid ;;
esac
fi
done
I hope that points you in the right direction. Good luck.
I should have asked at the beginning of this email.. what is it that
your new PNG exporter does differently to the existing .png exporter?
Would it be possible to just add features to the existing exporter?
Best wishes,
Peter Clifton
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: CNC Milling
Try this one: http://cynbe.us/~cynbe/gcoder/ I had to modify some functions to make it work, and it doesn't support poly fills, but I think it's not an issue if you mill a pcb. 2009/6/20 Bill Gatliff b...@billgatliff.com: Dave N6NZ wrote: Some of us local roboteers have been considering this unit but no one has plunked down the money yet: http://www.probotix.com/FireBall_v90_cnc_router_kit/ Heh, their office is like five minutes from mine! I've been meaning to swing by, haven't had time. Of course, there's little point in mentioning the above. :) But I thought I would anyway, in case my proximity to them would be of use to anyone. I don't dare invest in such a device because of the vast quantities of productive time it would almost certainly suck out of me. :) b.g. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: building gEDA for cygwin
Has anyone been able to compile gEDA v1.4.3 with cygwin? I can only build 1.4.2, but not 1.4.1 What about v1.5.x? It needs GTK 2.8 but unfortynately cygwin only has 2.6 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb-20080202
Actually it does have some bugs: at startup it tries to execute Listlibrarycontents.sh (and obviously windows complains) it cannot determine the home directory all of the GUI elements (buttons, strings etc.) are somewhat big compared to other applications. printing doesn't work (of course) But it's very impressive, and I think it should be publicized more on the project homepage: most of the potential users get scared if they cannot find a windows version. 2008/2/2, Levente [EMAIL PROTECTED]: On Fri, 01 Feb 2008 21:48:26 -0500 Dan McMahill [EMAIL PROTECTED] wrote: I've placed a new pcb snapshot up on sourceforge. In addition to the usual source release, there is an installer for windows. Be warned that the windows build has received very little testing. The windows build works for me. Many thank you for this. I can now teach my father and my girlfriend how to draw box contours. Pizza for the developers! Cheers, -- Levente http://web.interware.hu/lekovacs ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA/gaf stable version 1.4.0-20080127 released!
This is for sure a very stupid question, but how do I change language in gschem? Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Cygwin releases
Hi, I mostly use gEDA and PCB under cygwin, but packaged versions are still from 2006. I was successful in compiling the latest builds, but probably it would be a good idea to update the cygwin release directly; does anyone know the procedure? If nobody is available I volunteer to do it myself. Alberto ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
