Back
[06:30:39] <KGB-linuxcnc> 03John Thornton 052.6 70ab1fd 06linuxcnc 10docs/src/remap/structure.txt Docs: fix link I broke * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=70ab1fd
[08:34:19] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot%20-%2010242014%20-%2004:10:32%20PM.png
[08:35:38] <skunkworks> And the usb's work on the j1900 now with rtai
[08:35:58] <skunkworks> the only issue is I had to remove the rtai-modules bofore the new ones would install.
[08:36:13] <skunkworks> maybe there is a way to force that?
[08:37:25] <skunkworks> I will let the latency run over the weekend. brianmorel99! great work!
[08:43:42] <skunkworks> the_wench, how do I send a messege to someone offline?
[08:55:46] <bjmorel_work> skunkworks: Thanks, I'll work on the packaging issue over the weekend.
[08:56:04] <skunkworks> oh- there you are. :)
[09:09:02] <cradek> yay!!
[09:10:06] <cradek> bjmorel_work: can you send a usb patch to seb? he has all the packaging done and automated. don't burn up your time for no reason!
[09:12:21] <pcw_home> bjmorel_work: Thats great news, The Baytrail MBs are really impressive Speed vs power wise
[09:14:16] <seb_kuzminsky> yeah, awesome!
[09:14:50] <seb_kuzminsky> cradek: brian sent me a link to his github fork of my kernel builder already :-)
[09:15:32] <seb_kuzminsky> jthornton: thanks for that doc link fix!
[09:15:44] <seb_kuzminsky> oh man, everything is coming together this morning :-)
[09:15:52] <seb_kuzminsky> i think i'll celebrate with another cup of coffee
[09:18:39] <pcw_home> Here's a new J1900 MB with 2 PCI slots, and parallel port
[09:18:40] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157565&cm_re=j1900-_-13-157-565-_-Product
[09:27:08] <cradek> seb_kuzminsky: oh that's great!
[10:11:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 037c76b 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=037c76b
[10:11:19] <KGB-linuxcnc> 05seb/2.7/hm2-test-strict-aliasing 037c76b 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=037c76b
[10:17:06] <bjmorel_work> This is the one I bought:
http://amzn.com/B00J2CCDAC
[10:17:55] <bjmorel_work> Other than the USB issue, it was great out of the box. Nice low latency, parallel port and has a PCI slot if I want to move to MESA.
[10:22:12] <cradek> cool. people love when there is a known-good brand new board
[10:26:25] <cradek> seb_kuzminsky: can you package a patched kernel that doesn't become incompatible with rtai etc? if so I will build a new iso when you are ready.
[10:29:49] <CaptHindsight> cradek: can I look over your shoulder when you are building it? :)
[10:31:08] <CaptHindsight> is it really that hard to build deb packages?
[10:50:44] <cradek> CaptHindsight: my shoulder:
http://timeguy.com/gitweb?p=live-images.git;a=log;h=refs/heads/debian
[10:51:40] <cradek> seems like deb packages of kernels can be tricky, but I'm not doing that. the live image hackery I've done is in that git.
[10:52:15] <CaptHindsight> huh, the kernel part was easy for us
[10:53:43] <CaptHindsight> maybe it's what you're used to
[10:56:50] <CaptHindsight> if we can figure out how to build RTAI userspace we'd be happy to build and test new kernels and the new RTAI tree with Debian
[11:05:32] <jepler> CaptHindsight: did you package a 64-bit rtai kernel?
[11:07:33] <memleak> yes
[11:10:35] <jepler> I thought so
[11:11:09] <jepler> I should put debian packaging of your rtai repo on my list, since that's been a stumbling block to you
[11:11:17] <jepler> unfortunately my list is always long :-/
[11:14:21] <CaptHindsight> would it help if we were able to make packaging for debian easier? or is this some right of passage to with the debian folks? :)
[11:15:05] <CaptHindsight> too late this year but that would seem to be a wonderful Google Summer of Code project for some eager beaver
[11:38:43] <jepler> http://vimeo.com/108885687
[11:39:39] <jepler> http://emergent.unpythonic.net/01414165219
[11:46:54] <kwallace> I need to study this circuit more:
http://www.wallacecompany.com/machine_shop/Shizuoka/Screenshot-Shiz_TIP36-1a.png . Does anyone know if there is a good keyword to search with?
[11:49:36] <CaptHindsight> kwallace:
http://en.wikipedia.org/wiki/Darlington_transistor
[11:49:41] <archivist> kwallace, darlington
[11:50:17] <archivist> just an easy method to get high current gain
[11:51:38] <kwallace> Yeah but this is two transistors rather than one transistor with two stages.
[11:52:36] <CaptHindsight> same thing, only discrete vs all in one package
[11:52:50] <archivist> you can put two individual or two in a case, it is the same
[11:54:10] <CaptHindsight> some high power transistors are multiple lower power transistors combined into one package
[11:57:55] <kwallace> Okay, I'll look at Darlington information. I may consider going to a Darlington but I need to understand what I have to do that. Also my schematic has NPNs but I have PNPs on my board which adds to the mystery.
http://www.wallacecompany.com/machine_shop/Shizuoka/Bandit_Stepper_Driver.png
[11:58:14] <jepler> I agree, that is a darlington pair,
http://en.wikipedia.org/wiki/Darlington_transistor
[12:00:13] <archivist> that circuit seems to have both npn and pnp are you looking at the right devices
[12:01:04] <jepler> TIP36C's current gain is around 100x at 25C (see figure 5 of
http://www.st.com/web/en/resource/technical/document/datasheet/CD00001165.pdf), so 10mA base current only gives 1A collector current
[12:01:59] <jepler> but when you use that first TIP36C to give 1A base current to the second transistor, it will conduct much more collector current ..
[12:03:36] <kwallace> Sorry, I should have indicated where to look. Start at the top right at --O A1, then move left through the freewheel doides. The transistor pair is the next bit with the dashed box.
[12:04:14] <archivist> diagram is a bit low res
[12:04:51] <jepler> the dashed box makes me wonder if it is a single-package darlington transistor
[12:04:53] <archivist> yes I see npn darlington there
[12:05:05] <jepler> are there three discrete components like you showed in the first png or is it just one component?
[12:05:52] <archivist> if it was clear enough we could google the transistor number
[12:07:07] <kwallace> The dashed box is a pair of TIP36Cs and the 22 Ohm R on a mini PCB with three legs going to the main board.
[12:07:38] <jepler> aha
[12:07:42] <archivist> someone done a bad none working repair?
[12:09:22] <kwallace> Each label A1 through B Com has the same module:
http://www.wallacecompany.com/machine_shop/Shizuoka/00001-1a.jpg
[12:13:25] <jepler> seems more likely the A/B COM ones are NPN-type (TIP35C)
[12:13:55] <jepler> TIP35C and TIP36C look like they're still readily available
[12:15:05] <jepler> (or is it the other way around, with the A/B COM being PNP type?)
[12:15:13] * jepler squints at the scan
[12:17:36] <archivist> my squint says 2Sxxxxx a japanese partnumber
[12:22:48] <kwallace> I pulled the module apart:
http://www.wallacecompany.com/machine_shop/Shizuoka/Shiz_TIP36-1a.jpg
[12:25:22] <kwallace> Now, that I look closer, jepler may be right the A/B and Common module _do_ look like PNP and NPN.
[12:29:28] <jepler> kwallace: it would make sense that there are two different kinds. A/B COM is high side drive, and A/B 1/2 is low-side drive
[12:29:38] <kwallace> I think the boxes have Q18 through Q23, then a module part number. The module I took apart is 519 291 02 which is similar the to the number of digits in the schematic.
[12:30:05] <kwallace> Sorry to take up your time on off topic stuff.
[12:30:54] <kwallace> I ordered some TIP36Cs and extra fuses.
[12:31:04] <jepler> seb_kuzminsky: remind me how to see the problem in the lui branch with the status buffer not being updated as a side effect of sending commands?
[12:31:20] <jepler> seb_kuzminsky: seems like it was of the form "send something to linuxcncrsh"
[12:32:00] <archivist> kwallace, check the diodes are not open, letting back emf onto the transistors
[12:34:57] <kwallace> I checked the diodes for the fuse that blew (B1 leg). I'll try to check them all while waiting for the parts.
[12:38:28] <kwallace> Oh crud, looking again, the bad module is on the BB leg (with the fuse) which is PNP on the schematic (duh). All is well again.
[12:44:43] <kwallace> BTW, I think this module does the PWM current limit which runs all the time (makes the constant singing sound) and feeds two legs, so probably works pretty hard.
[12:45:21] <lair82__> Hey Guys, figured I would ask over here quick, In regards to the AMD APU's, where do I insert the line "radeon.modeset=0" to help with the latency on my new board
[12:47:03] <memleak> on the kernel command line, you can do it at the grub menu or through grub.cfg / menu.lst
[12:47:10] <memleak> put it after "ro"
[12:47:49] <memleak> once the new rtai debs are made / new iso with my rtai tree, nobody will need radeon.modeset=0 or isolcpus ever again :)
[12:49:35] <memleak> nevermind i thought your using rtai, not preempt_rt, sorry
[12:51:37] <lair82__> no problem memleak
[12:53:32] <kwallace> lair82__, I think adding the kernel command still applies.
[12:54:56] <lair82__> Not being very proficient, do you mean from the command line?
[12:56:44] <CaptHindsight> lair82__: when booting when the grub screen comes up when you have a few seconds to make modifications or change kernels
[13:00:33] <CaptHindsight> wish I could find a video of interacting with grub
[13:03:14] <jepler> also the way you change the commandline is different between when you are booting the binary.hybrid.iso vs after installation
[13:04:13] <jepler> if it's post installation, then just press "e" when the GNU GRUB screen comes up, cursor down to the line starting "linux", hit end to go to the end of the line, then type the extra stuff you need
[13:05:11] <kwallace> I think the main issue is that you need to tell the kernel to use the "radeon.modeset=0" setting. I believe this is done by telling grub to make the setting during boot-up. This covers the SMI setting but may apply to your setting too :
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?The_Isolcpus_Boot_Parameter_And_GRUB2 . Then again I could be all wet.
[13:09:01] <jepler> OK, three ways to do it
[13:09:10] <jepler> the one that involves editing the file in /etc after installation is durable
[13:11:22] <jepler> .. edit file /etc/default/grub as root, adding items to GRUB_CMDLINE_LINUX_DEFAULT, update-grub as root, reboot
[13:20:56] <kwallace> Hmm, the bit in the top right looks familiar:
http://www.semicon.sanken-ele.co.jp/sk_content/2sb1647_ds_en.pdf
[13:28:12] <jepler> do you think that it originally was a single component and somebody replaced them with the darlington daughterboard?
[13:30:29] <seb_kuzminsky> jepler: in commit c19fa73b3866fdcf408322acd52506ea39458def, take out the call to updateStatus()
[13:30:53] <seb_kuzminsky> and/or in commit 1c2dd415bddc98babf9c3f04568de37fea151a3a
[13:30:58] <seb_kuzminsky> bbl, work
[13:31:28] <jepler> seb_kuzminsky: man all the duplicated code in these UIs
[13:32:32] <pcw_home> you need the the user interface interface
[13:34:23] <seb_kuzminsky> pcw_home: that's what we're doing :-)
[13:34:36] <seb_kuzminsky> a simpler interface for programs (such as UIs) to talk to linuxcnc
[13:35:54] <pcw_home> Ahh
[13:40:20] <jepler> at least we hope it'll be simpler
[13:41:53] <jepler> http://mid.gmane.org/20141019130635.GA32102%40unpythonic.net
[13:43:36] <kwallace> jepler, I think my driver is original. I was still playing with the thought of replacing the module with a Darlington and the component I was looking at happens to have the same circuit as my module -- imagine that. Thinking aloud, the TIP36 has an hfe = 40, I think the module hfe = 1600, the 2SB1647 = 5000, so it should work, maybe. Anyway I need to get to the shop.
[13:46:13] <jepler> kwallace: OK, I wasn't sure what you were thinking, since above archivist was speculating about that schematic having 2S part numbers on it
[15:00:49] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 95e764c 06linuxcnc 10src/liblinuxcnc-ui/Submakefile 03src/liblinuxcnc-ui/get-status-nml.cc 10src/liblinuxcnc-ui/linuxcnc-ui.h lui: allow direct access to EMC_STAT in lui object * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=95e764c
[15:00:49] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui c4cf0f5 06linuxcnc 10(8 files) lui: switch shcom users to use lui for status buffer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4cf0f5
[15:00:49] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui c7c8a51 06linuxcnc 10src/liblinuxcnc-ui/luigetter.py fixup lui: license declaration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c7c8a51
[15:00:52] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 9d1b5ae 06linuxcnc 10(6 files) UIs: get rid of bogus serial number save/restore code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d1b5ae
[15:00:55] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui df3130e 06linuxcnc 10(6 files) UIs: get rid of updateStatus calls * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df3130e
[15:05:12] <seb_kuzminsky> woo
[15:13:37] <skunkworks_> what were the tuning issues at tx?
[15:15:10] <bjmorel_work> CaptHindsight / Memleak: Hopefully this weakend I will dig more into Seb's set up for building the RTAI debs. I hope I can help combine it with your RTAI / kernel trees.
[15:15:42] <jepler> skunkworks_: there were two bits of trouble I know about, but I was mostly on the sidelines
[15:16:10] <cradek> skunkworks_: the biggest problem was miswiring the enables all together instead of through three relays, which undid the careful isolation of one amp from another
[15:16:17] <jepler> skunkworks_: one was a ground loop problem, and the second was a surprising behavior of the mesa 7i77 board
[15:16:29] <jepler> skunkworks_: sounds like cradek just explained the first one better than I could of
[15:16:30] <cradek> ooh I didn't hear about #2
[15:16:51] <jepler> the 7i77 has six analog outputs. they're being used in pairs, one for velocity command and one for simulated tachometer
[15:17:32] <jepler> john k was having no luck getting the Z axis tuned, and eventually figured out that there was always 0V on the Z simulated tach
[15:17:47] <jepler> so we started pulling out our hairs about how we had damaged the 7i77 hardware
[15:17:58] <jepler> .. eventually found that the last analog out is governed by a separate enable
[15:18:20] <cradek> weird!
[15:18:24] <jepler> analogout0..4 are goverened by analogena, but analogout5 is governed by spinena or something like that
[15:18:42] <jepler> .. like the last analog output is supposed to be for a spindle only
[15:19:20] <CaptHindsight> bjmorel_work: thanks, I have to dive into how to build those debs
[15:19:42] <skunkworks_> neatI
[15:19:48] <skunkworks_> !
[15:20:48] <jepler> as far as I can tell from the hal driver source, it gets those pin names from a ROM in the 7i77
[15:21:50] <jepler> oh but I forgot the best part
[15:22:30] <jepler> either the Z axis motor already wasn't securely fastened, or the shaking while moving it untuned was so bad that it jiggled some huge bolts loose
[15:22:42] <jepler> so they had to recover them from the inside of the machine and bolt the motor back on again
[15:35:28] <linuxcnc-build> build #2557 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/2557 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:37:38] <jepler> but I ran the tests :-/
[15:38:07] <jepler> > lui_get_acive_gcodes_count inconsistent with lui_get_active_gcodes
[15:40:12] <linuxcnc-build> build #2557 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2557 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:40:12] <linuxcnc-build> build #2566 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2566 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:40:15] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui fe4347c 06linuxcnc 10tests/liblinuxcnc-ui/lui-test.c lui-test: in case of specific failure, print diagnostic information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe4347c
[15:42:34] <seb_kuzminsky> jepler: yes, but did you run it on lucid i386? ;-)
[15:43:08] <jepler> seb_kuzminsky: naturally not
[16:11:56] <jepler> lui_get_acive_gcodes_count inconsistent with lui_get_active_gcodes (count=0 count1=16)
[16:13:03] <linuxcnc-build> build #2558 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/2558 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:17:33] <linuxcnc-build> build #2558 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2558 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:17:34] <linuxcnc-build> build #2567 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2567 blamelist: Jeff Epler <jepler@unpythonic.net>
[16:23:35] * jepler finally spots his bug
[16:23:39] <jepler> 15 if(*count) *count = (ACTIVE_G_CODES);
[16:29:34] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui 33ba26d 06linuxcnc 10src/liblinuxcnc-ui/luigetter.py fixup! luigetter: additional getters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=33ba26d
[16:29:34] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui c8c0a0b 06linuxcnc 03tests/tclsh-extensions/expected 03tests/tclsh-extensions/test.sh 03tests/tclsh-extensions/test.tcl tcl: test that the Hal and Linuxcnc extensions load * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c8c0a0b
[16:29:34] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui a85259b 06linuxcnc 10src/emc/usr_intf/Submakefile fixup! lui: switch shcom users to use lui for status buffer * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a85259b
[16:49:30] <KGB-linuxcnc> 03Jeff Epler 05master 55ec5eb 06linuxcnc 10scripts/linuxcnc.in runscript: EMCTASK is a HAL component now * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=55ec5eb
[16:49:30] <KGB-linuxcnc> 03Jeff Epler 05master e1ed512 06linuxcnc 10scripts/linuxcnc.in 10src/emc/task/emcsvr.cc emcsvr: daemonize after setup is complete * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e1ed512
[16:49:30] <KGB-linuxcnc> 03Jeff Epler 05master bbdef1c 06linuxcnc 03tests/tclsh-extensions/expected 03tests/tclsh-extensions/test.sh 03tests/tclsh-extensions/test.tcl tcl: test that the Hal and Linuxcnc extensions load * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bbdef1c
[16:50:11] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 4ce5b23 06linuxcnc 10(29 files in 7 dirs) nml: implement command queue with reliable reception * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ce5b23
[17:10:38] <linuxcnc-build> build #133 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/133 blamelist: Jeff Epler <jepler@unpythonic.net>
[17:13:00] <KGB-linuxcnc> 03Jeff Epler 05liblinuxcnc-ui ed64c1f 06linuxcnc 54 commits pushed, 1017 files changed, 03733(+), 0493(-)
[17:39:54] <jepler> seb_kuzminsky: look out, I rebased liblinuxcnc-ui
[19:14:53] <seb_kuzminsky> jepler: i saw it, thanks
[19:49:12] <KGB-linuxcnc> 03Jeff Epler 05master fe0bf47 06linuxcnc 10src/emc/ini/inihal.cc 10src/emc/ini/inihal.hh 10src/emc/task/taskintf.cc task: shut down ini_hal at exit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fe0bf47
[19:49:18] <KGB-linuxcnc> 03Jeff Epler 05jepler/test-nml-over-tcp e3262de 06linuxcnc 10(10 files in 2 dirs) tests: test nml-over-tcp * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3262de
[20:16:01] <jepler> huh. The meaning of this code is different in C++11: #define X "X" .... puts("X"X"X");
[20:16:11] <jepler> though it's only a warning in g++-4.9 -std=c++11
[20:16:12] <jepler> xxx.c:4:10: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
[20:16:15] <jepler> puts("X"X"X");
[20:16:18] <jepler> ^
[20:52:53] <jepler> 1218 if (((min_compatible_version < 2.58) && (min_compatible_version > 1e-6)) || server->write_reply->confirm_write) {
[21:16:58] <KGB-linuxcnc> 03Jeff Epler 05jepler/test-nml-over-tcp 63056df 06linuxcnc 10(12 files in 6 dirs) nml: convert arch-dependent types to fixed-width types * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=63056df
[21:16:58] <KGB-linuxcnc> 03Jeff Epler 05jepler/test-nml-over-tcp 15d4377 06linuxcnc 04tests/linuxcncrsh-tcp/skip tests: this test now passes on 64-bit platforms * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=15d4377
[21:17:55] <seb_kuzminsky> holy.. wow
[21:19:07] <jepler> well now we have a conundrum
[21:19:16] <jepler> I know for a fact that nml-over-tcp works, and it works better now than yesterday
[21:19:26] <jepler> .. except for that other patch I really, *really* want to apply to fix local user interfaces locking up
[21:23:48] <jepler> indeed, after merging origin/jepler/master/sf328 the new test doesn't work at all
[21:23:55] <jepler> SET MDI NAK
[21:23:56] <jepler> SET MDI NAK
[21:23:56] <jepler> SET MDI NAK
[21:23:56] <jepler> SET MDI NAK
[21:23:57] <jepler> etc
[21:28:57] <andypugh> http://www.linuxcnc.org/index.php/french/forum/41-guis/26314-gmoccapy-a-new-screen-for-linuxcnc?start=920#52342 has me worried, random moves from a paused machine? That’s not right. I am trying to figure out if they are random commanded moves, or random random moves. I confess I don’t 100% trust gmoccapy.
[21:45:46] <linuxcnc-build> build #230 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/230 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Jeff Epler <jepler@unpythonic.net>, Dewey Garrett
[21:45:46] <linuxcnc-build> <dgarrett@panix.com>
[21:46:55] <jepler> > failed to select joint-0 in halui
[21:49:34] <linuxcnc-build> build #376 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/376 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Jeff Epler <jepler@unpythonic.net>, Dewey Garrett
[21:49:34] <linuxcnc-build> <dgarrett@panix.com>
[22:05:15] <linuxcnc-build> build #2571 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2571 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Jeff Epler <jepler@unpythonic.net>, Dewey Garrett <dgarrett@panix.com>
[22:23:31] <jepler> I suppose it may be the reverse of the last problem ^^^
[22:23:53] <jepler> originally the problem was sending a command via lui and then looking for the status via shcom
[22:24:07] <jepler> now the problem may be sending a command via shcom and looking for the status via lui
[22:24:13] <jepler> not sure though
[22:24:22] <jepler> also I've failed to get the new serial number stuff to work with tcp :-/
[22:28:36] <jepler> 'night
[23:04:51] <linuxcnc-build> build #751 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/751 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:07:10] <linuxcnc-build> build #2361 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2361 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:08:32] <linuxcnc-build> build #2563 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2563 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:23:57] <linuxcnc-build> build #2564 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2564 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:29:46] <linuxcnc-build> build #2563 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/2563 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:30:12] <linuxcnc-build> build #2565 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/2565 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:33:09] <linuxcnc-build> build #1765 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/1765 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:34:28] <linuxcnc-build> build #721 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/721 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:34:34] <linuxcnc-build> build #721 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/721 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:36:55] <linuxcnc-build> build #912 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/912 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:38:58] <linuxcnc-build> build #232 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/232 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:42:27] <linuxcnc-build> build #378 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/378 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:47:06] <linuxcnc-build> build #2564 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2564 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:48:41] <linuxcnc-build> build #2564 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2564 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:48:42] <linuxcnc-build> build #2573 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2573 blamelist: Jeff Epler <jepler@unpythonic.net>
