Back
[00:40:19] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[00:55:38] <jepler> cradek: for lathes, is it G43 that enables the X and Z offset from the tool table, and G41/G42 that enables radius compensation?
[00:55:41] <jepler> hi jmkasunich
[00:55:46] <jmkasunich> hi jeff
[00:58:18] <cradek> jepler: yes, it works just like a mill
[00:58:30] <jepler> what happens if the next move after G43 is an arc?
[00:58:42] <jepler> "it probably won't work"?
[00:58:46] <cradek> good question
[01:11:47] <cradek> I didn't try it, but I think the endpoint would be adjusted. If you consider that when you pick the center/radius, it would be fine
[01:29:26] <cradek> jepler: are you writing docs again?
[01:29:43] <jepler> cradek: yes
[01:30:30] <cradek> you're my hero
[01:30:45] <jepler> thanks
[02:40:55] <cradek> ha, the sample tool table in the spec has a '1/2" spot drill' with length of 173.740 units (inches?)
[12:50:19] <jepler> huh -- pwmgen doesn't have "offset"?
[12:51:00] <SWPadnos> hmmm
[12:51:09] <jepler> is this simply an oversight? I have an "offet" to pluto's pwm based on the canonical analog output spec
[12:51:17] <SWPadnos> scale / sum ...
[12:51:24] <SWPadnos> I guess it's an oversight then
[12:52:10] <SWPadnos> I guess it's a little different from standard analog anyway since there's a fixed maximum limit (100%)
[12:57:16] <jepler> I'm thinking of adding "G42 R-" and "G43 R-" to do compensation with dynamic tool radius
[12:58:25] <SWPadnos> I think that would be great
[12:58:44] <SWPadnos> but then again, I have no experience using G-code, so I could be missing something :)
[12:59:44] <SWPadnos> hmmm. there's a link to fix
[13:00:04] <SWPadnos> the wiki home page still points as unpy.net for the quick ref (which then points back at linuxcnc ...)
[13:00:15] <jepler> fix it then
[13:00:17] <jepler> stop your whining
[13:00:21] <jepler> coffee time here, bbl
[13:00:23] <SWPadnos> I am :P
[13:01:46] <SWPadnos> where is the source for that doc? there's a typo
[13:01:52] <SWPadnos> (the quick ref)
[13:02:58] <SWPadnos> ah - it's only in the PDF version - the HTML is correct
[14:02:55] <jepler> the PDF version was simply generated by doing a "print to file" from firefox, then running ps2pdf
[14:03:04] <jepler> it's never updated because there's not a convenient way to automate that process
[14:06:44] <jepler> cradek: any opinions on G42 R- / G43 R-? I think I have it ready to check in.
[14:07:48] <cradek> do you mean 41/42?
[14:08:14] <cradek> I think it's a great idea, and pretty safe since R is never sticky
[14:08:23] <jepler> umm sure
[14:08:42] <jepler> yes, 41/42
[14:09:05] <cradek> while we're at it, I'd like to do one more change to G43 - without an H word it defaults to the loaded tool
[14:09:18] <cradek> 41/42 do that, but 43 doesn't, which I think is strange
[14:09:29] <SWPadnos> I recall some discussions, but don't remember if we can't use L with G43 for length
[14:10:11] <jepler> for dynamic tool lengths, it's G43 I- L- or something like that
[14:10:16] <cradek> 43 uses I[J]K currently
[14:10:23] <SWPadnos> ah - right
[14:10:26] <jepler> right
[14:10:31] <jepler> bbl, work is calling
[14:11:57] <cradek> hm, the tool table uses diameters, using R for a diameter is going to be confusing, using radius when the tool table uses diameter is going to be confusing
[14:12:19] <cradek> brb
[14:20:21] <jepler> I could use a different letter
[14:20:32] <jepler> (I wrote it to take a radius in R-)
[14:24:52] <cradek> sadly I think it would be best to take diameter instead
[14:25:31] <jepler> I can accept that -- but what letter?
[14:26:11] <cradek> argh
[14:27:05] <cradek> G41.1 D-?
[14:27:11] <cradek> I dunno, this sucks
[14:27:22] <jepler> except that D's an integer now (I think)
[14:27:37] <cradek> yeah I'm sure it is
[14:27:55] <cradek> there's at least one letter that can be an integer or float - D could be that way too
[14:28:17] <cradek> maybe we should have G41.1 42.1 and 43.1
[14:29:14] <cradek> 43.1 I- [J-] K-
[14:30:00] <cradek> seems like they ought to work the same as much as possible
[14:30:42] <jepler> OK, I'll do it that way
[14:31:03] <cradek> don't take my word as gospel or anything - do you think it's any good?
[14:31:11] <cradek> I notice nobody else is chiming in
[14:31:27] <jepler> I had already proposed that G43.1 might be better than G43 H-1
[14:31:34] <cradek> that's true
[14:32:35] <cradek> what do you think about bare G43, should it work like bare 41/42
[14:33:46] <jepler> Is G43 without H an error now?
[14:33:50] <cradek> yes
[14:34:01] <jepler> sure, it makes sense but doesn't change the meaning of valid programs
[14:34:42] <cradek> wonder what tool change does to g43 now
[14:35:03] <cradek> it should probably set the new offset if you change wiht g43 in effect (if we allow g43 without H)
[14:36:04] <cradek> sorry I don't intend to shovel more onto your project, we can sure monkey with g43 later
[14:36:15] <jepler> #ifndef LATHE
[14:36:18] <jepler> huh I thought we got rid of these
[14:36:21] <cradek> me too
[14:36:29] <cradek> what is it?
[14:37:00] <jepler> in Interp::check_other_codes
[14:37:08] <jepler> #ifndef LATHE
[14:37:09] <jepler> ...
[14:37:14] <jepler> #else
[14:37:13] <jepler> CHK(((block->g_modes[1] > G_80) && (block->g_modes[1] < G_90)),
[14:37:13] <jepler> NCE_CANNED_CYCLES_NOT_SUPPORTED);
[14:37:29] <cradek> huh
[14:38:27] <cradek> I'm not sure they're not useful - for instance I can see using the peck drill cycle for parting
[14:38:43] <cradek> (not sure how serious I am about that)
[14:39:11] <jepler> we never define LATHE so they're always available
[14:39:23] <cradek> yeah
[14:40:38] <cradek> you could definitely use peck drilling with a tailstock
[14:40:51] <cradek> that's not even perverse
[14:41:12] <cradek> wonder if anyone has ever tried the cycles in other planes (I remember seeing there's code to handle it)
[14:48:43] <jepler> I also know there's code for it
[14:49:15] <cradek> strange, either g83 doesn't work, or I can't figure out how to use it
[14:53:44] <jepler> OK I think I just hit a proverbial brick wall
[14:54:18] <jepler> you're on a lathe. You use G42.1 D.01
[14:54:20] <cradek> uh-oh
[14:54:27] <jepler> what is the tool orientation?
[14:54:43] <cradek> hmm, good question
[14:55:25] <jepler> xtrans and ytrans refer to orientation and diameter from the tool table
[14:55:26] <jepler> int o = settings->tool_table[settings->tool_table_index].orientation;
[14:55:26] <jepler> double r = settings->tool_table[settings->tool_table_index].diameter / 2.0;
[14:55:42] <cradek> yeah
[14:56:04] <cradek> seems like you have to let that be specified too
[14:56:21] <cradek> if it's not, it defaults to 0, like a mill
[14:57:03] <jepler> any idea why xtrans and ztrans use settings->tool_table[].diameter / 2.0 instead of settings->cutter_comp_radius?
[14:58:07] <jepler> what letter do you want for tool orientation?
[14:58:21] <cradek> no, I don't remember
[14:58:26] <cradek> maybe just 'cause
[14:59:06] <cradek> L? E? one of the ints
[14:59:14] <jepler> I'll use L for now
[14:59:19] <cradek> ok
[15:03:14] <jepler> so you might write: G42.1 D.01 L3
[15:03:40] <cradek> looks great
[15:03:48] <jepler> let me see if all this compiles...
[15:03:54] <cradek> now you just have to fix up a dozen error detections...
[15:05:49] <jepler> yep
[15:09:44] <jepler> G410 requires D word to be a whole number
[15:09:48] <jepler> well I got something wrong...
[15:16:55] <cradek> yeah g83 is broken
[15:20:13] <cradek> ah, it's not seriously broken, it just has a bug
[15:20:57] <skunkworks> not fatal? just a flesh wound?
[15:21:02] <cradek> right
[15:21:24] <cradek> you can call it an F word
[15:21:32] <cradek> err, without an F word
[15:21:41] <cradek> and it runs with feed 0 (never going anywhere)
[15:54:22] <SWPadnos> so, I made the change to PWMgen - adding in an offset param
[15:54:52] <SWPadnos> I haven't committed it yet because I'm not sure if there's any unexpected interaction with min_dc
[15:55:44] <jepler> will the behavior be the same if offset=0?
[15:55:59] <jepler> if so, it's safe to commit for everyone who isn't using offset
[15:56:08] <SWPadnos> yes, it just subtracts offset from the pwm setting before going through all the other checks
[15:56:15] <jepler> I say check it in
[15:56:18] <SWPadnos> ok. will do
[15:56:35] <SWPadnos> I only have it in TRUNK - any thoughts about 2_1_branch?
[15:57:08] <jepler> start with TRUNK
[15:57:13] <jepler> it smells like a new feature to me
[15:57:31] <SWPadnos> yep
[16:26:28] <jepler> cradek: the docs say about G41/G42 "It is an error if ... the XY plane is not active"
[16:26:34] <jepler> cradek: is the limitation now to the XY or XZ plane?
[16:26:37] <jepler> YZ is not OK
[16:26:38] <jepler> ?
[16:26:51] <cradek> yes
[16:27:10] <cradek> well
[16:27:26] <cradek> err yes
[16:34:41] <SWPadnos> hmmm. I think it may be a bad idea to start working on computers just after you've been working on cars
[16:35:01] <SWPadnos> it makes it harder to judge how much torque you're putting on things
[16:35:20] <skunkworks> 'hand me the 13mm memory socket.'
[16:36:05] <skunkworks> I never put more screws in than I take out..
[16:36:12] <SWPadnos> how many foot-pounds to I tighten that memory to?
[16:36:16] <SWPadnos> s/to/do/
[18:09:51] <alex_joni> hi guys
[18:10:04] <alex_joni> SWPadnos: remind me .. what was your altium licence?
[18:11:48] <SWPadnos> err - full?
[18:12:06] <SWPadnos> or $12000
[18:14:29] <alex_joni> quite a bit :P
[18:14:35] <alex_joni> what machine do you run it on?
[18:14:56] <alex_joni> is this with the 9MP monitor?
[18:15:16] <SWPadnos> no - Windoes has issues with the 9MP monitor
[18:15:22] <alex_joni> ahh.. ok, too bad ;)
[18:15:43] <SWPadnos> I run it in this computer: an Athlon 1800 q/1.5G RAM and a Matrox Parhelia (3 monitors)
[18:15:50] <SWPadnos> s/q/w/
[18:16:17] <alex_joni> cool..
[18:16:24] <SWPadnos> I've gotten Wine installed on my dual Opteron machine, and I'll try it there at some point
[18:18:46] <alex_joni> what's the 9MP monitors resolution again?
[18:18:54] <SWPadnos> err - 9MP ;)
[18:19:05] <SWPadnos> 3840x2400, 204 DPI
[18:20:27] <alex_joni> nice :D
[18:20:42] <SWPadnos> yep. you should see Google maps with that
[18:20:51] <alex_joni> can you still see it?
[18:21:07] <SWPadnos> yeah, and you can read street names with a magnifying glass ;)
[18:21:20] <SWPadnos> but it's especially nice in hybrid or satellite mode
[18:21:59] <SWPadnos> the color is actually quite good. It's not up to par with the Eizo monitors or a Barco, but it's definitely on the high end
[18:24:20] <jepler> cradek: there's no fundamental reason that cutter radius compensation can't be extended to the remaining plane, is there?
[18:25:11] <SWPadnos> does it work in one vertical plane and not the other (now)?
[18:25:28] <jepler> SWPadnos: I think that's right -- since it can be used on lathes, and you're in the XZ plane there
[18:25:46] <jepler> the docs do say it's an error if plane is not XY though
[18:26:10] <SWPadnos> hmmm
[18:27:00] <SWPadnos> a lathe is only XZ by convention, the Y and Z are interchangeable since the part is rotating
[18:27:04] <SWPadnos> I don't know if that matters
[18:29:23] <cradek> jepler: well I think it's complicated. gene would want to cut an arc in XZ even though his tool is along Z. On a lathe the tool is "along" "Y" so it's all different
[18:43:29] <jepler> I tried to draw a picture and the only thing I saw is that you'd need to set something like a lathe tool orientation, so that the coordinates are for the tip of the tool and not somewhere up inside the tool
[18:43:52] <jepler> I also haven't figured out in what way the lathe tool is along "Y"
[18:44:09] <cradek> think of the radiused end of the tool as an end mill
[18:44:30] <cradek> the cutting occurs on the top edge of the circle
[18:44:38] <cradek> the pretend end mill is perp to XZ
[18:49:03] <jepler> maybe if I could see why trying to use XZ compensation mode on a mill would not work