Back
[00:51:20] <jmkasunich> on the axis/joints thing
[00:51:34] <jmkasunich> I'm opposed on principle to anything that pretends a joint is an axis
[00:51:49] <jmkasunich> that includes saying "if trivkins, then joint_0 = axis_X, etc
[00:53:34] <jmkasunich> joint to axis mappings should be explicit - either by the specific kins module, or for trivkins, somethin like [AXIS_X] JOINT_NUM = 0 [AXIS_Y] JOINT_NUM=2
[00:54:46] <jmkasunich> I'm also opposed in principle to having some kluge that says "if no joint sections, assume trivkins and pretend that AXIS sections are really joints
[00:55:09] <jmkasunich> at that rate, you'll NEVER get people converted to the correct form
[02:20:54] <jepler> cradek: do you want all constant-z for the tool comp torture test?
[02:22:48] <jepler> cradek: do you want changing feeds yet?
[02:25:50] <cradek> jepler: it should change Z sometimes since that is allowed. The feeds should change, and it should definitely use inverse time mode sometimes
[02:25:56] <jepler> cradek: OK
[02:26:04] <cradek> none of that will work yet of course
[02:27:10] <cradek> that one arc case is not even done - somehow the test program with the correctly compensated arc that I showed off earlier was a fluke! if I increase the radius it goes wrong.
[02:27:18] <jepler> drat
[02:27:28] <cradek> (I'm still not sure I'll actually be able to pull this off.)
[02:27:48] <cradek> I wonder if line-only would have any actual value, or if it would just confuse the issue.
[02:29:00] <cradek> I guess that's what I get for doing the easiest cases first
[02:31:08] <jepler> cradek: G0 moves?
[02:32:18] <cradek> good question. G0 is allowed with comp on, but it is treated specially
[02:32:41] <cradek> I'm afraid it's going to be hard to tell what behavior is right
[02:32:58] <cradek> unless the gcode "makes sense" (has some closed paths that seem like they could be part outlines)
[02:33:25] <jepler> yeah
[02:33:26] <cradek> maybe we should start with some 2.5D shapes made up of arcs and lines
[02:35:37] <cradek> maybe they could be a lot like the example I've been showing: a path that's taken as nominal, right, and left
[02:35:54] <cradek> sorry I hadn't really thought about what I actually want.
[02:41:00] <jepler> that's OK
[03:02:01] <SWPadnos> jmkasunich, I think we more or less agree on what to do for joints/axes
[03:03:05] <SWPadnos> I could be swayed, but I think if there are going to be ini file changes, let's just bite the bullet and convert, not do things the old way or the new, not with automagic "if we think it should be the simple way let's assume stuff"
[03:05:05] <jmkasunich> now we just need to convince alex
[03:05:08] <SWPadnos> heh
[03:05:41] <SWPadnos> I'm not sure where to put the mapping information
[03:05:54] <SWPadnos> oh - the way you had it was in the joint section
[03:06:35] <SWPadnos> hmmm. I think that would still require kins knowledge for the ini code - it has to know whether that should be ignored, which I think it should for a non-trivkins machine
[03:07:03] <jmkasunich> we can be sneaky
[03:07:12] <jmkasunich> crap, maybe we can't
[03:07:20] <SWPadnos> heh - I was going to ask in what way
[03:07:47] <jmkasunich> I was thinking the loadrt that loads the kins could pass the ini file data to trivkins as insmod params
[03:08:08] <SWPadnos> one of my design parameters is to have stupid init code. the less it knows about what's actually going on (and the less it has to do differently depending on that), the better
[03:08:31] <jmkasunich> but that loadrt isn't "loadrt trivkins <trivkins args>", it is "loadrt [KINS]KINSMODULE <can't really stick specific params here>"
[03:08:38] <SWPadnos> right
[03:08:45] <SWPadnos> no file access and all that jazz
[03:09:07] <jmkasunich> well, the code that does "loadrt kins" can do file access
[03:09:17] <SWPadnos> yes
[03:10:14] <jmkasunich> IOW, if I was writing my own hal file, I could write "loadrt mykins something=[KINS]SOME_MYKINS_PARAM1 something_else=[KINS]SOME_OTHER_MYKINS_PARAM"
[03:11:07] <SWPadnos> I'm not sure you could pass all that data to a module - I think you need floats and stuff
[03:11:08] <SWPadnos> for limits
[03:11:10] <jmkasunich> there MUST be some mechanism to convey kins-specific data to the kins code
[03:11:17] <SWPadnos> unless you've already converted to machine units there
[03:11:34] <jmkasunich> for hexapod kins, you have to send some geometry info, for scarakins you send arm lengths, etc
[03:11:59] <SWPadnos> there is, it's a question of defining it in the ini file, making it easy for the 94.5% of users that use trivkins, and (for me anyway) making the code as simple and unaware of what it's doing as possible
[03:12:02] <cradek> the kinses currently make hal params for that stuff
[03:12:23] <jmkasunich> oh, so you add setp lines after the loadrt kins line
[03:12:25] <SWPadnos> right - you have HAL params for some of it, it's the joints that have NML messages set up
[03:13:50] <jmkasunich> the more I think about the arbitrary mapping of axes to joints, the less simple it gets
[03:14:16] <jmkasunich> it is good for things like lathes - no more trying to trick the machine into skipping an axis
[03:14:28] <SWPadnos> yes, even if you don't allow for gantries by just having more than one [AXIS_N]JOINT=2
[03:14:48] <jmkasunich> gantries need their own kins, IMO
[03:14:53] <SWPadnos> so we have "trally trivial kins"
[03:15:01] <jmkasunich> XXY or anything like that is an abomination
[03:15:03] <SWPadnos> "mostly trivial kins" - like lathes or XYZB
[03:15:23] <SWPadnos> "not quite trivial kins" - like gantries (which can use nontrivkins)
[03:15:37] <SWPadnos> "really weird kins" like hexapods or cable-cams
[03:15:50] <SWPadnos> does that cover most of it?
[03:15:52] <jmkasunich> crap - I didn't want to get into this now
[03:16:00] <SWPadnos> oops - the first one was "really trivial kins"
[03:16:12] <jmkasunich> the cat finally jumped off my lap about 15 mins ago, and I started working on my part again
[03:16:17] <SWPadnos> ok - not a problem. I think we have a few weeks before a decision has to be made :)
[03:16:26] <SWPadnos> (or maybe months ;) )
[03:17:28] <jepler> cradek:
http://emergent.unpy.net/index.cgi-files/sandbox/comp_tort.py generates 25 short path fragments at different X, Y starting locations; each one is composed of a move to the fragment start; maybe turn on compensation (G41.1 with a specified D-number); then 4 moves, then G40 to turn off compensation, then a final move.
[03:17:49] <cradek> slick, thank you
[03:17:52] <cradek> I'll check it out tomorrow
[03:17:52] <jepler> many of the paths it generates are overlapping, but some may be useful in seeing what is going on
[03:18:11] <jepler> I'll add Z-changes, feed changes, and whatever else you want when that is useful to you
[03:18:14] <jepler> 'night
[03:18:18] <cradek> goodnight
[03:18:34] <jepler> each move may be an arc or a line
[03:18:49] <cradek> cool.
[03:34:26] <jmkasunich> cradek: "A positive Q value causes the leading edge of the tool to cut more heavily. Typical values are 29, 29.5 or 30."
[03:34:42] <jmkasunich> is this true for internal threads as well?
[03:36:40] <cradek> yes I think so; you should be able to easily see it in the preview to be sure
[03:37:17] <jmkasunich> yeah, that looks right
[03:37:20] <jmkasunich> something else isn't
[03:37:30] <jmkasunich> (probably my error, checking now)
[03:37:41] <cradek> huh, I don't think I've ever actually cut an inside thread with it
[03:37:50] <SWPadnos> heh
[03:38:34] <SWPadnos> for some reason, as soon as jmk asked the question, I was reminded of Martin Short in the movie "Merlin", piloting a boat and talking about "Treacherous waters, evil beasts" ... :)
[03:38:54] <jmkasunich> ah, I is offset from drive line, not absolute
[03:39:28] <jmkasunich> thats better, but there is still something fishy
[03:39:37] <jmkasunich> shouldn't all return moves be along the drive line?
[03:40:25] <cradek> I don't remember for sure. I think they're not, so entries are always the same length so it syncs
[03:40:46] <jmkasunich> but that means that the return moves get closer to the work
[03:41:04] <jmkasunich> in my case, the drive line was just a tiny distance from the inside thread peaks (not a lot of room to back off)
[03:41:12] <cradek> is it different from when you were doing external?
[03:41:14] <jmkasunich> so the later return moves will crash into the thread peaks
[03:41:20] <jmkasunich> I don't recall
[03:41:29] <cradek> oh really? that sounds bad
[03:41:33] <jmkasunich> I can change the sign of I and look a the preview
[03:41:59] <cradek> when I wrote that I worried about the "tight for space" problem
[03:42:23] <jmkasunich> external does the same thing
[03:42:31] <jmkasunich> but I gotta look closer
[03:42:45] <jmkasunich> it may be pulling out more in the early passes, so that it ends up at the drive line
[03:43:01] <jmkasunich> I'm gonna turn off tapered entry to make it easier to understand the preview
[03:43:09] <cradek> it might need a tweak...
[03:44:11] <cradek> falling asleep.... goodnight
[03:45:02] <jmkasunich> ok, it does respect the drive line - it won't cut into peaks
[03:45:21] <jmkasunich> but it does retract back behind the drive line in the early passes (so that the last pass will retract to the drive line)
[03:45:29] <jmkasunich> that could result in a rub on the inside of a small hole
[03:50:45] <jmkasunich> you get a better thread if you allow some accel distance before it starts cutting - velocity overshoot - really bad pitch error
[13:00:54] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/share/axis/tcl/axis.tcl: from TRUNK: didn't get entire keypad fix last time.
[13:02:08] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: new fix
[13:43:22] <jepler> it looks like adding the right compiler flag (-mtune=i686 or -Os are two candidates) would make doubles atomic in gcc-generated code
[13:44:23] <jepler> both probably have small effects on code speed -- since few if any people are actually running on pentiums or ppros, -mtune=i686 would probably increase the code speed a tiny bit.
[13:47:26] <jepler> userspace on dapper gets a default -mtune=pentium4, while the kernel is probably getting -mtune=pentium based on CONFIG_M586TSC=Y)
[16:02:41] <SWPadnos> although in practice using -mtune=i686 isn't a problem, it would make the design of EMC2/HAL reliant on that - ie, it changes the requirement from "any 486 or Pentium-class chip with a TSC" to "any PPro or P2"
[16:02:53] <SWPadnos> or later
[16:05:04] <alex_joni> PPro isn't 686 iirc
[16:05:32] <SWPadnos> ppro and p2 are basically the same thing
[16:05:47] <SWPadnos> the P2 was optimized to run 16-bit software better - the ppro sucked at that
[17:19:58] <skunkworks_> * skunkworks_ still has a pentium pro
[22:12:12] <jepler> hi guys. sorry that cvs is down -- there's a network problem. no eta to the fix.
[22:12:25] <alex_joni> no sweat from my end..
[22:12:46] <alex_joni> * alex_joni is having fun with lrm
[22:13:32] <SWPadnos> what is lrm anyway?
[22:13:43] <alex_joni> linux-restricted-modules
[22:13:44] <SWPadnos> or lum for that matter
[22:13:46] <SWPadnos> ah
[22:13:50] <alex_joni> linux-ubuntu-modules
[22:14:19] <SWPadnos> it's too bad - I downloaded the hardy beta CD, plus the ubuntu studio DVD for testing on my laptop
[22:14:34] <SWPadnos> the beta doesn't correctly enable the nvidia drivers, and there isn't any way I can see to enable them
[22:15:03] <SWPadnos> and the ubuntu studio boot menu option says "install ...", not "boot ...", so I didn't want to boot up (since I don't want to install it at the moment)
[22:19:12] <alex_joni> last time I tried it on a NVidia card, I had to enable the nonfree drivers from the menu somewhere
[22:19:23] <alex_joni> and it automatically downloaded and installed the lrm module
[22:19:28] <alex_joni> (that was on feisty I think)
[22:20:46] <SWPadnos> I was able to install using the restricted modules manager on Feisty, even when booted from the LiveCD
[22:21:18] <SWPadnos> in this case though, the restricted modules are shown as installed and up to date, but the restricted modules manager doesn't show any hardware that needs them - the window is empty
[22:22:22] <alex_joni> hmm.. can't check that here, cause I'm on i945 or whatever it's called
[22:22:34] <SWPadnos> heh - darned open-source drivers ;)
[22:24:29] <alex_joni> yeah, they happen to just work
[22:26:41] <SWPadnos> damn - that's the fastest response I've had from anyone about any purchase. ever
[22:26:59] <alex_joni> which one?
[22:27:07] <SWPadnos> I ordered some DVDs of the Zeitgeist Movie, but they were old ones without subtitles
[22:27:46] <SWPadnos> I emailed saying that, and one minute later (my mailbox check interval) I had a response "send me your address, I'll send you new ones"
[22:28:09] <alex_joni> nice
[22:28:22] <SWPadnos> yeah. so now I have 12 of them :)
[22:28:29] <SWPadnos> or I will soon
[22:29:23] <alex_joni> hmm, I noticed they made compiz crap out gracefully
[22:29:38] <alex_joni> you barely even notice when the window managers restarts
[22:30:00] <SWPadnos> it does "click" when you enable it, but then yes, it dies and says your hardware isn't useful (when the nvidia driver isn't present ...)
[22:32:11] <alex_joni> I meant that over here it mostly works
[22:32:23] <alex_joni> but once in a while it segfaults or whatever
[22:32:39] <alex_joni> I see the menus disappear for a couple of seconds, but then it's back
[22:32:49] <SWPadnos> interesting. my wife has been using it on 7.04 for a while, and it hasn't crapped out yet
[22:46:37] <jepler_> jepler_ is now known as jepler
[22:47:04] <jepler> cvs should be restored
[22:47:32] <jmkasunich> works from here
[22:47:51] <alex_joni> < 2h total
[22:59:02] <alex_joni> hmm.. crap having some issues compiling emc2 here
[22:59:16] <CIA-22> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: line->outside of arc, outside of arc->line
[22:59:57] <alex_joni> http://pastebin.ca/958819
[23:02:53] <alex_joni> I traced that to src/hal/classicladder/calc.c
[23:03:10] <alex_joni> disabling the RT build for CL gets the rest compiled just fine
[23:05:36] <cradek> wtf is that I wonder
[23:08:41] <alex_joni> hmm.. I also noticed 1-2 other strangenesses
[23:08:47] <alex_joni> I'm missing rtai_shm
[23:08:55] <alex_joni> let me rebuild the rtai package
[23:11:33] <alex_joni> jepler: I used your rtai source, but it seems it doesn't install symlinks
[23:23:43] <alex_joni> cradek: how can I search for files and symlinks using find?
[23:23:50] <alex_joni> find . -type f -type l ?
[23:25:34] <alex_joni> find . -type f -or -type l
[23:30:56] <alex_joni> well.. crap, still getting the same error for classicladder-RT as before
[23:32:27] <alex_joni> whine.. there's not tab completion for ./configure in hardy anymore
[23:35:48] <SWPadnos> you may need to source the completion script in /etc/somewhere