Back
[06:23:47] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve2 3c885cf 06linuxcnc 10(15 files in 5 dirs) First part of limited jerk support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c885cf
[06:23:47] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve2 448e247 06linuxcnc 10src/emc/kinematics/tc.h 10src/emc/kinematics/tp.c Limited jerk support: implement the S-Curve Acceleration with FSM in trajectory planner * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=448e247
[06:23:47] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve2 3999dcc 06linuxcnc 10src/emc/task/emccanon.cc canon: calculate jerk for each move using per axis max values from inifile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3999dcc
[06:23:49] <KGB-linuxcnc> 03Michael Geszkiewicz 05araisrobo-scurve2 ddc3bbe 06linuxcnc 10configs/sim/axis/axis_mm.ini config: add jerk parameter to sim/axis_mm * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ddc3bbe
[06:24:03] <micges> skunkworks: ^^
[06:24:11] <skunkworks> ooh
[06:24:31] <micges> you can try it but only lines are working atm
[06:24:36] <skunkworks> ok
[06:25:59] <micges> skunkworks: and please not use any hardware atm :) I'll test it on small mill at end of week
[06:26:33] <micges> bbl
[06:27:21] <skunkworks> I won't.. :) I will just run it through my test configs that give max vel/acc
[06:27:55] <skunkworks> is there an example ini file?
[06:28:38] <skunkworks> ah - see it
[07:12:59] <skunkworks> pretty...
http://electronicsam.com/images/KandT/testing/jerk/Neat.png
[07:13:05] <skunkworks> but...
[07:13:18] <skunkworks> http://electronicsam.com/images/KandT/testing/jerk/DangerDanger.png
[07:13:45] <skunkworks> that is set to 20in/s^2 and 2.2in/s 200 jerk
[07:14:16] <skunkworks> Jogging doesn't do jerk limited moves..
[07:37:05] <mozmck> skunkworks: maybe it's because of the first line in your MDI history there in DangerDanger.png :)
[07:37:41] <skunkworks> heh
[07:37:49] <skunkworks> paste buffers are evil
[07:44:34] <skunkworks> seems to be a consistant failure mode?
[07:44:35] <skunkworks> http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2007:25:20.png
[07:48:50] <skunkworks> and the velocity redout never gets above to 1
[07:48:55] <skunkworks> readout
[07:50:48] <skunkworks> kinda looks like it is exact stopping
[07:52:48] <skunkworks> yes - it seems like the velocity goes to 0 at each end point
[07:53:32] <skunkworks> suprising how hard that is to see from the backplot
[08:07:03] <skunkworks_> yes - pretty sure it is stopping at every end point
http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2007:47:32.png
[08:08:28] <skunkworks_> ^that was also setting jerk from 200 to 1000
[08:13:39] <cradek> this looks similar to what I saw in 4/2012:
http://timeguy.com/cradek-files/emc/ja3-jerklimit2.png
[08:15:38] <cradek> my thoughts from that time:
http://thread.gmane.org/gmane.linux.distributions.emc.devel/6364/focus=6367
[08:22:27] <skunkworks_> wow - I am not even testing for jerk... (have to add that to the panel..)
[08:22:53] <skunkworks_> but there are sure acc violations as is.
[08:23:35] <cradek> micges: we found some problems in ja4 when there are nonconsecutive axes. I was unable to get it to even start up on a lathe config (two axes XZ, two joints) and sam's machine (XYZB) would start but would not run gcode, giving errors about A being out of limits
[08:28:32] <skunkworks_> it actually would be neet to see jerk with the current/new planner
[08:29:12] <cradek> yep, it would
[08:30:12] <skunkworks_> never thought of that.. (just another derivative.)
[08:30:36] <cradek> yeah
[08:30:47] <cradek> each one gets muuuuuch harder than the last
[08:35:13] <skunkworks> to constrain? I bet
[08:36:00] <skunkworks> there was only a few times when rob was re-writing the TP that the velocity was violated.. Lots of acc issues though..
[08:37:54] <cradek> the sonja planner uses sine profiles, so ALL further derivatives are automatically constrained
[08:46:43] <skunkworks> sonja?
[08:48:00] <skunkworks> ah - google found it
[09:13:03] <skunkworks_> a single move looks right...
[09:13:05] <skunkworks_> http://electronicsam.com/images/KandT/testing/jerk/Neat.png
[09:21:13] <cradek> cool
[09:39:51] <skunkworks_> but multible lines... not so much..
http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2009:20:45.png
[09:49:25] <pcw_home> is that going bad where it changes directions?
[09:54:42] <skunkworks> line end points it seems
[09:55:02] <pcw_home> is the exact stop mode?
[09:55:07] <pcw_home> is this
[09:55:29] <skunkworks> it seems to be - but shouldn't.. (I am running G64)
[09:55:43] <skunkworks> maybe blending is broken with s-curve
[09:55:51] <pcw_home> i wonder if exact stop mode woudl be any different
[09:55:56] <skunkworks> or I am doing something wrong
[09:56:05] <skunkworks> hmm
[09:56:10] <skunkworks> easy enough to test
[09:58:38] <skunkworks_> http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2009:39:29.png
[09:58:40] <skunkworks_> eh
[09:58:47] <skunkworks_> still not quite right..
[09:59:01] <skunkworks_> but uses full acceleration...
[09:59:24] <skunkworks_> (like the current planner in exact stop mode)
[10:04:21] <pcw_home> looks like a math error followed by forcing the endpoint to be correct
[10:04:47] <skunkworks> I think very similar to what cradek was seeing a while ago
[10:06:19] <pcw_home> Ahh the velocity is offset up a bit
[10:08:20] <pcw_home> so it comes to s stop but the beginning of the next segment starts off the wrong way?
[10:09:53] <skunkworks> odd
[10:11:13] <pcw_home> assuming the red dotted line is 0 velocity
[10:13:51] <jepler> no, that's the trigger line
[10:14:05] <skunkworks_> zero is below that
[10:14:06] <jepler> the red baseline of velocity is probably the same as the other baselines; you end up seeing the green one because it's drawn last
[10:21:08] <micges> skunkworks: cradek: thanks for feedback
[10:22:49] <micges> cradek: I'll look into ja4 in a moment
[10:22:52] <pcw_home> looks like accel and velocity dont get to 0 at the same time
[10:23:34] <micges> yeah but apparently on higher jerk values only
[10:23:36] <cradek> satisfying the final condition of jerk=accel=vel=0 and position=desired is what makes it all hard
[10:23:48] <pcw_home> Sure
[10:25:28] <skunkworks_> http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2010:00:27.png
[10:25:45] <skunkworks_> micges: I see it with low jerk limits also
[10:25:58] <skunkworks_> micges: is blending supposed to work?
[10:26:50] <micges-dev> I didn't touched it but I think it's disabled
[10:34:13] <micges-dev> skunkworks_: spike was on any specific gcode?
[10:36:40] <skunkworks_> You can really see it running 3d_chips.. I could strip out a section of gcode..
[10:39:48] <micges-dev> ok
[10:40:33] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc4 c0e447c 06linuxcnc 10src/emc/tp/tp.c 10tests/trajectory-planner/circular-arcs/nc_files/spindle/g33_simple.ngc Fix for F-word limit in position sync * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c0e447c
[10:41:50] <Tom_itx> what happened to rob's TP? are you going with another version now?
[10:46:51] <skunkworks_> speak of the devil?
[10:46:54] <skunkworks_> :)
[10:47:00] <skunkworks_> 3d chips - with jerk set to 1000 (and even 200...) violates acc all over
[10:47:02] <Tom_itx> devel
[10:47:19] <Tom_itx> skunkworks, are you working with a different TP now instead of robs?
[10:47:36] <skunkworks_> http://electronicsam.com/images/KandT/testing/jerk/Screenshot%20from%202014-06-11%2010:22:25.png
[10:48:07] <skunkworks_> micges-dev: ^ you can see all the spikes - should be less than 20in/s^2
[10:48:26] <skunkworks_> most are over 50
[10:48:53] <skunkworks_> Tom_itx: just playing around with s-curve acc that micges has been working on
[10:49:25] <skunkworks_> robs planner in its current state is pretty darn solid. We ran it on the K&T this weekend - pretty cool.
[10:49:37] <Tom_itx> good to hear
[10:49:49] <skunkworks_> we found a little bug with threading - he just posted a fix :)
[10:50:54] <skunkworks_> could feel it in the floor...
[10:51:10] <skunkworks_> (partly because of the .0003" backlash in z)
[10:51:14] <Tom_itx> good it wasn't a big bug then :)
[10:52:07] <skunkworks_> well - you could work around it.. (setting the feed to something very high during spindle synced motion
[10:52:48] <KGB-linuxcnc> 05dgarr/separate-touchoff-buttons 5267409 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5267409
[10:53:30] <KGB-linuxcnc> 03Chris Radek 05master 7897231 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7897231
[10:53:30] <KGB-linuxcnc> 03Dewey Garrett 05master 752d6a0 06linuxcnc 10share/axis/tcl/axis.tcl 10src/emc/usr_intf/axis/scripts/axis.py axis: separate buttons for system, tool touchoff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=752d6a0
[10:53:30] <KGB-linuxcnc> 03Chris Radek 05master 43e5cbe 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py Remove the error-prone way of doing tool touch off * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43e5cbe
[10:53:32] <KGB-linuxcnc> 03Chris Radek 05master 5dea513 06linuxcnc 10share/axis/tcl/axis.tcl 10src/emc/usr_intf/axis/scripts/axis.py Add keyboard shortcut, tooltip, and quickref documentation for tool touchoff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5dea513
[10:59:19] <CaptHindsight> is the new planner just in master?
[10:59:31] <skunkworks_> not quite yet...
[11:01:11] <CaptHindsight> is this the best way to change linuxcnc repos? apt-get remove --purge linuxcnc then modify the /etc/apt/sources.list.d/linuxcnc-buildbot.list ?
[11:01:21] <skunkworks_> hoping to put ja4 and the new planner together - but ja4 has a few issues.
[11:03:10] <skunkworks_> I don't know
[11:03:29] <CaptHindsight> don't want to wreck a current install :)
[11:03:54] <skunkworks_> rip?
[11:04:15] <CaptHindsight> oh i have one in virtualbox for this very reason, nevermind
[11:07:57] <seb_kuzminsky> CaptHindsight: if you want to change where your debs come from, the recipe you posted is right
[11:10:19] <CaptHindsight> I have everything behaving pretty well in Precise with Unity including the touchscreen, now to try getting multitouch going
[11:12:15] <CaptHindsight> 14.04 has smoother touch operation
[11:12:55] <CaptHindsight> what does linuxcnc need to work in 14,04? I heard there was some Tcl changes needed
[11:13:09] <cradek> CaptHindsight: do you get an error?
[11:14:08] <CaptHindsight> I haven't tried to install Linuxcnc it on 14.04 yet, only got as far as the 3.4.55 RTAI kernel that work fine
[11:14:19] <micges-dev> skunkworks_: ok I got spikes also
[11:15:21] <CaptHindsight> brb, can't spell/write coherently yet today, more caffeine required
[11:17:05] <seb_kuzminsky> CaptHindsight: i think if the 3.4.55 rtai kernel works with Trusty, linuxcnc should run fine there
[11:17:47] <seb_kuzminsky> we don't yet have a Trusty buildslave, so it's not getting tested except when humans try it, so my confidence that there are 0 bugs/quirks is low
[11:18:36] <CaptHindsight> I just want to try and get a physical keyboard and mouse free system running
[11:21:10] <CaptHindsight> new 19-23" cap touch LCD's are starting <$200 now
[11:28:39] <CaptHindsight> unfortunately all the touchscreen support or screen keyboards in Debian, Mint or non-Unity Ubuntu doesn't work nearly as well as in Unity :(
[11:45:11] <skunkworks_> rtai works with 14.04? I should try
[11:52:03] <CaptHindsight> no crashes or panics
[11:52:18] <CaptHindsight> didn't have linuxcnc to test on it
[11:52:40] <seb_kuzminsky> does 14.04 ship with linux 3.13 normally?
[11:53:41] <pcw_home> I think so (it is new enough to support Baytrail so thats 3.12 or > )
[11:54:22] <seb_kuzminsky> the newest kernel that rtai supports is 3.10
[11:54:55] <CaptHindsight> almost supports
[11:56:49] <seb_kuzminsky> hmm
[11:56:53] <CaptHindsight> the scheduler in RTAI is still broken
[11:57:11] <seb_kuzminsky> i guess what i meant was, the newest kernel that shabby's rtai repo has a kernel patch for is 3.10 ;-)
[11:57:17] <CaptHindsight> memleak just checked the other day
[11:58:07] <CaptHindsight> and I don't think that 3.10 is stable
[11:58:23] <CaptHindsight> coin toss
[11:59:33] <CaptHindsight> shabby refactored the tree as well and lost the history
[12:00:35] <CaptHindsight> so the 3.4.55 RTAI is the latest stable and memleak can't reproduce it
[12:01:34] <CaptHindsight> so preempt_rt or xenomai for the time being until this all gets sorted out
[12:01:50] <CaptHindsight> for anything above 3.4
[12:02:31] <seb_kuzminsky> how about the 3.4.87 patch that's in shabby's repo? is that good? or do i need to fall back to the 3.4.55 patch (that's no longer in shabby's master)?
[12:02:53] <CaptHindsight> I'll ask him later to be sure
[12:04:28] <seb_kuzminsky> thx
[12:34:56] <CaptHindsight> seb_kuzminsky: memleak says: all the RTAI kernel patches are fine, but all the RTAI source is broken for the things that go into /user/realtime
[12:37:27] <CaptHindsight> Linuxcnc is stuck at 3.4, 3.5 and 3.8.13 until /proc changes are made in linuxcnc, but user space will still be broken
[12:38:32] <seb_kuzminsky> hmm, ok thanks
[12:41:38] <CaptHindsight> the RTAI scheduler is broken, but one trivial fix is in isocpu you need to leave the last cpu core out of the list
[12:42:49] <CaptHindsight> for example isolcpus=1,2,3 for a 4 core and it should work or a single core cpu should work fine
[12:43:29] <seb_kuzminsky> ok, i'll keep an eye out for that
[12:43:47] <CaptHindsight> but latency is still higher than it used to be
[12:44:09] <seb_kuzminsky> i think cpus are numbered from 0, so isolcpus=1,2,3 omits the first (cpu 0) not the last (cpu 3)
[12:47:07] <CaptHindsight> seb_kuzminsky:
https://github.com/ShabbyX/RTAI/tree/linuxcnc-old this might be the only working RTAI branch, and it might be the same tree you used for the RTAI debs
[12:49:41] <seb_kuzminsky> my old rtai debs are of RTAI commit a0dc5355ee233032926dd23d1e132ef1befbbd76, which is only in a branch called "old-master"
[12:52:24] <CaptHindsight> the problem with "old-master" is that it's actually not the old master, Shabbyx refactored it and lost the original "old-master"
[12:56:12] <CaptHindsight> seb_kuzminsky: are you using that specific commit?
[12:56:41] <CaptHindsight> if that is the same then it's not lost
[13:00:38] <CaptHindsight> Linuxcnc needs to fix /proc in order for any 3.10 or newer RTAI kernels to work
[13:01:59] <CaptHindsight> all the new RTAI rewritten math support doesn't work with Linuxcnc
[13:03:57] <CaptHindsight> Kconfig for RTAI has new math options, which are incompatible with Linuxcnc (uclibc, newlib and glibc options)
[13:04:15] <CaptHindsight> none work with linuxcnc
[13:06:08] <CaptHindsight> that's the latest RTAI news for today, good day!
[13:17:48] <skunkworks> minor details...
[13:17:53] <skunkworks> smop!
[13:36:21] <skunkworks> logger[psha],
[13:36:21] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-06-11.html
[14:09:20] <cradek> jepler: did you keep track of the pickconfig dancing fix?
[14:13:33] <skunkworks_> cradek: testing in sim - threading seems to work
[14:13:48] <cradek> yay!
[14:14:06] <seb_kuzminsky> thanks for the update CaptHindsight
[14:15:37] <seb_kuzminsky> should we ban aram from emc-users? this is getting ridiculous
[14:16:16] <cradek> nahhh
[14:16:24] <cradek> it'll solve itself
[14:21:39] <cradek> he's just whining now. if people would stop responding, the thread would stop.
[14:22:27] <archivist> has he got the record for number of emails in a thread
[14:22:48] <cradek> that's a little hard to figure out
[14:22:53] <cradek> frankly I doubt it :-)
[14:23:44] <cradek> I feel bad for the people who genuinely try to help him
[14:24:35] <seb_kuzminsky> yeah, the sink of peoples' helpfulness-effort is the tragic part here
[14:28:26] <skunkworks_> cradek: how hard would it be to put cab4 in master without ja4 - then ja4 on top when it is better
[14:29:58] <cradek> it would be a little extra work to do them separately, but mostly the work I did modifying ja4 to work on top of cba4 is already done and could still be used later
[14:30:16] <skunkworks_> I don't see the pause in sim that we may have been seeing on the emco (stopping and starting the spindle)
[14:30:17] <cradek> if I had put them in the other order, it would have been worse, so yay me
[14:30:35] <skunkworks_> heh
[14:30:37] <cradek> yeah I suspect that was a problem with the interpolated software encoder thing
[14:30:44] <skunkworks_> oh - that could be
[14:30:56] <cradek> I don't trust that yet, having never messed with it
[14:30:58] <seb_kuzminsky> yay for git and stacked feature branches
[14:31:09] <skunkworks_> does interpolated maybe need the index?
[14:31:10] <seb_kuzminsky> (and cradek's foresight)
[14:31:38] <cradek> should I put cba4 on master now/soon?
[14:31:44] <skunkworks_> I could see random pauses then depending on how far away the index was...
[14:32:18] * skunkworks_ says very very quietly.... 'yes'
[14:32:20] <cradek> skunkworks_: interpolated does still use the index. I think the basic setup is to hook your sensor to both A and Z.
[14:32:35] <archivist> interpolated always gives me the jitters because it cannot follow a speed change till the next edge
[14:32:57] <skunkworks_> I was using it even though I have 100 count single channel encoder...
[14:33:09] <skunkworks_> I should just try it without it
[14:33:20] <cradek> yeah I bet it works better without
[14:33:26] <cradek> you have 100 counts and index?
[14:33:29] <skunkworks_> yes
[14:33:36] <skunkworks_> remember turning the spindle by hand?
[14:33:37] <cradek> that'll work perfectly great
[14:33:41] <cradek> right
[15:18:54] <cradek> hm, having some trouble rebasing cba4 onto today's master, because of the rapid-override changes
[15:19:11] <cradek> the velocity during the blend arc seems wrong, so I am missing something
[16:07:53] <cradek> woo
[16:10:27] <KGB-linuxcnc> 03Chris Radek 05cradek/cba5 d699a06 06linuxcnc New branch with 414 commits pushed, 10161 files changed, 03224008(+), 043400(-) since master/5dea513
[16:11:40] <cradek> skunkworks_: this is an updated version of cba4 on top of current master (rapid override support is the important change)
[16:12:19] <cradek> the sooner we merge cba the sooner I can stop doing these :-P
[16:12:23] <skunkworks_> heh
[16:12:40] <seb_kuzminsky> heh
[16:12:41] <skunkworks_> I will run it through the motions
[16:12:48] <cradek> this has RE's latest fix for spindle-sync
[16:13:08] <cradek> thanks! please do test the overrides too.
[16:13:13] <cradek> I sure appreciate you.
[16:13:14] <seb_kuzminsky> are there any known bugs with cba5?
[16:13:24] <cradek> seb_kuzminsky: it's only existed for 3 minutes
[16:13:29] <skunkworks_> not at the moment...
[16:13:30] <seb_kuzminsky> well yes but
[16:13:35] <cradek> I don't know of any remaining bugs on cba4
[16:13:38] <seb_kuzminsky> are there any known bugs with cba4, how about that?
[16:13:42] <seb_kuzminsky> great!
[16:13:51] <cradek> we just found the one, and he already fixed it
[16:14:22] <jepler> >> checking libgl1-mesa-dri workaround... test for libgl1-mesa-dri workaround failed, please file a bug
[16:14:35] <jepler> this can fail ^^ when $TMPDIR does not allow executable files
[16:14:41] <jepler> this will apparently become a common hardening thing
[16:14:49] <cradek> ugh
[16:14:49] <seb_kuzminsky> https://www.youtube.com/watch?v=vCadcBR95oU
[16:15:11] <jepler> > checking libgl1-mesa-dri workaround... required - need to preload make[1]: Entering directory `/tmp/tmp.y1MRHAMotO'
[16:15:24] <jepler> apparently any output at all from the script screws everything up.
[16:15:25] <jepler> grgrgnr
[16:15:33] <jepler> why couldn't this be written as an actual configure test anyway?
[16:15:37] <seb_kuzminsky> jepler: which platform are you on?
[16:15:45] <jepler> seb_kuzminsky: debian 7, but with TMPDIR=/dev/shm
[16:15:52] <seb_kuzminsky> huh
[16:15:59] <cradek> doctor, doctor!
[16:16:57] <cradek> (is that test still needed?)
[16:17:09] <jepler> I don't recall which platforms required the workaround
[16:18:26] <skunkworks_> is seb saying 'push it' :)
[16:19:14] <cradek> skunkworks_: if you find I didn't screw it up between cba4 and cba5, I think we should do it
[16:20:49] <cradek> then I think I can rebase the appropriate parts of ja4-onto-cba4 atop the brave-new-world-master
[16:22:12] <jepler> as for the "linuxcnc status keeps scrolling" bug, so far I think I see that it *does not occur* when no logical line of text is split over fewer than 3 lines
[16:22:25] <cradek> whoah
[16:22:28] <jepler> I suspect it's a tkinter regression, though it could be that bumping the number of analog ins/outs contributed to it
[16:22:41] <cradek> does that mean making the window wider fixes it?
[16:22:47] <jepler> but so far, if I size my window wide enough that ain and aout only occupy two lines each, I don't see the scrolling behavior
[16:23:11] <cradek> fwiw, I've seen the behavior for years
[16:23:23] <cradek> possibly, years and years
[16:23:23] <jepler> huh
[16:23:26] <jepler> I didn't remember ever seeing it
[16:23:40] <cradek> maybe mwm window decorations cause it
[16:23:57] <cradek> or focus-follows-mouse
[16:24:39] <cradek> seb_kuzminsky: would you please use words instead of youtube links to express your feelings about cba5?
[16:25:46] <jepler> on the other hand, when I only reposition but do not change the text contents, it doesn't walk away
[16:31:12] <seb_kuzminsky> sure
[16:31:13] <seb_kuzminsky> push it
[16:31:15] <seb_kuzminsky> ;-)
[16:34:19] <CaptHindsight> looking for planner testers on actual hardware yet?
[16:34:35] <cradek> by all means, have at it
[16:34:49] <CaptHindsight> I saw skunkworks_ trainer video
[16:43:01] <skunkworks_> ran it on the k&t this weekend also
[16:45:48] <skunkworks_> real 4m25.322s
[16:45:50] <skunkworks_> user 21m3.469s
[16:45:51] <skunkworks_> sys 3m5.403s
[16:46:11] <seb_kuzminsky> you dont say
[16:46:29] <skunkworks_> make'ing cba5
[16:46:48] <seb_kuzminsky> ah
[16:46:54] <skunkworks_> on my ancient i7
[16:47:15] <jepler> http://emergent.unpythonic.net/files/sandbox/0002-linuxcnctop-fix-the-crawling-scrollbar-in-many-cases.patch
[16:47:18] <jepler> cradek: ^^^ if you wanna test
[16:47:22] <jepler> are i7s old enough to be ancient
[16:47:23] <jepler> ?
[16:47:35] <seb_kuzminsky> time flies i guess
[16:48:52] <skunkworks_> I bought it as a referb in 2010..
[16:49:26] <skunkworks_> in 2010 it took less than 1 minute...
[16:49:30] <skunkworks_> to compile
[16:50:25] <seb_kuzminsky> there's a huge increase in resources-needed-to-build between 2.5 and 2.6/master, due to the python interpreter mostly i think
[16:54:54] <jepler> yeah, boost::python is a resource hog
[16:55:06] <jepler> I am quite confident I was right not to choose it when I wanted to expose NML to Python
[16:55:46] <jepler> oh well, I don't suppose we're likely to ditch it as a prereq now
[16:57:10] <skunkworks_> cradek: inital testing looks good
[16:57:14] <skunkworks_> initial
[17:01:47] <skunkworks_> does this help? sort of a copy and paste from robs posts on the forum
http://pastebin.ca/2765738
[17:05:11] <cradek> skunkworks_: it could help in picking the appropriate default settings. maybe some of it should be added to the docs too.
[17:07:06] <cradek> jepler: that patch fixes it for me
[17:17:24] <skunkworks_> cradek: that is what I was hoping
[17:17:32] <skunkworks_> but I don't edit very well
[18:06:42] <KGB-linuxcnc> 03Jeff Epler 05v2.5_branch da8f301 06linuxcnc 10src/emc/usr_intf/axis/scripts/linuxcnctop.py linuxcnctop: fix the crawling scrollbar in many cases * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=da8f301
[18:15:26] <KGB-linuxcnc> 03Chris Radek 052.6 f639c08 06linuxcnc 10src/emc/usr_intf/axis/scripts/linuxcnctop.py Merge branch 'v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f639c08
[18:15:26] <KGB-linuxcnc> 03Jeff Epler 052.6 004e784 06linuxcnc 10tcl/bin/pickconfig.tcl pickconfig: speed automatic closing of other branches * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=004e784
[18:15:32] <cradek> wfm...
[18:33:01] <skunkworks_> ?
[18:33:55] <cradek> the last one fixes the thing where after pickconfig starts, it changes stuff around for a second or two
[18:41:31] <skunkworks_> nice!
[18:41:41] <skunkworks_> now you have to merge again?
[18:42:55] <skunkworks_> cradek: everythng looks good.. I will run some programs overnight - but I think I would have seen something by now
[18:48:47] <cradek> I just went over my changes again very carefully - I am sure cba4->cba5 is right
[18:48:56] <cradek> let's go for it
[18:53:23] <cradek> running the tests once more...
[19:03:22] <cradek> Runtest: 140 tests run, 140 successful, 0 failed + 0 expected
[19:03:31] <KGB-linuxcnc> 05cradek/cba5 d699a06 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d699a06
[19:13:56] <KGB-linuxcnc> 03Chris Radek 05master d699a06 06linuxcnc 414 commits pushed, 10161 files changed, 03224008(+), 043400(-)
[19:14:08] <cradek> !!
[19:15:21] <mozmck> that generated some commit emails!
[19:16:47] <CaptHindsight> I just installed the 3.4.55 RTAI in Ubuntu 14.04 again and it works
[19:41:40] <skunkworks_> Yay!!!!!
[19:41:47] <skunkworks_> Thanks!
[19:56:26] <seb_kuzminsky> wowness all around!
[20:00:47] <cradek> wish Rob E was here
[20:02:00] <cradek> it'll be a while 'til buildbot gets to it...
[20:04:17] <seb_kuzminsky> we should make an announcement on emc-users
[20:04:48] <cradek> that's a good idea, thanks for volunteering!
[20:04:52] <seb_kuzminsky> haha
[20:05:07] <seb_kuzminsky> i'll ask robert ellenberg if he wants to do it
[20:05:33] <cradek> even better
[20:19:24] <seb_kuzminsky> rob ellenberg replies: "please make the announcement, i'm busy"
[20:25:50] <seb_kuzminsky> who should get props? robert ellenberg and sam sokolik, obvs, who else?
[22:16:26] <skunkworks_> Yay!! again!
[22:18:10] <cradek> yay no more 400 step rebases, yayyy
[22:19:53] <cradek> thanks for putting it on the forum
[22:23:13] <KGB-linuxcnc> 03Chris Radek 05master 5c96888 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c96888
[22:24:36] <cradek> and with that, goodnight!
[22:25:24] <skunkworks_> night!
[23:10:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 142da1e 06linuxcnc 10VERSION 10debian/changelog Update changelog & VERSION for 2.6.0~pre4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=142da1e
[23:10:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 5409dec 06linuxcnc 03v2.6.0-pre4 LinuxCNC v2.6.0-pre4 (tagged commit: 142da1e) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5409dec
