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
Markus, Thanks for the reply. I tried the 'gEDA - Inkscape - pstoedit - dxf' route and was not happy with the round-off errors that Inkscape introduced into the image. In 'pcb', I tried a dpi of 2000 in the g-code exporter and the resulting pcb image is beautiful! FOSS pcb milling has arrived! 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. I have started trying to find the specifications for the dxf file format on the web to study. Here are my initial thoughts on adding a dxf exporter that builds on the pcb g-code exporter: You could have a process that first produces g-code with a mill bit of 0.000 diameter and 0.000 depth of cut. Take out all of the G0-rapid positioning code and the G1 code with Z information. Then, take the g-code line plots and do a (fairly simple, I think) conversion of all the line plots to dxf format. Save the file. Now you have a dxf with all the lines at 0 on the Z axis. What do you think? Other thoughts on the g-code exporter (which I am sure you have thought about, and are in the works); 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. I think it is important to at least organize the drilling operations by drill size - generate g-code for one drill size, then the next, ext. Also, it would be helpful if the exporter generated some notes in each g-code drilling block specifying which drill size is being drilled. The cnc machinist can find those spots easily and add the tool change codes as needed, by hand. If tool change options are added to the g-code exporter, you would probably want to read and write to a tool table file, so all of the tool numbers match the tool table for a particular machine. You could possibly code it to directly read EMC2's tool table file. (example location: ~/emc2/configs/sim/sim.tbl). The emc2 users manual explains the format. Thanks, Dave On 11/11/2010 04:28 AM, Markus Hitter wrote: 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 ___ 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
On Nov 1, 2010, at 2:01 PM, Vanessa Ezekowitz wrote: On Mon, 1 Nov 2010 10:05:17 -0600 John Doty j...@noqsi.com wrote: What you want doesn't matter. What the *job* needs is the thing that matters. Suppose the user can't get the job done *at all* without whatever feature is being proposed? That is the crux of my argument here. The key to problem-solving ... is to identify the right primitive operations and to put them at the right place. ... Merely adding features does not make it easier for users to do things — it just makes the manual thicker. -- Brian Kernighan and Rob Pike So, if the job can't be done, asking for a feature is the wrong approach. The first step is to figure out what primitive operation is missing from the toolkit. Sometimes when you ask that question, the answer is nothing, because merely asking that question focuses your attention on the tools, and you find a way. Other times, the necessary primitive operation is best implemented with a separate tool. Piling everything into a single tool as features leads to inflexibility and low productivity. It might be okay for a tool with limited horizons, but it is important to preserve toolkits like gEDA that serve wide horizons with minimal complexity. This is not to say that I am not intelligent enough to use a simulator outside of a GUI environment - I defy anyone to make that argument. Rather, it means I am not necessarily *skilled* enough to use one. The thing is, I shouldn't need to learn any special skills just to simulate a simple circuit. Indeed. But in fact, I bet if you did a time and motion study you'd find that typing commands is much faster than point and click. Point and click is a seductive time waster *except* for inherently graphical parts of the job. For some things, the command line is a little faster, but for some stuff, it doesn't make any sense. It also depends on how the interface in question is implemented and whether you are a particularly fast and accurate typist. I, for example, can barely manage 40 words a minute. I'm slower than that. But unlike button pushes, commands don't have to be retyped much. Any time I find myself doing the same thing repeatedly, I can make an alias, script, or makefile rule. And these approaches can be combined to automate very complex operations triggered by simple commands. But GUI operations generally depend on having a human guide them (by selecting something, filling out a form, etc.), so they are much less friendly to automation. In the case of the little script I mentioned, to run it I must open a terminal via a hotkey I already have set up for that purpose, hit ctrl-r and a few keys to find the command, hit Enter, and then supply my password. All told, it takes about 15 seconds and about 20 keypresses. Why do you tolerate such barriers? For one gEDA project, I recently had a simple change request. I hadn't worked on the project in months, but a quick grep for the refdes found the page, five minutes with gschem made the change (GUI *in its place* is great), then typing make rebuilt 50 pages of documentation, a 600 part BOM, and the netlist in the customer's requested format. The project's structure is specific to the customer's requirements, but I don't have to remember those details: the makefile remembers them for me. That's ease and productivity. No need to remember some complicated path through incomprehensible menus. On a bad day, my own inability to type accurately can inflate those figures significantly. Hell, just getting past the login prompt can take that long on a particularly bad day. On the other hand, I could just set up sudo to allow that script to run without my password, in which case a single click of the mouse would start the backup. It would undoubtedly save time, and save a lot of typing, but it's also insecure, as far as I'm concerned. Any other command line function I do is generally slowed down by the same problems, as are things such as this email. All you're saying is that you don't use the command line functions effectively. That's OK: work however you want. But then please don't ask that gEDA, an unusually effective toolkit for a different approach than yours, be changed to reflect a less flexible and scalable approach. You want a different tool. Your implication here is that these tools are and should be reserved only for experts, Absolutely not. However, there should exist tools that serve needs of experts. There are lots of tools out there that sacrifice productivity and flexibility for user comfort. Fair enough, but it doesn't have to be that way. The stupidity of some programmers' design decisions does not imply that *all* programmers make stupid decisions. The existence of a feature does not imply the requirement to *use* that feature, or the requirement to discard whatever feature(s) it is capable of replacing. Part
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: PCB+GL Testers (please test)
On 11.11.2010 00:13, Peter Clifton wrote:
On Wed, 2010-11-10 at 21:34 +0100, Frank Bergmann wrote:
And on my Intel system I have disturbances comming like rays from the
middle of the viewport/drawing area, see:
http://www.frajasalo.de/frank/projekt/pcb/pcb.local_customisation_no_pours-20101110_intel.ogv
Interesting.. I have no idea what is going on there. It could well be a
driver bug. Please let me know what mesa and kernel version you're
using.
$ aptitude show libgl1-mesa-dri | grep Version
Version: 7.7.1-1ubuntu3
$ cat /proc/version
Linux version 2.6.32-25-generic (bui...@palmer) (gcc version 4.4.3
(Ubuntu 4.4.3-4ubuntu5) ) #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010
I THINK I know what it might be, but I'm not certain. Please let me
know what graphics chipset you have. (Again, glxinfo output would help).
$ lspci -s $(lspci | grep VGA | awk '{print $1;}') -vvv -nn
00:02.0 VGA compatible controller [0300]: Intel Corporation Core
Processor Integrated Graphics Controller [8086:0046] (rev 12)
Subsystem: Toshiba America Info Systems Device [1179:0002]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 34
Region 0: Memory at d000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 2050 [size=8]
Capabilities: access denied
Kernel driver in use: i915
Kernel modules: i915
glxinfo output in appendix.
I just had a fix committed upstream to mesa master which gets around a
corruption when uploading data to the card. (An alignment issue).
Let me know what mesa version, and if the bug still applies, I'll see if
I can knock up up a patch. Are you on a Debian / Ubuntu system? (If so,
which version?)
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.1 LTS
Release:10.04
Codename: lucid
Does it go away with certain layers disabled?
Yes - with all disabled :)
Serious, with power board and only (!) silk enabled on zoom max (full
board in window) I have no disturbance. But if I zoom in it appear.
pins/pads, vias, far side and solder mask seems to be resist.
What is the minimum board which exhibits the problem? Does it relate to
certain objects on the board, or is it general?
I'll try it at the weekend.
Frank.
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read,
GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) IGDNG_M GEM 20091221 2009Q4
x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.7.1
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_EXT_compiled_vertex_array, GL_EXT_texture_env_add, GL_ARB_copy_buffer,
GL_ARB_depth_texture, GL_ARB_depth_clamp, GL_ARB_draw_buffers,
GL_ARB_draw_elements_base_vertex, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader,
GL_ARB_framebuffer_object, GL_ARB_half_float_pixel,
GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex,
GL_ARB_seamless_cube_map, GL_ARB_shader_objects,
GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow,
GL_ARB_sync, GL_ARB_texture_border_clamp,
Re: gEDA-user: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Alberto, Thanks for the comments. On 11/11/2010 04:24 PM, Alberto Maccioni wrote: 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. For me, HeeksCAD/CNC crashes on everything but the most simple gerber artwork files. They have a ways to go on the conversion. Maybe Dan Heeks could take some code from the (sweet!) pcb g-code exporter. With a dxf file, in a CAM program, you can program your fine line cutting with a tiny v bit, then program apocket 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. I would like to remove floating copper for RF and static electricity reasons. The 'pcb' program thinks that floating copper is enough of an issue to have code to detect and remove it. I have seen blogs where guys take tweezers and rip the floating copper off the boards they have isolation milled. I would like to have the cnc machine do it. I agree that it will destroy lots of bits, though. It is a trade-off between disposable etching chemicals and disposable bits. A company called LPKF make very nice (and expensive I am sure) pcb mills, bundled with software that pockets out all of the unwanted copper: http://www.lpkfusa.com/protomat/s-series.htm http://www.lpkfusa.com/datasheets/prototyping/rp_brochure.pdf They are beautiful machines that make beautiful pcb's. I am going to make a very rigid, accurate pcb milling machine out of epoxy-granite. Here is my build blog (with pics) on a cnc lathe that is part E-G: http://www.cnczone.com/forums/vertical_mill_lathe_project_log/42308-diy_benchtop_lathe_project-2.html 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. I think the 2000 dpi output is great! You coding wizards can do in a minute what would take me a month, but I would like to try writing a g-code to dxf conversion program in C. Thanks, Stephen Ecob for the jump start! Stephen, Some of the function calls seem to be missing from your dxf.c program, like DxfStart(); and DxfFinish();. Do you feel like posting those, also? The drill xxx.gcode.drill.cnc file goes through the board drilling all of the holes without differentiating thedifferent drill sizes (found in the xxx.fab.gbr file). And, there are no tool change g-codes for changingbetween 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. I will organize my thoughts on how tool changing might be implemented in 'pcb' g-code export. Thanks, Dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Testers (please test)
On 11.11.2010 00:58, Peter Clifton wrote: On Wed, 2010-11-10 at 23:13 +, Peter Clifton wrote: On my AMD Mobility Radeon HD3450 (driver: radeonhd) system (debian, stable but old!) and your local_customisation_no_pours branch (without the recent patches) the line ends look wrong http://www.frajasalo.de/frank/projekt/pcb/pcb.local_customisation_no_pours-20101110_amd4core.png The pixel shader which draws the rounded line ends (and vias / holes etc..) isn't working. Your hardware might not support that GL extension, I misread.. the card isn't that old.. but Debian stable is ;) Yes and therefore its a production system so unfortunately I can not play with drivers and/or mesa. I still want to see the glxinfo output. I'm not quite sure how new a mesa you need to get R600 series cards working properly. It might need gallium drivers. glxinfo comes here, but know, it dies with segmentation fault - so I suppose all my current available hardware are buggy in context with open-gl: $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 (2.1 Mesa 7.0.4) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24
Re: gEDA-user: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
On Fri, Nov 12, 2010 at 9:31 AM, d...@umich.edu wrote: I think the 2000 dpi output is great! You coding wizards can do in a minute what would take me a month, but I would like to try writing a g-code to dxf conversion program in C. Thanks, Stephen Ecob for the jump start! Stephen, Some of the function calls seem to be missing from your dxf.c program, like DxfStart(); and DxfFinish();. Do you feel like posting those, also? Oh yes, you'll need those! I'll send them to you off list. Stephen ___ 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: Comments on pcb's g-code exporter HeeksCAD/HeeksCNC FOSS program for pcb milling
Markus, That is good news. Could someone tell be how to add these files to the current pcb-20100929 source download and recompile? Otherwise, I will have to wait on the next source snapshot, which is fine. I would love to see the latest patches, though. I do not know how your '0023-board outline milling' patch works, but I would like to share a thought: On page 1 of the LPKF brochure (http://www.lpkfusa.com/datasheets/prototyping/rp_brochure.pdf ), it shows a screenshot of their pcb artwork software. The thick grey traces are used to route the border of the part. I noticed the breaks in the trace in order to create attachment tabs, which you can see in the picture to the right of the mill making some boards. You could have a field in the g-code export window where you can choose a layer from pcb, which contains the traces for the border routing operation. The user can customize with a simple series of thick (or thin) traces exactly what shape they want the pcb border to be, i.e. with or without tabs, what diameter endmill to use, etc. Thanks, Dave On 11/11/2010 07:14 PM, Markus Hitter wrote: 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 ___ 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
At 05:31 PM 11/11/2010, you wrote: Alberto, Thanks for the comments. On 11/11/2010 04:24 PM, Alberto Maccioni wrote: With a dxf file, in a CAM program, you can program your fine line cutting with a tiny v bit, then program apocket 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. I would like to remove floating copper for RF and static electricity reasons. The 'pcb' program thinks that floating copper is enough of an issue to have code to detect and remove it. I have seen blogs where guys take tweezers and rip the floating copper off the boards they have isolation milled. I would like to have the cnc machine do it. I agree that it will destroy lots of bits, though. It is a trade-off between disposable etching chemicals and disposable bits. My understanding is that the bits tend to break just at the tip of the conical bit. The broken bits can still be used for removing the floating copper perhaps. This may not apply to your machine as this was a very old machine I saw being used. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: NGspice and GNUcap Non-Linerar Dependent Sources
On Nov 10, 2010, at 4:09 PM, c...@eugeneweb.com wrote: Hi Gang, I've been playing with ngspice and gnucap and have gotten good results with the Non-Linerar Dependent Sources eg ASRC B devices in ngspice. I mostly use those with VC-Switches to make full wave bridges, SCRs, Triacs, etc... Why not use the semiconductor models for semiconductor devices? Make full wave bridges from diodes, SCR's from cross-coupled transistors, etc. A great deal of effort has gone into accurately modeling semiconductor physics in these simulators: why not exploit it? A Google search for spice scr model turns up quite a few subcircuit models of this sort. If you can't find exactly the model you need, it's probably better to tweak one of these than make one up. Though I see that they are not supported in gnucap. I guess the alternative is to use POLYs. I've looked around and except for a short description in the gnucap manual I haven't found a comprehensive howto on how to use them. A common way to go from data sheets to model parameters is to model test circuits and then tweak the parameters until there's a decent resemblance. I sapose you would want a curve fitting program to help you generate the coeficents like grace, or simfit, or you could use the fit function in gnucap. However this isn't supported in ngspice, so you couldn't use that model in both. You can configure ngspice to support POLY. See http://www.brorson.com/gEDA/SPICE/x496.html. Are POLYs really that much better at solving convergence problems to be worth the extra trouble? Is there a good into or howto on how to use them? There is a vast literature on the subject of constructing polynomial approximations to functions. Google for polynomial approximation. You'll never be able to digest it all. Are negitive coeficents even legal? Sure, why not? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda-user Digest, Vol 54, Issue 32
On Nov 10, 2010, at 4:09 PM, c...@eugeneweb.com wrote: Hi Gang, I've been playing with ngspice and gnucap and have gotten good results with the Non-Linerar Dependent Sources eg ASRC B devices in ngspice. I mostly use those with VC-Switches to make full wave bridges, SCRs, Triacs, etc... Why not use the semiconductor models for semiconductor devices? Make full wave bridges from diodes, SCR's from cross-coupled transistors, etc. A great deal of effort has gone into accurately modeling semiconductor physics in these simulators: why not exploit it? A Google search for spice scr model turns up quite a few subcircuit models of this sort. If you can't find exactly the model you need, it's probably better to tweak one of these than make one up. I do try to use models that I find out there when I can, though some are overkill for anything more then just a few devices, and can really bog down the simulation. At other times I've had problems with the diodes in a full wave bridge breaking down not at the peak reverse voltage but in the middle range somewhere. I wasn't sure if this was a bug or some esoteric behavior that my circuit was tickleing. Either way I wanted to get on with designing my circuit so I switched to a voltage controled switch model. I relize that it's not advisable to brut force a simulation to what you think it should be... but I had to move on. Maybe I'll go back later to see if I can figure out why it behaves that way. Though I see that they are not supported in gnucap. I guess the alternative is to use POLYs. I've looked around and except for a short description in the gnucap manual I haven't found a comprehensive howto on how to use them. A common way to go from data sheets to model parameters is to model test circuits and then tweak the parameters until there's a decent resemblance. Yes and I've done this too. I sapose you would want a curve fitting program to help you generate the coeficents like grace, or simfit, or you could use the fit function in gnucap. However this isn't supported in ngspice, so you couldn't use that model in both. You can configure ngspice to support POLY. See http://www.brorson.com/gEDA/SPICE/x496.html. Yes but there isn't much in the way of examples on how to use them. Are POLYs really that much better at solving convergence problems to be worth the extra trouble? Is there a good into or howto on how to use them? There is a vast literature on the subject of constructing polynomial approximations to functions. Google for polynomial approximation. You'll never be able to digest it all. True, but that dosn't help with for exmaple how to make models for multiple variables. Apparently you can say something like POLY(2) or POLY(3) but then how do you list the values? In Gnucap it seems you list the coeficent of X^0 (1) but a lot of models start with X^1. It would be helpfull to have a howto that described the best practices for all of this with some example problems. Also some discussion on when to use them vs arbituray expressions as in B sources. Naively one might assume that becuase they should be well behaived functions that each point would have a usable first or even second derivative, and this would help convergance. Though here is a quote from the NGspice manual Chapt 12.2.7 BSIM1 model (level 4): A known problem of this model is the negative output conductance and the convergence problems, both related to poor behavior of the polynomial equations. So it's not even obvious that they will perform better. Are they there just to support legacy models, or are there times when they are the best tool we have? Are negitive coeficents even legal? Sure, why not? Sorry, I thought I read somewhere that they weren't, can't find it now. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com Thanks, Clif ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
