Back
[02:25:49] <owhite> greetings. Would anyone have advice on how to launch a program from the axis menu? I'd like to run something like "perl_prog.pl -i input_file -o output_file".
[02:34:44] <owhite> or example I could add:
[02:34:44] <owhite> ".menu.machine add command \
[02:34:44] <owhite> -command {exec /usr/bin/perlprog.pl -i $input -o $output }
[02:34:44] <owhite> setup_menu_accel .menu.machine end [_ "My program"]
[02:34:44] <owhite> "
[02:34:45] <owhite> to line 166 of /usr/share/axis/tcl
[02:34:47] <owhite> thank you !
[08:05:09] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[11:49:42] <CIA-2> EMC: 03jthornton 07v2.4_branch * r61b2a4f8805e 10/docs/src/common/ (User_Concepts.lyx images/naive-cam.dxf images/naive-cam.png): add more info on naive cam detector
[11:56:33] <JT-Dev> * JT-Dev wonders why branch showed up before master
[11:56:37] <CIA-2> EMC: 03jthornton 07master * r3841d5607347 10/docs/src/common/ (User_Concepts.lyx images/naive-cam.dxf images/naive-cam.png): add more info on naive cam detector
[11:57:08] <alex_joni> JT-Dev: email queueing
[11:57:15] <alex_joni> is it the same change?
[11:57:24] <alex_joni> if so, it would be enough to just do it on 2.4
[12:01:23] <JT-Dev> yes
[12:01:58] <JT-Dev> I did it on master first then cherry-picked to 2.4
[12:05:12] <alex_joni> in the future I think the best way is to do it on 2.4 only
[12:05:42] <JT-Dev> how will it get to master?
[12:05:43] <alex_joni> 2.4 gets (periodically) merged into master
[12:06:32] <JT-Dev> ok, that makes it easier for me then
[12:06:33] <alex_joni> that means that all changes get applied
[12:06:45] <alex_joni> just like cherry-picking all of them, but all at once
[12:06:58] <alex_joni> (and it's smart enough to not re-apply changes already applied before)
[12:07:13] <alex_joni> JT-Dev: it's magic mostly, I try not to comprehend it too much
[12:07:33] <JT-Dev> me neither LOL
[12:14:50] <JT-Dev> at least I learned how to do a cherry pick from the command line :)
[18:43:37] <jepler> http://emergent.unpy.net/files/sandbox/ow-my-arc.png
[18:44:48] <jepler> master. cyan = preview, blue = backplot.
[18:45:19] <SWPadnos> G64?
[18:45:22] <jepler> scale = tiny
[18:45:29] <jepler> dunno, whatever the default is
[18:45:43] <jepler> it would look the same in exact stop mode; I set FO=1% to get that trace
[18:46:38] <SWPadnos> right. it's an endpoint rounding thing (presumably what you were testing for)
[18:47:28] <SWPadnos> I guess the radius length tolerance should be a function of the actual radius, not the arbitrary 0.0001
[18:48:54] <cradek> how'd you generate that arc?
[18:49:07] <cradek> oh look, the gcode
[18:49:33] <cradek> before y'all optimized it, the preview would have matched...
[18:50:11] <SWPadnos> the preview is showing the (more) expected path though
[18:50:31] <cradek> welllll that's sure debatable
[18:50:43] <SWPadnos> the backplot is the funny shape, which isn't affected by the optimizations ??
[18:51:02] <SWPadnos> (I thought the optimizations were in the openGL stuff, not the TP)
[18:51:07] <cradek> yes
[18:51:57] <cradek> I meant to say that the cyan preview previously would have matched the motion
[18:52:39] <SWPadnos> heh. I guess I'm just noticing that the preview looks like an arc, but the backplot doesn't
[18:52:53] <SWPadnos> well, a circular arc anyway
[18:52:56] <cradek> the preview looks like an arc except for the last 'segment' where it jumps to the new endpoint
[18:53:15] <SWPadnos> yes
[18:53:27] <SWPadnos> it looks like they're both wrong
[18:53:27] <cradek> (that jump is part of the 'preview' too)
[18:53:48] <cradek> well, it's just GIGO and they don't give the same GO
[18:54:48] <SWPadnos> yes
[18:54:54] <jepler> but should it be accepted if it's X.0005 I.0002 ?
[18:55:06] <jepler> at some point of noncircularity it changes from rejected to accepted
[18:55:13] <cradek> anyone want to suggest a fix?
[18:55:29] <cradek> (I sure don't)
[18:55:42] <SWPadnos> make the tolerance proportional to the radius?
[18:55:51] <cradek> heck does anyone want to say what he thinks the problem is? :-)
[18:55:54] <SWPadnos> heh
[18:56:32] <jepler> cradek: bernhard.kubicek wrote about how he has found that "scaling" gcode by scaling X, Y, Z, I, J, K doesn't work for some arcs
[18:57:01] <jepler> it could be because the absolute error of the arc center gets bigger when you scale up
[18:57:03] <cradek> I'm sure that's true
[18:57:11] <cradek> yep
[18:57:13] <jepler> so inevitably when you print with some fixed precision then scale up by multiplying, you'll hit this problem
[18:57:24] <SWPadnos> that fix would only push the error "downstream", since there will still be some (now moving) boundary between acceptable and not acceptable code
[18:57:40] <cradek> "don't scale more than a little bit" might be the fix for that
[18:57:59] <jepler> Making arc tolerance relative could be too
[18:58:21] <cradek> currently if you do your math to N digits after the decimal you'll get working gcode (where N depends on the units)
[18:58:35] <cradek> seems like you'll break that relation if you make it proportional
[18:58:42] <SWPadnos> but only if you don't change the effective value of N by scaling
[18:58:58] <jepler> this is something I'm concerned about for ttt as well, since it outputs arcs now but encourages the user to change a scaling factor
[18:59:04] <cradek> sorry I didn't follow that
[18:59:06] <SWPadnos> multiply by 100, and N needs to be 2+the minimum
[18:59:26] <jepler> (in fact I think we saw this problem and I increased the number of digits printed by 3 or 4..)
[18:59:33] <cradek> bleh
[18:59:37] <SWPadnos> since you shift the significant digits to the left, and N is a constant number of digits to the right of the DP
[19:01:22] <jepler> are you suggesting that we record the number of digits shown?
[19:01:31] <jepler> there is no "number of digits shown" for X[#1*3.87]
[19:01:44] <SWPadnos> I'm not suggesting that, if you're asking me
[19:01:53] <jepler> I'm just not understanding the suggestion
[19:02:30] <SWPadnos> oh. I was sort of answering cradeks point about choosing to use at least N decimals in your G-code
[19:02:51] <SWPadnos> the effective N changes when you scale
[19:03:34] <cradek> I'm struggling to care about scaling up by huge amounts
[19:03:59] <cradek> clearly there's a fundamental problem here and we have to choose our tradeoff
[19:04:01] <SWPadnos> there are also issues scaling down, but yeah, scaling by a factor of 10000 seems unreasonable at first glance
[19:04:29] <cradek> I don't think there's a problem scaling down
[19:04:31] <SWPadnos> the thing is, non-scaled code, which should work, doesn't
[19:04:42] <SWPadnos> there is, it's the one jeplers screenshot shows
[19:04:45] <cradek> example of that?
[19:05:08] <cradek> no, jepler's screen shot does not show that scaling down is a problem
[19:05:11] <SWPadnos> micron-scale arcs are ignored or screwed up, apparently
[19:05:29] <cradek> no, I think you misunderstand what jepler did
[19:05:47] <SWPadnos> my supposition is that the fixed radius tolerance is what caused the errors in that plot
[19:06:08] <SWPadnos> that's very possible
[19:06:09] <jepler> I made an "arc" where the distance from the start to center is .0004 and the end to the center is .0001
[19:06:39] <cradek> the fixed radius tolerance let that gcode through without generating an error. the bad arc specification is what caused it to make a non-arc.
[19:06:39] <SWPadnos> hmmm. shouldn't that have been rejected?
[19:06:48] <SWPadnos> sure
[19:06:57] <cradek> yes that's the point
[19:07:04] <cradek> it has nothing to do with scaling down
[19:07:07] <SWPadnos> that's my point - if you scale something down, you'll have problems
[19:07:13] <cradek> no, that does not follow
[19:07:40] <jepler> would help if I said the picture isn't really about the problem?
[19:07:41] <cradek> if you scale something down and throw out precision, you lose that precision
[19:07:44] <SWPadnos> heh
[19:08:10] <cradek> 13:55 < cradek> heck does anyone want to say what he thinks the problem is? :-)
[19:08:38] <jepler> I think it's a pity that the second arc in this code is rejected, while the first is accepted:
http://pastebin.ca/1850626
[19:08:42] <SWPadnos> if an arc is too small, is it rejected or skipped?
[19:08:48] <jepler> it's not a miniscule arc, and it's not a huge scale
[19:08:51] <jepler> SWPadnos: it's rejected
[19:08:58] <jepler> Radius to end of arc differs from radius to start: start=(X0.0000,Y0.0000) center=(X1.6670,Y0.0000) end=(X3.3330,Y0.0000) r1=1.6670 r2=1.6660
[19:09:29] <SWPadnos> ok. so scaling down will (ideally) cause a program to stop when the arcs get too small, and scaling up will cause a program to stop when the radius errors get big enough
[19:09:45] <jepler> er, wait, I didn't read your question
[19:09:49] <SWPadnos> (ideally, because it looks like that's not working quite right, and you get bogus non-arcs now)
[19:09:51] <SWPadnos> heh
[19:10:00] <cradek> arcs are not rejected for being too small
[19:10:03] <SWPadnos> ok
[19:10:04] <cradek> nor too large
[19:10:05] <jepler> the tiny degenerate arc generates the motion shown in my original screenshot
[19:10:09] <jepler> but it's not like you could measure it
[19:10:28] <jepler> cradek: not true; there is a min_radius check of .1*tolerance
[19:10:40] <cradek> oh really
[19:10:40] <jepler> I don't think you can program any arc 1/10 that big
[19:10:42] <SWPadnos> you could if you had a precision machine making that arc
[19:10:58] <jepler> double min_radius = 0.1 * tolerance; /* smaller than this is treated as zero */
[19:11:00] <SWPadnos> could measure it and machine it that is
[19:11:01] <jepler> CHKS(((radius < min_radius) || (radius2 < min_radius)), NCE_ZERO_RADIUS_ARC);
[19:11:56] <cradek> do we all think we need a matched-radii check of some kind?
[19:12:38] <jepler> would you like to reject invalid arcs based on geometry information?
[19:13:06] <SWPadnos> checking is the preferable option I think. The only other one I can come up with at the moment would be to try to guess what the code meant
[19:13:08] <cradek> * cradek snickers quietly
[19:13:21] <SWPadnos> err, s/code/person/
[19:13:55] <cradek> what's the fundamental problem? is it just that arcs are overspecified?
[19:15:10] <jepler> cradek: if the arc endpoint or center is the result of a calculation, but at least one input of the calculation is a non-exact constant written with a fixed number of decimals, it's difficult to know the number of decimals to specify in the constant.
[19:15:20] <cradek> fwiw we *could* accept them and make the spiral shape. if the radii aren't grossly mismatched, it's quite possible that shape is fine
[19:15:47] <SWPadnos> I wonder if the tolerances should be based on machine resolution (or settable in the ini)
[19:15:52] <jepler> we know we're making very slightly spiral "arcs" all the time; it's rare that the math comes out exact
[19:16:06] <cradek> yes and I bet we agree that's fine
[19:16:15] <cradek> (that was in response to jepler)
[19:16:18] <SWPadnos> right
[19:17:06] <cradek> what if we allow 100x as much spiralyness and call it good
[19:17:27] <SWPadnos> what about y and z? :)
[19:17:29] <cradek> gross errors in handwritten gcode will still error. cam or reasonably-scaled gcode won't.
[19:17:43] <jepler> http://emergent.unpy.net/files/sandbox/0001-Add-a-relative-tolerance-for-arcs.patch
[19:17:45] <cradek> I meant a 100-fold increase
[19:17:52] <SWPadnos> :)
[19:19:17] <SWPadnos> I naively think that patch is good
[19:19:34] <SWPadnos> I don't know the ramifications as well as you guys though
[19:19:37] <jepler> I called the 1% tolerance arbitrary, but it allowed my pastebinned program to run while a .05% tolerance didn't..
[19:19:40] <cradek> how about printing rel_error as a percentage?
[19:20:12] <cradek> or maybe there's a better way to make it more plain-language
[19:20:52] <SWPadnos> there should probably still be a max absolute error check
[19:20:59] <cradek> there is
[19:21:29] <SWPadnos> doesn't this remove it?
[19:21:31] <SWPadnos> - CHKS((fabs(radius - radius2) > tolerance),
[19:21:35] <cradek> CHKS((abs_err > tolerance
[19:21:41] <jepler> if you have a 96 million mile arc the permitted error is .1% * 96 million miles = 6e9 inches
[19:21:46] <SWPadnos> ah, right (duh)
[19:23:01] <jepler> if I wrote what I intended, this only allows arcs that weren't allowed before
[19:23:19] <jepler> the relative error check will allow some large arcs to pass when they didn't before
[19:23:23] <SWPadnos> hmmm
[19:23:38] <cradek> I was just making sure I also think that's what it does
[19:23:43] <cradek> ... and I do
[19:23:46] <SWPadnos> I bet some large arcs should still be rejected, but the tolerance value can be increased
[19:23:49] <cradek> specifically you'll still allow ow-my-arc
[19:23:54] <jepler> cradek: yes
[19:24:01] <jepler> but who cares about that
[19:24:44] <cradek> aside from thinking the error message should be plainer language, I like the patch
[19:25:17] <SWPadnos> I think the check should be an or: if rel_err > $arbitrary || abs_err > $something_bigger_than_old_tolerance
[19:25:33] <cradek> then you break existing programs
[19:25:40] <cradek> (like ow-my-arc)
[19:26:15] <jepler> even if an arc is a million inches, maybe an error of a half inch should always be rejected
[19:26:20] <jepler> is that what you're trying to say, SWPadnos?
[19:26:24] <SWPadnos> that's what I was trying to say
[19:26:25] <SWPadnos> thanks
[19:26:56] <cradek> I have no idea which poison to pick
[19:27:06] <SWPadnos> hmmm. maybe the patch works right as is
[19:27:41] <jepler> no; if I wrote what I meant, there's an arc large enough that a half-inch error is accepted (it's .5 / .1% = 500 in radius)
[19:28:13] <SWPadnos> ah yes, ok
[19:29:31] <SWPadnos> ok, yes. if the ratio is too far off or the difference is too big, then it should be an error
[19:30:12] <SWPadnos> where "too big" is larger than the old tolerance was, since the ratio will catch a lot of stuff that used to be caught only by the absolute error check
[19:31:30] <jepler> so compared to my original patch, you might be happier with something like
[19:31:31] <jepler> - CHKS((abs_err > tolerance && rel_err > .001),
[19:31:31] <jepler> + CHKS((abs_err > tolerance && (rel_err > .001 || abs_err > 100*tolerance)),
[19:32:03] <jepler> so that an error of .05 inches will always be rejected
[19:32:11] <jepler> (TOLERANCE_INCH = .0005 inches)
[19:32:26] <cradek> + // and here's what I was trying to accomplish with all that jazz up there
[19:33:37] <cradek> I bet R arcs can fail in a similar way when scaled up
[19:34:10] <SWPadnos> that does it, but this may be more obvious:
[19:34:11] <jepler> ight as is
[19:34:18] <cradek> ?
[19:34:22] <jepler> sorry, bad paste
[19:34:32] <jepler> the R arcs have problems near where they're semicircular
[19:34:32] <jepler> CHKS(((half_length - abs_radius) > tolerance),
[19:34:32] <jepler> NCE_ARC_RADIUS_TOO_SMALL_TO_REACH_END_POINT);
[19:34:43] <cradek> yes that was what I was thinking of
[19:34:50] <SWPadnos> + CHKS(abs_err > 100*tolerance || (abs_err > tolerance && rel_err > .001)),
[19:35:05] <SWPadnos> did I typo that right?
[19:35:46] <SWPadnos> the intent seems more obvious to me: if the error is really big, or it's not as big but still big relative to the radius
[19:35:49] <cradek> I want some coffee
[19:35:51] <SWPadnos> heh
[19:36:21] <jepler> it took me a moment to understand how you could rewrite (A && (B || C)) into (C || (A && B))
[19:36:36] <jepler> clearly those aren't equivalent in the general case
[19:36:37] <SWPadnos> heh
[19:36:39] <SWPadnos> no
[19:36:48] <jepler> but since C => A I bet it works out
[19:37:05] <SWPadnos> I believe so, but it's definitely good to check
[19:37:32] <SWPadnos> since A implies B in this case, I believe it's true
[19:38:28] <SWPadnos> err, well you know.
[19:38:54] <cradek> if(fabs(r1-r2) > .01)
[19:38:55] <jepler> errrr
[19:39:11] <jepler> cradek: where's that?
[19:39:11] <cradek> ERS(_("BUG: cutter compensation has generated an invalid arc with mismatched radii r1 %f r2 %f\n"), r1, r2);
[19:39:22] <cradek> interp_queue.cc
[19:39:38] <jepler> oh, so is there another layer of post-compensation that we'd have to fix too?
[19:39:39] <cradek> it's just a gross check for a bug that has never fired
[19:40:14] <cradek> we could take this one out
[19:40:33] <jepler> is that a check on all arcs emitted from cutter comp, or just arcs added for outside corners?
[19:41:03] <cradek> all arcs because they may have had their endpoints moved
[19:41:11] <cradek> (when part of inside corners)
[19:41:43] <jepler> *sound of jepler being punched in the gut*
[19:42:09] <cradek> just take it out I guess
[19:44:05] <cradek> old sweep %f new speed %f
[19:44:10] <cradek> heh, that's quite a typo for sweep
[19:44:57] <jepler> cradek: let's have that coffee
[19:45:05] <cradek> ok
[19:45:45] <jepler> Radius to end of arc differs from radius to start: start=(X0.0000,Y0.0000) center=(X166.7000,Y0.0000) end=(X333.3000,Y0.0000) r1=166.7000 r2=166.6000 abs_err=0.1 rel_err=0.0600%
[19:45:53] <jepler> I changed my program to successively scale by 10
[19:46:10] <jepler> it hits the 100*tolerance check here
[19:46:15] <jepler> which is what we want, maybe
[19:46:26] <cradek> that's the 0.1 inch?
[19:47:10] <jepler> yes. the previous error of .01 inches was accepted
[20:16:43] <jepler> http://emergent.unpy.net/files/sandbox/0001-Add-a-relative-tolerance-for-arcs-rev2.patch
[20:17:48] <jepler> still has an inhumane error message :-/
[20:53:32] <cradek> jepler: wfm
[20:53:43] <CIA-2> EMC: 03cradek 07v2.4_branch * r6771295e4fe5 10/lib/python/rs274/glcanon.py: reduce python overhead in arcs
[20:53:44] <CIA-2> EMC: 03cradek 07v2.4_branch * r6df4806d5db4 10/ (2 files in 2 dirs): Convert arcs to segments in C
[20:53:45] <CIA-2> EMC: 03cradek 07v2.4_branch * r93638e8833f1 10/src/emc/rs274ngc/gcodemodule.cc: reduce minimum number of arc segments
[20:53:46] <CIA-2> EMC: 03cradek 07v2.4_branch * r848fcededbec 10/lib/python/rs274/interpret.py: allow tuning of arc subdivision at this layer
[20:53:47] <CIA-2> EMC: 03cradek 07v2.4_branch * radbed46485fb 10/src/emc/usr_intf/axis/scripts/axis.py: allow inifile to set arc subdivision
[20:53:49] <CIA-2> EMC: 03cradek 07v2.4_branch * r41ad711bbd70 10/ (2 files in 2 dirs): reduce default number of segments
[20:53:49] <CIA-2> EMC: 03cradek 07v2.4_branch * ra62c4d5bd508 10/src/emc/rs274ngc/gcodemodule.cc: simplify populating n[]
[20:53:50] <CIA-2> EMC: 03cradek 07v2.4_branch * r31071d5d270f 10/docs/src/config/ini_config.lyx: document new inifile item
[20:53:51] <CIA-2> EMC: 03cradek 07v2.4_branch * re67319685903 10/src/emc/rs274ngc/gcodemodule.cc: make it build with python2.4
[20:53:53] <CIA-2> EMC: 03cradek 07v2.4_branch * rd5ee3ab4f1d7 10/src/emc/rs274ngc/gcodemodule.cc: calculate tx, ty without requiring rad
[20:53:55] <CIA-2> EMC: 03cradek 07v2.4_branch * r0188cfa57b9e 10/src/emc/rs274ngc/gcodemodule.cc: this reformulation allows g++ to see that plane is initialized
[20:53:56] <CIA-2> EMC: 03cradek 07v2.4_branch * r3e418d383661 10/src/emc/rs274ngc/gcodemodule.cc: fix helical arcs
[20:53:57] <CIA-2> EMC: 03cradek 07v2.4_branch * r342f9d24f287 10/src/emc/usr_intf/axis/scripts/axis.py: the machine coordinate system does not rotate
[20:53:58] <CIA-2> EMC: 03cradek 07v2.4_branch * r5e612f28b37e 10/src/emc/rs274ngc/gcodemodule.cc: make a certain "full circle" arc appear
[20:53:58] <CIA-2> EMC: 03cradek 07v2.4_branch * r2d8ea42b7d64 10/src/emc/rs274ngc/gcodemodule.cc: another fix for helical arcs
[20:54:10] <CIA-2> EMC: 03cradek 07v2.4_branch * r8c43c8a6510d 10/nc_files/polar.ngc: Update the sample file for how polar works now
[20:54:28] <jepler> cradek: thanks for testing and pushing
[20:54:42] <jepler> I'll do a merge of v2.4_branch -> master since I know there are conflicts
[20:54:44] <cradek> no, thanks to you for doing the hard work
[20:54:54] <cradek> oh ok, thanks
[20:56:18] <JT-Hardinge> thanks to both of you
[21:09:08] <jepler> .. spew spew spew ..
[21:10:21] <jepler> any moment now!
[21:10:33] <CIA-2> EMC: 03jepler 07master * r20ccc94871cf 10/src/emc/rs274ngc/interp_cycles.cc: Better error messages for canned cycles on missing axes
[21:10:33] <CIA-2> EMC: 03jepler 07master * r2b4273166636 10/src/emc/rs274ngc/interp_find.cc: fix g53 moves that don't specify all words, while current system is rotated
[21:10:33] <CIA-2> EMC: 03jepler 07master * rb401ab22739a 10/src/Makefile: nurbs are broken, so don't install this
[21:10:33] <CIA-2> EMC: 03jepler 07master * r3d01e8ef445c 10/.gitignore: generated file
[21:10:33] <CIA-2> EMC: 03jepler 07master * r9342820a64f3 10/docs/src/hal/ (3 files in 2 dirs): add remote program start example
[21:10:33] <CIA-2> EMC: 03jepler 07master * r8a3180bc4890 10/docs/src/gcode/main.lyx: add to M1nn description
[21:10:34] <CIA-2> EMC: 03jepler 07master * r07e780b99e9c 10/ (4 files in 3 dirs): Merge branch 'v2.4_branch' of ssh://jthornton@git.linuxcnc.org/git/emc2 into v2.4_branch
[21:10:35] <CIA-2> EMC: 03jepler 07master * r61b2a4f8805e 10/docs/src/common/ (User_Concepts.lyx images/naive-cam.dxf images/naive-cam.png): add more info on naive cam detector
[21:10:35] <CIA-2> EMC: 03jepler 07master * r6771295e4fe5 10/lib/python/rs274/glcanon.py: reduce python overhead in arcs
[21:10:36] <CIA-2> EMC: 03jepler 07master * r6df4806d5db4 10/ (2 files in 2 dirs): Convert arcs to segments in C
[21:10:36] <CIA-2> EMC: 03jepler 07master * r93638e8833f1 10/src/emc/rs274ngc/gcodemodule.cc: reduce minimum number of arc segments
[21:10:37] <CIA-2> EMC: 03jepler 07master * r848fcededbec 10/lib/python/rs274/interpret.py: allow tuning of arc subdivision at this layer
[21:10:37] <CIA-2> EMC: 03jepler 07master * radbed46485fb 10/src/emc/usr_intf/axis/scripts/axis.py: allow inifile to set arc subdivision
[21:10:38] <CIA-2> EMC: 03jepler 07master * r41ad711bbd70 10/ (2 files in 2 dirs): reduce default number of segments
[21:10:52] <CIA-2> EMC: 03jepler 07master * r31071d5d270f 10/docs/src/config/ini_config.lyx: document new inifile item
[21:10:53] <CIA-2> EMC: 03jepler 07master * re67319685903 10/src/emc/rs274ngc/gcodemodule.cc: make it build with python2.4
[21:10:53] <CIA-2> EMC: 03jepler 07master * ra62c4d5bd508 10/src/emc/rs274ngc/gcodemodule.cc: simplify populating n[]
[21:10:53] <CIA-2> EMC: 03jepler 07master * rd5ee3ab4f1d7 10/src/emc/rs274ngc/gcodemodule.cc: calculate tx, ty without requiring rad
[21:10:53] <CIA-2> EMC: 03jepler 07master * r0188cfa57b9e 10/src/emc/rs274ngc/gcodemodule.cc: this reformulation allows g++ to see that plane is initialized
[21:10:53] <CIA-2> EMC: 03jepler 07master * r3e418d383661 10/src/emc/rs274ngc/gcodemodule.cc: fix helical arcs
[21:10:54] <CIA-2> EMC: 03jepler 07master * r342f9d24f287 10/src/emc/usr_intf/axis/scripts/axis.py: the machine coordinate system does not rotate
[21:11:52] <CIA-2> EMC: 03jepler 07master * r5e612f28b37e 10/src/emc/rs274ngc/gcodemodule.cc: make a certain "full circle" arc appear
[21:11:52] <CIA-2> EMC: 03jepler 07master * r2d8ea42b7d64 10/src/emc/rs274ngc/gcodemodule.cc: another fix for helical arcs
[21:11:52] <CIA-2> EMC: 03jepler 07master * r8c43c8a6510d 10/nc_files/polar.ngc: Update the sample file for how polar works now
[21:11:52] <CIA-2> EMC: 03jepler 07master * rd990f8695571 10/ (5 files in 4 dirs): Merge remote branch 'origin/v2.4_branch'
[21:11:53] <CIA-2> EMC: 03jepler 07master * rac3320f0a58b 10/share/axis/tcl/axis.tcl: make the program text resizeable
[21:11:53] <CIA-2> EMC: 03jepler 07master * rce24e1924e2f 10/share/axis/tcl/axis.tcl: don't prevent window from being shrunk
[21:11:54] <CIA-2> EMC: 03jepler 07master * r77e0b0c9a742 10/share/axis/tcl/axis.tcl: on tk8.5, make top pane enlarge by default
[21:11:54] <CIA-2> (4 lines omitted)
[21:12:29] <SWPadnos> oh look. an email
[21:12:32] <SWPadnos> or 32
[21:12:36] <SWPadnos> thanks :)
[22:21:11] <alex_joni> mozmck_work: same for me
[22:21:22] <alex_joni> been using it in production for a couple months now
[22:21:42] <alex_joni> mozmck_work: saw you left #openobject..
[22:40:32] <alex_joni> good night all
[22:40:56] <mozmck> alex_joni: yep, just came home.
