Back
[00:03:02] <linuxcnc-build> build #545 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/545 blamelist: Norbert Schechner <nieson@web.de>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>
[02:12:08] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 644c52e 06linuxcnc Merge branch 'master' into gmoccapy_JA_based_on_master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=644c52e
[02:12:08] <KGB-linuxcnc> 03Norbert Schechner 05gmoccapy_JA_based_on_master 0208697 06linuxcnc 10configs/sim/gmoccapy/gmoccapy_with_user_tabs.ini 10src/emc/usr_intf/gmoccapy/getiniinfo.py 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_JA_master_2_0_26 - bugfix tbtn_user_tabs and getiniinfo increments * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0208697
[06:25:26] <jthornton> following the instructions on the buildbot page to get master, how do you get updates?
[06:37:58] <jthornton> when I click on
http://linuxcnc.org/docs/devel/html/ I get This documentation refers to LinuxCNC version 2.6.12-59-g075a445.
[07:10:34] <skunkworks> zlog
[07:14:48] <jepler> linuxcnc-build: force build --branch=master 0000.checkin
[07:14:54] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[07:17:07] <jepler> jthornton: not sure why that should be, but hopefully asking buildbot to build master branch it will replace those wrong docs
[07:17:24] <jthornton> ok, thanks
[07:17:27] <jepler> jthornton: if you add something to sources.list then you get updates from that server just like you do from any other server.
[07:17:35] <jepler> via apt-get or your favorite GUI front end
[07:19:40] <jthornton> ok, I see that now in the synaptic package manager I did a reload then checked status installed (upgradeable)
[10:30:36] <seb_kuzminsky> jthornton: hm, docs/devel should be from master branch
[10:30:40] <seb_kuzminsky> that's a bug
[10:31:05] <seb_kuzminsky> i'll look at the buildbot...
[10:34:45] <seb_kuzminsky> it's a bug in the get-version-from-git script
[10:35:03] <seb_kuzminsky> it's actually building master, but it's using the release tag from 2.6
[10:37:16] <seb_kuzminsky> err
[10:38:39] <seb_kuzminsky> no that's not it
[10:40:27] <seb_kuzminsky> strange, lookks like the buildbot built an invalid combination of branch & commit-sha:
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4430
[10:41:07] <seb_kuzminsky> 075a4456f19ee811e44c097104fe965e1e30077f wasn't committed to master, it was committed to 2.6, and later merged into master
[11:06:26] <seb_kuzminsky> i think what happened is this:
[11:07:12] <seb_kuzminsky> i pushed 9633f07334acde63975d376079f0a04b6c13725b to master, which was a merge of 2.6 -> 2.7 -> master of the issue 117 test & fix
[11:07:37] <seb_kuzminsky> the notifier at glo ran and started notifying the buildbot of each commit
[11:08:13] <seb_kuzminsky> after 075a4456f19ee811e44c097104fe965e1e30077f there was a delay longer than 5 seconds, which is the buildbot's "tree stable timer", so it went ahead and started the build
[11:08:42] <seb_kuzminsky> in the seconds after the build started, the notifications for the other commits came in, but they didn't make it into that build
[11:09:14] <seb_kuzminsky> so i'm going to increase the tree stable timeout from 5 seconds to 20 and the problem should become much more rare
[11:34:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15rene-dev commented on issue #97: There is a lot more to this problem, in world mode all the joint limits(acc/vel) are ignored.... 02
https://github.com/LinuxCNC/linuxcnc/issues/97#issuecomment-235942889
[13:28:12] <JT-Shop> just tested the 2.7.5 branch and it lets you check the check box fine and F2 power up but you have to hit the keyboard jog key twice, the first time it does not jog
[13:29:59] <linuxcnc-build> build forced [ETA 4h22m04s]
[13:29:59] <linuxcnc-build> I'll give a shout when the build finishes
[13:32:15] <JT-Shop> which is the same behavior as 2.7.4, must be a keyboard thing because you can use other jog means like my joystick and it jogs straight away
[13:41:55] <jepler> JT-Shop: thank you for testing!
[13:47:03] <JT-Shop> you would laugh at how many times I had to build the RIP before I got everything right... I should have that memorized by now
[14:24:50] <skunkworks> I did try master on the matsuura. The only issue I ran into so far was the conversion script added some pins to some setp lines.. :) I think I was setp-ing the axis.0.jog-enable and it added joint.0.jog-enable to the same line
[14:27:44] <skunkworks> andypugh, your carousel component works great - the index homing fix made it into master and now jogging works as expected.
[14:28:01] <andypugh> Grand :-)
[14:28:44] <skunkworks> (although we have to move the index back to where it was originally - it now homes 1 pocket off ;) )
[14:29:00] <skunkworks> atleast now it makes sense.
[15:29:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #126: coordinate system changed to G54 on Abort and program end 02
https://github.com/LinuxCNC/linuxcnc/issues/126
[15:33:12] <linuxcnc-build> Hey! build 0000.checkin #4433 is complete: Success [3build successful]
[15:33:12] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4433
[15:59:51] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #97: @rene-dev Yes, obeying joint constraints (velocity and acceleration) while running in Cartesian mode is a major area for future work. 02
https://github.com/LinuxCNC/linuxcnc/issues/97#issuecomment-236016280
[16:21:10] <seb_kuzminsky> jthornton: i'm curious if the current tip of 2.7 fixes the "limit switch causes Axis hang" problem you reported, let me know if you get a chance to test it
[16:23:47] <jepler> seb_kuzminsky: have a look at the log around 12:01 your time
[16:27:28] <seb_kuzminsky> did i space out at the wrong time again?
[16:27:39] <seb_kuzminsky> oh, heh
[16:28:33] <seb_kuzminsky> i saw that, but my eye stopped at "2.7.5" and i though "nope, 2.7.5 is before my fix, he's not talking about the one thing i care about" and i stopped reading
[16:29:27] <seb_kuzminsky> so... it sounds like that particular regression is fixed, now there's just the 'incorrect reset to G54' that skunkworks_ reported, amirite
[16:29:37] <jepler> yeah that must be the last one
[16:29:48] <seb_kuzminsky> hahahah .. hah...
[16:29:52] * seb_kuzminsky sobs
[16:31:26] <seb_kuzminsky> https://forum.linuxcnc.org/forum/38-general-linuxcnc-questions/31270-2-7-5-becomes-unresponsive/78109
[16:31:33] <seb_kuzminsky> same bug
[16:32:47] <seb_kuzminsky> revert is the right answer, does anyone disagree? better to live with the stale-statbuffer-on-abort bug that zultron reported, than to have all these common regressions people are running into
[16:33:17] <seb_kuzminsky> i'll fix all the bugs i introduce in master, but i shouldn't destabilize the stable branches while doing so
[16:36:29] <jepler> seb_kuzminsky: it will take some care to revert all the right commits in 2.6, then merge all the way up to master, then un-revert them in master
[16:36:32] <jepler> ugh *shudders*
[16:36:38] <seb_kuzminsky> agreed
[16:36:48] <seb_kuzminsky> it's totally manageable
[16:37:14] <seb_kuzminsky> because everyone else is smart enough not to touch task, it'll be pretty clean and conflict-free
[16:37:43] <seb_kuzminsky> the alternative is to fix the current last known regression, release again, and hope for the best
[16:38:05] <seb_kuzminsky> i know how to restore the old behavior, it's not hard
[16:38:12] <seb_kuzminsky> but i dont know what other regressions i introduced
[16:38:42] <JT-Shop> seb, I pulled 2.7 this morning and built a RIP
[16:39:18] * JT-Shop just pulled the the wires out of his new probe... was in the MDI window of Touchy not Auto...
[16:39:34] <seb_kuzminsky> bummer
[16:43:46] <JT-Shop> according to the ohm meter it was clean break about 1/2 way from the probe to the plug... whew
[18:11:34] <andypugh> JT-Shop: My probe connector is a home-made MagSafe thing:
https://picasaweb.google.com/108164504656404380542/HarrisonMill#5901893707657187586
[18:11:45] <andypugh> https://picasaweb.google.com/108164504656404380542/HarrisonMill#5901893706748072338
[18:11:55] <andypugh> to avoid just that sort of trouble.
[18:15:38] <JT-Shop> very nice
[18:24:19] <JT-Shop> I'm guessing the ring part is the magnet?
[18:26:30] <andypugh> Yes, I bought a bunch of ring-shaped magnets from eBay.
[18:27:49] <andypugh> The small bit is all rigid, just a bit of brass pressed in with a delrin sleeve. (and the black wire nipped between the sleeve and the magnet, you can’t really solder to magnets. The “plug” has a spring on the inner pin.
[18:28:40] <andypugh> it does tend to pick up swarf, of course…
[18:30:44] <JT-Shop> yes I can imagine it does so does almost every screwdriver I have... I need a unmagnetization thing
[18:31:06] <kwallace1> I'm surprised that wireless probes are not more common.
[18:31:16] <andypugh> They cost money :-)
[18:31:39] <andypugh> I think that they are very common in industry, which is why the wired ones are found on eBay
[19:14:00] <jepler> http://fuckyeahfortran.tumblr.com/post/148120699949/liartownusa-british-pub-sign-the-34-x-18
[19:20:29] <seb_kuzminsky> we should hold the next+1 hackfest there
[19:22:30] <JT-Shop> I wonder if my wife would understand me wanting to go there
[20:49:59] <mozmck> interesting, if I turn on block delete and use / in front of probe lines, it fixes the display problems with tool size and all on the live preview
[20:51:17] <mozmck> I was thinking it would be nice to have an option for the backplot to simply ignore G38.2 and G92 lines. Is there a way to enable block delete while loading a file in the backplot and then disable it after it's done?
[21:04:17] <jepler> I don't think you can do that without modifying the UI programs
[21:05:46] <mozmck> Yeah, I'm using my gscreen based UI, but the file loading is done with File_Action_Open and I'm not sure how easily I can do it.
[21:06:03] <jepler> see class StatMixin in lib/python/rs274/interpret.py
[21:06:15] <jepler> you need to replace that implementation of the method get_block_delete with one that does what you want
[21:06:21] <jepler> for instance, by making it always return true
[21:06:50] <jepler> you could do this by creating a new subclass of gremlin's class StatCanon
[21:06:54] <mozmck> is interpret.py part of the backplot code?
[21:07:04] <jepler> but how you do this within the structure given to you by gscreen I have no clue
[21:07:07] <jepler> yes
[21:07:36] <mozmck> Hmm, subclassing will make me learn more python - which I need to do anyhow.
[21:08:25] <mozmck> thanks for the tip - I'll look into it. If I get too deep I may look at the tool and measurement scaling code.
[21:10:27] <jepler> there's also the special variable #<_task>
[21:10:27] <jepler> // predicate: 1 in milltask instance, 0 in UI - control preview behaviour
[21:10:30] <jepler> init_readonly_param("_task", NP_TASK, PA_USE_LOOKUP);
[21:10:47] <jepler> seems to be documented down at docs/src/gcode/overview.txt
[21:13:10] <mozmck> so the interpreter can see if #<_task> != 1.0 and ignore probe failures?
[21:13:29] <mozmck> or other things...
[21:15:04] <jepler> gcode can do whatever it wants with that value
[21:18:01] <mozmck> oh, so the interpreter sets it. hmm
[21:18:44] <jepler> it's a built-in variable provided by the interpreter for the part program or gcode subroutines to use
[21:20:46] <mozmck> so I could say o100 if #<_task> do G38.2 etc. That's good to know, but I may look at other options first so users don't have to change all their code.
[21:22:11] <KGB-linuxcnc> 03Jeff Epler 05master 7bcf62b 06linuxcnc 10debian/configure 03debian/control.top.in 10src/Makefile Merge branch 'jepler/master/uspace-plus' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7bcf62b
[21:23:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #110: "uspace plus": uspace with support for preempt-rt, rtai, and xenomai (06master...06jepler/master/uspace-plus) 02
https://github.com/LinuxCNC/linuxcnc/pull/110
[21:24:37] <KGB-linuxcnc> 05jepler/master/uspace-plus a63d5f8 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a63d5f8
[21:26:01] <mozmck> yay! uspace-plus is good to see!
[21:29:21] <jepler> I wish more (any) people had tested it but yeah I think it's cool.
[21:29:23] <jepler> 'night
[21:49:45] <linuxcnc-build> build #4419 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4419 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:53:09] <jepler> hmph.
[21:57:23] <linuxcnc-build> build #4434 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4434 blamelist: Jeff Epler <jepler@unpythonic.net>
[21:57:52] <jepler> linuxcnc-build: force build --branch=master 0000.checkin
[21:57:53] <linuxcnc-build> build forced [ETA 3h12m38s]
[21:57:53] <linuxcnc-build> I'll give a shout when the build finishes
[22:08:19] <jepler> 5000 local runs of the failed test (module-loading/pid/num_chan=16) on wheezy posix non-realtime and no failure...
[22:09:39] <jepler> seems like uspace branch had another failure of that test, which I had chalked up to a bug in the RTAPI rtapi_print_msg implementation at the time
[22:09:55] <jepler> but this is not about messages printed from RT, this is about the output of halcmd show pin...
[22:16:05] <KGB-linuxcnc> 03Jeff Epler 05master 19c43d4 06linuxcnc 10src/hal/hal_lib.c hal_lib: factor condition out to local variable * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=19c43d4
[22:16:05] <KGB-linuxcnc> 03Jeff Epler 05master 106fcd8 06linuxcnc 10src/hal/hal_lib.c hal_lib: drive first non-input-pin value onto signal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=106fcd8
[22:31:53] <linuxcnc-build> build #2613 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2613
[22:31:53] <linuxcnc-build> build #4435 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4435
[22:35:07] <jepler> linuxcnc-build: force build --branch=master 0000.checkin
[22:35:15] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[22:42:27] <jepler> that one *could* be a problem with messages printed in rtapi_app..
[22:52:45] <jepler> sure reproduced the hm2-idrom failure on my odroid
[22:53:06] <jepler> hm2_test: loading HostMowaitpid failed /home/jepler/src/linhm2/hm2_test.0: IDROM IOPortsbroken-load-test.hal:3: /home/jepler/src/linuxcnc/bin/rtapi_app exited without becoming ready
[22:53:15] <jepler> it's not an exfiltration problem, it's a buffering problem
[22:53:16] <jepler> 'night once more
[23:05:35] <linuxcnc-build> build #2614 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2614 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:05:35] <linuxcnc-build> build #4436 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4436 blamelist: Jeff Epler <jepler@unpythonic.net>
[23:05:35] <linuxcnc-build> build forced [ETA 3h12m38s]
[23:05:36] <linuxcnc-build> I'll give a shout when the build finishes