Back
[02:02:21] <cradek> [ 499.645461] timedelta: module license 'unspecified' taints kernel.
[02:53:51] <jmkasunich> didn't jeff write that one?
[02:54:04] <jmkasunich> if so, its just an oversight, easily fixed
[03:18:57] <jepler> fixed in rev 1.2.2.1 of timedelta.comp -- but not in 2.2.2
[03:24:20] <cradek> thanks
[16:29:56] <SWPLinux_> SWPLinux_ is now known as SWPLinux
[16:44:28] <cradek> I worry about G-X... I hope he can do this safely
[16:44:54] <SWPLinux> indeed
[16:44:58] <SWPLinux> that's a good point
[18:06:29] <jepler> cradek: speaking of which, do you think you could write a Python function that takes machine XYZUVWABC and returns the tooltip XYZ, roll, and pitch?
[18:07:28] <jepler> cradek: for a specific mill, that is
[18:07:45] <cradek> do you mean "you" (me) or "one"?
[18:08:12] <cradek> if you mean "me" then probably, if I knew what roll and pitch are
[18:08:14] <jepler> what I mean is that if I thought someone would give me that code, I'd try improving the preview to be more useful for 5-axis machining
[18:08:47] <jepler> well, two angles that give the orientation of the tool in a well-defined way
[18:08:55] <cradek> for max, I think it's virtually the same as the kins
[18:09:22] <cradek> B,C already are that, I think
[18:10:16] <cradek> let's go to lunch
[18:10:20] <jepler> yay lunch
[19:38:56] <alex_joni> it would be nice if TLO and tool diameter compensation, and tool were in UVW always
[19:39:11] <jepler> except for one detail
[19:39:16] <alex_joni> and canon/task/GUI would know where UVW is rotated translated (based on the machines XYZABC)
[19:39:25] <jepler> well, at least one detail
[19:39:26] <alex_joni> jepler: I know it can't work for the general case..
[19:39:38] <alex_joni> that's why I said it would be nice..
[19:39:58] <alex_joni> what detail did you have in mind?
[19:40:07] <jepler> the one I had in mind -- and I know chris has mentioned this before -- is that length compensation isn't applied until the axis it's applied to is moved again
[19:40:42] <jepler> introducing the requirement to move W in 3-axis programs would be .. weird
[19:41:02] <alex_joni> well.. W would move if any of XYZABC would be commanded to move
[19:41:17] <alex_joni> (I know at the moment the requirement is to command W to move..)
[19:42:03] <alex_joni> but it's probably a PITA to mix RT and non-RT code
[19:42:12] <cradek> imagine: go to top of travel, insert longer tool and activate length comp. now go to some XY, now go down to safety height, now cut
[19:42:33] <alex_joni> (kins is obviously RT, and the TLO and whatnot is not)
[19:42:36] <cradek> you can't apply the length comp on the XY move, because you'll go out of limits
[19:42:54] <alex_joni> cradek: then it's an program error :)
[19:42:59] <cradek> well, I suspect this is by far the usual case, actually
[19:43:50] <alex_joni> * alex_joni draws the same conclusion as last time
[19:44:18] <alex_joni> g-code is too strange to be used for a real robot
[19:44:37] <cradek> could be. I want to use it for real mills instead, where it's always used :-)
[19:44:53] <alex_joni> yes, it might just work for most of those ;P
[20:02:08] <jepler> in posemath, how do I rotate a point (PM_CARTESIAN) around an axis?
[20:05:40] <jepler> pmMatCartMult
[20:05:41] <jepler> aha
[20:05:58] <jepler> there doesn't seem to be a version of this in the C++ code
[23:35:08] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: show version number in title bar