Back
[06:52:48] <KGB-linuxcnc> 03Norbert Schechner 052.7 612ca3e 06linuxcnc 10docs/src/gui/gmoccapy.txt docs - minor changes to gmoccapy.txt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=612ca3e
[06:53:32] <KGB-linuxcnc> 03Norbert Schechner 05master fe60c7f 06linuxcnc 10docs/src/gui/gmoccapy.txt Merge branch '2.7' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe60c7f
[07:01:59] <jthornton> I have this short tutorial that used to work and I was revisiting them and now I get this error message
http://gnipsel.com/files/linuxcnc/gui/error.txt
[07:02:12] <jthornton> the short program
http://gnipsel.com/files/linuxcnc/gui/gui1.py
[07:02:24] <jthornton> the glade file
http://gnipsel.com/files/linuxcnc/gui/gui1.glade
[07:03:30] <Tom_itx> morning Mr. T
[07:06:48] <jthornton> morning Mr. T
[07:11:18] <Tom_itx> :)
[07:49:39] <jepler> >>> HAL: ERROR: duplicate component name 'gui01'
[07:50:05] <jepler> you have already loaded something else in your halrun / linuxcnc session with that name.
[07:50:57] <jthornton> thanks
[14:54:16] <seb_kuzminsky> skunkworks: if you start latency-test and get the the 1 ms spike, then quit latency-test and start it again, what happens?
[14:56:55] <skunkworks> same usually.
[14:59:20] <seb_kuzminsky> bummer
[14:59:26] <skunkworks> so - unless I did something wrong installing - 3rd machine exibiting the behavior..
[14:59:37] <skunkworks> that runs the wheezy livecd just fine
[15:00:13] <skunkworks> 2 of those machines give a rtai delay when starting axis. one doesn't
[15:00:34] <seb_kuzminsky> skunkworks: what does the rtai latency test say? /usr/realtime-3.16.0-9-rtai-686-pae/testsuite/kern/latency
[15:01:11] <seb_kuzminsky> is that the 2.7 live cd? or 2.6? rtai-5 is based on master, maybe something has changed in our test program
[15:01:21] <skunkworks> 2.7
[15:05:50] <skunkworks_> seb_kuzminsky: is there any settings I should do.. I is looking good doing a ./run
[15:06:10] <skunkworks_> 6800ns
[15:06:12] <skunkworks_> max
[15:06:20] <skunkworks_> running glx gears
[15:06:34] <skunkworks_> no spike at the begining
[15:06:46] <skunkworks_> I get the same spike on the latencyhistogram
[15:07:07] <skunkworks_> the rtai latency looks really good
[15:07:52] <seb_kuzminsky> ok, that's probably good news
[15:08:08] <skunkworks_> let me try the other system that was even worse.
[15:10:52] <skunkworks_> tsc: fast clock calibration failed? anything?
[15:11:00] <skunkworks_> just saw it fly by in dmesg
[15:11:15] <Roguish_test> seb: would you please look this over and let me know if the rtai-5 kernel is here. i am just not sure.
http://imgur.com/glTEBUP
[15:14:19] <seb_kuzminsky> skunkworks_: looking at the timedelta comp that latency-test uses, it looks like the first sample should always be ridiculously large, though it won't get included in min & max, etc
[15:14:50] <seb_kuzminsky> Roguish_test: yes, it's the file name vmlinuz-3.16.0-9-rtai-686-pae
[15:15:09] <seb_kuzminsky> ... which is identified as a DOS/Windows executable for some reason
[15:16:00] <seb_kuzminsky> Roguish_test: next you should run "uname -a" and make sure it says something like "Linux jessie-i386 3.16.0-9-rtai-686-pae #1 SMP PREEMPT Debian 3.16.7-5linuxcnc (2015-11-18) i686 GNU/Linux"
[15:16:07] <seb_kuzminsky> if not, you forgot to reboot to the new rtai kernel
[15:16:20] <skunkworks_> seb_kuzminsky: 10us so far...
[15:17:40] <skunkworks_> I will let the rtai run over night
[15:20:27] <Roguish_test> seb:
http://imgur.com/T4B4dlq
[15:20:53] <Roguish_test> I think I have booted in correctly.
[15:25:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 05rtai-5 bb58e08 06linuxcnc 10src/hal/components/timedelta.comp timedelta: don't glitch on the output pin on the first cycle * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb58e08
[15:25:48] <Roguish_test> so, you guys are seeing a big latency in just stating the latency test using the rtai-5 ?
[15:25:59] <skunkworks_> only me...
[15:26:01] <Roguish_test> starting
[15:26:02] <seb_kuzminsky> ^^^ doesn't fix skunkworks_' glitch
[15:26:29] <seb_kuzminsky> looks good Roguish_test, that's the right kernel
[15:26:43] <skunkworks_> aww
[15:26:48] <Roguish_test> I don't see here.
[15:27:24] <skunkworks_> wait a second - what does the test say 9 over runs? the max is 10362
[15:28:18] <skunkworks_> when I restart it it says 25 overruns
[15:28:29] <skunkworks_> restart it again and it says 116
[15:28:53] <skunkworks_> but ovl max is <10us
[15:30:38] <skunkworks_> it doesn't seem to increase while running...
[15:35:59] <seb_kuzminsky> uh oh
[16:34:56] <skunkworks> what does that even mean?
[18:15:53] * jepler pulls his hair out over the forum
[18:16:36] <jepler> why did I start engaging there? argh ugh blech
[18:17:28] <jepler> if I calm down maybe I can figure out the right way to say: adding SQL anything is the wrong answer when the goal is to fix a bug in a stable release
[18:31:50] <malcom2073> Lol
[18:32:11] * JT-Shop has to look now
[18:34:29] <malcom2073> Haha
[18:34:36] <malcom2073> "I can just write some LUA code to fix this"
[18:36:48] <cradek> a gui reading the var file to present offsets to the user is doing the wrong thing
[18:40:53] <JT-Shop> yep
[18:44:33] <mozmck> jepler: in order to be modern, the solution surely should be on the cloud.
[18:44:41] <JT-Shop> lol
[18:44:49] <Roguish> make a phone app
[18:45:09] <JT-Shop> eyepad
[18:46:23] <andypugh> I made a start on using SQL for the tool table…
[18:47:02] <mozmck> Doesn't pathpilot do that?
[18:47:48] <andypugh> It might. I know that I talked through the database format with Tormach.
[18:48:12] <andypugh> It would be interesting to see if they went with it.
[18:48:33] <mozmck> The source is available... I downloaded it but haven't had time to look at it yet.
[18:49:43] <JT-Shop> someone emailed the source to me... what a drain on my bandwidth
[18:50:02] <andypugh> It is possible that they went half-way, and just replaces the tool table file, rather than the whole tool offset transfer mechanism.
[18:51:03] <andypugh> It would be kind of annoying if they were using my work, and linuxCNC wasn’t.
[19:49:45] <jepler> cradek: I didn't want to even mention that bridge by name
[19:49:59] <jepler> tormach put all offsets in the stat buffer, I can tell you that much
[19:50:36] <jepler> cradek: unfortunately we can't currently offer any method *besides* parsing the var file, for a GUI that must display ALL offsets and not the active offset
[19:50:50] <jepler> I don't know what user story there is for viewing ALL offsets
[19:51:14] <jepler> do you check them against the correct offsets shown on a laminated card by the machine?
[21:05:06] <KGB-linuxcnc> 03Robert Ellenberg 05feature/reverse-run-master2 85ea15f 06linuxcnc New branch with 47 commits pushed, 1025 files changed, 03453(+), 04103(-) since master/fe60c7f
[22:16:16] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/uvw-blending-dev c87b004 06linuxcnc 10tests/motion-logger/basic/expected.g0 10tests/motion-logger/basic/expected.g1 test: adjust expected outputs to handle XYZUVW velocity and acceleration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c87b004
[22:17:36] <cradek> jepler: ooh could we isolate that tormach change?
[22:18:33] <cradek> jepler: maybe one user story is "I want to see if they're all cleared out"?
[22:21:13] <seb_kuzminsky> yay, rob updated the test that failed in the uvw branch
[23:10:31] <linuxcnc-build> build #195 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/195 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:10:56] <linuxcnc-build> build #195 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/195 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:11:30] <linuxcnc-build> build #1251 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1251 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:12:30] <linuxcnc-build> build #238 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/238 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[23:20:28] <linuxcnc-build> build #237 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/237 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>