Back
[03:42:03] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[04:50:20] <jmkasunich> jepler: you around?
[04:50:23] <jmkasunich> feed per rev
[04:50:40] <jmkasunich> I believe that uses motion.spindle-speed-in
[04:50:47] <jmkasunich> is that supposed to be in RPM?
[04:53:21] <SWPadnos> it seems it should be the same units as the spindle speed output
[04:55:32] <jmkasunich> that would be RPM
[04:55:39] <jmkasunich> but it seems to be wrong on my machine
[04:55:47] <SWPadnos> hmmm
[04:55:59] <SWPadnos> does the nist-lathe config tell you anything?
[04:56:15] <SWPadnos> that should be the one that was used for all that lathe testing/demos
[04:56:26] <jmkasunich> right now its doing 176 RPM (and that is what I'm sending to motion.spindle-speed-in), but when I command a G95 move with F0.001, it moves a lot more than 0.176" in a minute
[04:57:10] <SWPadnos> does it seem to be 60x as far? ;)
[04:57:16] <SWPadnos> /fast
[04:57:29] <jmkasunich> could be
[04:57:40] <jmkasunich> I commanded a 1/2" move, and it was only a second or so
[04:57:45] <SWPadnos> then I'd say the input is in revs/second ;)
[04:59:31] <jmkasunich> nist-lathe isn't helpfull, that pin isn't hooked up
[04:59:39] <jmkasunich> cradek's lathe is what FPR was tested on
[04:59:53] <SWPadnos> oj, I thoought it was the loaner NIST lathe
[04:59:55] <SWPadnos> oh
[05:00:25] <jmkasunich> sim/lathe: net spindle-rps-filtered lowpass.0.out scale.0.in motion.spindle-speed-in
[05:00:29] <jmkasunich> so it is in RPS
[05:00:55] <jmkasunich> that is gonna annoy people who want to loop back spindle-speed-out to spindle-speed-in
[05:01:02] <SWPadnos> indeed
[05:01:02] <jmkasunich> but there must have been a good reason for it
[05:01:22] <SWPadnos> velocities in the motion controller are /second, not /minute
[05:01:28] <SWPadnos> so that would be easier
[05:01:31] <jmkasunich> yeah
[05:01:45] <jmkasunich> I just realized that its almost midnight and I'm still setting up to make this part
[05:01:57] <jmkasunich> I think I'll stick with conventional feeds and move on ;-)
[05:02:16] <SWPadnos> heh
[13:03:10] <jepler> jmkasunich: the output of "encoder" is going to be in rps with any natural setting of encoder.scale, but motion.spindle-speed-out was always in rpm
[13:03:22] <jepler> I probably should have changed spindle-speed-out to be rps but I didn't have the guts
[13:28:17] <fenn_> fenn_ is now known as fenn
[14:14:51] <cradek_> WOOWOOOOO! <- sound of oncoming trainwreck
[14:15:10] <cradek_> cradek_ is now known as cradek
[14:16:40] <SWPadnos> oooooh - a train!
[14:19:57] <skunkworks> * skunkworks likes trains
[14:20:31] <alex_joni> cradek: where's the train?
[14:23:12] <fenn> * fenn sets up a lawn chair next to the tracks
[14:24:55] <skunkworks> * skunkworks has cookies and coffee
[15:29:36] <cradek> yay, lerman bites the bullet for us
[15:30:18] <skunkworks> very nice.
[15:30:38] <skunkworks> * skunkworks hugs lerman
[15:31:41] <skunkworks> * skunkworks thinks he would be ok with that.
[15:44:58] <SWPadnos> hmmm - maybe I shouldn't have sent mine :)
[16:16:19] <skunkworks> bunch of emc fan-boys on the list now.. ;)
[16:16:35] <SWPadnos> luvvly
[16:25:53] <fenn> * fenn swoons
[16:34:36] <jepler> alex_joni: have you been building rt kernels on hardy alpha4 yet?
[16:35:35] <jepler> any idea when the post-alpha4 disc image is scheduled? I want to start playing with this, but won't realistically have time before the start of March
[16:36:35] <alex_joni> about the same here
[16:36:53] <alex_joni> jepler: I still ponder on a PC to use.. the one I have would be too slow
[16:37:18] <jepler> ah, I found dates for alphas 4 and 5 on the page HardyReleaseSchedule
[16:37:28] <jepler> er, 5 and 6 that is
[16:38:01] <jepler> Feb 27 and Mar 6, respectively
[17:02:23] <alex_joni> jepler: I was planning to have something set up by beta-1
[17:05:54] <jepler> alex_joni: I didn't see anything called "beta" on the schedule, just alphas 1 through 6..
[17:12:39] <SWPadnos> the beta release is supposed to be March 22 - it's just not pointed out in the last column
[17:12:47] <SWPadnos> on this page:
https://wiki.ubuntu.com/HardyReleaseSchedule
[17:12:53] <SWPadnos> err - March 20
[17:13:57] <jepler> ah ok
[17:15:30] <jepler> I know I don't get to set deadlines, but it would be great to have the EMC2 Hardy Live CD working well enough to hand out at the upcoming CNC Workshop in June
[17:15:36] <jepler> it also seems like a pretty doable goal
[17:15:44] <SWPadnos> I agree on all counts
[17:16:09] <SWPadnos> I'd like to have discs for the ESC presentation, but that's in late April so it's unlikely
[17:16:21] <SWPadnos> actually, it's impossible - nevermind
[17:16:30] <SWPadnos> the release is a week after the presentation ;)
[17:17:59] <fenn> better to distribute something older and well tested
[17:18:20] <SWPadnos> yeah. I'll probably mention that there'sa new release being worked on
[17:18:32] <SWPadnos> and not bother handing stuff out - they can download it if they want
[17:24:47] <alex_joni> jepler: given the fact that there's a 2.6.24 patch in volcano, I suspect it should be doable
[17:25:12] <alex_joni> but the RT kernel is basicly a coinflipping technology :)
[17:25:21] <alex_joni> sometimes it works great, sometimes not at all
[17:25:32] <cradek> very good news that there's the right patch
[17:25:45] <cradek> maybe if all of us try, one of us will get a working kernel
[17:25:57] <alex_joni> oh, I am sure I'll get a working kernel
[17:26:18] <alex_joni> the thing I'm worried about is getting a working kernel which works on a lot of machines :)
[17:26:37] <cradek> no kidding
[17:26:58] <alex_joni> nope :)
[17:28:32] <jepler> exactly
[17:29:30] <jepler> of course, with time and hardware marching on, we can just turn stuff like APIC on and tell people who can't run it to use dapper instead
[17:29:44] <jepler> (to name the thing besides 1GB RAM that I remember being the most trouble)
[17:31:07] <cradek> that's an interesting idea
[17:31:18] <alex_joni> jepler: I don't see why APIC would be different in 2.6.24
[17:31:34] <alex_joni> was there something on this which I missed?
[17:31:43] <cradek> I think jepler is saying we could build for smp
[17:32:11] <jepler> APIC, not ACPI. APIC is newer alternative to the old PIT timer
[17:32:13] <jepler> ooh lunchtime
[17:32:14] <jepler> bbl
[17:34:49] <alex_joni> oh, APIC
[17:34:55] <alex_joni> * alex_joni is dislexic
[19:38:43] <alex_joni> hello
[19:38:47] <acemi> hi
[19:39:05] <alex_joni> I'm having trouble deciding where to put the packages
[19:39:18] <alex_joni> would linuxcnc.org/experimental/lenny/ work for you?
[19:39:30] <acemi> yes, it's okay
[19:41:42] <alex_joni> acemi: ok, great.. will let you know when it's done :)
[19:42:08] <acemi> thanks
[19:47:10] <alex_joni> acemi: when you built the packages.. there should have been a couple more files
[19:47:29] <acemi> today
[19:47:30] <alex_joni> .dsc and .tar.gz for the sources
[19:48:33] <acemi> you means for rtai-xxx or for the kernel
[19:48:39] <alex_joni> rtai
[19:48:43] <alex_joni> I saw the kernel source
[19:49:01] <acemi> I don't create source for rtai
[19:49:24] <alex_joni> how did you make the package then?
[19:49:32] <alex_joni> I'm not talking about a source deb
[19:49:39] <acemi> make-kpkg ... module_image
[19:49:39] <alex_joni> the source in a tar.gz is enough
[19:51:21] <acemi> alex_joni: I don't understand what you mean. do you want a package sometinh like rtai-source
[19:51:33] <alex_joni> acemi: no
[19:51:49] <alex_joni> I want the rtai-x.y.tar.gz you used to create the deb
[19:52:02] <acemi> hmm ok
[19:52:20] <alex_joni> I think you used rtai-3.6.tar.bz2
[19:52:27] <alex_joni> (judging by the wiki page..)
[19:52:33] <cradek> if you do make-kpkg ... modules, instead of modules_image, you should get source pacakges too
[19:53:03] <acemi> alex_joni: wget --no-check-certif
https://www.rtai.org/RTAI/rtai-3.6.tar.bz2
[19:53:04] <cradek> oh wait I think I'm wrong
[19:53:12] <acemi> I use this tar.gz
[19:53:38] <alex_joni> cradek: I think it only creates a diff for stuff you changed from the original src
[19:54:13] <acemi> I created theese packages as described in
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI
[19:54:36] <acemi> module_image didn'T create a source package
[20:04:19] <alex_joni> doesn't python do garbage collection?
[20:06:16] <jepler> alex_joni: yes, python uses reference counting plus a cyclic garbage collector to reclaim memory used by unreachable objects.
[20:06:26] <jepler> why do you ask?
[20:07:04] <alex_joni> hmm.. seems odd python progs can have memory leaks..
[20:07:19] <alex_joni> do you have to specifically dealocate something so the garbage collector eats it?
[20:08:09] <jepler> When coding extensions for Python (e.g., in C or C++) you have to explicitly manage reference counts and for objects that can participate in cycles you must also write specific hooks for the cyclic garbage collector.
[20:09:56] <jepler> when writing Python code, you can't specifically free objects (you can only remove references to objects -- this is what the 'del' statement does; when an object becomes unreferenced, the implementation may free it)
[20:10:12] <jepler> so, why do you ask?
[20:10:22] <alex_joni> oh, was hanging around in #cia
[20:10:41] <alex_joni> and the guy working on cia is having some fun with python and memory leaks
[20:12:03] <SWPadnos> hmmm. this page defines U V W axes as parallel to X Y Z (not in rotated tool-space):
http://www.linuxcnc.org/handbook/gcode/g-code.html
[20:12:48] <jepler> don't believe everything you read :-P
[20:12:56] <SWPadnos> heh - well ok then
[20:13:03] <cradek> someone smart recently said that when the docs and the code disagree, the code wins
[20:13:16] <SWPadnos> Maxwell Smart?
[20:13:25] <alex_joni> I think it was jepler
[20:13:35] <alex_joni> Jeff Smart?
[20:13:36] <cradek> fwiw, the tool-space uvw is how I decided to write my kinematics. you can do whatever you like when you write yours
[20:14:01] <SWPadnos> I choose to complain about the current implementation instead ;)
[20:14:16] <SWPadnos> complain complain complain
[20:14:22] <SWPadnos> there, I'm done now
[20:14:22] <jepler> fwiw here's what the current docs say:
http://linuxcnc.org/docs/2.2/html/gcode_main.html#axes,%20secondary%20linear
[20:14:26] <jepler> The U, V, and W axes produce linear motion in three mutually orthogonal directions. Typically, X and U are parallel, Y and V are parallel, and Z and W are parallel.
[20:14:36] <cradek> I wasn't being a smartass, actually - there are 6 linear axes and 3 rotary - you really can do whatever you want
[20:14:38] <jepler> notice the weasel-word stuck in there :-P
[20:14:42] <SWPadnos> ooohhhh - clever wording there
[20:15:14] <SWPadnos> cradek, I understand - I just noticed that there was a definition somewhere - something we missed when we (i) looked for it before
[20:16:07] <jepler> there's, uh, probably not much value to the stuff under /handbook anymore
[20:16:14] <jepler> in fact I'm surprised it even mentions UVW
[20:16:59] <SWPadnos> "X, Y, and Z words will be accepted by the current (Jan, 2000) interpreter. NIST will soon release an expanded interpreter that will allow for three rotary axis A, B, C, as well."
[20:19:45] <jepler> yeah I can't wait for that to come out
[20:20:05] <SWPadnos> well, it's not like it's Duke Nukem Forever or anything
[20:25:45] <alex_joni> acemi: done.. please check the filenames
[20:25:50] <alex_joni> I had to manually rename them all
[20:26:01] <acemi> ok, thanks alex_joni
[20:26:35] <alex_joni> * alex_joni leaves for a while..
[20:29:34] <alex_joni> haha this is fun
[20:29:43] <alex_joni> df -h
[20:29:53] <alex_joni> 749G -8.0Z 1.1T 101% /home/.jared
[20:30:33] <alex_joni> total / used / free / percent used
[20:32:25] <alex_joni> bbl..
[20:36:51] <cradek> -8.0Z
[20:39:24] <alex_joni> heh, guess it doesn't support Yottabytes
[20:39:55] <alex_joni> 8Zetta's is still a *huge* load of data .. missing
[20:40:21] <alex_joni> 8 billion TB
[20:55:28] <jepler> -8.0 zettibytes seems is -2^63 1024-byte blocks i.e., the signed 64-bit number with all bits set
[20:55:32] <jepler> s/seems//