Back
[00:28:47] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:54:43] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[01:11:43] -!- Tom_itx has quit []
[01:28:31] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[01:39:54] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[01:41:31] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[01:53:41] <linuxcnc-build> Hey! build 0000.checkin #4293 is complete: Success [3build successful]
[01:53:41] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4293
[01:54:15] <jepler> halcmd: loadusr -Wn nope hal_manualtoolchange
[01:54:15] <jepler> Waiting for component 'nope' to become ready.
[01:54:16] <jepler> while waiting for coponent 'nope', component 'hal_manualtoolchange' loaded. did you specify the correct component name via loadusr -Wn?...............
[01:54:38] <jepler> I wonder if getting this ^^^ is worth the price, which the way I've implemented it includes converting a big swath of halcmd to C++ (!)
[01:55:15] <seb_kuzminsky> ooh me likey
[01:56:21] <jepler> I should fix the typos
[01:57:11] <jepler> jmk would have my head for putting C++ into his beautiful design
[01:59:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 98ccaf7 06linuxcnc 10src/hal/hal_priv.h hal_priv: Introduce, use SHMFIELD * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98ccaf7
[01:59:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 5598a7e 06linuxcnc 10src/hal/hal_priv.h hal_priv: Make it possible to forward-declare these structures * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5598a7e
[01:59:03] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus b0f6e8c 06linuxcnc 10src/hal/hal_priv.h hal_priv: forward-declare these types * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b0f6e8c
[01:59:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 8107f82 06linuxcnc 10src/hal/hal_priv.h hal_priv: reorder slightly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8107f82
[01:59:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 455a8cd 06linuxcnc 10src/hal/halmodule.cc halmodule: better check for HAL being initialized * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=455a8cd
[01:59:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 32a2499 06linuxcnc 10src/hal/hal_priv.h hal_priv: Type-safe C++ for access to HAL shared memory area * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=32a2499
[01:59:17] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 6ebeaa5 06linuxcnc 10src/hal/utils/halcmd.h 10src/hal/utils/halcmd_commands.h halcmd: Make headers usable from C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ebeaa5
[01:59:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 5e66f97 06linuxcnc 10src/hal/utils/halcmd.c 10src/hal/utils/halcmd_commands.c 10src/hal/utils/halcmd_commands.h halcmd: const-correctness fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e66f97
[01:59:26] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 6aab928 06linuxcnc 10src/hal/utils/halcmd_commands.c halcmd: use SHMFIELD() for next-pointers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6aab928
[01:59:30] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus c352d25 06linuxcnc 10src/hal/utils/Submakefile 04src/hal/utils/halcmd_commands.c 03src/hal/utils/halcmd_commands.cc halcmd: convert halcmd_commands to C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c352d25
[01:59:34] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus d5299a9 06linuxcnc 10src/hal/utils/halcmd_commands.cc halcmd: improve user feedback when loading components * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d5299a9
[01:59:34] <jepler> .. when writing C++ that gets into low-level hal structures, you can also now write nice clear code like this:
[01:59:37] <jepler> for(auto comp = hal_data->comp_list_ptr; comp; comp=comp->next_ptr) {
[01:59:40] <jepler> result.insert(comp->name);
[01:59:43] <jepler> instead of mucking with SHMOFF and SHMPTR
[01:59:45] <jepler> }
[02:00:11] <jepler> hm I forgot to do a full runtests before pushing, surely at least one thing will turn up...
[02:01:02] <linuxcnc-build> build #1434 of 1903.clang-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/1434 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:04:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 1f7f56a 06linuxcnc 10src/hal/hal_priv.h hal_priv: Type-safe C++ for access to HAL shared memory area * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f7f56a
[02:04:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 70d5566 06linuxcnc 10src/hal/utils/halcmd.h 10src/hal/utils/halcmd_commands.h halcmd: Make headers usable from C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=70d5566
[02:04:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 7442414 06linuxcnc 10src/hal/utils/halcmd.c 10src/hal/utils/halcmd_commands.c 10src/hal/utils/halcmd_commands.h halcmd: const-correctness fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7442414
[02:04:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 494fbbd 06linuxcnc 10src/hal/utils/halcmd_commands.c halcmd: use SHMFIELD() for next-pointers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=494fbbd
[02:04:47] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 83ec76d 06linuxcnc 10src/hal/utils/Submakefile 04src/hal/utils/halcmd_commands.c 03src/hal/utils/halcmd_commands.cc halcmd: convert halcmd_commands to C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83ec76d
[02:04:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 7ee79ff 06linuxcnc 10src/hal/utils/halcmd_commands.cc halcmd: improve user feedback when loading components * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7ee79ff
[02:07:19] <linuxcnc-build> build #4281 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4281 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:07:38] <linuxcnc-build> build #4279 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4279 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:09:18] Mathnerd314_ is now known as Mathnerd314
[02:09:52] <linuxcnc-build> build #1433 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/1433 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:11:11] <jepler> In file included from hal/utils/halcmd.c:68:
[02:11:11] <jepler> hal/utils/../hal_priv.h:306:3: error: redefinition of typedef 'hal_comp_t' is invalid in C [-Wtypedef-redefinition]
[02:11:14] <jepler> } hal_comp_t;
[02:11:14] <jepler> huh it is?
[02:15:35] <mozmck> ooh neat! you won't catch me complaining about using c++ :-) c++11+ adds some nice things
[02:16:27] <linuxcnc-build> build #3490 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3490 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:16:46] <mozmck> but I bet we can't use much of that because it is probably only supported on the newest platforms we support.
[02:17:42] <jepler> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions For master, our oldest platform has g++-4.7 which has imperfect C++11 support.
https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
[02:26:54] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 9380a21 06linuxcnc 10src/hal/hal_priv.h hal_priv: forward-declare these types * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9380a21
[02:26:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 786f037 06linuxcnc 10src/hal/hal_priv.h hal_priv: reorder slightly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=786f037
[02:26:55] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus aa65ad3 06linuxcnc 10src/hal/halmodule.cc halmodule: better check for HAL being initialized * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aa65ad3
[02:26:56] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus c998ceb 06linuxcnc 10src/hal/hal_priv.h hal_priv: Type-safe C++ for access to HAL shared memory area * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c998ceb
[02:27:00] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 85d58bb 06linuxcnc 10src/hal/utils/halcmd.h 10src/hal/utils/halcmd_commands.h halcmd: Make headers usable from C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85d58bb
[02:27:04] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus 9c83693 06linuxcnc 10src/hal/utils/halcmd.c 10src/hal/utils/halcmd_commands.c 10src/hal/utils/halcmd_commands.h halcmd: const-correctness fixes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9c83693
[02:27:09] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus db6e0ce 06linuxcnc 10src/hal/utils/halcmd_commands.c halcmd: use SHMFIELD() for next-pointers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=db6e0ce
[02:27:13] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus bdb3f9a 06linuxcnc 10src/hal/utils/Submakefile 04src/hal/utils/halcmd_commands.c 03src/hal/utils/halcmd_commands.cc halcmd: convert halcmd_commands to C++ * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bdb3f9a
[02:27:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/halcmd-cplusplus ab83f39 06linuxcnc 10src/hal/utils/halcmd_commands.cc halcmd: improve user feedback when loading components * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ab83f39
[02:27:33] <jepler> maybe I can get it to build on all our platforms in only 4 or 9 tries :)
[02:45:35] <linuxcnc-build> build #2440 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2440 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:51:29] <linuxcnc-build> build #2440 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2440 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:51:56] <linuxcnc-build> build #2474 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2474 blamelist: Jeff Epler <jepler@unpythonic.net>
[02:58:52] <linuxcnc-build> build #1950 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1950 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:01:31] <mozmck> jepler: so what is the motivation to move parts of hal to c++?
[03:02:58] <linuxcnc-build> build #2639 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/2639 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:06:48] -!- GJdan has quit [Ping timeout: 244 seconds]
[03:11:37] <linuxcnc-build> build #2106 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2106 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:20:29] -!- ve7it has quit [Remote host closed the connection]
[03:33:04] <linuxcnc-build> build #4294 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4294 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:58:48] -!- skunksleep has quit [Ping timeout: 244 seconds]
[04:15:36] -!- GJdan has quit [Ping timeout: 272 seconds]
[04:37:55] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[04:47:07] -!- skunksleep has quit [Ping timeout: 252 seconds]
[04:48:00] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[04:48:34] -!- skunkworks has quit [Ping timeout: 260 seconds]
[04:54:45] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[05:56:45] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[06:06:47] -!- anth0ny_ has quit [Quit: anth0ny_]
[06:13:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #94: Axis GUI "Calibrate" window needs axis calibrations too 02
https://github.com/LinuxCNC/linuxcnc/issues/94
[06:31:40] -!- Mathnerd314 has quit [Ping timeout: 264 seconds]
[06:50:00] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:51:00] -!- teepee has quit [Ping timeout: 244 seconds]
[06:51:08] teepee_ is now known as teepee
[06:56:26] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #95: Axis GUI: spurious Teleop commands when idle 02
https://github.com/LinuxCNC/linuxcnc/issues/95
[07:01:27] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #96: Task Abort loop on joint soft limit 02
https://github.com/LinuxCNC/linuxcnc/issues/96
[07:09:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #97: joint vs axis soft limits 02
https://github.com/LinuxCNC/linuxcnc/issues/97
[07:24:00] -!- rob_h [rob_h!~R@97e428d3.skybroadband.com] has joined #linuxcnc-devel
[08:37:59] -!- kalxas has quit [Changing host]
[09:07:49] -!- Komzzpa has quit [Ping timeout: 252 seconds]
[09:17:54] -!- rob_h has quit [Ping timeout: 276 seconds]
[09:50:57] -!- radish has quit [Ping timeout: 260 seconds]
[10:01:21] -!- md-2 has quit [Quit: Leaving...]
[10:01:38] md2 is now known as Guest74687
[10:03:28] -!- tobias47n9e has quit [Remote host closed the connection]
[10:31:10] -!- kingarmadillo has quit [Ping timeout: 272 seconds]
[10:58:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #94: ("calibrate" is inherited from tklinuxcnc and is a standlone Tk program) 02
https://github.com/LinuxCNC/linuxcnc/issues/94#issuecomment-229324292
[11:00:36] <jepler> mozmck: it's a very, very long-winded way to make a long-running 'loadusr' command give the user some troublehshooting information:
[11:00:39] <jepler> While waiting for 'wrongname', component 'example' loaded.
[11:00:42] <jepler> Did you specify the correct name via 'loadusr -Wn'?
[11:38:38] -!- rob_h [rob_h!~R@97e428d3.skybroadband.com] has joined #linuxcnc-devel
[11:46:12] -!- Robh__ [Robh__!~R@97e428d3.skybroadband.com] has joined #linuxcnc-devel
[11:49:04] -!- rob_h has quit [Ping timeout: 264 seconds]
[11:55:24] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[11:55:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #98: Improve the 'halcmd loadusr' message when component is failing to load (06master...06jepler/master/halcmd-cplusplus) 02
https://github.com/LinuxCNC/linuxcnc/pull/98
[12:20:33] -!- b_b has quit [Changing host]
[12:56:16] -!- skunksleep has quit [Ping timeout: 264 seconds]
[12:57:32] -!- ikcalB [ikcalB!~ikcalB@mail.team-electronics.com] has joined #linuxcnc-devel
[13:38:58] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[13:41:31] -!- skunkworks has quit [Ping timeout: 240 seconds]
[14:15:14] <KGB-linuxcnc> 03Dewey Garrett 05master 3e93bfa 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py don't set_motion_teleop() unless needed #95 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3e93bfa
[14:18:32] -!- Daerist has quit [Quit: Leaving]
[14:37:15] <linuxcnc-build> build #2476 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2476 blamelist: Dewey Garrett <dgarrett@panix.com>
[14:37:39] -!- ivansanchez has quit []
[14:43:28] <jepler> funny, gitweb implicitly criticizes you for commiting "at night", which includes 05:58 local time
[14:43:43] <jepler> <span xmlns="
http://www.w3.org/1999/xhtml" class="atnight">05:58</span>
[14:44:31] <linuxcnc-build> build #4296 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4296 blamelist: Dewey Garrett <dgarrett@panix.com>
[14:47:52] -!- Robh__ has quit [Ping timeout: 264 seconds]
[14:51:43] -!- the_w548 [the_w548!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[14:51:52] -!- archivist has quit [Ping timeout: 244 seconds]
[14:52:03] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[14:52:07] -!- the_wench has quit [Ping timeout: 252 seconds]
[14:52:34] -!- the_w548 has quit [Remote host closed the connection]
[14:52:54] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[14:59:05] -!- anth0ny_ has quit [Quit: anth0ny_]
[15:09:06] <seb_kuzminsky> dgarr: that build failure is because the buildbot is overheating, not because anything you did wrong
[15:09:08] <seb_kuzminsky> pdflatex -interaction=batchmode Master_Documentation_es.tex
[15:09:11] <seb_kuzminsky> Segmentation fault
[15:10:06] <ikcalB> seb_kuzminsky: how strong should a reasonable build machine be?
[15:10:26] <seb_kuzminsky> depends how impatient you are
[15:10:40] <seb_kuzminsky> i think 2 gigs of ram is required these days
[15:10:48] <seb_kuzminsky> thanks, boost
[15:11:08] <ikcalB> for linuxcnc purposes. im asking, because I'm buying a new server for my home. that's be a coreDuo, 6G RAM or so
[15:11:33] <ikcalB> "s/'s/'d/"
[15:11:52] <seb_kuzminsky> that sounds like it'll be plenty powerful to develop on
[15:13:00] <ikcalB> I might be willing to run a linuxcnc buildbot/mirror/.. on that one. interested?
[15:13:39] <seb_kuzminsky> oh! cool, yes, i'm interested in that!
[15:14:06] <seb_kuzminsky> i wonder how much of the buildbot script pile expects to run locally to the buildmaster now days
[15:14:32] <ikcalB> atm we're renovating, meaning a lot of offtime - maybe end of summer / begin of autumn I'd be prepared. (also need fresh OS disks (SSDs i.e.)) everything else, running in btrfs raid1
[15:15:17] <ikcalB> that configuration thing I'd be really interested in - atm a complete noob in that regard
[15:20:21] <archivist> running a buildbot slave is fine till someone decides to turn up the build speed (no of parallel)
[15:20:54] <seb_kuzminsky> the buildbot currently runs parallel make with 1.5x as many jobs as the machine has CPUs
[15:21:01] <ikcalB> archivist: why would that be a problem?
[15:21:06] <seb_kuzminsky> each buildslave runs in a 2-cpu virtual machine
[15:21:20] <seb_kuzminsky> on a well provisioned hypervisor
[15:21:27] <seb_kuzminsky> so it all works out
[15:23:20] <archivist> ikcalB, I was running it on my cnc and my server with a database system on the buildbot, they used to grind my server to a halt at times
[15:24:16] <ikcalB> i see. that's just one aspect - as this'd be my home network, I'd be greeatly interested in security ;)
[15:24:24] <archivist> something like -j6 iirc on a system serving the web and me on irc etc
[15:26:07] -!- skunkworks [skunkworks!~skunkwork@184-157-216-139.dyn.centurytel.net] has joined #linuxcnc-devel
[15:39:08] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[15:56:04] <jepler> there are a few specific source files which allocate >250MB RAM while building, so there's a big relationship between -j# and the amount of memory required
[15:56:40] <jepler> looks like one of them is nearly 500MB, total memory allocation reported by -fstats
[15:56:59] <mozmck> I run -j8, but I also have 20Gb mem on my machine
[15:57:23] <jepler> I use -j15 on a 12-thread machine with 16GB and it's fine, but I can't use -j4 on a 4-thread ARM with 2GB RAM. -j2 is OK
[15:57:33] <mozmck> interesting.
[15:58:32] <mozmck> I have a 16 thread workstation ($50 auction special) with 12GB and it has no problems either with -j16
[15:59:26] <jepler> ugh. the 500MB number is for gcc 4.7.2 (debian wheezy). on 4.9.2 (debian jessie), the biggest is over 900MB
[16:00:14] <mozmck> is -fstats a gcc option?
[16:00:28] <jepler> yes, not in clang though
[16:00:34] <jepler> make EXTRA_DEBUG=-print-stats
[16:01:12] <mozmck> I've not used clang - seems like from what I've read gcc has kept up and is not behind clang in anything really
[16:01:54] <seb_kuzminsky> clang has better static analysis,
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/index.html
[16:01:55] <jepler> At $DAY_JOB we find the results of the clang static-analyzer to be useful, and gcc doesn't really have an equivalent right now.
[16:02:04] <jepler> and I was just going to look for the link seb_kuzminsky shared
[16:02:13] <mozmck> I see.
[16:03:18] <mozmck> maybe I can run the clang static analyzer and then compile with gcc.
[16:04:26] <jepler> http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-03QdrE.html#EndPath
[16:04:40] <jepler> so circa line 2448 it needs to return early if there are no components
[16:05:15] <jepler> http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-7ZY1uZ.html#EndPath
[16:05:24] <jepler> looks like this one should be addressed too
[16:06:17] <jepler> mozmck: the downside of "scan-build" is that it makes compile times much longer, and renders technologies like ccache useless
[16:06:33] <mozmck> Looks like some useful information though
[16:06:38] <jepler> yeah it is
[16:07:09] <jepler> at $DAY_JOB we don't aim for zero scan-build diagnostics, but we do investigate each new diagnostic from scan-build and often make fixes based on them
[16:07:53] <jepler> I actually have a script which looks at two days' reports on buildbot for new diagnostics, bisects them, and e-mails the committer the information about it
[16:08:19] <seb_kuzminsky> nice
[16:08:29] <seb_kuzminsky> robotic nagging to go with the robotic code review :-)
[16:08:43] <jepler> otherwise, like with linuxcnc, somebody will only go looking rarely
[16:08:53] <jepler> but even if you remember to go looking once you encounter a crash in a particular source file, it can be a huge help
[16:09:03] <jepler> "oh clang already told me I was doing something obvously wrong here"
[16:11:26] <jepler> you may also find that certain checkers emit diagnostics you're not interested in looking at. For instance, we -disable-checker deadcode.DeadStores because this is a common practice that we're not going to address right away
[16:12:32] <jepler> also that checker encourages you to change code to have worse style IMO. Consider this one:
http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-N3HORD.html#LN1814
[16:12:53] <jepler> now ideally you'd do something besides open-code a loop to find the index of greatest eigenval
[16:13:21] <jepler> but given that you're going to do *that*, I believe it's better for the last 'if' statement to still assign eigenval, so that the form of each if statement is the same
[16:13:59] -!- tobias47n9e has quit [Ping timeout: 260 seconds]
[16:15:15] <CaptHindsight> are there any freelance C devs that are familiar with Linuxcnc as well as CAM, post processors, printer drivers etc out there?
[16:16:07] * jepler shivers with cold: printer drivers !?
[16:16:26] <jepler> I'm sure if I tried real hard I could remember the epson control codes from the '90s!
[16:16:49] <archivist> I bet very few apart from me and capt have done printer drivers
[16:17:05] <seb_kuzminsky> i once wrote an octagonal chess board in postscript, does that count?
[16:17:25] <CaptHindsight> well an understanding of how print heads space nozzles, and how motion gets synced to lasers, inkjets etc
[16:18:00] <jepler> oh you mean things you would understand to write printer firmwares? Or has this knowledge been pushed out of the printers into the "real computers" now?
[16:18:06] <archivist> fscking random jumble of nozzles, that I do remember
[16:18:20] <CaptHindsight> random jumble of nozzles
[16:18:39] <archivist> offsets and spacing and buffers
[16:19:14] <CaptHindsight> you handle some in it in an fpga
[16:19:26] <archivist> we did it in code
[16:20:29] <CaptHindsight> but you still need to go from some image format or table of data and jumble it into some format the printheads require
[16:21:44] <CaptHindsight> one example is Linuxcnc to control and inkjet printer that prints DNA strands
[16:21:54] <archivist> my last one was in ARM C for a got at Olivetti printer which we shoved HP heads in
[16:22:12] <CaptHindsight> the users aren't EE's, ME's and have never seen G-code
[16:23:01] <CaptHindsight> you jet one of eight fluids (in 8 separate banks of inkjet nozzles) onto a glass slide
[16:23:45] <CaptHindsight> you do this 100-1000 times over itself with different fluids every layer
[16:23:49] <jepler> sounds fun! but it's above my pay grade
[16:24:02] <CaptHindsight> I need to write a user friendly front end
[16:24:42] <seb_kuzminsky> a gui for printing gooey dna
[16:25:11] <jepler> also, we can print dna strands and the problem is the UI isn't friendly enough. welcome to the 21st century
[16:25:26] <CaptHindsight> heh
[16:25:38] <seb_kuzminsky> 1st world CS problem
[16:26:01] <archivist> isnt a command line good enough?
[16:26:11] <CaptHindsight> the biologist knows GACT
[16:27:05] <archivist> I assume you mean this
http://www.uvm.edu/genomics/software/gact/
[16:28:09] <archivist> rofl they cant manage online docs
[16:29:19] <CaptHindsight> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/
[16:29:29] <CaptHindsight> POSaM: a fast, flexible, open-source, inkjet oligonucleotide synthesizer and microarrayer
[16:31:39] <CaptHindsight> they kludged some boards together for motion control
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/bin/gb-2004-5-8-r58-s1.pdf
[16:33:19] <CaptHindsight> they used the software that came wit the Compumotor servo controller and something by national Instruments to generate the printhead pulses
[16:34:09] -!- ktchk [ktchk!~eddie6929@n219079126222.netvigator.com] has joined #linuxcnc-devel
[16:37:23] <CaptHindsight> archivist: similar to that conversion tool, but that only targets the microarrayers by Illumina
[16:38:07] -!- ktchk has quit [Client Quit]
[16:38:17] <CaptHindsight> microarrayers are like pick and place with a matrix of nozzles for fluids
[16:42:21] <CaptHindsight> Linuxcnc with some custom M codes can handle >90% of what this needs
[16:43:31] <archivist> mebe
[16:43:32] <CaptHindsight> what is needs is a g-code generator and a way to sync motion to the printhead buffer
[16:43:41] <CaptHindsight> is/it
[16:44:47] <CaptHindsight> I've already synced Linuxcnc to printheads but they were two independent systems
[16:45:07] <archivist> well I remember flight time and errors in the nozzle alignments to fixup in code too
[16:45:17] <CaptHindsight> the printhead buffer would use the gated encoder signals as a clock
[16:46:23] <archivist> that only works where the spacing is regular and the same as your encoder
[16:46:59] <CaptHindsight> jetting DNA fluids is a bit more simple since there is no grey scaling or interpolating going on
[16:47:33] <CaptHindsight> yeah, the drops for DNA are in the same place every time
[16:47:48] <CaptHindsight> you just put drops on top of previous drops
[16:48:04] <CaptHindsight> with wash and dry cycles in between
[16:48:57] <archivist> not sure how we add the laser diode drop checking that doc mentions
[16:49:55] <CaptHindsight> an external input
[16:50:19] <CaptHindsight> like QC when you machine apart
[16:50:30] <CaptHindsight> it goes back over the bad area
[16:52:02] -!- ams-w [ams-w!~androirc@182.58.232.23] has joined #linuxcnc-devel
[16:52:38] <CaptHindsight> this only XY scans
[16:52:45] <jepler> hm, Eagle (PCB software) has been sold to Autodesk. One more reason I should use Free software next time I make a PCB.
[16:52:45] <CaptHindsight> so motion planning is simple
[16:53:10] <seb_kuzminsky> jepler: i used kicad last time, it was great (but i'm not a power user)
[16:54:36] <CaptHindsight> archivist: the drop checker is like having an indicator go over a path that was just machined to QC and then deciding if it should make another pass or go on to the next path
[16:54:59] <archivist> kicad seems to be actively developed, but the schematic needs a revamp
[16:55:29] <archivist> CaptHindsight, been looking at
http://www.uvm.edu/genomics/software/gact/
[16:55:42] <ikcalB> DipTrace atm is a good windows alternative - free for small projects, cheap for private use
[16:55:43] <archivist> wrong this
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/figure/F3/
[16:55:52] <ams-w> Active g codes and m codes are decided right at RS274 interpreter level, this is way before it passes through emctaskmain and then gets executed.
[16:56:19] <ikcalB> also started to use kicad, it is REALLY becoming useful!! many things need revamp, but as I said, especially the push n shove router is likeable
[16:56:19] <archivist> jepler, I have the founder flag on the #kicad channel :)
[16:56:27] <jepler> archivist: nice
[16:57:59] <ams-w> I tried a 5 line g code
[16:58:27] <ams-w> Which has m3 on line 3 and line 4 had error
[16:58:46] <ams-w> File did not got executed but active g codes were altered
[17:00:05] <ams-w> Active g codes (if are queue busters) can be updated from within emccanon
[17:00:25] <ams-w> Is this a right way ?
[17:02:20] <archivist> ams-w, not sure what you are asking or trying to do
[17:06:11] -!- ams-w has quit [Ping timeout: 240 seconds]
[17:06:46] <archivist> CaptHindsight, a hack of
http://linuxcnc.org/docs/html/man/man9/streamer.9.html ?
[17:08:21] <CaptHindsight> maybe
[17:13:39] <CaptHindsight> archivist: the g-code generator would be mostly a set of subroutines that match the print, wash and drying to make G, A, T and C
[17:15:06] <archivist> g code to scan but something else to produce the dot patterns
[17:16:12] <CaptHindsight> that could be outside of Linuxcnc, a buffer that gets drops aligned to the planned motion
[17:16:49] <archivist> I get the impression unidirectional would be ok to avoid flight time and head accuracy
[17:17:14] <CaptHindsight> but yeah, the g-code generator would also have to generate bitmaps for the buffer
[17:17:48] <archivist> nah I think the bitmaps should be elsewhere
[17:17:52] <CaptHindsight> yeah just X-Y scan at all right angles, print would only be in say Y axis
[17:24:09] -!- ams-w [ams-w!~androirc@182.58.175.1] has joined #linuxcnc-devel
[17:24:35] <CaptHindsight> archivist:
https://ibin.co/2mM02TarMu3R.jpg block diagram of the original electronics
[17:25:37] <CaptHindsight> now replaced by Mesa boards and a custom printhead FPGA board
[17:28:14] <archivist> while {do the test spit and capture the result, fire the C to write the bit pattern, spit the dots}
[17:33:06] <CaptHindsight> this came up about a year ago in another channel where many of the devs work with GRBL, repraps and other silliness
[17:33:41] <CaptHindsight> they even wanted to replace the mesa cards with something cheaper and less flexible
[17:34:26] <CaptHindsight> but since I don't wish to vomit, I'm not going that direction
[17:36:42] -!- Guest74687 has quit [Quit: Leaving...]
[17:38:51] <CaptHindsight> archivist:
http://www.bioinformatics.org/pogo/Lombardi073.tgz http://bioinformatics.org/cgi-bin/cvsweb.cgi/pogo/ http://www.bioinformatics.org/pogo/Arrayer092.tgz
[17:39:09] <archivist> I can think of a possible improvement to the drop detector, have an a-d and get the waveform from the sequence of drops, one then gets size/fluid changes
[17:39:59] <CaptHindsight> the Epson heads are low cost, that's about it
[17:40:19] <CaptHindsight> the drop detector is really for detecting missing drops
[17:40:40] <CaptHindsight> we have much better heads but thats for V2.0
[17:41:44] <CaptHindsight> archivist: lets take this to the linuxcnc channel vs the dev channel
[17:42:04] <CaptHindsight> we are just noise in here now
[17:47:43] -!- basiclaser has quit [Quit: Connection closed for inactivity]
[17:48:59] -!- ams-w has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
[17:58:41] -!- ikcalB has quit [Quit: WeeChat 1.5]
[18:14:48] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[18:47:45] -!- Robh__ [Robh__!~R@97e428d3.skybroadband.com] has joined #linuxcnc-devel
[19:01:36] -!- Dev0n has quit [Ping timeout: 244 seconds]
[19:02:38] -!- leptonix has quit [Ping timeout: 244 seconds]
[19:07:48] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[19:16:51] -!- b_b has quit [Remote host closed the connection]
[19:20:16] -!- kwallace has quit [Ping timeout: 264 seconds]
[19:21:14] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[20:07:19] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[20:23:33] -!- PCW__ [PCW__!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[20:24:27] <seb_kuzminsky> huh, i think i found a workaround for the rtai 5 hangs i've been seeing
[20:24:37] <seb_kuzminsky> fingers crossed
[20:24:45] -!- PCW_ has quit [Ping timeout: 244 seconds]
[20:30:48] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[20:32:04] -!- Komzzpa has quit [Ping timeout: 240 seconds]
[20:41:20] -!- kalxas has quit [Read error: No route to host]
[20:45:55] <andypugh> I assume there is no legal reason that I can’t tell Machinekit that they are welcome to adapt and use my LinuxCNC patches? In fact I rather supsect that I couldn’t even deny them permission?
[20:47:41] <seb_kuzminsky> your assumptions are both correct
[20:51:34] <andypugh> OK. Though I really do wish that Machinekit had better support and we saw less of their users on our forums, where sometimes we spend days puzzled until it turns out that they are running MK on a BBB
[20:53:22] <andypugh> Does anyone know if MK is JA-based? I stopped following the project after MAH told me to bugger off.
[20:53:38] <seb_kuzminsky> dont know, dont care
[20:55:02] <andypugh> I care a bit, because of users and some of the other devs, like Zulton who is doing the decent thing and patching both.
[20:55:10] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[20:55:36] <seb_kuzminsky> yeah, i appreciate the work zultron's doing, that's all top notch
[20:56:16] -!- teepee has quit [Ping timeout: 272 seconds]
[20:56:16] teepee_ is now known as teepee
[21:00:30] <andypugh> So…. Sticky tools. Should I do do something?
[21:01:35] <andypugh> I rather suspect that nearly every user leaves their tool in the spindle at the end of the day, and would prefer the system to come back up set for that spindle, and the same offsets.
[21:02:02] <andypugh> Or maybe I am just a sloven?
[21:02:30] <seb_kuzminsky> i sure do that
[21:03:23] <andypugh> I think it is almost as simple as putting #5400 in the sefault vars file.
[21:03:30] <andypugh> (default)
[21:03:31] <seb_kuzminsky> how does multispindle deal with the random-tool-changer pocket 0 thing now? i guess each spindle must get its own pocket?
[21:03:57] <seb_kuzminsky> and for nonrandom you'll need a numbered parameter for each spindle?
[21:04:36] <seb_kuzminsky> how does that interact with cutter comp and tlo and things? do they all take an extra argument to specify which spindle is your reference?
[21:04:45] <andypugh> seb_kuzminsky: It doesn’t deal with it. Partly why multispindle is not even a candidate for 2.8. That and finding other #parameters for the other tools
[21:05:25] <seb_kuzminsky> ah ok, your question is just about single-spindle sticky tools, sorry
[21:05:30] * seb_kuzminsky gets confused a lot
[21:06:17] <andypugh> Yes, at the moment, sticky-tools is monotool only, and yet to be solved for multispindle
[21:06:56] <andypugh> mutlispindle at the moment only expects to not break spindle.0 behaviour.
[21:07:37] <seb_kuzminsky> probably 5400-5413 need to be persistent, right?
[21:07:41] <andypugh> I am rather expecting cutter-comp to only ever work for spindle.0
[21:07:53] <seb_kuzminsky> or 5401-5413 could be reloaded from the tool table based on 5400 at startup?
[21:08:13] <andypugh> Yes, something like that
[21:09:12] <seb_kuzminsky> that seems reasonable to me
[21:09:35] <seb_kuzminsky> i sometimes use m61 to remind my machine at bootup what tool i left in the spindle the night before
[21:09:45] <andypugh> I have not looked at the implementation details yet, I have just seen a perfectly sensible forum question to which I was forced to give a really convoluted answer, and then realised that it would suit me to have an option to build-in sticky tools too
[21:10:40] <andypugh> (It was one of those “How can you be happy with this answer, it should be so much simpler” situations)
[21:10:45] <seb_kuzminsky> i sometimes remove the tool after shutting the machine down (manual tc), i guess it would wake up wrong in that case because i did stuff while it was asleep
[21:11:02] <seb_kuzminsky> andypugh: we have a few of those in our software... :-/
[21:11:23] <andypugh> Yeah, can’t solve anything that happens when the software isn’t running.
[21:11:36] <andypugh> I can’t get my tools out if LinuxCNC isn’t running
[21:12:19] <andypugh> seb_kuzminsky: We should have a list of “it shouldn’t be this hard” features.
[21:12:27] <seb_kuzminsky> i think we should pick one behavior (remember the tool, or dont), and not have an option to switch between them
[21:12:42] <seb_kuzminsky> easier to test, easier to understand users bug reports
[21:13:05] <andypugh> OK… I agree but it’s more scary :-)
[21:13:06] <seb_kuzminsky> andypugh: jog while paused! oh wait i really meant change tools and touch off while paused!
[21:14:20] <seb_kuzminsky> bbl, time to go celebrate independence day a few days early
[21:14:40] <seb_kuzminsky> we celebrate by shooting our guns in the air and throwing tea in the nearest body of water
[21:20:40] <andypugh> Ours might be 23rd of June. Or it might be Disaster Day. No way to know yet.
[21:20:52] <andypugh> seb:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?This_Should_Be_Easier
[21:21:55] <andypugh> Need to figure out where to link it, or it’s a dead page. But it feels like a different thing to bugs or feature requests.
[21:39:18] <cradek> I like that idea
[21:39:39] <skunkworks> grinding the matsuuras spindle taper. (with a dremel)
[21:39:59] <skunkworks> a 6 inch long tool is down to less than .001 runout - used to be .006
[21:40:24] <cradek> I hesitate to tell anyone that I wrote (hacked in) this persistent tool feature many years ago for a customer
[21:40:45] <cradek> his machine was nonrandom but he wanted persistence
[21:41:19] <cradek> I think it made the pocket number of the loaded tool negative or somesuch asinine thing, and restored it at startup (including the g43 offset)
[21:42:28] <cradek> I agree with seb that whenever possible we should do only the right thing and not make the right thing an option just because we are scared, because proliferation of options makes testing impossible
[21:43:03] <cradek> and frankly "forget about the loaded tool" probably isn't a thing anyone ever wanted or wrote on purpose
[21:43:34] <cradek> my vmc is random and so it remembers the tool, but I always unload the tool before shutting down anyway
[21:44:01] <cradek> (fwiw)
[21:49:35] <andypugh> if you unload the tool, it’s all good anyway. I think it might turn out to be what my employer calls a “surprise and delight feature” Something that folk were not expecting, but like.
[21:49:58] <cradek> which thing would be surprise and delight?
[21:51:06] <andypugh> Turning on the machine, issuing your habitual G6 TN G43 to load the tool you left in there, and not being prompted to change the tool and press OK
[21:51:20] <cradek> ah yeah
[21:51:45] <cradek> http://timeguy.com/cradek-files/emc/0001-Persistent-toolchanger.patch
[21:52:00] <cradek> probably applies to 2.5ish, fails badly to apply on masterp
[21:52:02] <cradek> master
[21:52:45] <cradek> (please don't try to use as-is because I really don't think it should be another option)
[21:53:29] <skunkworks> I would also like linuxcnc to remember what tool was in the spindle. I figured I would have it remember then run some sort of gcode scrip after homing is done
[21:54:00] <skunkworks> I had found a hal componant that saved a pins value I think
[21:54:20] <andypugh> cradek: That seems to store the tool-in-spindle in a special pocket? (I only scanned it quickly)
[21:54:22] <skunkworks> then I found another example that just wrote to the var file
[21:54:36] <cradek> no it apparently marks it with L1 in the tool table
[21:54:41] <cradek> "loaded" I suppose I was thinking
[21:55:00] <cradek> but random thinks of the spindle as a special pocket 0
[22:00:49] <andypugh> If I ever get back to the tooltable database work then tool-in-spindle becomes an explicit feature of the database.
[22:01:33] <cradek> do you think we could then remove m61 (and all its code in io?)
[22:01:56] <cradek> bleh, my customer wanted this added to iov2
[22:02:18] <cradek> (speaking of being scared and making testing hard)
[22:02:57] <andypugh> M61 should still work, but I don’t think it ever belonged in IO. Actually I am not sure that iocontrol ever belonged in LinuxCNC
[22:03:51] <cradek> I don't even know what face to make in response to that
[22:05:30] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:05:47] <andypugh> The things it does belong, it does useful things.
[22:05:51] <cradek> I bet separate io over an nml interface made a lot more sense pre-hal, because you could abstract there
[22:06:01] <cradek> brb
[22:07:21] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:08:19] <andypugh> Something that I wanted to do back when I was working on the tool database was have a loadable HAL component “field” NML messages. That’s mainly why I stopped. At the time MAH was going to relace NML with 0MQ and that was going to let HAL components act on not-NML messages.
[22:09:03] <skunkworks> https://www.youtube.com/watch?v=2BFTifZgQVs
[22:11:36] <andypugh> That’s mildy brave
[22:12:08] <andypugh> I tried that making an ER32 collet chuck and could not get the taper right.
[22:14:19] -!- skunkworks has quit [Ping timeout: 244 seconds]
[22:17:52] -!- skunkworks [skunkworks!~AndChat39@184-157-216-139.dyn.centurytel.net] has joined #linuxcnc-devel
[22:18:47] <skunkworks> andypugh: we figured we could not make it worse
[22:37:24] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[22:38:10] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:38:12] -!- skunkworks_ [skunkworks_!~AndChat39@184-157-216-139.dyn.centurytel.net] has joined #linuxcnc-devel
[22:45:00] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[23:06:44] <PCW__> The 4.1.27-rt30 kernel seems to run well on older (CoreDuo) and newer (N3150) hardware
[23:06:46] <PCW__> maybe its a good default choice for Preempt-RT dists (will test on mode hardware)
[23:06:58] <PCW__> s/mode/more/
[23:09:11] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[23:09:49] -!- Robh__ has quit [Ping timeout: 250 seconds]
[23:11:38] -!- teepee has quit [Ping timeout: 244 seconds]
[23:12:21] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[23:26:01] <CaptHindsight> skunksleep: lots of wear inside the spindle? or was it just poorly made?
[23:30:56] -!- kalxas has quit [Quit: Goodbye]
[23:36:15] -!- archivist has quit [Ping timeout: 250 seconds]
[23:36:24] -!- the_wench has quit [Ping timeout: 258 seconds]
[23:38:36] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[23:38:59] -!- the_wench [the_wench!~the_wench@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[23:41:06] -!- Gaston|Home has quit [Quit: No Ping reply in 180 seconds.]
[23:41:25] <jepler> for me, 4.1 had better rt performance than 4.4 or 4.6 on a newish i7, but I believe that's because I only did 4.1 tests without nvidia graphics enabled.
[23:42:13] -!- Gaston|Home [Gaston|Home!~quassel@rosie.office.tw.ly] has joined #linuxcnc-devel
[23:46:06] <PCW__> I think its the first 4.1.x kernel that worked on my N3150
