#linuxcnc-devel | Logs for 2014-02-28

Back
[01:34:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 05unified-build-candidate-3 cd064dc 06linuxcnc 10src/rtapi/rtapi_time.c use perf interface if no rdtsc instruction is known * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd064dc
[02:53:36] <mhaberler> Seb: the ARM tsc replacement fragment from the google code link works fine. Just have to figure the proper ARM #defines, ARMV6 isnt enough.
[03:48:52] <mhaberler> Seb: tentative patch for ARM TSC, please have a look : http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blobdiff;f=src/rtapi/rtapi_time.c;h=0d4c3ea421215fc46aafd811f33852d919e6b51d;hp=30683dad5914eac5e124534b10f6b0c4c8b977d7;hb=9135e4364ce931ff89698885b187afbb62c9d64e;hpb=771757a315303adecd7c97db9707a5e840ca1794
[03:49:12] <mhaberler> Jeff - in case you're around: I'd appreciate a look from you as well
[03:49:30] <mhaberler> eventually this should go into an archdep.h file in src/rtapi
[03:54:20] <mhaberler> oh man.. doubled up. I suggest to use my code as ARM read_tsc and Seb's perfcount method as fallback.
[04:51:13] <linuxcnc-build> build #7 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/7 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[04:51:14] <linuxcnc-build> build #1825 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1825 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:00:33] <skunkworks__> dgarr, cool video - are you playing with the new tp?
[11:03:16] <dgarr> a little-- rob is looking at my patches, the video is a demo for him; if you want to try, there is a patch set that applies to his branch named circular-blend-arc-experimental
[11:03:19] <dgarr> http://www.panix.com/~dgarrett/stuff/tptest_all.mbox
[11:07:41] <seb_kuzminsky> mhaberler: does that code work? how do you set the user enable bit?
[11:09:57] <seb_kuzminsky> i bet you tested on a xenomai kernel, and i bet it sets user enable for that register
[11:10:28] <seb_kuzminsky> the problem i reported occurs on the vanilla kernel (with bbb patches, but without xenomai patches)
[11:11:18] <seb_kuzminsky> the arm assembly fragment failed on my kernel (it killed my process with an Illegal Instruction signal, as you'd expect if user enable was not set on that reg)
[12:41:20] <seb_kuzminsky> mhaberler: would you mind taking a look at the test failure on wheezy-armhf from last night?
[12:41:38] <seb_kuzminsky> this is a build of glo/ubc, posix flavor, on a bbb
[12:41:57] <seb_kuzminsky> the threads.0 test failed:
[12:41:59] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/7/steps/runtests/logs/stdio
[12:42:06] <seb_kuzminsky> search for "threads.0: FAIL"
[12:48:32] <seb_kuzminsky> the result file recorded by halsampler is here: http://highlab.com/~seb/linuxcnc/threads.0-result
[12:49:15] <seb_kuzminsky> line 2491 shows a reset from 10, and halsampler reads 0 instead of 1
[12:49:55] <seb_kuzminsky> i think the only way that can happen is if the slow thread interrupts the fast thread between the threadtest.increment funciton and the halsampler read function
[12:50:22] <seb_kuzminsky> linuxcnc-build: force build --branch=unified-build-candidate-3 checkin
[12:50:23] <linuxcnc-build> build #1826 forced
[12:50:23] <linuxcnc-build> I'll give a shout when the build finishes
[13:09:23] <seb_kuzminsky> about that threads.0 test failure... it looks like the build doesn't set the capabilities on rtapi_app_posix? but shouldnt that make realtime_thread() print all those error messages? i dont see them anywhere
[13:10:04] <seb_kuzminsky> do i need DEBUG=5 or ULAPI_DEBUG=5 or something? i still dont understand what messages go where, in ubc :-/
[13:11:46] <CaptHindsight> I guess I should look into the BBB branch. Someone just asked me about an Evil Linuxcnc version where it runs from a remote server on a subscription basis :)
[13:14:42] <CaptHindsight> http://boingboing.net/2014/01/06/high-end-cnc-machines-cant-b.html
[13:19:49] <skunkworks__> does anyone have the 4 axis tort.ngc file?
[13:21:09] <skunkworks__> ie http://wiki.linuxcnc.org/uploads/planner-test.jpg
[13:24:54] <mozmck> CaptHindsight: I can't stand that kind of stuff (GPS on a milling machine?!?), but the article is a little ignorant: "A subtly weakened or defective part from a big mill like the NV5000 might find its way into a vehicle or a high-speed machine, with disastrous consequences." Huh?
[13:26:31] <mozmck> But I guess since the guy is a science fiction novelist, it's understandable ;)
[13:26:55] <archivist> scare mongering
[13:30:47] <skunkworks__> hmm - looks like the torture.py makes the 4 axis version
[13:32:46] <skunkworks__> hmm maybe not
[13:33:05] <skunkworks__> oh - yes it does
[13:37:02] <CaptHindsight> mozmck: wasn't sure how much was actual truth and how much is writers embellishment
[13:37:13] <CaptHindsight> http://www.practicalmachinist.com/vb/dmg-mori-gildemeister-maho-cnc/mori-ellison-gyroscope-unlocking-273841/
[13:37:45] <mozmck> :) I *think* most machine shops measure parts to make sure they meet specs.
[13:38:42] <CaptHindsight> mozmck: I'm sure on the QC but it was the machine tracking and subscription that got me thinking about controlling can a corp get
[13:38:58] <mozmck> that can include surface finish as well.
[13:39:24] <mozmck> Yes, I just read the practical machinist thread. Yuck!
[13:39:43] <CaptHindsight> ok, this is all coming together now
[13:39:50] <mozmck> Looks like it is probably gov requirements though
[13:40:13] <mozmck> and there's no limit to how controlling they can get...
[13:40:40] <CaptHindsight> I just met with a government lab and they are working on anti-counterfeit techniques built into devices for the military
[13:41:06] <CaptHindsight> this requirement makes since now
[13:41:38] <CaptHindsight> sense/since
[13:49:52] <CaptHindsight> ah and CNC machines needing to meet ITAR http://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations
[13:53:17] <skunkworks__> so.. is there a way to make the program display rotate instead of the tool? so the tool would stay vertical - but the program preveiw would rotate...
[13:53:49] <skunkworks__> The AXYZBC geomitry setting gets you 50% there..
[13:54:01] <skunkworks__> geometry
[15:03:38] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ini_includes 849884b 06linuxcnc 10(21 files in 2 dirs) linuxcnc.in: support ini with includes directives * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=849884b
[15:05:08] <seb_kuzminsky> that's cool dgarr
[15:06:56] <seb_kuzminsky> the #includes won't work for programs other than 'linuxcnc', such as sai
[15:07:05] <seb_kuzminsky> also, would you document it in the ini config docs?
[15:16:47] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_1_0 5797977 06linuxcnc 10(219 files in 22 dirs) gmoccapy 1.0 - stand alone , separated from gscreen * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5797977
[15:29:38] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_1_0 5ccf94a 06linuxcnc 10debian/linuxcnc.files.in gmoccapy 1.0 - changed the debian/linuxcnc.files.in file to make buildbot happy * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5ccf94a
[15:32:09] <KGB-linuxcnc> 03Norbert Schechner 05master 5ccf94a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5ccf94a
[16:20:16] <linuxcnc-build> build #0 of deb-wheezy-sim-binary-armhf is complete: Failure [4failed apt-get-update shell_1] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-wheezy-sim-binary-armhf/builds/0
[16:21:58] <seb_kuzminsky> aw yea
[16:22:24] <seb_kuzminsky> so the first wheezy-armhf build passed, and it went on to try to build wheezy-armhf (posix) debs, and that failed
[16:22:33] <seb_kuzminsky> the next mole rears its head!
[16:22:37] <linuxcnc-build> build #45 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/45
[16:22:41] <linuxcnc-build> build #45 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/45
[16:34:07] <linuxcnc-build> Hey! build checkin #1826 is complete: Success [3build successful]
[16:34:07] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1826
[16:49:00] <linuxcnc-build> build #46 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/46
[17:28:14] <linuxcnc-build> build #1415 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1415
[18:45:38] <zultron> Whack it, Seb!
[18:46:28] <seb_kuzminsky> i never stop whacking it
[18:48:03] <seb_kuzminsky> what are you doing for arm builds on your buildbot?
[18:57:36] <zultron> No ARM builds yet. There is a beaglebone port for Fedora 20.
[18:58:56] <zultron> I'm thinking I might run the ./configure step on the beaglebone, then do the actual build in a cross-compile enviroment on the fatty builder, then back to the beaglebone for runtests.
[19:00:54] <zultron> Half of the infra is already in place for that, so it wouldn't be too horrible after what it's already doing, where the fatty builds in a chroot, sequentially for each distro+arch, and special build slaves running the right distro+arch+kernel run the unit tests.
[19:02:09] <zultron> Off to dinner. See you later!
[19:21:59] <linuxcnc-build> build #10 of wheezy-armhf-sim is complete: Failure [4failed git] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/10 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:22:00] <linuxcnc-build> build #1827 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1827 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:32:26] <linuxcnc-build> build #11 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/11 blamelist: Norbert Schechner <nieson@web.de>
[19:46:14] <dgarr> i dont understand the buildbot fail: stdio says: 'warning: bad links found in Spanish docs!; oh well, continuing anway;... program finished with exit code 0"
[19:47:02] <dgarr> does it fail to build because of the output on stderr? "Error: no ID for constraint linkend: finding-maximum-velocity. ..." ?
[19:51:24] <dgarr> #1827 checkin
[20:08:12] <linuxcnc-build> build #1828 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1828 blamelist: Norbert Schechner <nieson@web.de>
[20:13:59] <seb_kuzminsky> dgarr: i added link-checking to our docs, but the unmaintained spanish docs are full of broken links, so i made broken links in that translation a warning instead of a build failure
[20:14:27] <seb_kuzminsky> the buildbot fails if a program returns with a non-zero exit code
[20:15:48] <linuxcnc-build> build #12 of wheezy-armhf-sim is complete: Failure [4failed apt-get-update compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/wheezy-armhf-sim/builds/12 blamelist: Norbert Schechner <nieson@web.de>
[20:15:55] <seb_kuzminsky> ugh
[20:16:05] <seb_kuzminsky> the buildbot *also* fails if you try to build master on arm :-(
[20:16:44] <dgarr> i thought the exit code was 0 step 3.1 stdio: http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1827
[20:16:57] <dgarr> i guess i don't know which or where to see that non-zero exit code
[20:18:35] <seb_kuzminsky> if you click on that stdio link you'll see this: program finished with exit code 0
[20:19:07] <dgarr> so the buildbot fails with exit code 0 ?
[20:20:17] <dgarr> i mean the program failed with exit code 0 build1827 so i thought it would build
[20:30:32] <seb_kuzminsky> linuxcnc debs (ubc) on armhf (beagle bone black): http://imgur.com/Q9HC8PF
[20:30:43] <seb_kuzminsky> dgarr: the step you pointed to (3.1) succeeded
[20:30:47] <seb_kuzminsky> the step after (4) failed
[20:31:08] <seb_kuzminsky> but it's a "trigger" step, so it just starts other builds on other machines, so it doesnt have any output
[20:31:32] <seb_kuzminsky> one (or more) of those other builds failed, but unfortunately there's no link in the trigger step :-(
[20:31:57] <seb_kuzminsky> you have to look for red in the waterfall page, http://buildbot.linuxcnc.org/buildbot/waterfall
[20:32:00] <seb_kuzminsky> bbl
[20:55:21] <linuxcnc-build> build #1829 of checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1829 blamelist: Norbert Schechner <nieson@web.de>
[20:57:26] <skunkworks> no issues with 4 axis and the new tp (although I think it falls back to parabolic blending which is pretty solid
[20:57:29] <skunkworks> http://imagebin.org/296431
[21:06:41] <Tom_itx> makes me dizzy
[21:09:05] <skunkworks> the torture.py program is still setup to create 4 axis torcher programs ;)
[21:11:49] <Tom_itx> where are all these test programs?
[21:14:09] <skunkworks> well - the torture.py happens to be in the scripts directory. There are a few programs that rob has added in the tests->trajectory-planner
[21:15:06] <seb_kuzminsky> linuxcnc-build: force build --branch=master checkin
[21:15:07] <linuxcnc-build> build #1830 forced
[21:15:07] <linuxcnc-build> I'll give a shout when the build finishes
[21:15:59] <skunkworks> seb_kuzminsky: sometimes a rebootis needed... ;)
[21:16:06] <skunkworks> rebootis?
[22:25:18] <linuxcnc-build> Hey! build checkin #1830 is complete: Success [3build successful]
[22:25:18] <linuxcnc-build> Build details are at http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1830
[22:37:30] <linuxcnc-build> build #2 of deb-wheezy-sim-binary-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-wheezy-sim-binary-armhf/builds/2
[22:40:16] <linuxcnc-build> build #1420 of deb-precise-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-amd64/builds/1420
[22:40:21] <linuxcnc-build> build #1421 of deb-precise-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-sim-binary-i386/builds/1421
[22:41:48] <linuxcnc-build> build #250 of deb-precise-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rt-binary-i386/builds/250
[22:42:43] <linuxcnc-build> build #1415 of deb-lucid-sim-binary-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1415
[22:57:42] <linuxcnc-build> build #1416 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1416
[22:59:27] <linuxcnc-build> build #1415 of deb-lucid-sim-binary-amd64 is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-amd64/builds/1415