Back
[10:19:05] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 a045a3e 06linuxcnc 10debian/configure packaging: accept linux 3.4-9-rtai-686-pae as a "known" kernel * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a045a3e
[10:38:47] <seb_kuzminsky> speaking of things that are not news any more
[10:59:11] <skunkworks> seb_kuzminsky: rob pushed some fixes for the trajectory planner overage. I have been testing and no issues so far
[11:03:41] <seb_kuzminsky> groovy
[11:03:53] * seb_kuzminsky looks at the 2.7 todo list
[11:04:40] <archivist> last item...ship it?
[11:05:39] <Tom_itx> the todone list is getting longer
[11:08:58] <seb_kuzminsky> last time i spoke with rob he said he wanted to rename or at least document the new kink ratio variable, but that's not in his branch yet
[11:09:49] <seb_kuzminsky> skunkworks: are you happy with gcode constraints & run speed? you had found some problem with 2-axis configs, but that got fixed, right?
[11:10:44] <Tom_itx> what about the toolchange bug?
[11:11:08] <seb_kuzminsky> do you mean the recent buildbot failure in the t0 test?
[11:11:20] <seb_kuzminsky> or the remap bug any found?
[11:11:22] <cradek> the mdi-remap problem
[11:11:27] <seb_kuzminsky> yeah
[11:11:27] <Tom_itx> i believe so... the one andy's comp brought to surface
[11:11:32] <seb_kuzminsky> right
[11:11:56] <seb_kuzminsky> i think that's a real bug we need to fix, but it's not a regression between 2.6 and 2.7 so i dont think we should hold up 2.7 for it
[11:12:48] <seb_kuzminsky> i made the 2.6-remap-bug branch to do the fix in, once someone decides to take it on
[11:12:59] <Tom_itx> is andy's comp gonna be in 7?
[11:13:03] <Tom_itx> 2.7
[11:13:26] <Tom_itx> maybe it should come with a warning in the docs if so
[11:13:38] <Tom_itx> that seems to be the only thing that discovered it
[11:13:48] <seb_kuzminsky> the carousel comp shouldn't go in, because it doesn't work (because of this pre-existing bug, not because of anything andy did wrong)
[11:13:57] <Tom_itx> ok
[11:14:34] <seb_kuzminsky> i'm fine with adding new comps, drivers, and configs to a stable branch, because they won't destabilize things for people who dont use the new thing
[11:15:04] <seb_kuzminsky> so if/when we fix the remap bug, andy's carousel comp and remap trickery will magically start working, and then we can merge it (even if it's after 2.7.0)
[11:15:16] <Tom_itx> that's why i mentioned the warining maybe instead of holding it out
[11:15:27] <Tom_itx> few will use it early on
[11:15:39] <jepler> seb_kuzminsky: I believe jepler/arm-atomics is suitable to go into 2.7, but it is only to fix rare testsuite failures on arm, really
[11:15:46] <Tom_itx> those that did could have a head start on example setups for it
[11:15:59] <seb_kuzminsky> rob's branch has a commit in it that lacks SoB, and so can't be pushed to our repo. i asked him to add it, but haven't heard back
[11:16:12] <seb_kuzminsky> i'd prefer not to sign that commit off myself, because then our branch and his will diverge
[11:16:42] <seb_kuzminsky> jepler: i'd like arm-atomics in 2.7, to start getting more runtime on it
[11:18:24] <jepler> seb_kuzminsky: OK, will merge tonight.
[11:22:14] <skunkworks> seb_kuzminsky: yes - the 2 bug was also fixed
[11:27:09] <skunkworks> * 2 axis bug
[11:28:16] <seb_kuzminsky> thanks guys
[11:28:50] <seb_kuzminsky> jthornton sounds like he wants to work on the docs a little more
[13:11:07] <skunkworks> I emailed rob. (he has to be getting sick of me...)
[13:58:17] <PCW> 4 hm2_eth cards seem OK at 3 KHz (going from 3 to 4 cards added about 14 usec to the average servo thread time)
[13:58:51] <skunkworks> wow
[14:05:26] <PCW> eventually I will run out of margin for reading the sserial inputs. n the H97 the max servo thread time
[14:05:28] <PCW> with 4 cards is about 200 usec so at 3 KHz, all sserial devices must answer back in 133 usec
[14:09:28] <jthornton> yes, I have a bit more to do on the docs
[14:54:59] <seb_kuzminsky> jthornton: ok, cool
[14:55:07] <seb_kuzminsky> thanks for working on that
[15:40:21] <skunksleep> seb_kuzminsky: rogge was wondering about the status of the liblinuxcnc? (Is that the right branch for ui interface)
[15:53:23] <cradek> skunksleep: you're the least-efficient irc gateway I can imagine
[15:53:51] <skunksleep> Sorry.. What?
[15:55:18] <cradek> you relay messages in and out of irc for people who don't participate in irc, and that is a very inefficient way for them to use irc
[15:55:24] <jepler> skunksleep: it's on its own branch and nowhere near finished. branch name (origin/)liblinuxcnc-ui
[15:57:14] <skunksleep> jepler: thanks. cradek: agreed
[15:58:12] <skunksleep> jepler: I assume at this point it would go into master vs 2.7
[15:58:18] <jepler> skunksleep: absolutely
[16:22:25] <skunkworks> if someone wanted to look at that branch - is it pretty selfe explainatory? hmm when did spell checking quit on chatzilla
[16:26:43] <seb_kuzminsky> skunkworks: i think it's pretty clear, for a work-in-progress
[16:27:24] <seb_kuzminsky> why is drogge interested in it? ask him and let me know what he says
[16:27:31] <seb_kuzminsky> j/k
[16:28:46] <cradek> skunksleep: seb wants you to ask drogge what's up and report back here. thanks in advance.
[16:30:52] <skunkworks> heh - he is interested in it because they could then create closed source frontends (you guys actually talked about it when you all discussed the pathpilot roll out)
[16:32:05] <skunkworks> * a closed soure..
[16:32:12] <skunkworks> source
[16:41:56] <PCW> jepler: did you see that I have 4 hm2_eth cards running from a single MAC at 3 KHz?
[16:41:57] <PCW> So a 8 card max is probably OK (well maybe crazy but possible timing wise)
[16:42:52] <jepler> PCW: 3kHz? wow
[16:43:06] <jepler> I can bump the max board count up at any time, it's just a #define in the C source
[16:43:20] <PCW> yeah only 14 usec more for the 4th card
[16:44:45] <PCW> now with 10GE....
[17:28:43] <jepler> skunkworks: it's important to notice that in its current incarnation, liblinuxcnc-ui is not particularly likely to be free of depending on GPL code. In the plan outlined in
http://mid.gmane.org/20141019130635.GA32102%40unpythonic.net this would be possible with the implementation of step 2, where we introduce a new IPC system and take care that the client side is not a derivative work of GPL code
[17:41:24] <seb_kuzminsky> jepler, would you tell skunkworks to suggest to drogge that they should drop their closed-source nightmares and embrace the open-source world
[18:29:53] <jepler> seb_kuzminsky: no, I don't want to cause trouble
[18:42:09] <seb_kuzminsky> awesome, chris lesiak reviewed the arm-atomics code
[19:09:46] * jepler goes to read
[19:29:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/arm-atomic f529fae 06linuxcnc 03docs/man/man3/rtapi_atomic.3rtapi 10src/Makefile 03src/rtapi/rtapi_atomic.h rtapi: implement subset of <stdatomic.h> * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f529fae
[19:29:52] <KGB-linuxcnc> 03Jeff Epler 05jepler/arm-atomic a694daf 06linuxcnc 10src/hal/components/sampler.c 10src/hal/components/sampler_usr.c 10src/hal/components/streamer.c 10src/hal/components/streamer_usr.c streamer, sampler: fix memory-order bugs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a694daf
[20:09:16] <skunkworks> jepler: thanks!
[20:09:33] <skunkworks> rob hopes to push a branch tonight with sob
[20:11:09] <PCW> sob?
[20:15:43] <jepler> PCW: signed-off-by, a line we put in all commit messages to indicate it is offered to the linuxcnc project under an appropriate open-source license
[20:17:52] <PCW> Ahh. Sounds like 2.7 is getting pretty close
[20:18:37] <jepler> yeah, sob is not a big deal