Back
[00:21:38] <KGB-linuxcnc> 05unified-build-candidate-3-testmerge-glo c264b30 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c264b30
[00:27:10] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev c1c396e 06linuxcnc 96 commits pushed, 10131 files changed, 0320076(+), 049215(-)
[00:49:25] <linuxcnc-build> build #1761 of lucid-amd64-sim is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1761 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>, John Thornton <jthornton@gnipsel.com>, Chris Morley
[00:49:25] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Andy Pugh <andy@bodgesoc.org>, Bence Kovacs <bence.kovacs@generalmechatronics.com>, Norbert Schechner <nieson@web.de>, Michael Geszkiewicz <micges@wp.pl>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[00:55:16] <zultron> seb_kuzminsky, something funny's going on here.
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1761
[01:26:52] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder 6e9797f 06linuxcnc 10(32 files in 3 dirs) pncconf -GTK BUILDER refactor * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6e9797f
[01:26:52] <KGB-linuxcnc> 03Chris S Morley 05pncconf_builder 8c28504 06linuxcnc 10src/emc/usr_intf/pncconf/dialogs.glade 10src/emc/usr_intf/pncconf/pages.py 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -fix live test bugs - openloop and stepper tune test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8c28504
[01:26:53] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder 678b234 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -factor out mesa and parport loading wip * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=678b234
[01:26:56] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder f5ca597 06linuxcnc 10src/emc/usr_intf/pncconf/pport2.glade pncconf -add pport test panel button * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f5ca597
[01:27:00] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder ada6e6f 06linuxcnc 10src/emc/usr_intf/pncconf/pages.py pncconf -fix parport test for pport2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ada6e6f
[01:27:04] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder 246b1aa 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -fix up tests to use common I/O loading code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=246b1aa
[01:29:54] <linuxcnc-build> build #1762 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1762 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Andy
[01:29:54] <linuxcnc-build> Pugh <andy@bodgesoc.org>, Bence Kovacs <bence.kovacs@generalmechatronics.com>, Norbert Schechner <nieson@web.de>, Michael Geszkiewicz <micges@wp.pl>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[07:39:29] <skunkworks> pcw_home, I just ran it this morning and it seems to have tripped in the same spot.. (which makes me think it is not a computer jitter thing but an actual motion issue)
[09:01:46] <pcw_home> skunkworks are there many violations or just occasional ones?
[09:31:56] <skunkworks> well - if you keep resetting the stats - it pretty quickly goes 50+ acc (set to 30)
[09:46:20] <pcw_home> wonder if they ever looked at what their TP was doing in the time domain
[09:49:19] <skunkworks> no clue. might have been - hey - this works - ship it!
[09:49:43] <skunkworks> kind lets you know what you can get away with on steppers... (unless people keep lowering the acc to fix the issue)
[09:50:37] <pcw_home> accel limits on steppers are pretty nebulous because of the steep drop at higher velocities
[09:50:50] <pcw_home> steep torque drop
[09:58:00] <skunkworks> right
[10:14:46] <skunkworks> pcw_home,
http://www.youtube.com/watch?v=HfU4uyGgLZw
[10:15:06] <skunkworks> I reset the peaks half way through
[10:19:38] <skunkworks> (and the 'should it be explained' is should I explain it.. (not should mach explain it..)
[10:29:16] <pcw_home> With my patented "curve fitting via a piece of paper against the screen" method I also see
[10:29:18] <pcw_home> ~100 IPS/S accels by estimating the velocity slope
[10:30:20] <pcw_home> (on one of your previous plots)
[10:30:49] <seb_kuzminsky> zultron: whoops, i'll check it out
[10:31:47] <mozmck> skunkworks: I think lowering the acc to fix the issue is the way people set up their machines! In fact, I'm not quite sure how else you would do it?
[10:32:24] <pcw_home> I would verify that rapids match the measured velocity to make sure you dont have a scaling error
[10:32:43] <mozmck> run the acc up until is starts stalling at some speed/load and then back it off.
[10:33:13] <pcw_home> yeah but it should obey the machine limits
[10:34:48] <mozmck> yes, the tp should obey the limits, but how do you find the limits other than setting a value and trying it out?
[10:37:46] <pcw_home> if the TP doesn obey the limits I dont think I would trust testing very far
[10:41:08] <mozmck> :) Well, maybe it obeys it's version of the limits. I guess if it is consistent then people never know the difference - unless some smart guy like skunkworks goes nosing around... ;)
[10:42:14] <pcw_home> Yeah or someone sets up a big servo machine by the numbers and cant get it to track
[10:43:36] <mozmck> true, but I don't know if anyone actually does that with Mach.
[10:48:55] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 816604a 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf: look for linuxcnc-wizard image in the correct dirs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=816604a
[10:55:30] <seb_kuzminsky> cradek: the version of stepconf in 2.5 has some wonkiness regarding the wizard gif, just like master did before that commit ^^^^
[10:55:55] <seb_kuzminsky> it's not a problem in 2.5 because that version of stepconf uses the standard datadir, whereas master's stepconf uses a private datadir
[10:56:20] <seb_kuzminsky> so i think no action is needed in 2.5, but just in case, you may consider cherrypicking 816604a
[10:58:38] <cradek> I don't understand under what circumstances 2.5 would break (and would be fixed by this commit)
[10:59:28] <seb_kuzminsky> the stepconf bug that's in 2.5 wo't be exposed unless we change the location of the wizard gif, or change stepconf just right
[10:59:46] <seb_kuzminsky> but look at the wizard-finding code, there's a cut-n-paste error with linuxcncicon vs wizard
[10:59:52] <seb_kuzminsky> it's just wrong
[11:00:12] <seb_kuzminsky> but the wrongness isn't triggered because of the order that the dirs are searched
[11:00:47] <seb_kuzminsky> bbl, work
[11:01:11] <cradek> thanks
[11:01:26] <CaptHindsight> "Create a file called /etc/apt/sources.list.d/linuxcnc-buildbot.list, containing the line: deb
http://buildbot.linuxcnc.org precise master-rt or deb
http://buildbot.linuxcnc.org precise v2.5_branch-rt" are these branches identical?
[11:01:53] <cradek> nope
[11:02:27] <cradek> 2.5 is the stable release branch. master is ongoing development.
[11:03:48] <CaptHindsight> which branch do you guys want feedback on for kernel testing?
[11:03:58] <CaptHindsight> or does it matter?
[11:04:16] <cradek> probably doesn't matter
[11:04:42] <CaptHindsight> I think we have master on one and 2.5 on another machine
[11:05:50] <skunkworks> pcw_home, that is how I calculated one :)
[11:06:22] <skunkworks> halscope has ddt built in - but it is all over the place because of the jagget line...
[11:06:30] <skunkworks> jagged
[11:20:59] <seb_kuzminsky> CaptHindsight: thanks for testing
[11:22:30] <seb_kuzminsky> dgarr: did you see the email from cmorley? he says your removal of -ini from halshow broke gscreen
[11:23:14] <dgarr> its fixed sunday eve
[11:23:48] <dgarr> 9f6c219 halshow: eliminate unused ref to a -ini option
[11:23:48] <dgarr> 73f1240 gscreen -fix launch of halshow
[11:24:14] <dgarr> it only occurred with tcl8.4
[11:24:38] <seb_kuzminsky> oh, i missed that
[11:24:38] <seb_kuzminsky> thanks
[11:25:46] <dgarr> finding the share dir in both rip and debs is simplified with;
[11:25:49] <dgarr> import linuxcnc;dir=os.path.join(linuxcnc.SHARE,"linuxcnc")
[11:26:24] <dgarr> ref:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=019df68e3bfd4b818275d2c;hp=68b13e112e9f7e6311c92b9ebd7a608cbde42dc7
[11:28:33] <seb_kuzminsky> that's nice and clean
[11:52:38] <skunkworks> pcw_home, this is a jog.. Seems right...
http://imagebin.org/292777
[11:53:51] <skunkworks> 500ipm - 30ish acc
[12:01:38] <KGB-linuxcnc> 03Michael Haberler 05master 85b4849 06linuxcnc 10src/emc/usr_intf/axis/extensions/emcmodule.cc 10src/emc/usr_intf/axis/scripts/linuxcnctop.py task state: teach linuxcnctop.py, emcmodule.cc about WAITING_FOR_SPINDLE_ORIENTED * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85b4849
[12:10:11] <pcw_home> so the TP only violates accel in G1 (2,3)?
[12:32:30] <skunkworks> I am going to try to isolate the moves...
[12:35:18] <CaptHindsight> seb_kuzminsky: on precise from either branch we see ~40uS with preemptRT and ~8uS with RTAI on all AMD hardware
[12:36:01] <CaptHindsight> with integrated graphics
[12:53:11] <seb_kuzminsky> wow, those number are both great
[12:55:18] <micges> CaptHindsight: what hardware with preempt-rt ?
[13:07:02] <brianmorel99> Is Hardy being supported with 2.6 ? The Todo mentions it on the first line, but it's not mentioned under the Kernels section.
[13:13:54] <skunkworks> This is one of the big ones...
http://imagebin.org/292790
[13:14:09] <skunkworks> http://pastebin.ca/2638713
[13:14:17] <skunkworks> (section of the tort program...)
[13:18:17] <skunkworks> I think it follows that path a bit too close for the speed..
http://imagebin.org/292791
[13:19:55] <skunkworks> you run it more than once and it has the exact same profile..
[13:20:18] <skunkworks> Granted - that is a diabolical path.. but that is why it was made...
[13:27:13] <pcw_home> So is this just a Mach TP bug with painful Gcode? maybe something simpler would be a good test
[13:40:55] <seb_kuzminsky> brianmorel99: hardy runs the current version of master (what will become 2.6), but we're trying to merge in a branch that requires us to drop hardy support
[13:41:17] <seb_kuzminsky> new installs should use lucid or precise
[13:47:45] <CaptHindsight> micges:
http://www.asrock.com/mb/amd/e350m1/ http://www.gigabyte.us/products/product-page.aspx?pid=4343#ov and
http://www.gigabyte.us/products/product-page.aspx?pid=3447#ov
[13:48:01] <CaptHindsight> and similar
[13:48:12] <CaptHindsight> HexChat: 2.9.5 ** OS: Linux 3.12.9-201.fc19.x86_64 x86_64 ** Distro: Fedora release 19 (Schrödinger’s Cat) ** CPU: 6 x AMD Phenom(tm) II X6 1090T Processor (AuthenticAMD) @ 3.62GHz ** RAM: Physical: 15.2GB, 89.3% free ** Disk: Total: 1.8TB, 38.0% free ** VGA: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] ** Sound: HDA-Intel - HDA ATI SB1: HDA-Inte
[13:48:13] <CaptHindsight> l - HDA ATI HDMI ** Ethernet: Realtek Semiconductor Co., Ltd. CIe Gigabit Ethernet ** Uptime: 1d 16h 50m 36s **
[13:49:12] <micges> thanks
[13:50:34] <CaptHindsight> also
http://www.asus.com/Motherboards/F2A85V_PRO/
[13:52:16] <skunkworks> micges, I just get a 7i80 not found. Sometimes it takes more than 2 tries
[13:58:25] <CaptHindsight> the Gigabyte GA-F2A85X-UP4 is nice since it has 6 PCI-E slots for fpga cards
[14:30:42] <micges> anyone was running latest master with axis sim? doesn't working here either 10.04 or 12.04
[14:30:44] <micges> Traceback (most recent call last):
[14:30:44] <micges> File "/home/micges/realtime/linuxcnc-dev/bin/axis", line 123, in <module>
[14:30:44] <micges> nf.start(root_window)
[14:30:44] <micges> File "/home/micges/realtime/linuxcnc-dev/lib/python/nf.py", line 119, in start
[14:30:44] <micges> source_lib_tcl(r, "support.tcl")
[14:30:45] <micges> File "/home/micges/realtime/linuxcnc-dev/lib/python/nf.py", line 111, in source_lib_tcl
[14:30:47] <micges> r.tk.call("source", os.path.join(tcl_libdir, f))
[14:30:49] <micges> _tkinter.TclError: can't find package Img
[14:37:49] <brianmorel99> seb, I assume thats UB3? I've been working off the unified_build_3 branch on git. That is the merge canidate to work off correct? I see zulton has a branch also, but I assume that will be merged back into the unified_build_3
[14:45:12] <micges> seb_kuzminsky: libtk-img dependency was added for master but ./confiugre doesn't check for it
[15:13:05] <seb_kuzminsky> micges: someone should add it ;-)
[15:13:33] <seb_kuzminsky> brianmorel99: yes, the branch we're trying to merge is unified-build-candidate-3 on git.linuxcnc.org
[15:14:49] <seb_kuzminsky> speaking of ubc3, zultron, what's your opinion on
https://sf.net/p/emc/bugs/355/ ?
[15:15:24] <seb_kuzminsky> this kind of issue is one of the main reasons why feature branches shouldnt be integration branches - the logging issue is now holding up the (largely independent) new rtos support
[18:56:51] <owhite> hey people. I'm running a xy table using gecko drives and a 5i20 board. When I run some gcode using gmoccapy or axis, the execution of the gcode stops arbitrarily. It will stop in different places in the code, and with the spiral in nc_codes/examples.
[18:57:17] <owhite> I can find any debug information. Nothing is coming out of stderr, or appears in dmesg.
[18:57:20] <owhite> Any suggestions?
[19:19:24] <skunkworks> open linuxcnc from terminal and see if there are any errors when it stops.
[19:19:53] <skunkworks> Maybe noise - causing abort or estop or something
[19:41:25] <owhite> thanks skunkworks. I was running from the terminal. But have to run for now.
[19:48:11] <cmorley> use linuxcnc status display while the program is running to see the interpreter status when it locks.
[20:16:39] <cradek> I bet you have a pendant, complex halui setup, etc...?
[20:17:00] <cradek> well he's gone.
[20:17:20] <cradek> something is probably sending an abort.
[21:37:19] <KGB-linuxcnc> 03Dewey Garrett 05master f4e16c6 06linuxcnc 10tcl/ngcgui.tcl ngcgui: bug fixes for gcmc usage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f4e16c6
[21:37:19] <KGB-linuxcnc> 03Dewey Garrett 05master be56120 06linuxcnc 10tcl/ngcgui.tcl ngcgui: remove deprecated globals entry boxes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be56120