Back
[00:45:00] <linuxcnc-build> build #34 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/34 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[00:45:09] <linuxcnc-build> build #34 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/34 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:12:02] <linuxcnc-build> build #34 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/34 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[01:41:58] <linuxcnc-build> build #1334 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/1334 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:24:33] <skunkworks> PCW, Yay - no watchdog bite. Flashing a GPIO
[08:24:52] <skunkworks> micges, ^ Great work!
[08:48:03] <micges> skunkworks: that's good, try any hardware if you have
[08:51:26] * skunkworks needs to order some hardware..
[08:51:54] <micges> :)
[08:52:22] <micges> I was talking about some encoders or stepper drivers
[08:52:39] <Tom_itx> what branch is this?
[08:52:47] <Tom_itx> i could try the sherline
[08:54:34] <skunkworks> heh - will do
[08:54:46] <skunkworks> This is for ethernet connected mesa cards
[08:54:51] <Tom_itx> ahh
[08:54:55] <Tom_itx> can't help ya there
[08:55:06] <skunkworks> heh
[09:02:29] <pcw_home> good news and bad: no WD problem but read time is now about 1 ms (was around 200 usec before)
[09:03:39] <skunkworks> for me the servo thread is about 429 and 851
[09:04:06] <skunkworks> (that is what it was always for me.. - well - over 600us
[09:04:34] <pcw_home> for me its about 3-5x slower
[09:05:08] <skunkworks> yeck
[09:05:43] <pcw_home> write time is faster
[09:06:30] <skunkworks> (I am talking peak) let me look at what current is
[09:06:49] <pcw_home> read time looks like almost always thread time and rarely lower
[09:20:02] <skunkworks> what would have changed?
[09:23:12] <pcw_home> looks like a bug in the read polling
[09:24:59] <pcw_home> old:
http://imagebin.ca/v/1AVo9fimKk3c
[09:25:00] <pcw_home> new:
http://imagebin.ca/v/1AVofpXtSj3Q
[09:26:09] <micges> pcw_home: I
[09:27:00] <micges> I'll try to remove delays in read code in a hour or so
[09:27:26] <pcw_home> Ahh
[09:27:52] <micges> but they are 10us each so not so significant
[09:28:12] <micges> back in 2h
[09:28:14] <micges> bbl
[09:28:16] <pcw_home> looks like write timing has been improved
[09:34:45] <skunkworks> still flashing the led.. :)
[09:35:57] <skunkworks> The matsuura homes.. The y axis still trips but seems to get longer the more it is used.. so That to me still points to bad caps
[09:37:08] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev bc0f394 06linuxcnc 10scripts/runtests runtests script: run with 'bash -e' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc0f394
[09:37:08] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev c5f6aa9 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/watchdog.c mesa-hostmot2 driver: Remove int->double conversions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c5f6aa9
[09:37:08] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 7f5e042 06linuxcnc 10debian/linuxcnc.files.in 04scripts/check-logging.sh 03scripts/check-system-configuration.sh 10src/Makefile check-system-configuration.sh: check for common problems * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f5e042
[09:55:58] <KGB-linuxcnc> 03Dewey Garrett 05v2.5_branch 6ecaa28 06linuxcnc 03nc_files/ngcgui_lib/qpex_mm.ngc 10nc_files/ngcgui_lib/qpocket.ngc qpocket: fix stepover, notably wrong for mm tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ecaa28
[10:01:32] <cradek> skunkworks: did you find which fault led?
[10:02:27] <skunkworks> not yet. I am going to actually be able to fondle it tonight
[10:03:51] <skunkworks> dad was able to enter some gcode and run it around
[10:06:31] <skunkworks> don't know if the spindle drive works yet. (no tooling)
[10:13:57] <seb_kuzminsky> zultron: i like your check-system-config script, & the 'make install' installation of the required files in /etc
[10:14:00] <seb_kuzminsky> thanks!
[10:18:03] <skunkworks> zultron is a good guy.. I met him once somewhere out west.
[10:18:56] <skunkworks> Although for some reason he doesn't have an accent even though he is from texas
[10:47:49] <linuxcnc-build> build #35 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/35 blamelist: dummy, John Morris <john@zultron.com>
[10:47:52] <KGB-linuxcnc> 05seb/ubc3-deb 673b7ae 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=673b7ae
[10:47:55] <linuxcnc-build> build #35 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/35 blamelist: dummy, John Morris <john@zultron.com>
[10:59:52] <micges> pcw_home: on what pc was those tests?
[11:17:48] <skunkworks> mine is pretty old atom.. I could switch it over to a newr motherboard
[11:23:35] <linuxcnc-build> build #35 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/35 blamelist: dummy, John Morris <john@zultron.com>
[11:23:52] <pcw_home> Core Duo 2180 or something
[11:26:23] <pcw_home> Using built in Atheros MAC
[11:51:42] <skunkworks> still flashing..
[11:57:49] <linuxcnc-build> build #1335 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/1335 blamelist: dummy, John Morris <john@zultron.com>
[12:26:06] <skunkworks> dummy, john morris - that is harsh..
[12:42:11] <zultron> Ha ha! Thanks y'all!
[12:42:27] * zultron has a few traces of Texas accent....
[12:43:03] <pcw_home> micges problem was Atheros MAC (RTK8139 works OK)
[12:44:19] <pcw_home> Had to change the PID tuning, I suspect the previous rev was always reading the old data
[12:45:02] <zultron> Atheros? WiFi? Is that a supported means of talking to ethernet-connected Mesa boards?
[12:45:14] <pcw_home> this tuning makes more sense (FF1 = 1.000, FF2 = 0 P= 50)
[12:45:28] <pcw_home> Atheros Ethernet MAC
[12:45:48] <zultron> Whew!
[12:46:41] <pcw_home> WIFI is a little lumpy for RT
[12:47:36] <skunkworks> pcw_home, what is your peak thread period?
[12:49:01] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 1174a03 06linuxcnc 10tests/hm2-idrom/test.sh hm2-idrom test: fix "too many arguments" error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1174a03
[12:49:01] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 2124f82 06linuxcnc 10scripts/realtime.in realtime.in: recursively remove kmods and depending modules at unload * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2124f82
[12:49:01] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 691e3b3 06linuxcnc 10scripts/runtests runtests script: run with 'bash -e' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=691e3b3
[12:49:03] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 b9456dc 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c 10src/hal/drivers/mesa-hostmot2/watchdog.c mesa-hostmot2 driver: Remove int->double conversions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b9456dc
[12:49:07] <KGB-linuxcnc> 03John Morris 05unified-build-candidate-3 cf53d83 06linuxcnc 10debian/linuxcnc.files.in 04scripts/check-logging.sh 03scripts/check-system-configuration.sh 10src/Makefile check-system-configuration.sh: check for common problems * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cf53d83
[12:50:50] <seb_kuzminsky> sweet
[12:53:34] <pcw_home> pretty lousy about 200 usec for write and 700 usec for read
[12:53:36] <pcw_home> (average write about 30 usec average read about 330 usec)
[12:54:37] <skunkworks> hmm - it won't start your config. Doesn't seem to be creating the stepgens. pcw_home did you change the firmware in my 7i80?
[12:54:41] <skunkworks> by chance
[12:56:25] <pcw_home> not unless its on a public IP address...
[12:57:00] <skunkworks> pcw_home, heh - I sent it to you
[12:57:29] <pcw_home> maybe then, I dont remember
[12:58:59] <skunkworks> ok - I can check it
[13:01:10] <micges> pcw_home: that's good but even so I'll try to remove delays
[13:10:04] <micges> pcw_home: try to comment rtapi_delay() in hm2_eth_enqueue_read() and hm2_eth_read()
[13:10:11] <micges> 20% better times here
[13:10:51] <micges> but about 60 times trying to read data from socket
[13:11:12] <micges> now it's max 5 retries
[13:18:58] <skunkworks> micges, what source is that
[13:19:14] <micges> hm2_eth.c
[13:26:18] <skunkworks> I was getting 800+us now I am getting about 600ish us total thread time.
[13:26:44] <micges> nice
[13:35:25] <skunkworks> pcw_home, one last time - what is a good firmware for the 7i80hd 16? that has steppers, encoders and pwm
[13:35:45] <skunkworks> I think it must have been flashed as it doesn't even have pwm's
[13:45:04] <pcw_home> well no luck commenting out the rtapi delay
[13:48:22] <pcw_home> (linuxcnc hangs the system --> hard reset required to recover)
[13:58:49] <skunkworks> it worked here...
[13:59:08] <skunkworks> it is only in the file in the 2 places it looks like
[13:59:39] <skunkworks> yay - something worked for me an not you!! neener neener neener.. oh wait..
[14:01:33] <Tom_itx> speak too soon?
[14:03:01] <skunkworks> no - just not something to be excited about ;)
[14:04:18] <skunkworks> pcw_home, running your config I get read times that peak at a little over 500us.
[14:04:30] <skunkworks> watchdog still hasn't bit - yay
[14:04:46] <skunkworks> although if I try to run the program at full speed I get a following error
[14:05:21] <skunkworks> did you say that you changed the tuning?
[14:10:57] <skunkworks> (FF1 = 1.000, FF2 = 0 P= 50) seemed to fix it
[14:12:23] <pcw_home> Yes I think the FF2 was needed because the lack of waiting for read meant the read was always a cycle late
[14:14:10] <skunkworks> I can still get a trip with the FO set at 3000%
[14:14:26] <skunkworks> seems to be unrelated to read/write time
[14:15:08] <pcw_home> mainly depends on the velocity and read delay
[14:17:11] <pcw_home> note the the actual errors will be much smaller (that is 200 usec added read delay will show
[14:17:13] <pcw_home> 2 mill error at 10 IPS but PID correction is slew limited so averages out the delay spikes)
[14:17:40] <skunkworks> but - so far so good!
[14:18:07] <skunkworks> >||< close to working :)
[14:18:28] <pcw_home> wonder why mine is broken now...
[14:19:04] <skunkworks> tomorrow I will try faster hardware
[14:19:12] <skunkworks> bbl
[14:19:17] * skunkworks is excited
[14:22:43] <micges> pcw_home: send me your config
[14:27:07] <pcw_home> sent
[14:27:37] <pcw_home> I must have broken something with the comments
[14:28:05] <pcw_home> only change in PID stepper config is FF2 = 0
[14:29:43] <pcw_home> looking carefully it may be that a tiny bit of ff2 will help (probably to compensate for the read=write latency)
[14:29:58] <pcw_home> read --> write
[14:30:09] <pcw_home> bbl
[14:56:05] <linuxcnc-build> build #36 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/36 blamelist: John Morris <john@zultron.com>
[14:56:29] <linuxcnc-build> build #36 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/36 blamelist: John Morris <john@zultron.com>
[14:59:14] <Tom_itx> how would i apply this patch:
http://sourceforge.net/p/emc/bugs/329/
[14:59:23] <Tom_itx> does it require recompiling?
[15:04:10] <Pekkis> hi! Could any one help me with Ubuntu 10.04 and LinuxCNC 2.5.3 this is not start
[15:04:54] <Pekkis> I am install it by CD from linuxcnc.org
[15:06:22] <Tom_itx> unplug your ethernet
[15:06:24] <Tom_itx> try again
[15:06:38] <Tom_itx> there was a bug with that... dunno if it got fixed or not
[15:07:28] <Pekkis> ok I'll try
[15:13:34] <Pekkis> unplugging connection is not solve starting poblem
[15:14:10] <Tom_itx> did you checksum the disk?
[15:14:42] <Pekkis> no
[15:14:53] <Tom_itx> maybe it's bad, try that
[15:14:54] <Pekkis> I dont know how to made it
[15:15:10] <Tom_itx> did you burn the iso to a disk?
[15:15:32] <CaptHindsight> Pekkis: what type of disk drive are you using? I have problems with disks burned in one drive that won't read properly in others.
[15:15:35] <Pekkis> I made starting USB stick
[15:16:31] <CaptHindsight> does your PC support boot from USB? some BIOS don't or can't get it right
[15:17:42] <Pekkis> hmm. amazing Linux work well
[15:17:46] <cradek> what do you see? is there an error?
[15:17:50] <Pekkis> how it possible
[15:17:54] <CaptHindsight> Pekkis: how far does it boot?
[15:18:02] <cradek> you have given us no information. please say more.
[15:18:30] <linuxcnc-build> build #36 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/36 blamelist: John Morris <john@zultron.com>
[15:19:43] <Pekkis> I have long error list but I dont know how I can show it
[15:19:56] <Tom_itx> pastebin
[15:20:02] <Tom_itx> .ca .com etc
[15:24:59] <Pekkis> Realtime system did not load
[15:26:37] <Pekkis> and next row is: Shutting down and cleaning up LinuxCNC...
[15:27:53] <seb_kuzminsky> Pekkis: upload linuxcnc_debug.txt, linuxcnc_print.txt, and the output of 'dmesg' to pastebin.ca
[15:29:35] <seb_kuzminsky> Tom_itx: that patch is broken a little bit, it includes changes to a generated file
[15:29:57] <seb_kuzminsky> i'd say, apply the linuxcnc.in part by hand and ignore the linuxcnc part, then rerun configure and rebuild
[15:30:51] <Pekkis> I am not never used pastebin
[15:31:21] <Pekkis> how this work
[15:33:39] <KGB-linuxcnc> 03Michael Haberler 05unified-build-candidate-3-testmerge-glo c264b30 06linuxcnc 10debian/linuxcnc.files.in 10src/Makefile Merge remote-tracking branch 'github-mah/unified-build-candidate-3' into unified-build-candidate-3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c264b30
[15:33:51] <Pekkis> ok I made it
[15:45:12] <CaptHindsight> Pekkis: paste the link from pastebin here
[15:45:25] <CaptHindsight> then we can see your post
[15:46:32] <CaptHindsight> http://www.pastebin.ca/2599624 my example
[15:49:05] <Pekkis> heh ok sorry
[15:49:08] <Pekkis> http://pastebin.com/0k4An1k8
[15:51:13] <memleak> Pekkis, you need to modify /etc/udev/rules.conf or /etc/udev.d/rules/99-rtai.conf
[15:51:22] <memleak> you also need to modify /etc/security/limits.conf
[15:51:26] <memleak> one moment for details
[15:52:03] <memleak> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LockedMemory
[15:53:33] <memleak> hmm trying to find that example file for the udev rule
[15:53:54] <Pekkis> hmm intresting I'll try :-)
[15:55:14] <memleak> https://code.google.com/p/neo-technical/wiki/emc2ubuntu step 13a
[15:55:35] <memleak> considering this is ubuntu 8.04 im not sure exactly where the path is to the udev rules
[15:56:38] <memleak> Pekkis, if you run this command in a terminal: ls /etc/udev does a rules.d directory show up?
[15:59:06] <seb_kuzminsky> memleak: looks to me like pekkis is on 10.04, not 8.04
[15:59:43] <Pekkis> I have 10.04
[15:59:48] <memleak> wow i had no idea 2.6.32 was used for the 10.04 distro
[15:59:52] <seb_kuzminsky> Pekkis: you installed from the LinuxCNC Lucid LiveCD?
[16:00:10] <seb_kuzminsky> i thought that set up the ulimits right
[16:00:23] <seb_kuzminsky> did you modify any of the config files after installing?
[16:00:29] <Pekkis> no
[16:00:36] <seb_kuzminsky> memleak: we shipped 2.6.24 (iirc) for hardy
[16:00:57] <memleak> oh
[16:05:30] <Pekkis> dsplabs.upt.ro/~juve/emc/get.php?file=ubuntu-10.04-linuxcnc3-i386.iso
[16:05:54] <Pekkis> I install this
[16:09:07] <seb_kuzminsky> and then how did you start linuxcnc?
[16:09:19] <cradek> [ 0.000000] Local APIC disabled by BIOS -- you can enable it with "lapic"
[16:09:35] <linuxcnc-build> build #1337 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/1337 blamelist: John Morris <john@zultron.com>
[16:09:37] <cradek> [ 0.012820] no APIC, boot with the "lapic" boot parameter to force-enable it.
[16:10:18] <cradek> [ 365.275288] RTAI[hal]: ERROR, LOCAL APIC CONFIGURED BUT NOT AVAILABLE/ENABLED.
[16:11:02] <cradek> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TroubleShooting#emc2_doesn_t_run_missing_lapic
[16:14:44] <Pekkis> I need restartart and check bios. thanks for all
[16:21:34] <memleak> thanks cradek i missed that part of the pastebin
[16:22:03] <memleak> i saw locked memory and i'm like "oh!"
[16:23:07] <cradek> I knew that wasn't the problem since he's using our cd image -- so I kept looking
[16:23:22] <cradek> hope he lets us know if he gets it
[16:29:48] <Pekkis69> Great :-) This lapic in grub fix my problem
[16:30:09] <Pekkis69> Thanks for all
[16:49:01] <CaptHindsight> what's the easiest way to get EMC to trigger running a script? Say when it hits some spot in G-code a script would start.
[16:50:20] <micges> CaptHindsight: custom M codes
[16:50:45] <micges> http://www.linuxcnc.org/docs/html/gcode/m-code.html#sec:M100-to-M199
[16:55:11] <CaptHindsight> micges: yeah that's the ticket
[16:55:18] <CaptHindsight> thanks
[17:02:15] <linuxcnc-build> build #37 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/37 blamelist: Michael Haberler <git@mah.priv.at>
[17:02:34] <linuxcnc-build> build #37 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/37 blamelist: Michael Haberler <git@mah.priv.at>
[17:21:17] <memleak> andypugh, welcome back!
[17:21:41] <andypugh> Been back a while, just doing other stuff :-)
[17:22:12] <andypugh> (Though today was an unfortunate combination of 2 9-0-clock meetings at work.
[17:22:38] <andypugh> A 9am meeting with the Paris office, and a 9pm meeting with the Detroit one...
[17:24:28] <linuxcnc-build> build #37 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/37 blamelist: Michael Haberler <git@mah.priv.at>
[17:25:03] <zultron> seb_kuzminsky, just to be sure, the deb-* build failures for ubc3 branches have always failed for ubc3? They weren't working earlier, and these recent failures are regressions, right?
[17:34:48] <linuxcnc-build> build #1337 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/1337 blamelist: Michael Haberler <git@mah.priv.at>
[17:36:55] <linuxcnc-build> build #1343 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/1343 blamelist: Michael Haberler <git@mah.priv.at>
[17:36:56] <linuxcnc-build> build #1342 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/1342 blamelist: Michael Haberler <git@mah.priv.at>
[17:38:37] <linuxcnc-build> build #172 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/172 blamelist: Michael Haberler <git@mah.priv.at>
[17:49:08] <linuxcnc-build> build #39 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/39 blamelist: Michael Haberler <git@mah.priv.at>
[17:56:01] <linuxcnc-build> build #1337 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/1337 blamelist: Michael Haberler <git@mah.priv.at>
[17:56:08] <linuxcnc-build> build #1338 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/1338 blamelist: Michael Haberler <git@mah.priv.at>
[18:37:32] <seb_kuzminsky> zultron: since i merged seb/ubc3-deb into ubc, nearly all deb builders should pass
[18:37:57] <seb_kuzminsky> the ones that still fail are: lucid-rtai and precise-rtpreempt-{i386,amd64}
[18:38:22] <seb_kuzminsky> lucid-rtai fails because ubc links liblxrt, and the lucid rtai packages dont provide it correctly for the deb packaging
[18:38:53] <seb_kuzminsky> the precise-rtpreempt ones fail because they dont know where to apt-get the rtpreempt kernel headers (i just snarfed the debs from debian.org by hand)
[18:39:20] <seb_kuzminsky> any failures other than those three are either a regression in the branch or another mole in the buildbot :-/
[18:39:26] <seb_kuzminsky> i have not triaged these failures yet
[18:47:06] <seb_kuzminsky> zultron: i just looked at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-sim-binary-i386/builds/1337
[18:47:25] <seb_kuzminsky> it has my deb fixes in its history, so i'd expect it to succeed
[18:48:08] <seb_kuzminsky> the failure is this:
[18:48:16] <seb_kuzminsky> install -m 0644 -o root ../share/linuxcnc/stepconf/*.glade /tmp/buildd/linuxcnc-2.6.0~pre~unified.build.candidate.3.testmerge.glo~c264b30/src/../debian/tmp/usr/share/linuxcnc/stepconf
[18:48:20] <seb_kuzminsky> install: target `/tmp/buildd/linuxcnc-2.6.0~pre~unified.build.candidate.3.testmerge.glo~c264b30/src/../debian/tmp/usr/share/linuxcnc/stepconf' is not a directory
[18:48:37] <seb_kuzminsky> looks like a problem with the merge of master into that branch maybe?
[18:49:51] <seb_kuzminsky> the commit that failed to build debs is a merge commit, one of the parents is ubc3 which successfully builds debs
[18:51:08] <seb_kuzminsky> the other parent of the merge is a branch i've never seen before, which looks like a branch of michael's, containing a merge of master into and old version of ubc3, plus a couple of new commits
[18:51:50] <seb_kuzminsky> so i think something went wrong with either the merge of master into michael's branch, or with the merge of glo/ubc3 into michael's branch
[18:53:08] <seb_kuzminsky> i spot checked a couple of the other deb build failures, they all looked like that stepconf problem
[18:53:15] <seb_kuzminsky> imma wait for mah to fix it
[20:11:21] <seb_kuzminsky> zultron: i forgot to mention - it's great that he did his test-merge in a throw-away integration branch, this way he can fix it before pushing it to ubc for real
[21:30:56] <skunkworks> cradek: the error on the control is fuse(y). dad says that there is an unpopulated 'fuse' led on the drive. (so the logic must go back to the board) No change in other led's when the control faults.
[21:39:04] <skunkworks> the other two drive that look to have newer caps - do have that led.
[21:39:24] <skunkworks> btw - the spindle drive seems to work.
[21:40:05] <skunkworks> the only thing (other than the y axis servo drive issue) is the tool changer doesn't seem to do anything. (from the front panel) but we may just be doing something wrong
[21:40:42] <skunkworks> you can
[21:40:50] <skunkworks> you can't stop it at 100rpm..
[21:41:07] <skunkworks> I didn't try any slower
[21:54:53] <zultron> Hi seb_kuzminsky, thanks! So those three you mention are failing with ubc3, plus deb-precise-xenomai-binary-amd64, which says
[21:54:56] <zultron> tar: build/www: Cannot mkdir: No space left on device
[21:57:43] <zultron> On mine, I'm getting intermittent problems with linuxcncrsh-based tests. You mind taking a quick look at
http://junction.ext.zultron.com/builders/fc20-32-x-tst/builds/52 ?
[21:58:12] <zultron> bbl
[22:29:26] <zultron> Actually, n/m, I see what's going on. The gcode-output is just like expected output up until the last several lines, which are missing.
[22:30:15] <zultron> So this looks like a race condition: the gcode-output file is compared to the expected-gcode-output file before the former is completely written.
[22:31:28] <zultron> Looking at it on disk, it's actually complete:
[22:31:30] <zultron> $ md5sum tests/toolchanger/toolno-pocket-differ/nonrandom/*gcode-output
[22:31:30] <zultron> 44f37ceb5784108cf9ccfcdd9b1671a0 tests/toolchanger/toolno-pocket-differ/nonrandom/expected-gcode-output
[22:31:33] <zultron> 44f37ceb5784108cf9ccfcdd9b1671a0 tests/toolchanger/toolno-pocket-differ/nonrandom/gcode-output
[22:31:52] <zultron> So there's a race condition.
[22:32:49] <zultron> And apparently a known race condition, since tests/toolchanger/toolno-pocket-differ/shared-test.sh contains these lines:
[22:32:58] <zultron> # give linuxcnc a second to finish
[22:33:01] <zultron> sleep 1.0
[22:33:31] <zultron> [trailing spaces added :P ]
[22:34:53] <seb_kuzminsky> aha, that sucks :-(
[22:35:04] <seb_kuzminsky> clocks and timers in tests are bad :-(
[22:36:42] <zultron> Yeah. Worse, I'm so tired, I'm considering a commit that just raise the 'sleep' cmd argument.
[22:36:57] <zultron> Guess I'd better sleep longer myself, instead. :)
[22:37:06] <seb_kuzminsky> heh
[22:37:22] <seb_kuzminsky> i couldnt figure out a way to close the loop with linuxcncrsh
[22:37:28] <seb_kuzminsky> hence the sleep :-/
[22:37:47] <seb_kuzminsky> there's some wait commands, and i dont remember why they didnt work for me
[22:39:55] <zultron> Hmm. The 'wait' command would wait for the 'linuxcnc' process to finish.
[22:40:34] <zultron> I think that one spawns other processes, though, like linuxcncrsh or linuxcncsvr or the like?
[22:41:00] <zultron> I don't know this stuff well, but there're a few moving parts in there.