Back
[11:18:34] <cradek> Lerneaen_Hydra: I just have a minute to talk, but I wanted to ask you about G76, the threading canned cycle
[11:19:01] <cradek> the only one really documented on the wiki page is the Fanuc and it's crazy, I don't want to use it
[11:19:14] <cradek> some numbers in the gcode have implied decimal points and others don't
[11:19:41] <cradek> do you know if there is a more sane one that we can use?
[13:42:46] <jepler> I've modified emc2 so that the kinematics can be selected by name when motmod is loaded. But it looks like the nontrivial kinematics (e.g., genhexkins) actually have to be modified to match the geometry of the machine.
[13:42:53] <jepler> is there any point in checking in this change?
[13:43:20] <jepler> that is, the source code has to be modified
[13:53:42] <SWPadnos> I'd say that it should be checked in, if it doesn't disrupt existing configs
[13:54:05] <SWPadnos> (ie, like you must specify kinematics, which would break any existing configs)
[13:54:15] <jepler> no, it defaults to "trivial"
[13:54:44] <SWPadnos> ok. in that case, I'd say it's an excellent first step toward user-created kins
[13:55:32] <SWPadnos> another good one, though not required, would be some sort of method to make user modules, without needing to rebuild all of axis (similar to the way you can build a kernel module out-of-tree)
[13:55:46] <SWPadnos> err - emc, not axis (not enough caffeine)
[13:55:52] <jepler> yes, I understand
[13:56:15] <jepler> right now, this still links all the available kinematics into motmod at compile time -- you just get to choose which one gets called
[13:56:26] <SWPadnos> ah - ok
[13:56:53] <SWPadnos> so you more or less made an array of function pointers, and select which group gets used?
[13:56:58] <jepler> exactly
[13:57:46] <SWPadnos> hmmm - as a side note, do you know how to load multiple shared libraries that have functions with the same name?
[13:57:55] <SWPadnos> (like init or cleanup ...)
[13:58:50] <jepler> I would have guessed that it would work OK as long as you don't use dlopen(... | RTLD_GLOBAL )
[13:59:24] <SWPadnos> it may be - I was thinking about userspace HAL modules, and run-time linking
[14:10:07] <jepler> this program loads two shared libraries and calls the function 'f' in each one:
http://emergent.unpy.net/files/sandbox/multi.tar.gz
[14:10:16] <SWPadnos> err -thanks ;)
[14:13:14] <jepler> it was not much work
[14:13:16] <jepler> as you'll se
[14:13:16] <jepler> e
[14:13:24] <jepler> heck, the tar is 650 bytes
[14:13:28] <SWPadnos> heh
[14:13:40] <SWPadnos> I was wondering if you had gotten curious enough to try it
[14:13:53] <SWPadnos> I'm booting a Linux machine so I can mess with it
[14:14:25] <SWPadnos> that could be a way to get a userspace HAL working
[14:33:33] <jepler> * jepler tries to figure out a way that kinematics could be a separate module, but without the module loaded it would default to trivial.
[14:34:41] <skunkworks> jepler: does the emc1 tp look much better than what you had done?
[14:36:42] <jepler> skunkworks: I don't know about the new planner in bdi4emc. the emc1 planner was terrible -- it frequently disobeyed machine constraints.
[14:37:25] <jepler> skunkworks: based on the graph posed by matt t. last week it looks like it does a bit better at keeping the velocity up when contouring, but I have no way of knowing if it actually obeys machine constraints or not.
[14:38:53] <jepler> skunkworks: I looked at emc1's quickstep driver and it looks like that driver will respect machine acceleration and velocity limits, but not by giving a following error. it just tries to get to the commanded position as fast as it can.
[14:39:24] <SWPadnos> jepler - how about loading a specified kins modulle, or pointing at (a) built-in functions or (b) loading trivkins if nothing is specified
[14:39:49] <jepler> but again, I don't run the version of emc on bdi so this is speculation based only on reading the source code
[14:44:01] <jepler> SWPadnos: if it was OK to break all the .hal files I would require the user 'loadrt trivkins' and then just let the kernel's dynamic linking take care of it.
[14:44:16] <SWPadnos> yep
[14:44:45] <SWPadnos> though trivkins is a no-op, right?
[14:45:04] <SWPadnos> ie - the ioutput coordinates are identical to the input coordinates, though they are a copy
[14:45:50] <skunkworks> thanks jepler
[14:46:08] <jepler> SWPadnos: yes
[14:47:23] <SWPadnos> can it work if you replace the fwd and rev kins fcuntions with function pointers, and just default them to the trivkins functions (suitably renamed, of course)
[14:47:38] <SWPadnos> if a module is loaded, change the pointers
[14:48:49] <SWPadnos> it's also probably not too much overhead to make the kins functions into wrappers (as you've probably done already), and do something like if (!module_loaded) deafult_kins_func()
[15:47:19] <jepler> logger_devel: help
[15:48:11] <jepler> sorry to spam the channel with that
[15:48:21] <jepler> for some reason, /msg logger_devel help won't give the same text
[15:59:25] <jepler> http://emergent.unpy.net/files/sandbox/newspeed2.png
[15:59:51] <jepler> 3 graphs of velocity vs time, with the horizontal scales approximately the same
[15:59:56] <jepler> (2 seconds per div in the halscope photos)
[16:00:37] <jepler> the recent improvement (to use full accel instead of half accel in many cases during contouring) makes a big difference
[16:01:49] <jepler> from top to bottom: emc2 with merging and accel fix, p.03. emc2 without accel fix, p.03. bdi4emc, e.03
[16:04:32] <SWPadnos> I wonder what the scale is on the BDI plot
[16:05:09] <SWPadnos> and how high that last vel mag peak actually is, since it goes off the top of the chart
[16:06:19] <jepler> I don't know much about the plot from bdi4emc
[16:06:35] <cradek> it's hard to say which is better without more data, but they sure look comparable to my eye
[16:06:42] <SWPadnos> though the emc2 plots look less ragged
[16:07:08] <SWPadnos> at least the first one does ;)
[16:07:13] <cradek> I think the 2006-06-19 plot looks the best, 2006-06-12 looks the worst
[16:07:29] <jepler> yeah there's a big improvement between 12 and 19
[16:07:34] <SWPadnos> yep
[16:07:45] <cradek> bdi4emc looks in between the two
[16:08:03] <cradek> although on -19 there is some vel variation at cruise that bdi4emc doesn't have
[16:08:29] <jepler> yeah, but I think there's some unknown amount of smoothing in the bdi4emc plot
[16:08:34] <SWPadnos> what's the vertical resolution on the emc2 plots?
[16:08:38] <cradek> but bdi4emc has much lower spikes
[16:09:00] <jepler> SWPadnos: 1 inch/sec/div
[16:09:08] <SWPadnos> ok
[16:09:09] <jepler> the top machine speed is 72 ipm, or 1.2 (?) ips
[16:09:38] <jepler> the commanded speed is 1000mm/minute, or .656 in/sec
[16:12:11] <jepler> I'm pretty sure the emc2 -19 plot shows it finishing in less time than bdi4 but with the horizontal scaling I had to do I'm not sure
[16:12:43] <cradek> but they're within a few %
[16:12:59] <SWPadnos> where is the g-code for this? (I thought Matt T had sent it to the list)
[16:13:28] <cradek> I can't decide if this is useful or if it's a pissing contest
[16:13:35] <jepler> emergent.unpy.net/files/sandbox/chips.ngc
[16:13:44] <SWPadnos> ah = ok ;)
[16:13:55] <jepler> yeah, I should probably leave bdi4emc out of it
[16:14:06] <jepler> but I did want to show that emc2 improved compared to when I posted my graphs
[16:14:09] <SWPadnos> well, if it results in smoother motion, and/or a "better" TP, then it's more than a pissing contest
[16:14:19] <cradek> I'm sad that we've duplicated so much work and that we have a disparate set of features because of it
[16:14:46] <SWPadnos> yeah - the e.03 vs p.03 acutally makes the interps incompatible
[16:14:59] <cradek> yes, and gratuitiously so
[16:15:33] <cradek> matt T suggested in an email that paul use the same format we did when he put that in, but he didn't choose to
[16:15:43] <jepler> offs
[16:15:47] <SWPadnos> ah - well that would have been nice
[16:17:17] <jepler> cradek: can you remember what test we were doing when I decided to increase the number of mergeable segments from 100 to 1000?
[16:17:56] <cradek> the crazy file from skunkworks?
[16:18:35] <jepler> oh, I know--it was the 4000-line 2-inch parabola file
[16:21:58] <jepler> hi skunkworks
[16:22:01] <jepler> we were just talking about you
[16:22:57] <jepler> 11:22:51 <jepler> cradek: can you remember what test we were doing when I decided to increase the number of mergeable segments from 100 to 1000?
[16:23:00] <jepler> 11:23:31 <cradek> the crazy file from skunkworks?
[16:32:01] <skunkworks> funny
[16:32:07] <skunkworks> I do what I can :)
[16:32:38] <skunkworks> I am glad it had a use.
[18:28:54] <cradek> Lerneaen_Hydra: yell if you're around, I want to bother you about lathes some more
[18:55:52] <cradek> hmm
[18:56:04] <cradek> I'm trying to figure out how to do cutter comp for lathes
[18:56:11] <cradek> right now you can only do cutter comp in XY
[18:56:41] <cradek> I can't decide whether I should allow XZ as well (and specify it in the ini file) or generalize it somehow, maybe basing it on the active plane
[18:57:11] <cradek> the problem is the algorithm is going to end up different because of tool shape issues
[19:04:33] <cradek> I'm tempted to use the active plane, but that has the potential of breaking existing gcode programs
[19:04:46] <cradek> currently the plane is only used for arcs
[19:05:07] <cradek> you can set plane to XZ to do an arc, then leave it there and do cutter comp (which comps in just XY)
[19:05:33] <jepler> are you sure?
[19:05:50] <cradek> as long as you comp just lines
[19:06:25] <cradek> so if you do an arc, it doesn't get comped (which is going to do something screwy I think)
[19:06:31] <jepler> the documentation says it's an error if the XY plane is not selected when you program G41 or G42
[19:06:44] <jepler> see page 119 of
http://linuxcnc.org/EMC2_User_Manual.pdf
[19:07:42] <jepler> that text is almost certainly the same as the old NIST document
[19:07:43] <cradek> CHK((settings->plane != CANON_PLANE_XY),
[19:07:43] <cradek> NCE_CANNOT_TURN_CUTTER_RADIUS_COMP_ON_OUT_OF_XY_PLANE);
[19:07:47] <cradek> you're right
[19:07:52] <cradek> I didn't see it
[19:08:08] <cradek> so I would break that
[19:08:21] <jepler> you'd make some formerly improper programs valid
[19:08:25] <jepler> that's just fine
[19:09:00] <cradek> still this is just half the issue, the tool table has to be different
[19:09:26] <cradek> hmm
[19:10:08] <jepler> that I can't help you with
[19:10:56] <cradek> well maybe I can just add optional columns to it
[19:11:45] <cradek> yeah maybe that's the ticket
[19:12:05] <jepler> clearly you should be using xml
[19:12:09] <jepler> </troll>
[19:27:37] <cradek> ok the new restriction is you can't switch to a different plane with comp on
[19:27:50] <cradek> that lets you still program G_17 (xy) with comp on, which you could do before
[19:31:11] <skunkworks> sounds like a plan
[19:33:10] <cradek> hmm, do left and right comp make sense on a lathe?
[19:33:29] <cradek> say you're cutting on the outside
[19:33:52] <cradek> whether you cut in +z or -z, you'll want to be +x of the work
[19:34:02] <cradek> but that's either "left" or "right" depending on which way Z goes
[19:34:45] <cradek> if you're boring, it's the opposite way but the problem is the same
[19:35:05] <cradek> I guess a lathe program is usually not going to cut back and forth, it will cut in one direction
[19:42:42] <jepler> I bet it should have been an error to switch out of g17 during compensation
[19:43:00] <cradek> I think it was
[19:43:21] <cradek> but you could program the current plane during comp (which I'm still allowing)
[19:43:26] <jepler> oh
[19:43:54] <cradek> at first I thought I should disallow g17/18/19 during comp, but that'll break old programs
[20:32:28] <cradek> cursed inverse time feed rates
[20:57:14] <Lerneaen_Hydra> yoohoo? cradek= I'm here now ;)
[20:57:58] <Lerneaen_Hydra> yes, the fanuc spec is rather... non-intuitive, to say the least
[20:59:05] <Lerneaen_Hydra> I prefer the siemens one (I only know of EMCO's bastardised version, which will no doubt need changes as it doesn't allow an angled thread exit)
[21:00:13] <cradek> hi
[21:00:38] <cradek> I'm doing radius comp now, but I want to tackle g76 soon
[21:00:57] <cradek> can you figure out the sanest g76 and document it on that same page for me?
[21:01:04] <cradek> g67? whatever it is
[21:01:08] <Lerneaen_Hydra> oh, ok
[21:01:51] <Lerneaen_Hydra> It uses the format of (IIRC) CYCLE97(parameters)
[21:02:03] <Lerneaen_Hydra> so changing it to a gcode is probably good
[21:02:28] <cradek> it would be nice if it were something cam software can put out
[21:02:33] <cradek> or do they just use g33?
[21:02:36] <Lerneaen_Hydra> as for the actual way the parameters are lined up, it sucks. It's probably best to make something from scratch
[21:02:51] <Lerneaen_Hydra> my cam software can either do g33 or canne
[21:02:57] <Lerneaen_Hydra> if I enter how it's made
[21:03:50] <cradek> there's no sane existing canned threading cycle??
[21:06:28] <Lerneaen_Hydra> as for the spec, as long as you have all these parameters, it should be good: pitch, speed (rpm/css), approach/retreat angle, lead in/out (typically specified as n counts of pitch, ie a pitch of 3 and lead in of 2 would give a lead in of 6 units), degression factor (1.0 for constant chip volume, 0.0 for constant increment, possibly other values inbetween for a blended result), total depth,...
[21:06:30] <Lerneaen_Hydra> ...outer diameter, cut increment, number of passes, final increment, start depth, and spring cuts,
[21:06:37] <Lerneaen_Hydra> not that I know of, unfortunately
[21:06:49] <Lerneaen_Hydra> I'm not sure if heidenhein has a good one
[21:10:20] <Lerneaen_Hydra> cradek: IRT cutter compensation, EMC needs to support all the nine cutter positions to be competive with commercial systems, though some are rarely used they are still valid (I think I've used them all except 1 and 5)
[21:15:41] <cradek> so you don't think it matters how I define g76?
[21:15:48] <Lerneaen_Hydra> no, not really
[21:16:18] <Lerneaen_Hydra> I'm sending a mail with descriptions about the different things to your mail, is that ok? the cradek at users.sourceforge.net one?
[21:16:58] <cradek> can you put it on the wiki page instead please?
[21:17:23] <cradek> I'm still crossing my fingers hoping for some help on some of this, I want to keep it all public
[21:17:47] <Lerneaen_Hydra> oh, ok
[21:17:53] <Lerneaen_Hydra> It'll be messy though
[21:18:05] <Lerneaen_Hydra> any suitable page?
[21:18:34] <cradek> a new one maybe? or on the end of the previous page you made?
[21:18:40] <Lerneaen_Hydra> hmm, ok
[21:18:43] <Lerneaen_Hydra> I'll append it
[21:18:55] <cradek> thank you
[21:23:34] <Lerneaen_Hydra> there,
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Lathe_Advanced_Features
[21:28:25] <Lerneaen_Hydra> cradek: any thoughts?
[21:28:33] <alex_joni> hi guys
[21:29:05] <SWPadnos> hi Alex
[21:30:18] <Lerneaen_Hydra> hello
[21:58:34] <cradek> sorry, I'm back now
[22:01:26] <cradek> wow that's a lot of stuff
[22:02:24] <cradek> darn, I bet you're gone for the night
[22:04:40] <Lerneaen_Hydra> nope
[22:04:46] <Lerneaen_Hydra> still here for a little while
[22:04:55] <Lerneaen_Hydra> any questions?
[22:05:48] <Lerneaen_Hydra> but now cradek is gone... haha
[22:06:36] <jepler> huh. I'm comparing the behavior of the "greedy" and "douglas" methods of removing trajectory points based on a distance comparison, and to my surprise "greedy" does better (has fewer output points) on my first input data
[22:06:51] <jepler> 74 output points from 1000, instead of 114 output points
[22:07:06] <jepler> 8488 distance computations instead of 8167
[22:08:46] <Lerneaen_Hydra> jepler: do you know if cradek left?
[22:08:59] <Lerneaen_Hydra> * Lerneaen_Hydra pokes cradek
[22:09:00] <jepler> Lerneaen_Hydra: no idea
[22:09:18] <Lerneaen_Hydra> ok
[22:10:00] <cradek> hi
[22:10:06] <Lerneaen_Hydra> hi
[22:10:36] <cradek> now I have more questions about radius comp
[22:10:42] <Lerneaen_Hydra> oh, ok. shoot
[22:11:04] <cradek> if I am turning (not boring) and I cut in +z, the comp is "right" but if I do the same cut in -z the comp is "left"
[22:11:20] <cradek> is this normal, or is there "outside" (turning) and "inside" (boring) comp?
[22:11:28] <Lerneaen_Hydra> what do you mean by "cut in z+"
[22:11:39] <cradek> from z0 to z1 for instance
[22:12:09] <Lerneaen_Hydra> uh, I'll do a quick image
[22:12:19] <cradek> heh
[22:12:48] <cradek> g41/42 are right/left now, I just wonder if lathes do the same thing
[22:13:06] <cradek> if so it seems strange
[22:16:42] <Lerneaen_Hydra> it's not the same
[22:16:47] <Lerneaen_Hydra> Im adding it to the wiki
[22:16:50] <cradek> ok
[22:19:00] <Lerneaen_Hydra> hmm, now I'm starting to become uncertain...
[22:19:11] <Lerneaen_Hydra> *thinks*
[22:19:33] <cradek> uh-oh
[22:24:12] <Lerneaen_Hydra> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Lathe_Advanced_Features
[22:24:14] <Lerneaen_Hydra> there
[22:24:20] <Lerneaen_Hydra> this is IIRC
[22:25:32] <cradek> oh good!! that's how it works
[22:25:38] <cradek> I think
[22:25:41] <cradek> haha
[22:25:57] <Lerneaen_Hydra> understandable?
[22:25:58] <cradek> ok I'm starting to think I can make it work
[22:26:03] <cradek> yes very clear with the picture
[22:26:04] <Lerneaen_Hydra> ooh, spiffy
[22:26:17] <Lerneaen_Hydra> yes I thought it would be easier to understand with it
[22:27:10] <Lerneaen_Hydra> heh, that page is starting to get a bit big. think that something should be done about it if it gets a lot bigger?
[22:27:50] <jepler> oh -- there was a bug in the "greedy" version as I rewrote it for my test program
[22:28:04] <jepler> now they give a much more similar number of output points
[22:28:14] <jepler> on "chips"
[22:28:16] <cradek> Lerneaen_Hydra: I'm not too worried about that
[22:28:24] <jepler> on my simple test, "douglas" now gives many fewer
[22:28:28] <Lerneaen_Hydra> jepler: what is this program you are talking about?
[22:28:36] <Lerneaen_Hydra> cradek: ok
[22:30:35] <jepler> Lerneaen_Hydra: when turning a continuous function (or even a discontinuous but high-resolution function) into a series of linear movements for machining, you have to chose which points on the function you'll touch
[22:30:58] <Lerneaen_Hydra> oh, becuase of accel/deccel?
[22:31:11] <Lerneaen_Hydra> oh, no, now I get it
[22:31:16] <Lerneaen_Hydra> can emc read in functions?
[22:31:48] <Lerneaen_Hydra> as in f(x)=sin(x) etc etc?
[22:31:50] <jepler> right
[22:32:09] <jepler> well
[22:32:21] <jepler> ignore that for now
[22:32:27] <Lerneaen_Hydra> haha
[22:33:23] <jepler> you want to mill some surface, and your g-code came from a very dumb program that outputs scans in X separated by .001 inch: "G0 X1.001 Z???" "G0 X1.002 Z???"
[22:34:00] <jepler> you want to simplify that path into a similar path, but without going more than .003 inches away from the original one
[22:34:09] <Lerneaen_Hydra> oh, ok. like a form/function that's not straight or circular
[22:34:16] <jepler> right
[22:34:17] <Lerneaen_Hydra> ooh, sounds nice
[22:34:28] <Lerneaen_Hydra> is it an external app or something in emc?
[22:34:50] <jepler> I've now implemented two different methods. One, which I call "greedy" is in emc2 HEAD and enabled when you program G64 Pnnn
[22:35:23] <Lerneaen_Hydra> oh, it stays within the g64 tolerance?
[22:35:49] <jepler> it works by moving to the first point specified, and then gathering up points. Each time, it checks the distance from the intermediate points to the next point. If it's over the tolerance, then it actually moves to the previous point (because that's within the P-distance) and starts over again
[22:36:20] <jepler> I call it "greedy" because it makes its decision about a point as soon as it gets it, this is a comp sci term that I may be slightly misusing
[22:36:57] <Lerneaen_Hydra> oh, that sounds like it could be very cpu intensive for small values of P
[22:37:40] <jepler> the other method is called "douglas" after the person who discovered it. It's recursive: start with all the points, then find the one that is farthest away from the line drawn from the first one to the last one. If it's further away than tolerance, then divide the problem in two, with the points on either "side" (before and after) the furthest-away one
[22:37:55] <jepler> if the point isn't further than tolerance, then you're done (with this portion of the problem, anyway)
[22:38:13] <Lerneaen_Hydra> oh, that sounds more efficient
[22:39:04] <jepler> it seems to depend on the data
[22:39:21] <jepler> for a simple function, greedy makes fewer comparisons and outputs more points
[22:39:56] <jepler> er, makes more comparisons and outputs more points
[22:40:07] <jepler> for 3d_chips, douglas makes more comparisons but outputs fewer points
[22:41:27] <Lerneaen_Hydra> oh, ok
[22:41:51] <jepler> it's not entirely clear why, but it seems like each one is better in some cases
[22:49:12] <Lerneaen_Hydra> cradek: I'm going to go soon, but was there anything else you were unsure of?
[22:50:10] <cradek> not yet
[22:50:15] <cradek> thanks again for all your help
[22:50:24] <Lerneaen_Hydra> sure, I'm glad to help
[22:50:30] <cradek> except for it working completely wrong, compensation in XZ is done :-)
[22:50:40] <Lerneaen_Hydra> woohoo! ;)
[22:50:51] <Lerneaen_Hydra> it shouldn't be that hard to adjust, right?
[22:50:58] <cradek> simple matter of programming
[22:55:07] <Lerneaen_Hydra> okay, goodnight then
[22:55:14] <cradek> goodnight
[23:53:30] <jmkasunich> evening folks
[23:57:00] <cradek> hi
[23:58:47] <jmkasunich> sounds like you and jeff are both quite busy
[23:59:14] <cradek> yeah I guess so
[23:59:29] <cradek> I took vacation and programmed most of today, which was nice
[23:59:35] <jmkasunich> heh
[23:59:48] <cradek> I have a lot of vacation to burn this month before it renews
[23:59:48] <jmkasunich> working vacation
