Back
[01:57:01] <jepler> jmkasunich: I'm around for a little bit if you want to ask now
[01:59:52] <jepler> http://emergent.unpy.net/files/sandbox/demo_comp3.png is the best image I have to show what the code presently does
[02:01:02] <jepler> each original primitve (arc and lines are supported primitives) is offset by a small amount. if the offset primitives intersect, they are trimmed to the intersection point. if not, they are joined with an arc that is the same radius as the offset.
[02:01:28] <jepler> with a big offset, this creates self-crossing paths, which you see in the left paths with large offset.
[02:01:57] <jepler> the next embellishment to the algorithm is to "snip off" the self-crossings, leaving the offset paths shown on the right
[02:02:29] <jepler> the code also supports closed paths (not shown)
[02:06:19] <jmkasunich> I'm back
[02:06:31] <jepler> hi
[02:06:43] <jmkasunich> the reason I'm asking is I have a use for it
[02:06:49] <jepler> ah
[02:07:05] <jmkasunich> is it semi-usable? what are the inputs and outputs?
[02:07:30] <jepler> the output is gcode. the input is hard-coded C++
[02:07:58] <jmkasunich> the latter makes it a bit harder to use, but not fatally
[02:08:24] <jmkasunich> I assume the process is "edit source, make, have fun with output" ?
[02:08:59] <jepler> here's the program thag generates the gcode in the screenshot:
http://git.unpy.net/view?p=offs.git;a=blob;f=demo_comp.cc;h=f9c80be955a0245bbc3f95022a3fe4433ca08d14;hb=404a2b1bbe7bd42e9569d34d9c52c05bbcfe0f32
[02:09:42] <jepler> yep
[02:10:34] <jepler> if you need me to I can easily make you a tarball
[02:10:44] <jmkasunich> that would be appreciated
[02:10:55] <jmkasunich> I'm trying to match up the code with the png
[02:11:23] <jepler> I wouldn't be surprised if it doesn't match that png
[02:11:31] <jepler> the code's gone through several revisions
[02:11:58] <jmkasunich> the base path is in void path(), right
[02:12:18] <jepler> right
[02:12:31] <jepler> it's called several times with different offsets, including one that just copies the lines and arcs to the output
[02:12:42] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/offs-0.1.tar.gz
[02:12:43] <jmkasunich> thats the dummy one...
[02:13:07] <jmkasunich> thanks
[02:13:32] <jepler> I bet this one is more like the one that generated the screenshot:
http://git.unpy.net/view?p=offs.git;a=blob;f=demo_comp.cc;h=eeda833eb72d4b78b1885fff23d547f16ac7809a;hb=154505a5b4640bae127f74a7c5f68fec202617e3
[02:14:13] <jepler> if you just run make, it builds and executes demo_comp to create out/demo_comp.ngc, then calls axis-reomte to load it in a running emc / axis session
[02:15:07] <jepler> look in 2d.hh to see how lines and arcs may be specified -- in particular there are a bunch of ways for arcs
[02:15:07] <jmkasunich> if I was better at C++ I might try to hack it to accept g-code input
[02:15:43] <jmkasunich> I have a path that is the outline of a pocket - step 1 is to make a new path offset from that by the tool radius
[02:16:14] <jmkasunich> step 2...n is to make additional paths offset by small steps from that, but with different Z values
[02:16:32] <jmkasunich> I assume there will be hand-hacking of the resulting g-code, for example to set the Z values
[02:16:46] <jepler> you can just print the additional moves you need in the source code
[02:17:09] <jmkasunich> oh, I think I see
[02:17:14] <jepler> after you get the path into the C++ "format" the rest should be easy (and assuming you don't hit bugs in my code)
[02:17:48] <jepler> for(...) { printf("g1z-%f", ...); comp c(...); path(c); }
[02:17:57] <jmkasunich> the 'c' that is passed to path is a 'comp' object?
[02:18:00] <jepler> right
[02:18:28] <jepler> 78 for(int i=-9; i<=9; i++) {
[02:18:29] <jepler> 79 double o = i/8.;
[02:18:29] <jepler> 80 comp c(o, 1);
[02:18:29] <jepler> 81 printf("G0 X0 Y0 Z0\n");
[02:18:33] <jepler> 82 path(c); }
[02:18:34] <jmkasunich> ok, I'm starting to catch on
[02:18:37] <jmkasunich> * jmkasunich is slow
[02:18:56] <jepler> so this does a bunch of different offets of the same path by different values, and always emitting a G0 X0 Y0 Z0 before each path
[02:19:00] <jmkasunich> I can drop the stuff before the loop
[02:19:20] <jepler> (offsets from -9/8 to 9/8 inches)
[02:19:27] <jmkasunich> and my loop will go from tool-radius up in increments of whatever I want my step to be
[02:19:46] <jepler> I'd write it as an integer loop and calculate the radius, but yeah
[02:19:53] <jmkasunich> right, I would too
[02:20:05] <jmkasunich> that way radius and Z are both functs of n
[02:20:21] <jmkasunich> does this version work with closed paths? I saw a comment about that being broken
[02:20:23] <jepler> oh and I should note the second "argument" to the comp constructor is 1 or true if you want to eliminate loops, and 0, false, or unspecified if you don't want to eliminate loops (you probably do)
[02:20:59] <jmkasunich> * jmkasunich takes notes
[02:21:08] <jepler> hm you're right -- you probably want the version before that change. I can tar that up for you too..
[02:21:21] <jmkasunich> I'm going to try to go to bed at a reasonalbe hour for a change, I'll actually be trying this tomorrow
[02:22:33] <jmkasunich> I'll be sure to screenshot the results (and I should have photos of the parts too)
[02:22:36] <jepler> 3
http://emergent.unpy.net/index.cgi-files/sandbox/offs-0.0.5.tar.gz
[02:22:44] <jepler> I think that is the one before I broke the closed paths
[02:22:57] <jepler> I can't tell from here, no emc on this machine
[02:25:20] <jepler> if you don't have any more questions right now, I'll call it a night too
[02:26:03] <jmkasunich> http://jmkasunich.com/pics/block-end-faced-2007.jpg
[02:26:10] <jmkasunich> that is the part I'm working on
[02:26:25] <jmkasunich> the rough-cast opening needs milled out to match the opening in the engine block
[02:26:53] <jmkasunich> and then tapered down to eventually blend into the cast passage
[02:27:57] <jmkasunich> should be an interesting program
[02:36:12] <jepler> neat and good luck
[02:36:23] <jmkasunich> thanks, and good night ;-)
[04:59:15] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c:
[04:59:15] <CIA-30> EMC: Add a layer of indirection in front of the info needed to do io with
[04:59:15] <CIA-30> EMC: the boards. This just reorganizes struct board_info, there are no
[04:59:15] <CIA-30> EMC: behavioral changes at all.
[05:02:34] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/ (bitfile.c bitfile.h): When reading in a bitfile, record the filename in the struct bitfile.
[05:05:47] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: better awareness of different kinds of io for different kinds of boards
[05:07:35] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: Start adding support for the 7i43. Doesnt actually talk to the board yet.
[05:09:28] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: This begins to add support for the other variant of the 7i43.
[05:10:18] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: the old command-line handling only deals with pci boards
[18:57:17] <alex_joni> * alex_joni yawns
[18:57:19] <alex_joni> hi all
[18:57:57] <skunkworks_> Hi alex
[18:59:18] <skunkworks_> didn't our president visit your country last week?
[19:00:27] <cradek> too bad he didn't stay there
[19:00:29] <alex_joni> he did. why?
[19:00:31] <cradek> oh did I say that aloud?
[19:00:36] <cradek> oops
[19:00:37] <alex_joni> cradek: no thanks, you can have him back
[19:00:38] <skunkworks_> heh
[19:00:38] <cradek> :-)
[19:00:45] <alex_joni> we have our own
[19:00:47] <cradek> surely someone would want him
[19:01:06] <alex_joni> send him to some strange country
[19:01:08] <alex_joni> like texas
[19:01:12] <cradek> haha
[19:01:15] <alex_joni> :-P
[19:01:23] <alex_joni> did I say that aloud? ;)
[19:01:31] <cradek> perhaps
[19:01:32] <alex_joni> well.. gotta pack
[19:01:34] <cradek> it's contagious
[19:01:40] <alex_joni> yeah, seems so
[19:01:51] <alex_joni> flying to germany again tomorrow
[19:01:58] <cradek> safe trip
[19:02:03] <alex_joni> * alex_joni starts to make a habit out of these
[19:02:21] <cradek> are you coming for cnc workshop this year?
[19:02:59] <alex_joni> doesn't look like it :(
[19:03:04] <cradek> darnit
[19:03:14] <alex_joni> I have about 3 different things scheduled for that week
[19:03:39] <alex_joni> one of them is vacation
[19:04:01] <alex_joni> the other one is an exhibition I really need to attend
[19:04:16] <alex_joni> gotta bring a robot, etc
[19:04:39] <alex_joni> are the dates for 2009 final?
[19:05:06] <cradek> seems like
[19:05:15] <cradek> you'd have to ask roland to be sure though
[19:05:21] <cradek> 2009 is a long time from now :-)
[19:05:40] <alex_joni> yeah, I know.. but if I schedule it from now it's gotta stand :)
[19:06:31] <alex_joni> maybe you can confirm it with roland during this years workshop
[19:07:33] <SWPadnos> there are 2009 dates on the website
[19:07:42] <SWPadnos> along with the 2008 dates, and not much else ;)
[19:08:24] <alex_joni> SWPadnos: I saw that
[19:08:26] <cradek> I bet he would not put them there unless he was pretty sure
[19:08:27] <SWPadnos> I wonder when he
[19:08:42] <SWPadnos> he'll post all the other info, like hotels and classes and stuff
[19:13:08] <awallin> has there been any CAM activity at cnc-workshop?
[19:13:18] <SWPadnos> some
[19:13:29] <SWPadnos> OneCNC had some people there last year
[19:13:43] <SWPadnos> I think some people were showing off the Mach "LazyCAM" plugins
[19:14:56] <awallin> ok. any people interested in open-source CAM?
[19:16:03] <skunkworks_> tons.
[19:16:18] <awallin> :)
[19:16:34] <skunkworks_> that is like saying - anyone want free energy?
[19:16:39] <SWPadnos> sure
[19:17:40] <SWPadnos> what most people want is the ability to make parts. they aren't usually concerned about who writes the CAM, or how much it costs (as long as it's <$150 ;) )
[19:18:27] <SWPadnos> the major Windows-based control packages (Mach, DeskCNC) have some CAM built in - you can load DXF, STL and image files and it does the CAM internally
[19:18:48] <SWPadnos> I don't think you can export the resulting G-code with DeskCNC, dunno about Mach
[19:20:09] <SWPadnos> the CAM portion of DeskCNC is available as a standalone app, for maybe $100. it deals with STL reasonably well (it's called STLworks)
[19:20:49] <SWPadnos> so I guess what that means is that many people could care less about open source CAM, but the percentage of people who do care is much higher in the EMC2 community ;)
[19:22:12] <awallin> right. I haven't really found a good programming environment for trying out things yet...
[19:22:30] <SWPadnos> like a development IDE?
[19:22:38] <SWPadnos> or a language / toolset?
[19:22:56] <SWPadnos> or just algorithms? ...
[19:22:59] <awallin> programming language/toolset and 3D framework etc.
[19:23:08] <SWPadnos> ah, ok
[19:23:23] <awallin> for the algorithms almost anything will do but it's not much fun if you can't see what is happening in 3D
[19:24:10] <awallin> I'm not very eager to learn C++, so either C# or Python like languages would be nice
[19:24:18] <SWPadnos> no C# please
[19:24:25] <SWPadnos> pretty please
[19:24:28] <awallin> The C# support on linux is quite weak, so that leaves out a lot of the MS-haters...
[19:26:11] <SWPadnos> I think C# knowledge is pretty weak outside MSDN members
[19:29:14] <awallin> I guess something based on Coin3D would be the sensible way to go (www.coin3d.org)
[19:29:37] <alex_joni> good night all
[19:30:18] <SWPadnos> seee you Alex
[19:31:19] <awallin> anyone know how much of a pain working with C++ is? I mean things like lists and sorting etc. which are very easy in Python
[19:31:33] <alex_joni> awallin: more pain
[19:31:34] <SWPadnos> I'm sure it's harder in C++
[19:31:37] <cradek> language war!
[19:31:49] <alex_joni> but you have some gained speed
[19:31:56] <SWPadnos> but there are STL containers that are specifically meant for lists, queues, maps, arrays, etc.
[19:32:04] <alex_joni> cradek: wanna change it to editor+language war?
[19:32:16] <SWPadnos> pico + fortran FTW!
[19:32:21] <SWPadnos> (ehatever FTW means)
[19:32:28] <SWPadnos> s/e/w/
[19:32:46] <alex_joni> Homepage des ftw. Forschungszentrum Telekommunikation Wien.
[19:32:59] <SWPadnos> oh, excellent :)
[19:33:30] <cradek> I doubt any of this is news to any of you guys but:
http://ask.metafilter.com/64517/Programming-Desktop-GUIs-Using-OpenSource
[19:33:58] <cradek> the funny part is the love/hate for tcl
[19:35:20] <awallin> qt seems popular with FOSS developers?
[19:35:43] <cradek> qt and gtk are the big ones
[19:37:25] <cradek> all things being equal, I'd prefer gtk to qt, since ubuntu and emc use it already
[19:37:51] <cradek> prefer python to ruby, same reason
[19:39:05] <awallin> any 3D toolkits for gtk? opengl bindings?
[19:39:19] <awallin> is there a way to run a gtk app on Windows?
[19:39:56] <SWPadnos> I think 3D will be a problem for cross-platform stuff
[19:40:05] <SWPadnos> I'm not sure there is support in Vista for OpenGL
[19:40:21] <cradek> seriously?
[19:40:31] <SWPadnos> If that's true (I think I read it somewhere), then driver writers won't bother with openGL
[19:40:32] <cradek> you surely must be wrong
[19:40:39] <SWPadnos> I hope so, but I'm not sur
[19:40:45] <SWPadnos> SirectX is so much better, remember?
[19:40:48] <SWPadnos> DirectX
[19:41:09] <awallin> I think they have a layer that converts Opengl calls to directx
[19:41:12] <cradek> the OpenGL ARB wishes to reinforce the positive synergy between OpenGL graphics and Windows Vista
[19:41:34] <cradek> the first idiot-speak website I found says it works (if I successfully translated this crap)
[19:41:38] <SWPadnos> ok, I could be totally wrong
[19:41:52] <alex_joni> see you guys
[19:41:56] <SWPadnos> maybe it was a specific driver I was thinking of (or I'm just plain wrong)
[19:42:51] <cradek> Microsoft has dramatically changed the user experience with the Windows Aero compositing desktop and introduced a completely new display driver architecture.
[19:43:00] <SWPadnos> of course :)
[19:43:15] <Roguish> check the date:
http://www.opengl.org/pipeline/article/vol003_9/
[19:43:23] <SWPadnos> it appears that performance is slightly worse in Vista, or much worse if you use Aero (if that's "DWM")
[19:43:24] <cradek> so they probably "dramatically and completely" screwed it up and then flogged it into working again
[19:43:44] <SWPadnos> Roguish, yep, same article I'm reading :)
[19:43:52] <cradek> (fwiw, sounds like compiz)
[19:44:28] <cradek> anyway, opengl is still surely the thing to use for 3d. no doubt at all.
[19:44:59] <SWPadnos> ah - here's maybe more of the scoop:
http://www.neowin.net/index.php?act=view&id=34586
[19:45:09] <cradek> hmm, performance on vista "is extremely competitive with" XP
[19:45:17] <cradek> wonder what that means in english
[19:45:30] <SWPadnos> OGL was originally supposed to be supported by conversion to D3D, btu I guess they backpedaled on that one
[19:45:53] <SWPadnos> and they don't include the OGL drivers on the Vista disc, you have to download them yourself
[19:49:03] <awallin> gotta go, gnight.
[21:59:58] <jepler> jmkasunich: I'm back home, should be paying attention on and off this evening to help you with your tool offsetting task
