Back
[00:05:16] <seb_kuzminsky> that was 2.4 failing on newer platforms (wheezy, jessie, precise), to be expected
[00:06:00] <seb_kuzminsky> it's currently building 2.5 with the new tests and the fix for the bug they trigger, this should all succeed
[02:23:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-bug-448 a89d0bc 06linuxcnc 10src/emc/rs274ngc/interp_cycles.cc Merge branch '2.5-bug-448' into 2.6-bug-448 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a89d0bc
[02:36:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7-bug-448 8b98364 06linuxcnc Merge remote-tracking branch 'origin/2.6-bug-448' into 2.7-bug-448 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b98364
[04:44:37] <linuxcnc-build_> build #1434 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1434 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:15:22] <seb_kuzminsky> as soon as the #448 fix gets ratified i'll release 2.6.11 and 2.7.2
[10:18:29] <jepler> you're a champ
[11:40:28] <jepler> yay after fixing DNS and SMTP "MAIL FROM", a password reminder from the testing forum gets through to my gmail inbox
[11:40:41] <jepler> though the fact that I had marked several as "not spam" may have helped for me personally.
[12:48:57] <cradek> seb_kuzminsky: I trust your tests more than my ability to understand the change
[12:50:37] <cradek> seb_kuzminsky: it would be nice if another? test exercised the g98/g99 switching stuff intended in df5a469d7
[13:07:52] <seb_kuzminsky> cradek: the behavior that the tests verify, that worked in 2.4 and broke in 2.5 and got fixed in 2.5-bug-448, is this:
[13:08:00] <seb_kuzminsky> rapid to the higher of old_z and r
[13:08:04] <seb_kuzminsky> rapid to the xy place
[13:08:17] <seb_kuzminsky> rapid down to r if it's lower
[13:08:21] <seb_kuzminsky> feed down to z
[13:08:30] <seb_kuzminsky> rapid up to r or old_z, depending on g98/g99 mode
[13:09:00] <seb_kuzminsky> looking at df5a469d7 now...
[13:11:44] <seb_kuzminsky> hm, none of my tests try switching between g98/g99 in the middle of a string of g81 cycles, that's the additional test you're suggesting?
[13:43:13] <cradek> well it's not exactly related to bug 448 or bug 448's tests, but that was the reason for df5a469d7 which is what caused all the trouble
[13:43:55] <cradek> but meanwhile, your 448 stuff looks great and I thank you for doing it
[15:09:15] <skunksleep> Thanks!
[15:56:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 9d789df 06linuxcnc 10tcl/bin/emccalib.tcl emccalib: update msg txt for JOINT_ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d789df
[15:56:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 1bd80fa 06linuxcnc 10lib/hallib/core_servo.hal 10lib/hallib/core_stepper.hal core_servo,core_stepper use JOINT_ ini settings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1bd80fa
[15:56:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 05538cb 06linuxcnc 10(16 files in 4 dirs) attic/unclaimed (new) for unknown config files (ja) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=05538cb
[15:56:25] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs d42cfe0 06linuxcnc 10configs/sim/axis/xhc-hb04/README xhc-hb04/README use JOINT_ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d42cfe0
[15:56:29] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 5c3b309 06linuxcnc 10lib/python/gladevcp/hal_actions.py 10lib/python/hal_glib.py hal: use mask for homed detection(joints_axes) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c3b309
[16:00:46] <skunksleep> pcw_home: you're arguing with crazy people again
[17:43:01] <PCW> skunksleep: yes, someone is wrong on the internst
[17:47:07] <andypugh> 5i25 “Kernel Error” or something else?
[17:48:48] <PCW> Ye Olde microstepping reduces torque nonsense
[17:49:43] <andypugh> It reduces torque per step. Sort-of
[17:49:53] <malcom2073_> Why hasn't anyone hooked a torque meter up to a stepper yet?
[17:50:10] <malcom2073_> I mean, with all the arguments about it
[17:51:15] <PCW> Its been done...
[17:51:16] <PCW> A lot of people read the MICROMO paper and mis-intepret what it says
[17:52:36] <PCW> I think its the main vector of incorrect idea that microstepping reduces torque
[17:52:51] <malcom2073_> Yeah it's what I usually see linked along with that argument
[17:54:18] <PCW> The paper is correct, but I think people look at the chart and say ooh I don't want 256 usteps/step I will only get a fraction of full torque
[17:54:29] <malcom2073_> Yeah
[17:54:51] <malcom2073_> So why doesn't someone make a competing graph that shows how it works, without using the term "incremental torque" :P
[17:56:11] <andypugh> Because “Incremental Torque” is an accurate and adequate description for anyone who deserves to be using steppers :-)
[17:56:34] <PCW> or a video with a magnet and a compass to show how u-stepping works
[17:56:40] <malcom2073_> The majority of people who do X don't deserve to do it :P
[17:56:57] * malcom2073_ steals andypugh's rose colored glasses
[17:57:20] <malcom2073_> Yeah, a video isn't abad idea
[19:03:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.4_branch 5ed89d2 06linuxcnc 03scripts/platform-is-supported add platform-is-supported script in 2.4 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5ed89d2
[19:18:26] <skunkworks> a laser mounted on the shaft with marks on the wall...
[19:59:04] <linuxcnc-build_> build #2865 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2865 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:09:11] <linuxcnc-build_> build #1428 of 4002.deb-hardy-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4002.deb-hardy-amd64/builds/1428 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:12:05] <linuxcnc-build_> build #1428 of 4001.deb-hardy-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4001.deb-hardy-i386/builds/1428 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:12:24] <linuxcnc-build_> build #1431 of 4000.deb-hardy-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4000.deb-hardy-rtai-i386/builds/1431 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:19:36] <linuxcnc-build_> build #2864 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2864 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:22:14] <linuxcnc-build_> build #2859 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3 shell_4] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2859 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:01:23] <KGB-linuxcnc> 03Dewey Garrett 05master ce429f0 06linuxcnc 10docs/src/hal/tools.txt 10tcl/bin/halshow.tcl halshow: support multiple line watchfile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ce429f0
[23:39:20] <mozmck> I need a hal component that is the inverse of mux2 - one input and two outputs. The active output is selected by another pin.
[23:39:39] <mozmck> What would that be called, and does such a component exist and I'm not seeing it?
[23:46:54] <mozmck> I'll make one if there isn't one, but I'm not sure what to call it.