Back
[00:09:44] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[00:09:46] -!- kalxas has quit [Quit: Goodbye]
[00:28:51] -!- Loetmichel has quit [Ping timeout: 248 seconds]
[00:29:16] -!- theorbtwo has quit [Ping timeout: 244 seconds]
[00:30:30] -!- leafletnewb has quit [Quit: Page closed]
[00:41:01] Jymmmm is now known as Jymmm
[01:02:27] -!- asdfasd has quit [Ping timeout: 260 seconds]
[01:09:33] -!- radish has quit [Ping timeout: 240 seconds]
[01:10:16] -!- pozzoni has quit [Ping timeout: 250 seconds]
[01:25:33] -!- Duc has quit [Ping timeout: 240 seconds]
[01:32:32] <mozmck> ah, yes - it's on a different IRC server.
[01:35:40] <mozmck> irc.oftc.net is how I'm connected to it.
[01:46:55] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:48:08] <linuxcnc-build> build #4029 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4029 blamelist: Jeff Epler <jepler@unpythonic.net>, Norbert Schechner <nieson@web.de>
[01:51:34] <linuxcnc-build> build #644 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/644 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[01:51:34] <linuxcnc-build> <email@honzamrazek.cz>
[01:51:42] -!- Polymorphism has quit [Ping timeout: 246 seconds]
[01:51:53] <linuxcnc-build> build #644 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/644 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>,
[01:51:53] <linuxcnc-build> Jan Mr?zek <email@honzamrazek.cz>
[01:52:15] <linuxcnc-build> build #644 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/644 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner
[01:52:15] <linuxcnc-build> <nieson@web.de>, Jan Mr?zek <email@honzamrazek.cz>
[01:52:33] <linuxcnc-build> build #644 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/644 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[01:52:33] <linuxcnc-build> <email@honzamrazek.cz>
[01:57:56] <linuxcnc-build> build #4018 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/4018 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[01:57:56] <linuxcnc-build> <email@honzamrazek.cz>
[01:58:16] <linuxcnc-build> build #2177 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/2177 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[01:58:16] <linuxcnc-build> <email@honzamrazek.cz>
[01:58:44] <linuxcnc-build> build #2176 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/2176 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[01:58:44] <linuxcnc-build> <email@honzamrazek.cz>
[01:59:08] <linuxcnc-build> build #1842 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1842 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan
[01:59:08] <linuxcnc-build> Mr?zek <email@honzamrazek.cz>
[02:00:24] <linuxcnc-build> build #4016 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/4016 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[02:00:24] <linuxcnc-build> <email@honzamrazek.cz>
[02:01:04] <linuxcnc-build> build #2372 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/2372 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner
[02:01:04] <linuxcnc-build> <nieson@web.de>, Jan Mr?zek <email@honzamrazek.cz>
[02:01:22] <linuxcnc-build> build #1687 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/1687 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner
[02:01:22] <linuxcnc-build> <nieson@web.de>, Jan Mr?zek <email@honzamrazek.cz>
[02:01:49] <linuxcnc-build> build #3227 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/3227 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan
[02:01:49] <linuxcnc-build> Mr?zek <email@honzamrazek.cz>
[02:11:12] <linuxcnc-build> build #2210 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/2210 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek
[02:11:12] <linuxcnc-build> <email@honzamrazek.cz>
[02:11:13] <linuxcnc-build> build #4030 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4030 blamelist: Jeff Epler <jepler@unpythonic.net>, Chris Morley <chrisinnanaimo@hotmail.com>, John Thornton <bjt128@gmail.com>, Norbert Schechner <nieson@web.de>, Jan Mr?zek <email@honzamrazek.cz>
[02:17:33] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[02:18:00] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:d1cb:c616:6fc3:25e0] has joined #linuxcnc-devel
[02:22:47] <linuxcnc-build> build #4019 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/4019 blamelist: Norbert Schechner <nieson@web.de>
[02:24:08] <linuxcnc-build> build #4017 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/4017 blamelist: Norbert Schechner <nieson@web.de>
[02:24:48] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8201:5d87:d1cb:c616:6fc3:25e0] has parted #linuxcnc-devel
[02:26:37] <linuxcnc-build> build #3228 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/3228 blamelist: Norbert Schechner <nieson@web.de>
[02:26:44] <linuxcnc-build> build #2178 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/2178 blamelist: Norbert Schechner <nieson@web.de>
[02:26:45] <linuxcnc-build> build #2177 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/2177 blamelist: Norbert Schechner <nieson@web.de>
[02:27:54] <linuxcnc-build> build #645 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/645 blamelist: Norbert Schechner <nieson@web.de>
[02:27:57] <linuxcnc-build> build #645 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/645 blamelist: Norbert Schechner <nieson@web.de>
[02:28:59] <linuxcnc-build> build #645 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/645 blamelist: Norbert Schechner <nieson@web.de>
[02:29:00] <linuxcnc-build> build #2373 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/2373 blamelist: Norbert Schechner <nieson@web.de>
[02:29:05] <linuxcnc-build> build #1688 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/1688 blamelist: Norbert Schechner <nieson@web.de>
[02:29:23] <linuxcnc-build> build #645 of 1500.rip-jessie-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/645 blamelist: Norbert Schechner <nieson@web.de>
[02:29:28] <linuxcnc-build> build #1843 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1843 blamelist: Norbert Schechner <nieson@web.de>
[02:34:00] <linuxcnc-build> build #2211 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/2211 blamelist: Norbert Schechner <nieson@web.de>
[02:35:49] <linuxcnc-build> build #4031 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4031 blamelist: Norbert Schechner <nieson@web.de>
[02:37:06] -!- Nick001 has quit [Read error: Connection reset by peer]
[02:42:16] <KGB-linuxcnc> 03Jeff Epler 052.7 9d6a5bc 06linuxcnc 10src/emc/task/taskintf.cc interp: fix build error on Ubuntu 16.04 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d6a5bc
[02:42:16] <KGB-linuxcnc> 03Jeff Epler 052.7 b8ca05c 06linuxcnc 10docs/src/gui/gladevcp.txt docs: fix build error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8ca05c
[02:42:16] <KGB-linuxcnc> 03Jeff Epler 052.7 5954dcf 06linuxcnc 10docs/src/Submakefile build: make failure copying images an error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5954dcf
[02:49:39] <jepler> https://sourceware.org/bugzilla/show_bug.cgi?id=5781#c9
[02:49:47] <jepler> > I have also come across a very similar issue on i7 Intel platforms, please see bug 16531. Calls to cos can take around 0.15 ms, 1000 times their normal time, which is a serious problem for the real-time system we are developing.
[02:49:51] <jepler> ouch
[02:51:37] <jepler> I documented something similar at $DAY_JOB, and I think I talked about it here, where I found that under glibc's exp() the worst case could be 2000x the average case
[02:52:43] <jepler> .. certainly while doing circular interpolation I know motion will be calling sin and cos. I wonder if that is the cause of pcw's observation that there are very rare spikes in the runtime of motion
[02:53:17] <cradek> is he on x86_64?
[02:53:42] <pcw_home> Yeah, I wonder if that explains motion-command-handlers 60 usec spikes
[02:53:55] <jepler> that poster doesn't say. I think back when I was fiddling around I was using 64-bit code but I'm not sure
[02:55:07] <cradek> this bug says it's 64 bit only
[02:55:18] <jepler> yes, elsewhere in the thread it says that 32-bit x86 is using x87 for math
[02:56:11] -!- Polymorphism has quit [Changing host]
[02:56:17] <jepler> pcw_home: 64-bit userspace on your system?
[02:56:27] <pcw_home> no, 32
[02:56:49] <cradek> how rare is very rare?
[02:57:01] -!- AR_ has quit [Ping timeout: 248 seconds]
[02:58:36] <jepler> http://paste.debian.net/424581/
[02:58:47] <pcw_home> motion-command handler median time on this machine is about 100 ns spikes a couple times a day are 60 usec
[02:58:59] <jepler> my findings ^^
[02:59:24] <jepler> I seem to have misplaced the program I ran to look for problem cases, which was just a random search and a print every time it found a new highest-time input..
[02:59:47] <jepler> plus something fancy to call the same exp() a bunch of times in a row to make sure I wasn't counting a task switch
[03:00:23] <pcw_home> let me plot it
[03:00:46] <jepler> aha
https://emergent.unpythonic.net/files/sandbox/mathbench.cc (compile with g++ -std=c++11 -O or so)
[03:02:12] <jepler> hm I see it doesn't even print the culprit values :-/ derp
[03:03:08] <jepler> anyway with -m64 the first printout (1 million trials) it already clocks some runs in the 2^13 range, while with -m32 it doesn't clock any above 2^8 within 1 minute (same core i7 system)
[03:05:41] <jepler> .. updated with version that prints last value seen in each bin ..
[03:16:45] <jepler> for 32-bit targets, I also tested sin, atan2, hypot and didn't find any outlier behavior
[03:17:11] <jepler> so no, if it's a 32-bit system this is probably not the explanation for occasional thread time spikes
[03:18:40] -!- BeachBumPete has quit [Ping timeout: 268 seconds]
[03:22:50] <jepler> I didn't grep to see what other libm functions are used, that's all guessing on my part
[03:30:46] SpeedEvil is now known as Guest21328
[03:31:05] -!- Guest21328 has quit [Read error: Connection reset by peer]
[03:31:35] <pcw_home> https://imagebin.ca/v/2cmST4sB12z8
[03:31:37] <pcw_home> the biggest spikes there are about 20 usec
[03:31:38] <pcw_home> but occasionally get to 60 usec
[03:32:21] -!- JT-Shop has quit [Read error: Connection reset by peer]
[03:32:21] -!- jthornton has quit [Read error: Connection reset by peer]
[03:33:05] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[03:33:05] -!- JT-Shop [JT-Shop!~emc@198.45.191.246] has joined #linuxcnc-devel
[03:37:36] <pcw_home> ( and the spikes seem to be dependent on the gcode being run )
[03:42:06] <pcw_home> https://imagebin.ca/v/2cmVnlYB6EAQ
[03:42:08] <pcw_home> big flurry of activity at start of motion
[03:49:07] -!- unfy has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
[03:53:51] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[03:54:32] <skunksleep> Calculating the path? (Look ahead)
[03:56:17] <pcw_home> maybe
[03:56:18] <pcw_home> I just dont see how you get to 60 usec (~180000 inst)
[03:56:58] <linuxcnc-build> build #1173 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/1173 blamelist: Jeff Epler <jepler@unpythonic.net>
[03:59:12] <skunksleep> You could set the look ahead lower for grins and see if it improves
[04:00:22] -!- Polymorphism has quit [Ping timeout: 260 seconds]
[04:02:52] -!- eFuchs has quit [Ping timeout: 264 seconds]
[04:04:11] -!- kwallace [kwallace!~kwallace@162.222.30.12] has parted #linuxcnc-devel
[04:04:24] <pcw_home> Ill try disabling the new TP o see if that makes any difference
[04:04:38] <linuxcnc-build> build #1173 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/1173 blamelist: Jeff Epler <jepler@unpythonic.net>
[04:05:57] <skunksleep> I dont know how that works.. The trajectory planner in real-time plans the path every servo cycle. How does it know how much time it has? Or does it add only 1 segment every servo cycle (because it is unlikely you will have segments that take 1 servo cycle so you gain on the que)
[04:14:40] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[04:16:35] -!- teepee has quit [Ping timeout: 244 seconds]
[04:16:35] teepee_ is now known as teepee
[04:17:19] <pcw_home> the spikes do appear to be TP related (old TP seems to have much lower max times)
[04:18:43] -!- skunksleep has quit [Ping timeout: 248 seconds]
[04:39:50] -!- phillcarter [phillcarter!~phillcart@oztime.lnk.telstra.net] has joined #linuxcnc-devel
[05:06:52] -!- steves_logging has quit [Ping timeout: 250 seconds]
[05:08:04] <linuxcnc-build> build #4033 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4033 blamelist: Jeff Epler <jepler@unpythonic.net>
[05:13:46] -!- anth0ny has quit [Quit: anth0ny]
[06:04:07] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[06:42:04] -!- sabrex has quit [Read error: Connection reset by peer]
[06:49:24] -!- GJdan has quit [Quit: WeeChat 1.5-dev]
[06:58:43] -!- FloppyDisk has quit [Ping timeout: 252 seconds]
[07:01:54] -!- ve7it has quit [Remote host closed the connection]
[07:20:56] -!- rob_h [rob_h!~robh@90.208.148.138] has joined #linuxcnc-devel
[07:22:05] -!- skunksleep has quit [Ping timeout: 250 seconds]
[07:43:18] -!- Daerist has quit [Quit: Leaving]
[07:52:21] -!- gambakufu has quit []
[08:26:05] -!- Komzzpa has quit [Ping timeout: 248 seconds]
[09:00:25] -!- b_b has quit [Changing host]
[09:27:37] -!- nofxx has quit [Ping timeout: 260 seconds]
[10:21:29] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[10:26:04] -!- skunksleep has quit [Ping timeout: 252 seconds]
[10:28:38] -!- unfyhome has quit [Ping timeout: 250 seconds]
[10:41:15] -!- skunkworks has quit [Ping timeout: 264 seconds]
[11:24:58] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:25:08] <skunkworks> wow..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150558
[11:28:08] <skunkworks> such advancements!!
[11:28:09] <skunkworks> Imagine being able to touch the graphics screen and rotate the screen around in 3D space. While it is running! Let's see Fanuc do that! Or use the mouse to pan and zoom the display. How about pausing the motion and the motion immediately stops.
[11:46:46] -!- b_b has quit [Remote host closed the connection]
[11:50:53] <skunkworks> I initially had the spindle encoder plugged into encoder.00 - so when I rotated the spindle - X dro would count ;)
[11:54:20] -!- Tecan has quit [Ping timeout: 244 seconds]
[11:54:44] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[12:01:25] <Tom_itx> we all need to rotate our screens
[12:01:55] <Tom_itx> makes parts cut so much better
[12:03:26] md-2 is now known as md2|lunch
[12:05:47] BitEvil is now known as SpeedEvil
[12:06:25] -!- rwlloyd has quit [Client Quit]
[12:12:42] -!- rob_h has quit [Ping timeout: 260 seconds]
[12:13:42] -!- rob_h [rob_h!~robh@90.207.192.44] has joined #linuxcnc-devel
[12:18:59] <skunkworks> You didn't dare touch the preview in mach3 because it would cause motion problems
[12:22:22] <skunkworks> sorry * 'could cause motion problems..'
[12:35:10] -!- gaute has quit [Ping timeout: 250 seconds]
[12:45:17] <skunkworks> https://www.youtube.com/watch?v=MaH_Nlh4sxk
[12:46:56] <skunkworks> zlog
[12:46:56] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-04-06.html
[12:50:19] -!- Mathnerd314 has quit [Ping timeout: 268 seconds]
[12:50:22] <archivist> I would not dare measure that on my thread pitch measuring machine :)
[12:53:00] -!- Valen has quit [Remote host closed the connection]
[12:54:17] -!- chillly has quit [Quit: Ex-Chat]
[12:54:19] <skunkworks> It is hard to see - but it sure looks like the thread gauge doesn't fit well
[12:54:44] <skunkworks> you can see the shavings are inconsistant - the second to the last path takes hardly nothing
[12:55:09] <skunkworks> but the nut fits
[12:55:28] <archivist> rattling fit
[12:55:40] <skunkworks> ;)
[12:57:24] -!- Komzzpa has quit [Ping timeout: 260 seconds]
[12:58:00] <archivist> funny thing is, a rattling fit is a requirement in clockmaking
[12:58:24] <archivist> but it has to the right rattle
[13:02:52] -!- Polymorphism has quit [Ping timeout: 260 seconds]
[13:05:41] md2|lunch is now known as md2
[13:05:49] md2 is now known as md-2
[13:06:27] -!- gregcnc has quit [Read error: Connection reset by peer]
[13:15:38] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[13:49:13] -!- Tecan has quit [Changing host]
[14:04:06] -!- Polymorphism has quit [Ping timeout: 276 seconds]
[14:07:38] -!- anth0ny has quit [Quit: anth0ny]
[14:09:04] -!- kwallace [kwallace!~kwallace@162.222.30.12] has joined #linuxcnc-devel
[14:26:49] -!- dannybloe has quit [Quit: Page closed]
[14:45:12] -!- jthornton has quit [Read error: Connection reset by peer]
[14:45:26] -!- JT-Shop has quit [Read error: Connection reset by peer]
[14:45:52] -!- JT-Shop [JT-Shop!~emc@198.45.191.246] has joined #linuxcnc-devel
[14:45:59] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[14:46:28] -!- japio has quit [Ping timeout: 250 seconds]
[14:59:51] -!- radish has quit [Ping timeout: 244 seconds]
[15:24:56] -!- swarfer has quit [Quit: swarfer]
[15:31:25] <seb_kuzminsky> jessie-backports has a 4.4.6-rt kernel
[15:38:15] -!- b_b has quit [Changing host]
[15:43:09] SpeedEvil is now known as Guest40220
[15:43:14] -!- Guest40220 has quit [Ping timeout: 244 seconds]
[15:46:19] <pcw_home> wonder if its any good, all the 4.4.x kernels I've tried were terrible
[15:46:37] <pcw_home> (latency or stability wise)
[15:50:45] <pcw_home> so big spikes in motion-command-handler.time seem to be from new TP
[15:50:47] <pcw_home> ~17 us peak with old TP vs 71 usec peak with new
[15:53:22] <mozmck> how often do you see them?
[15:53:29] <cradek> wonder if there's a trouble situation that could be massaged
[15:53:43] <pcw_home> its gcode dependent
[15:54:01] <cradek> can you make a minimized gcode program that causes one?
[15:54:02] <mozmck> oh, I see you said a couple times a day...
[15:55:00] BitEvil is now known as SpeedEvil
[15:55:35] <pcw_home> i have been running a very dense torus png to gcode program to test things and it takes hours to run but I suspect a simple test would show the issue
[15:56:37] <cradek> if you can trigger on it, plot motion.program-line
[15:56:48] <pcw_home> this is with a 3.16 Ghz core duo, an Atom might trip on this at anything faster than 1 KHz or so
[15:59:29] <pcw_home> yeah let me try a shorter program
[15:59:29] -!- FloppyDisk has quit [Read error: Connection reset by peer]
[15:59:29] -!- Komzzpa has quit [Ping timeout: 252 seconds]
[16:15:51] <seb_kuzminsky> heh yeah my machine crashed with that rt kernel in the first 5 minutes
[16:18:36] <pcw_home> Ive had much better luck with the 4.1.x kernels
[16:23:29] <jepler> $ uname -a; uptime
[16:23:29] <jepler> Linux babs 4.4.0-trunk-rt-amd64 #1 SMP PREEMPT RT Debian 4.4.1-1~0.jepler8~1 (2016-02-16) x86_64 GNU/Linux
[16:23:32] <jepler> 11:23:23 up 24 days, 23:01, 130 users, load average: 0.52, 0.52, 0.46
[16:23:54] <jepler> I've had fine luck on 4.4, though without a close eye on latency. also 64-bit kernel and userspace here, it could matter(?)
[16:24:19] <pcw_home> Ive had stable with terrible latency or great latency and hard crashes
[16:25:05] <pcw_home> but I've only done 32 bit
[16:31:34] -!- floppydisk-ph has quit [Read error: Connection reset by peer]
[16:33:01] -!- XXCoder has quit [Ping timeout: 248 seconds]
[16:33:42] <pcw_home> ( terrible meaning 100s of usecs )
[16:34:20] <pcw_home> great latency meaning 24 or so usec on the core Duo and 7 or so usec on the G3258
[16:36:13] -!- floppydisk-ph1 has quit [Ping timeout: 252 seconds]
[16:42:55] -!- elhe has quit [Quit: Leaving]
[16:44:20] <pcw_home> Ha just got 91 usec peak motion-command-handler time but my trigger was set too low so lost the program line
[16:46:51] -!- ReadError has quit [Excess Flood]
[16:51:20] <cradek> interesting - I would expect it to be -controller, not -command-handler
[16:51:33] <cradek> it's almost as if I don't know how any of that works
[16:52:30] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[16:53:54] <pcw_home> motion controller is less spikey (maybe 10-1 max vs average)
[16:54:26] <pcw_home> command handler is more like 1000-1
[16:59:50] -!- floppydisk-ph has quit [Read error: Connection reset by peer]
[17:00:07] -!- ReadError has quit [Excess Flood]
[17:00:11] -!- maxcnc has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0/20160304114926]]
[17:21:57] <pcw_home> spikes _seem_ to happen at G0
[17:30:12] <pcw_home> hard to tell, another large spike at G1-G2
[17:30:48] <pcw_home> sorry G2 --> G1
[17:40:05] -!- swarfer has quit [Quit: swarfer]
[17:42:33] -!- tobias47n9e has quit [Ping timeout: 240 seconds]
[17:52:31] -!- anth0ny has quit [Quit: anth0ny]
[17:53:16] -!- anth0ny has quit [Client Quit]
[17:53:43] -!- Nick001 has quit [Ping timeout: 268 seconds]
[17:53:56] Nick001_ is now known as Nick001
[17:54:51] -!- Nick001-shop has quit [Ping timeout: 276 seconds]
[17:55:00] Nick001-shop_ is now known as Nick001-shop
[18:02:26] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:02:44] -!- SpeedEvil has quit [Ping timeout: 244 seconds]
[18:02:59] <cradek> I don't understand why command-handler is even doing anything when gcode is just running
[18:04:13] -!- rob_h has quit [Ping timeout: 248 seconds]
[18:04:55] -!- rob_h [rob_h!~robh@94.3.110.218] has joined #linuxcnc-devel
[18:06:51] -!- Bushman has quit [Ping timeout: 244 seconds]
[18:09:13] <PCW> its hard to tell there may be significant delays between the line number and the delay spike
[18:09:42] <PCW> the spikes are not there if gcode is not running
[18:22:09] <cradek> do you have them fairly reproducable now?
[18:22:25] <cradek> you said an older version didn't do it. you could, in theory, bisect it
[18:27:10] -!- orangey has quit [Remote host closed the connection]
[18:44:31] <PCW> if i disable the new TP t get only 1/5 the spike magnitude
[18:44:38] <PCW> I get
[18:46:03] -!- orangey has quit [Ping timeout: 264 seconds]
[18:56:54] <jepler> I bet -command-handler does very very little if there isn't actually a command for it to read from task via shared memory..
[18:58:26] <jepler> what we may need is a way to finally split the command-handler and controller into separate HAL functions that can go on different threads
[18:59:01] <PCW> yes on the core duo average is a couple hundred instructions (say 100 ns)
[18:59:02] <jepler> .. but they mutually touch so much structured data and that means it's a lot of work to make sure controller never sees a partially updated memory area
[18:59:51] <PCW> wonder why the new TP is so much worse
[19:07:39] <skunkworks> I assume it is doing a lot more math?
[19:08:46] <seb_kuzminsky> does it get better if you turn down the look-ahead?
[19:10:07] <PCW> I didnt try that yet, I need a better torture gcode with mixes of G2,G3, G1 an G0
[19:11:31] -!- eFuchs_mobil has quit [Remote host closed the connection]
[19:23:28] <skunkworks> PCW, is that time or clock cycles?
https://imagebin.ca/v/2cmVnlYB6EAQ
[19:28:49] -!- miss0r has quit [Quit: Leaving]
[19:31:42] * skunkworks is aways confused as to what is time and what is clock cycles
[19:42:32] <jepler> skunkworks: it's not well-documented, let alone clear from e.g., pin names...
[19:43:20] <PCW> clock cycles
[19:43:32] <PCW> (at 3.16 GHz)
[19:46:43] -!- kingarmadillo has quit [Ping timeout: 248 seconds]
[19:50:53] <skunkworks> isn't 60k 18us?
[19:52:49] <PCW> yes, about
[19:54:40] <PCW> the peaks on the core duo (using the tmax parameter) are up to 91 usec ( ~288000 clocks )
[19:54:58] <skunkworks> ah - ok
[19:58:16] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:01:53] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[20:05:06] -!- teepee has quit [Ping timeout: 246 seconds]
[20:05:06] teepee_ is now known as teepee
[20:11:08] -!- b_b has quit [Remote host closed the connection]
[21:01:31] -!- FinboySlick has quit [Quit: Leaving.]
[21:07:34] -!- Deejay has quit [Quit: bye]
[21:18:02] -!- nofxx has quit [Ping timeout: 244 seconds]
[21:19:35] -!- SpeedEvil has quit [Quit: No Ping reply in 210 seconds.]
[21:45:19] -!- maybekoo2 has quit [Ping timeout: 260 seconds]
[21:49:33] -!- chillly has quit [Quit: Ex-Chat]
[22:16:20] -!- Guest57762 has quit [Quit: Page closed]
[22:19:47] -!- archivist_herron has quit [Ping timeout: 248 seconds]
[22:26:33] -!- DaViruz has quit [Ping timeout: 276 seconds]
[22:26:57] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.92 [Firefox 39.0.3/20150806001005]]
[22:43:37] -!- Mathnerd314 has quit [Ping timeout: 252 seconds]
[22:45:30] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:47:11] <skunkworks> zlog
[22:47:12] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-04-06.html
[22:47:48] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[22:49:47] -!- jasen_ has quit [Quit: Page closed]
[22:52:33] -!- Duc has quit [Ping timeout: 244 seconds]
[22:55:26] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[23:05:30] <andypugh> This is a strange one:
[23:05:31] <andypugh> http://www.pastebin.ca/3455566
[23:06:08] <andypugh> This is my generic turning sub, called from a galdVCP button that does an O<sub> call with a bunch of paramters.
[23:07:09] <andypugh> If I machine a taper (#6) then it works fine, until I set the taper angle back to zero. Then I get the very odd erir message “unknown operation beginning with e”
[23:07:30] -!- rob_h has quit [Ping timeout: 276 seconds]
[23:08:49] <andypugh> Sorry, mis-reading my own G-code. #7 is the taper angle.
[23:15:27] -!- eFuchs has quit [Remote host closed the connection]
[23:26:27] <jepler> O106 ENDIF
[23:26:32] <jepler> surely it's not the double space here
[23:27:02] <jepler> .. I don't see anything obvious but I only spent about 2 minutes looking at the code
[23:28:03] <andypugh> I can try removing the spare space.
[23:28:52] <andypugh> I could also make the condition [LT -0.00001] too.
[23:33:28] <jepler> I didn't succeed in making it happen here
[23:34:12] <jepler> I ran with sim/axis/lathe.ini, moved the capture of <_x> and <_z> to before the tool change, and called it like:
[23:34:15] <jepler> G0 X0 Z.5
[23:34:18] <jepler> O<turning> call [1] [300] [1] [99] [1] [1] [0]
[23:34:20] <jepler> tested with recent-ish master-ish branch
[23:34:32] <jepler> full file is
https://emergent.unpythonic.net/files/sandbox/tu.ngc
[23:36:31] -!- KimK_laptop [KimK_laptop!~Kim@helixmachine.com] has joined #linuxcnc-devel
[23:39:07] <andypugh> I think it is something wierd with the GUI passing a very, very, small negative number in param #7
[23:39:42] <cradek> well that's a quite inscrutable error then
[23:42:44] <andypugh> I will investigate tomorrow maybe, I was more interested in making parts today.
[23:43:29] <cradek> do you mean: Unknown operation name starting with e
[23:43:44] <andypugh> Sounds about right
[23:44:41] <cradek> heh "operation name"
[23:44:55] <andypugh> I wonder if something is getting “error” passed as a number from Python/Glade
[23:44:56] <cradek> that means it's inside [square brackets] and is e not followed by q (making eq)
[23:45:15] <cradek> I can get that by typing #1 = tan[1e-10]
[23:45:21] <cradek> but ... I can't imagine how you'd get that
[23:45:23] <andypugh> Aha!
[23:45:31] <cradek> but how...!?
[23:45:50] <andypugh> The numbers come from a spinbox in my lathe gui
[23:46:08] * cradek squints
[23:46:14] <cradek> I'm still not seeing it
[23:46:43] <cradek> ohhhh it constructs a mdi call and you think it's saying O1 call [1e-10]?
[23:46:47] <andypugh> Well, the number displays as -0.000000 but perhaps Glade is passing “1e-300” or something?
[23:47:02] <andypugh> Yes,
[23:47:19] <cradek> ok, at first I didn't think of it literally being in the mdi call line
[23:47:27] <andypugh> But, typing “0” in the box and pressing enter doesn’t fix it. Which is annoying
[23:47:48] <cradek> yuck, so maybe it's a gui/spinbox/toolkit problem
[23:48:56] <andypugh> The MDI GladVCP button lest you use a special syntax to substitute python variables into the MDI.
[23:49:49] <cradek> so maybe it's using something like %g when it should use something like %f
[23:50:12] <andypugh> http://linuxcnc.org/docs/2.7/html/gui/gladevcp.html#_parameter_passing_with_action_mdi_and_toggleaction_mdi_widgets
[23:50:34] <jepler> >>> "%s" % 1e-100
[23:50:34] <jepler> '1e-100'
[23:50:34] <jepler> >>> "%f" % 1e-100
[23:50:35] <jepler> '0.000000'
[23:50:39] <andypugh> (it’s HAL pins, now I look, not Python variables)
[23:51:30] <jepler> ..I see that you have no control at the configuration level over how gladevcp is turning the float value into a string value..
[23:52:55] <andypugh> Argh! Why is GitHub search so _deliberately_ broken?
[23:54:02] <jepler> it is using Python string.Template
[23:54:02] <jepler> >>> string.Template("${x}").substitute(x=1e-10)
[23:54:02] <jepler> '1e-10'
[23:54:18] <jepler> string.Template doesn't seem to give any control over how a non-string object is converted to a string, it always does it by str()
[23:54:33] <jepler> so there's no spot to change from %g to %f or whatever
[23:55:01] <jepler> $ git grep -n Template -- "*.py"
[23:55:02] <jepler> lib/python/gladevcp/hal_actions.py:437:class HalTemplate(string.Template):
[23:55:05] <jepler> lib/python/gladevcp/hal_actions.py:461: template = HalTemplate(self.command)
[23:56:51] <andypugh> I was using the github version of the sourcecode purely so it was easy to post a link. But th search is so utterly broken “You can't use the following wildcard characters as part of your search query: . , : ; / \ ` ' " = * ! ? # $ & + ^ | ~ < > ( ) { } [ ]. The search will simply ignore these symbols.”
[23:57:14] <cradek> oh sure, you'd never find those in source code anyway
[23:58:04] <jepler> https://emergent.unpythonic.net/files/sandbox/0001-untested-work-around-1e-10-problem.patch
[23:58:41] <cradek> 1?
[23:58:59] <jepler> I said untested!
[23:59:28] <jepler> but yeah it's much more likely to work without that line