Back
[13:13:43] <mozmck> pcw_home: did you say that the 4.1.7 rt kernel performed better than previous ones?
[13:19:51] <jepler> 09:58 <pcw_home> Linux pcw-G41M-Combo 4.1.7-rt8 #1 SMP PREEMPT
[13:19:52] <jepler> 09:58 <pcw_home> seems better then 4.1.5
[13:20:01] <jepler> back on 9/24
[13:20:29] <mozmck> thanks jepler, I thought I remembered something like that.
[13:20:54] <mozmck> I don't know if it's my config or hardware, but I'm not seeing any improvement over 3.18.11 so far.
[13:21:09] <jepler> 12:14 <PCW> Yeah. dont know if you noticed the LCNC forum7I80/7i77 thread, stock Debian Preemt-RT (3.2.xx) had terrible latency
[13:21:12] <jepler> 12:14 <PCW> 4.1.5 fixed it
[13:21:30] <PCW> 4.1.7 _seems_ to be better but its difficult to tell without a lot of testing since the latency spikes I see on my Core Duo are so infrequent
[13:22:06] <PCW> Oh yes 3.2 is bad on lots of newer hardware
[13:23:04] <PCW> 3.18 would likely have fixed the guys on the forums problem also
[13:25:20] <PCW> 3.2 wont even boot on lots of things ( Celeron 29XX's for example )
[13:27:51] <mozmck> Hi PCW, I've tested on a pentium 4, pentium D, and G3260 so far and don't see any improvement over 3.18.11 rt
[13:28:37] <mozmck> are you still using the stock config and just turning on preempt-rt?
[13:29:34] <PCW> I think the preempt-RT patch patches the config
[13:30:14] <mozmck> that could be, I'm using the ubuntu debian stuff to build with.
[13:31:30] <PCW> I think the major improvement I got was from stock to 3.18
[13:31:32] <PCW> but 4.x seems a bit better after a month or so uptime
[13:32:12] <mozmck> I see! I haven't run anything close to a month yet. maybe a day.
[13:32:40] <PCW> my H97 MB is still the best by quite a bit
[13:33:27] <skunkworks> mozmck, that video of machine/gui. nice work. That machine is fast.
[13:33:30] <mozmck> I have one I need to play with.
[13:33:40] <mozmck> thanks skunkworks
[13:34:01] <PCW> no problem running 4 Ethernet FPGA cards and 7 sserial remotes at 2 KHz for 3/4 weeks or so so
[13:34:09] <skunkworks> other than a few warts - happy with it?
[13:35:34] <mozmck> The rapids are 1000 in/min, and to cut thinner material you need to cut up to 300 in/min
[13:36:06] <mozmck> Yes, we are liking it. I still have some (lots!) of works to do.
[13:37:05] <PCW> Nice looking GUI mods
[13:37:59] <PCW> I guess the new TP still has a few bugs in corner cases
[13:38:48] <skunkworks> I want to make a video of me picking up network cable - looking at it with a blank expression shrugging - plugging it into the mill - launching linuxcnc and running a program.
[13:39:24] <skunkworks> pcw: saw that - sent the forum issue off to rob. he responded that he will have to look at it as it does seem like a TP issue
[13:48:39] <maxcnc> hi i discoverd a little bug
[13:48:56] <maxcnc> using #<_coord_system>
[13:49:20] <maxcnc> this gives me a out of range 0 for G54
[13:49:27] <maxcnc> i expected 1
[13:50:55] <maxcnc> G10 L20 P#>_coord_system> X[#<_x> /2)
[13:51:08] <maxcnc> <>?
[13:51:14] <maxcnc> ;-)
[13:51:37] <maxcnc> if i use p1 it works fine
[13:52:10] <jepler> hm
[13:53:00] <jepler> how do you know that you got 0?
[13:53:57] <jepler> note that G10 L20 P0 will refer to the active coordinate system, no need to use #<_coord_system>
[13:55:03] <maxcnc> will try that
[13:55:37] <jepler> READ => G54
[13:55:39] <jepler> READ => (DEBUG,#<_coord_system>)
[13:55:40] <jepler> 17 N..... MESSAGE("540.000000")
[13:55:56] <jepler> READ => G59.3
[13:56:00] <jepler> READ => (DEBUG,#<_coord_system>)
[13:56:00] <jepler> 21 N..... MESSAGE("593.000000")
[13:56:05] <maxcnc> i got lots of G53 in the tool change mdi commands so maybe then i will harm the mashine origin
[13:56:22] <maxcnc> if the G53 is executed befor
[13:56:25] <jepler> I get a different result than you describe: It is the G-code to enter that coordinate system multipled by 10
[13:56:51] <jepler> .. which is different than what the documentation says ..
[13:57:02] <maxcnc> ok
[13:57:54] <skunkworks> pug
[13:58:51] <maxcnc> ok P0 works fine for me THANKS
[13:58:58] <jepler> jthornton: will you please check the documentation for #<_coord_system>? I think it needs to be revised to match the implementation.
[14:07:06] <jepler> maxcnc: you're welcome
[18:36:39] <jthornton> jepler, will do
[18:41:33] <jthornton> #<_coord_system>' - Return index of the current coordinate system (G54..G59.3)
[18:41:45] <jthornton> is that incorrect?
[18:42:09] <jthornton> if I'm in G54 it returns 540.00000
[18:42:33] <jthornton> G59.3 returns 593.000000
[18:43:26] <jthornton> should it say "returns a float of the current coordinate system"?
[18:44:47] * jthornton reading back and I see the confusion about what it returns
[18:50:11] <KGB-linuxcnc> 03John Thornton 052.7 9b0d411 06linuxcnc 10docs/src/gcode/overview.txt Docs: correct and expand description of #<_coord_system> * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9b0d411
[19:03:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 1c5461c 06linuxcnc 10src/emc/task/emccanon.cc canon: fix bug #439, non-NCD arcs on machines with ABCUVW axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c5461c
[19:04:34] <jepler> jthornton: isn't the table below it just incorrect too?
[19:10:52] <KGB-linuxcnc> 03andypugh 05master 9833ec8 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/spindle.hal Change the Vismcah VMC demo to use the new orient.N.is-oriented pin * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9833ec8
[20:57:53] <seb_kuzminsky> i wish our website was a git repo instead of a joomla
[20:58:50] <seb_kuzminsky> how do you even see a diff of what you've changed? dont expect me to remember what i did like 30 seconds ago
[21:37:38] <cradek> if you have energy for it, I bet everyone would be open to a new website (but you have to not lose all the forum posts)
[21:40:04] <skunksleep> seb_kuzminsky: nice work on the w issue
[21:42:56] <cradek> yeah, that was fast
[21:43:25] <cradek> I don't understand how we got that regression
[21:58:03] <skunksleep> Any thoughts on time tool offset issue?
[22:05:48] <skunksleep> Tom's
[22:09:55] <seb_kuzminsky> cradek: it was in a big commit named "canon: bug fixes in ARC_FEED overhaul", which followed a giant commit named "Bulk overhaul of emccanon", too much for any of us to review & grok apparently
[22:10:12] <seb_kuzminsky> ... and our test suite obviously didnt cover it
[22:10:29] <seb_kuzminsky> i tried to write an interp test for it, but sai doesn't show UVW :-/
[22:10:47] <seb_kuzminsky> hmm, i think the bug shows up in ABC too, i could have tested that
[22:11:00] <seb_kuzminsky> skunksleep: what's the tool offset issue?
[22:12:59] <skunksleep> It was on the mailing list. Offset was applied seemingly before it should have.
[22:13:22] <seb_kuzminsky> i'm super behind on email
[22:14:01] * seb_kuzminsky approaches https://en.wikipedia.org/wiki/Email_bankruptcy
[22:15:52] <linuxcnc-build> build #1372 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1372 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:16:13] <seb_kuzminsky> well shit
[22:17:26] <skunksleep> That assumes you care that you have unread emails... I have thousands of them... :)
[22:28:36] <seb_kuzminsky> skunksleep: this one?
http://thread.gmane.org/gmane.linux.distributions.emc.devel/15245
[22:36:20] <seb_kuzminsky> i just started a sim lathe config and noticed that the splash screen says "EMC2 AXIS"...
[22:44:28] <skunksleep> seb_kuzminsky: yes
[22:47:25] <seb_kuzminsky> it seems to be doing the right thing, seems to me
[22:47:40] <seb_kuzminsky> in my testing here, i dont really understand exactly what tom was describing
[22:48:21] <seb_kuzminsky> i copied his gcode, added m2, and ran it in sim/axis/lathe in 2.7
[22:49:05] <seb_kuzminsky> when it pauses on N85, i hit escape, switch to MDI, and G53 G0 around, and it's going where it should go, according to the TLO of T1
[22:49:13] <seb_kuzminsky> guess i'll email him and ask some questions
[22:55:31] <linuxcnc-build> build #3471 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3471 blamelist: andypugh <andy@bodgesoc.org>
[23:06:41] <seb_kuzminsky> hm, dropped mdi again
[23:13:00] <seb_kuzminsky> I blame my anemic VMs:
[23:13:03] <seb_kuzminsky> USRMOT: ERROR: command timeout
[23:13:03] <seb_kuzminsky> emcTaskIssueCommand() returning: -2
[23:13:03] <seb_kuzminsky> task: main loop took 7.622931 seconds
[23:13:03] <seb_kuzminsky> NML_INTERP_LIST(0x80a80c0)::append(nml_msg_ptr{size=268,type=EMC_TASK_PLAN_EXECUTE}) : list_size=2, line_number=0
[23:13:06] <seb_kuzminsky> NML_INTERP_LIST(0x82eeb48)::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
[23:13:09] <seb_kuzminsky> mdi_execute_abort: dropping 2 queued MDI commands