Back
[01:22:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 8880d3a 06linuxcnc 10src/hal/components/mux_generic.c mux_generic: add missing return value check * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8880d3a
[02:33:10] <linuxcnc-build> build #184 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/184 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:28:28] <ktchk> I did use a dell vostro 1510 load with ubuntu 12.04 3.4.55 and linuxcnc but the nvadia driver is not working linuxcnc need glx so not sucess to test linxcnc on it
[08:31:25] <pcw_home> ktchk: dont know if this helps with 12.04:
[08:31:27] <pcw_home> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_EMC2#Nvidia_Card_configuration_issues
[09:59:43] <seb_kuzminsky> cradek: i just got "remote: warning: refname 'v2.6.0-pre1' is ambiguous." too
[09:59:48] <seb_kuzminsky> maybe i just missed it earlier?
[10:02:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 038bc94 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=038bc94
[10:17:20] <cradek> I wonder if 71d59fde was supposed to be in 2.6
[10:18:02] <seb_kuzminsky> could be
[10:18:29] <seb_kuzminsky> i'll ask him next time i see him
[10:22:11] <seb_kuzminsky> ok i mailed him
[10:30:48] <cradek> I could upgrade git on the server from 1.8.4 to 1.9.0
[10:31:09] <cradek> (1.8.4.3)
[10:32:31] <skunkworks> rob emailed me and said he had issues figuring out the issue and rewrote most of the arc_feed function in cannon. it seems to have fixed most of the issue
[10:33:21] <skunkworks> (but I think he is pretty busy with school right now)
[10:35:12] <seb_kuzminsky> yowser
[10:35:18] <seb_kuzminsky> he's very prolific
[10:35:30] <seb_kuzminsky> makes me wish we had good unit tests for some of our internal functions
[10:35:58] <skunkworks> sure.. I ran a buch of random stuff through it before it showed an issue.
[10:36:32] <skunkworks> I blame the keyborad
[10:36:34] <skunkworks> ;)
[10:36:48] <seb_kuzminsky> i guess we should keep poking at it in the feature branch until rob's happy with it and the rate of discovery of new bugs slows to near zero
[10:37:28] <skunkworks> right - so far (well with what I have been testing) it is very close.
[10:37:43] <seb_kuzminsky> that's wonderful
[10:37:51] <seb_kuzminsky> i'm just starting to look at it too
[10:38:12] <seb_kuzminsky> i'm way behind you
[10:39:02] <seb_kuzminsky> hmm, that's two lathe-mode bug reports from gene heskett in the past few days, agains 2.7.0-pre0
[10:39:24] <skunkworks> he wanted me to test the current slash and burn - so it is in his github..
https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-experimental2
[10:41:20] <skunkworks> gene....
[10:44:21] <KGB-linuxcnc> 03Dewey Garrett 052.6 27ae7c7 06linuxcnc 10tcl/bin/emccalib.tcl emccalib.tcl: improve noncompatible ini message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=27ae7c7
[10:45:56] <seb_kuzminsky> dgarr: does this address gene's issue?
[10:51:35] <cradek> seb_kuzminsky: have urls handy?
[10:52:33] <KGB-linuxcnc> 03Norbert Schechner 052.6 90bb5f4 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_3 - solved G92 as system bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=90bb5f4
[10:53:33] <seb_kuzminsky> http://article.gmane.org/gmane.linux.distributions.emc.devel/13142
[10:53:38] <seb_kuzminsky> http://article.gmane.org/gmane.linux.distributions.emc.devel/13144
[10:54:15] <cradek> oh, not really bug reports...
[10:54:58] <cradek> hm the limits one looks important
[10:56:34] <cradek> limits in sim/axis/lathe.ini look right
[10:58:14] <ktchk> I got the linuxcnc 2.6 install and tested on a dell 1510 nvidia video card. Have to disable all others kernels installed before. And then install the nvidia 173.14.39 VDPAU driver.
[10:58:58] <cradek> the nvidia proprietary driver messes up latency, and should be avoided
[11:02:25] <cradek> seb_kuzminsky: I asked for his ini (wfm in 2.6 and master)
[11:04:32] <ktchk> Yes latency not good but which driver for nvidia card?
[11:04:55] <cradek> vesa usually works
[11:05:17] <cradek> and if you install and then do nothing special, it usually works
[11:05:24] <ktchk> but display will be 800x600
[11:05:32] <cradek> not in my experience
[11:05:39] <ktchk> Thnaks
[11:11:48] <seb_kuzminsky> cradek: thanks for checking
[11:12:21] <cradek> I'm in bug-squashing mode
[11:12:25] <seb_kuzminsky> i probably sound like a broken record, but i wish we had tests of fundamental functionality like "jog or mdi into the soft limits and make sure we stop in the right place"
[11:12:26] <cradek> it's fun for a change
[11:12:32] <seb_kuzminsky> then we'd know without spending any time on it
[11:12:54] <seb_kuzminsky> yay :-)
[11:13:23] <cradek> tests for things that you see and use every single time you use the software aren't the most useful tests
[11:13:45] <cradek> gene probably has something weird - much harder to test for that kind of thing
[11:14:36] <cradek> gui stuff is even harder (does the mist checkbutton disappear when you start AXIS without anything connected to the iocontrol pin?)
[11:15:03] <cradek> that's why I throw up my hands and instead just try running it and looking around for weirdness :-/
[11:15:58] <cradek> people with and without institutional knowledge see different weirdnesses
[11:16:23] <cradek> I'm rambling
[11:16:30] <skunkworks> heh
[11:20:49] <skunkworks> I don't know how you could test motion... seems like there could always be that one situation that wasn't handled..
[11:21:31] <cradek> running some gcode and watching motion's output for constraint violations seems fairly possible compared to some of these other things
[11:21:34] <skunkworks> I guess you could randomly build a path everytime.. (but can you build it randomly enough)
[11:21:51] <cradek> it would be really useful to add that since TP work will probably be ongoing for a while
[11:22:07] <cradek> you'd want to use fixed gcode, so the test is deterministic
[11:22:13] <skunkworks> I think rob has some runtests setup.. (I think)
[11:22:21] <cradek> the fixed gcode should be chosen carefully to exercise "everything"
[11:22:35] <skunkworks> that is the probelm.. 'everything'
[11:22:40] <cradek> yep
[11:25:07] * cradek feels bad saying "yeah sure but that's hard" to seb
[11:25:15] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-experimental2/tests/trajectory-planner/circular-arcs
[11:51:15] <seb_kuzminsky> i started looking at those tests this morning
[11:51:31] <seb_kuzminsky> it's not integrated with runtests, so it requires a human to run it
[11:51:38] <seb_kuzminsky> it's a good start though
[11:52:04] <seb_kuzminsky> i'll ask rob if he wants me to work on integrating his tests with runtests
[12:01:43] <seb_kuzminsky> iit seems easy to verify velocity & acceleration constraints in motion
[12:02:11] <seb_kuzminsky> run halsampler and record the waypoints, the have checkresults compute vel & acc and compare to the ini-file limits
[12:03:03] <seb_kuzminsky> i've been thinking about how to test the positions themselves - specifically to verify TP adherence to the G64 P-word
[12:03:45] <seb_kuzminsky> you could run each ngc file through sai first, so that checkresults can compare the canonical path with the waypoints you got from halsampler after TP processed the path
[12:04:39] <seb_kuzminsky> each waypoint should be within $P_WORD of the currenct path segment, until you're within $P_WORD of the end of the current segment, then you go on to the next
[12:05:55] <seb_kuzminsky> this algorithm gets into trouble when a path segment passes within $P_WORD of its endpoint, for example a complete or nearly-complete circle
[12:06:08] <seb_kuzminsky> i'm not sure how to tell checkresults to stay on the current path segment in that situation
[12:07:02] <seb_kuzminsky> rob mailed me back and accepted my offer of help with integrating his test
[12:07:20] <seb_kuzminsky> (he prefers to receive github pull requests, fwiw, which is fine by me)
[12:07:33] <seb_kuzminsky> ok, back to work for me
[20:52:00] <skunkworks> logger[psha]:
[20:52:00] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-04-23.html
[20:55:55] <skunkworks> yay
http://imagebin.org/307045
[20:56:42] <skunkworks> did dgarr add the tcl stub patch to master?
[21:27:50] <skunkworks> looks like it is.
[21:31:58] <skunkworks> question - should sim -> axis show anything in the calibration menu? I get
http://imagebin.org/307048
[21:57:44] <dgarr> skunkworks: the stubs patch has not been added, seb wants to check with cradek to see if it is wanted for trusty + 2.5.x
[21:58:53] <dgarr> skunkworks: no sim (to my knowledge) has an ini with tunable (eg pid) parameters. The message in 2.6 says that. The message was improved (hopefully) today with commit 27ae7c7
[22:02:46] <skunkworks> dgarr: thanks!
[22:04:24] <dgarr> the prior (2.5.x) behavior for sim ini
[22:04:40] <dgarr> was probably even more confusing
[22:04:53] <dgarr> when calibration (emccalib) was selected
[22:05:14] <dgarr> sinde there are no items to tune