Back
[00:05:20] <KGB-linuxcnc> 03seb 05master 2c5fe74 06linuxcnc 10debian/configure * deb: don't build-depend on texlive's german and polish localizations
[00:05:50] <KGB-linuxcnc> 03TODO: deletor 05build-deb-without-de-pl 2c5fe74 06linuxcnc 04. * branch deleted
[00:27:24] <KGB-linuxcnc> 03seb 05v2.5_branch 5645d04 06linuxcnc 10docs/src/gcode/m-code.txt * docs: fix handling of the old tool in the M6 description
[00:27:25] <KGB-linuxcnc> 03seb 05v2.5_branch dea503a 06linuxcnc 10docs/src/gcode/m-code.txt * docs: remove incorrect T-word info in M6 description
[00:31:54] <KGB-linuxcnc> 03seb 05v2.5_branch b2edb8a 06linuxcnc 10docs/src/gcode/overview.txt * docs: clarify numbered parameters
[02:12:10] <KGB-linuxcnc> 03seb 05v2.5_branch f0294e5 06linuxcnc 10src/emc/task/emccanon.cc * canon: fix some comments
[02:12:10] <KGB-linuxcnc> 03seb 05v2.5_branch 5f7693a 06linuxcnc 10src/emc/task/emccanon.cc * canon: rename a CHANGE_TOOL_NUMBER() argument for clarity
[02:13:00] <KGB-linuxcnc> 03seb 05m61-fix de4d0a7 06linuxcnc 10src/emc/iotask/ioControl.cc * io: fix a tool number/pocket number bug in EMC_TOOL_SET_NUMBER (M61)
[02:13:00] <KGB-linuxcnc> 03seb 05m61-fix 3b9f5b8 06linuxcnc 10src/emc/iotask/ioControl.cc * io: better debug message
[02:13:03] <KGB-linuxcnc> 03seb 05m61-fix bfe54f9 06linuxcnc 10src/emc/iotask/ioControl.cc * io: update the spindle "pocket" on M61
[02:13:09] <KGB-linuxcnc> 03seb 05m61-fix 44041e2 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc * interp: fix M61
[07:33:59] <jepler> seb_kuzminsky: part of the m61 bug says it's specific to axis. do you see that yourself? I notice your fix doesn't touch UIs
[07:34:20] <jepler> seems like one could write a test for this issue..
[07:48:36] <skunkworks> logger[mah],
[07:48:37] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-08-01.html
[08:37:11] <pcw_home> seb_kuzminsky: I wonder if the PCI issue with the new RTAI is something with memcpy
[08:37:13] <pcw_home> not sure I would trust memcpy and all it optimizations for needs-to-be-aligned writes
[08:42:57] <skunkworks> pcw_home, if you guys get anything to test with the 7i80 - let me know. :)
[08:46:20] <skunkworks> http://groups.yahoo.com/group/mach1mach2cnc/message/141185
[09:14:30] <cradek> is M61 supposed to do everything that M6 does except actually tell iocontrol to change the tool?
[09:55:07] <seb_kuzminsky> jepler: yes, a test would be useful
[09:57:02] <seb_kuzminsky> m61 didn't copy the tool to slot 0, and didn't update #5400 and friends
[09:57:32] <seb_kuzminsky> all it did was set emcioStatus.tool.toolInSpindle (but it set it wrong: pocket number vs tool number bug again)
[09:57:41] <seb_kuzminsky> cradek: that's my understanding
[09:59:08] <cradek> thanks for making sense of it
[09:59:30] <cradek> the report that it was gui-specific didn't seem to make sense to me
[09:59:44] <seb_kuzminsky> yeah
[10:00:10] <seb_kuzminsky> i think m61 is for the operator to tell the machine "you actually have tool n in the spindle, you just forgot"
[10:00:21] <cradek> yeah I understand
[10:00:28] <seb_kuzminsky> (me, i'd just use TnM6, rather than make up a new gcode for it)
[10:00:55] <cradek> I think it was a very poor way to implement "remember what tool is loaded across shutdown/restart"
[10:01:11] <seb_kuzminsky> pcw_home: interesting! i'll look into the implementation of it
[10:01:33] <cradek> for some tool changers I bet TnM6 is crashy if you already have a tool loaded
[10:01:44] <seb_kuzminsky> hmm
[10:01:49] <cradek> I think of M61 as a way to do a certain kind of error recovery
[10:02:15] <seb_kuzminsky> T#5400 M6 should always be safe, no? move to the tool-change position, notice that you already have #5400 loaded, and consider the M6 complete
[10:02:51] <cradek> it'd be better if the tool table would remember the loaded tool across shutdown/restart (like it already does in random mode)
[10:03:01] <cradek> ... optionally would remember
[10:03:12] <cradek> I think M61 predates random
[10:03:23] <cradek> I don't know the answer to your question
[10:04:35] <seb_kuzminsky> somtimes the machine might still remember wrong - i sometimes power down my machine and then move the loaded tool back to my tooling rack
[10:04:49] <cradek> sure
[10:05:05] <cradek> with my scheme, you'd manually edit the tool table to recover
[10:07:42] <seb_kuzminsky> right
[10:08:13] <seb_kuzminsky> i guess it's not that hard to get into a situation where the machine will crash if you command m6
[10:08:28] <seb_kuzminsky> for example, if you're in the middle of cutting a dovetail and your cutter is in the underhang
[12:19:28] <mozmck> seb_kuzminsky: are you aware of the assume_unchanged bit in git?
[12:21:42] <mozmck> Somehow that got set on a file in one of my projects and it took a while asking on #git for someone to come up with that. There is apparently no good way to tell if it is set - you just have to try un-setting it. So if you have a file whose changes are not getting picked up by git, try unsetting that bit on that file.
[12:38:46] <seb_kuzminsky> mozmck: never heard of it
[12:40:12] <seb_kuzminsky> wow that sounds awful
[12:46:57] <mozmck> seb_kuzminsky: see
http://jk.gs/git-update-index.html for more info, but the "use git ls-files -v" apparently does not work right or something. It showed me nothing different with the file, and the guy on #git said the output was hard to parse.
[12:52:15] <seb_kuzminsky> i hope i never set that bit by mistake!
[12:52:36] <seb_kuzminsky> it's pretty easy to commit the thing you want git to ignore, then rebase your branch to get that commit out of the way
[12:52:45] <seb_kuzminsky> seems way simpler than manipulatig hidden magic state
[13:01:15] <mozmck> :) yes. I didn't set the bit, so I don't know how it got set. Did notice the problem till much further down the line.
[13:06:30] <seb_kuzminsky> that sounds hard to debug!
[13:09:27] <cradek> yuck
[13:09:56] <cradek> now you must write another koan
[13:10:02] <seb_kuzminsky> heh
[13:12:33] <mozmck> koan?
[13:12:50] <skunkworks> http://www.tormach.com/blog/talking-specs-tormach-sbl-1012-slant-bed-lathe/?utm_source=blog&utm_medium=email&utm_campaign=postnotify&utm_id=4422&utm_title=Talking+Specs%3A++Tormach+SBL+1012+Slant+Bed%26nbsp%3BLathe
[13:13:00] <skunkworks> they still don't say linuxcnc :)
[13:16:40] <seb_kuzminsky> mozmck:
http://stevelosh.com/blog/2013/04/git-koans/
[13:17:42] <mozmck> Ah, I think I saw that site once. :)
[13:18:13] * seb_kuzminsky <=== "The historian hung his head as enlightenment crushed down upon him."
[13:18:41] <mozmck> I switched to git from bzr mainly for the way git handles branches. I like having multiple branches but just one working tree. Keeps my overloaded projects folder a little cleaner.
[13:19:07] <mozmck> But bzr does have some things going for it.
[13:19:44] <seb_kuzminsky> bzr has lots going for it, though i haven't used it much since linuxcnc switched to git
[13:20:22] <mozmck> I think I saw at one point that they were adding the ability to handle branches like git, but I don't remember now.
[21:04:28] <KGB-linuxcnc> 03seb 05v2.5_branch 5b6fe02 06linuxcnc 10tests/ 03toolchanger/simpockets.tbl.orig 10toolchanger/toolno-pocket-differ/shared-test.sh 04toolchanger/toolno-pocket-differ/simpockets.tbl.orig * tests: move toolchanger-test's tool-table file
[21:04:28] <KGB-linuxcnc> 03seb 05v2.5_branch 00b6ff4 06linuxcnc 10tests/ 10(7 files) * test: add a test of M61
[21:04:32] <KGB-linuxcnc> 03seb 05v2.5_branch 855415e 06linuxcnc 10src/emc/iotask/ioControl.cc * io: fix a tool number/pocket number bug in EMC_TOOL_SET_NUMBER (M61)
[21:04:39] <KGB-linuxcnc> 03seb 05v2.5_branch 90f8598 06linuxcnc 10src/emc/iotask/ioControl.cc * io: better debug message
[21:04:45] <KGB-linuxcnc> 03seb 05v2.5_branch f146fd9 06linuxcnc 10src/emc/iotask/ioControl.cc * io: update the spindle "pocket" on M61
[21:04:51] <KGB-linuxcnc> 03seb 05v2.5_branch 92e9cf3 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc * interp: fix M61
[21:05:12] <seb_kuzminsky> writing tests in python instead of linuxcncrsh gives me a little nerdgasm
[21:05:44] <KGB-linuxcnc> 03TODO: deletor 05m61-fix 44041e2 06linuxcnc 04. * branch deleted
[21:25:24] <KGB-linuxcnc> 03seb 05master 5645d04 06linuxcnc 10docs/src/gcode/m-code.txt * docs: fix handling of the old tool in the M6 description
[21:25:24] <KGB-linuxcnc> 03seb 05master dea503a 06linuxcnc 10docs/src/gcode/m-code.txt * docs: remove incorrect T-word info in M6 description
[21:25:27] <KGB-linuxcnc> 03seb 05master b2edb8a 06linuxcnc 10docs/src/gcode/overview.txt * docs: clarify numbered parameters
[21:25:33] <KGB-linuxcnc> 03seb 05master f0294e5 06linuxcnc 10src/emc/task/emccanon.cc * canon: fix some comments
[21:25:39] <KGB-linuxcnc> 03seb 05master 5f7693a 06linuxcnc 10src/emc/task/emccanon.cc * canon: rename a CHANGE_TOOL_NUMBER() argument for clarity
[21:25:45] <KGB-linuxcnc> 03seb 05master 5b6fe02 06linuxcnc 10tests/ 03toolchanger/simpockets.tbl.orig 10toolchanger/toolno-pocket-differ/shared-test.sh 04toolchanger/toolno-pocket-differ/simpockets.tbl.orig * tests: move toolchanger-test's tool-table file
[21:25:53] <KGB-linuxcnc> 03seb 05master 00b6ff4 06linuxcnc 10tests/ 10(7 files) * test: add a test of M61
[21:25:59] <KGB-linuxcnc> 03seb 05master 855415e 06linuxcnc 10src/emc/iotask/ioControl.cc * io: fix a tool number/pocket number bug in EMC_TOOL_SET_NUMBER (M61)
[21:26:06] <KGB-linuxcnc> 03seb 05master 90f8598 06linuxcnc 10src/emc/iotask/ioControl.cc * io: better debug message
[21:26:12] <KGB-linuxcnc> 03seb 05master f146fd9 06linuxcnc 10src/emc/iotask/ioControl.cc * io: update the spindle "pocket" on M61
[21:26:18] <KGB-linuxcnc> 03seb 05master 92e9cf3 06linuxcnc 10src/emc/rs274ngc/interp_convert.cc * interp: fix M61
[21:26:24] <KGB-linuxcnc> 03seb 05master 0653ab9 06linuxcnc 10docs/src/gcode/m-code.txt 10src/emc/iotask/ioControl.cc 10src/emc/task/emccanon.cc * Merge branch 'v2.5_branch'
[21:50:38] <linuxcnc-build> build #439 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/439 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:50:52] <linuxcnc-build> build #1240 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1240 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:51:34] <linuxcnc-build> build #1237 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1237 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[21:52:40] <linuxcnc-build> build #1235 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1235 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:02:35] <seb_kuzminsky> hmm, i should have maybe tested on a realtime machine before pushing
[22:07:58] <memleak> seb_kuzminsky, 3.2 support is extremely difficult, how badly do you guys need this?
[22:08:30] <memleak> (kernel 3.2 support w/ RTAI)
[22:08:46] <memleak> paolo even tried to get it going but it was a fail so he dropped it.
[22:12:17] <seb_kuzminsky> i guess i would rather have *anything* working well first, then worry about things that are awesomer but harder
[22:13:07] <seb_kuzminsky> it's been useful for us to ship a kernel that's as similar as possible to the ubuntu kernel, because it means we can deflect some support requests to ubuntu
[22:14:15] <memleak> 3.4 is really just 3.2 with some enhancements that most people won't even notice.
[22:14:37] <memleak> I've been pulling my hair out trying to get it going and 3.2 just isn't cooperating.
[22:14:50] <seb_kuzminsky> yikes
[22:16:10] <seb_kuzminsky> you said the other day that the config i had for my 3.4.53-2-rtai kernel had bad config settings in it, can you elaborate on that?
[22:17:07] <memleak> A lot of options known to hurt latency and expose practically every bug within the kernel scheduling code.
[22:17:21] <seb_kuzminsky> are there a lot of bugs in the scheduler?
[22:17:59] <seb_kuzminsky> oh, maybe you mean performance bugs, things that make latency suck
[22:18:11] <memleak> Most of the bugs are in userspace but certain kernel config settings expose them.
[22:18:52] <seb_kuzminsky> are these rtai-specific bugs?
[22:19:00] <memleak> yes.
[22:19:05] <seb_kuzminsky> afaik the 3.4 kernel and the canonical userspace are pretty solid
[22:19:18] <memleak> RTAI userspace is not solid ;)
[22:19:26] <seb_kuzminsky> ah :-(
[22:19:44] <memleak> I bumped 3.4 support and I'm working on the other parts of the RTAI tree atm.
[22:19:46] <seb_kuzminsky> wait, what userspace are we talking about? isn't rtai mostly in the kernel
[22:20:02] <memleak> /usr/realtime
[22:20:33] <memleak> I'm not bothering with 3.2 any time soon, I'm working on 64-bit now. 3.2 killed me.
[22:20:43] <seb_kuzminsky> ah, you mean liblxrt and librtdm
[22:21:15] <memleak> and rtai hal and all that stuff (sched.c sched.h)
[22:21:42] <memleak> mainly HAL really.
[22:21:51] <seb_kuzminsky> could you prepare a 3.4.5anything kernel config with the known bad config options turned off, but everything else on? based on the 3.4.53-2-rtai config would be great
[22:21:54] <memleak> but there is some scheduling code in userspace too
[22:22:07] <seb_kuzminsky> if that'd be quick and easy, it'd be helpful for me to test
[22:22:14] <memleak> yes I'm doing that right now as well.
[22:22:28] <seb_kuzminsky> thanks!
[22:23:10] <memleak> to save me an hour of reverse engineering the ubuntu .deb kernel packages, can you post the stock latest kernel config for the version of ubuntu you want it based off of?
[22:23:32] <memleak> so many dummy packages and virtual packages is an incredible nuisance.
[22:24:03] <memleak> /boot/config-whatever-ubuntu
[22:24:03] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/rtai-pci/config-3.4.53-2-rtai
[22:24:07] <memleak> thanks
[22:27:51] <cradek> wow, what a test that is
[22:28:12] <seb_kuzminsky> wish i hadn't written it wrong :-(
[22:28:24] <seb_kuzminsky> wish i'd pushed it to a feature branch before 2.5 :-(
[22:29:00] <cradek> sure appreciate you fixing the last bugs in 2.5
[22:36:16] <linuxcnc-build> build #440 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/440 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:39:33] <linuxcnc-build> build #1241 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1241 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:40:08] <linuxcnc-build> build #1238 of hardy-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1238 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:40:09] <linuxcnc-build> build #1236 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1236 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:53:45] <KGB-linuxcnc> 03seb 05v2.5_branch 9868fcf 06linuxcnc 10tests/toolchanger/m61/test-ui.py * m61 test: don't throw exceptions in LinuxcncControl.g()
[22:53:45] <KGB-linuxcnc> 03seb 05v2.5_branch 6ff9451 06linuxcnc 10tests/toolchanger/m61/test-ui.py * m61 test: fix some spurious failures