Back
[09:37:16] <skunkworks_> ship it!
http://imagebin.org/307118
[09:42:16] <skunkworks_> http://imagebin.org/307124
[09:42:20] <skunkworks_> 5 hours
[09:46:24] <cradek> have you tried anything with uvw, or more than one rotary?
[09:47:03] <skunkworks_> I don't have any gcode.. (that I know of) but I could.
[09:47:17] <cradek> I wonder if we still have the tort generator
[09:47:30] <skunkworks_> it is still in scrips I think
[09:47:35] <cradek> it would be easy to tweak it (just add some lines), since arcs aren't valid in those other axes
[09:47:40] <skunkworks_> (that is how I generated the 4 axis one)
[09:47:44] <cradek> aha
[09:48:37] <skunkworks_> I would just have to add the rest of the axis's peaks to the panel
[09:52:45] <skunkworks_> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/144240
[09:54:06] <skunkworks_> someone else had tried a config where w was a second spindle (2 spindle machine) and it worked as expected after a small bug.
[09:54:17] <skunkworks_> (no readahead in those axis yet though)
[09:54:40] <skunkworks_> falls back to parabolic blending
[10:11:49] <cradek> I think that's utterly reasonable
[10:26:15] <seb_kuzminsky> cradek: do you care about support in 2.5 for ubuntu trusty 14.04?
[10:26:43] <seb_kuzminsky> dgarr's got a patch that fixes a bug in linuxcnc when running on trusty, and we're wondering if we should apply it in 2.5 or 2.6
[10:27:15] <cradek> is it simple and unlikely to break the other platforms?
[10:28:11] <seb_kuzminsky> http://psha.org.ru/irc/%23emc-devel/2014-04-18.html#15:31:23
[10:28:13] <seb_kuzminsky> yeah
[10:28:29] <seb_kuzminsky> it's a straight copy of code that's already in some other places in our code base
[10:29:20] <cradek> oh that's great - no problem then
[10:29:36] <seb_kuzminsky> cool
[10:29:48] <cradek> thanks for fixing edge harder
[10:29:55] <seb_kuzminsky> heh
[10:30:46] <seb_kuzminsky> i doubt anyone would care about the two little "edge" cases i fixed
[10:31:11] <seb_kuzminsky> well, except maybe the "out_invert is wrong on the first cycle" one
[10:48:56] <KGB-linuxcnc> 03Dewey Garrett 05v2.5_branch 5f36acb 06linuxcnc 10src/hal/utils/Submakefile 10src/hal/utils/halsh.c halsh: initialize stubs library * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f36acb
[10:50:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 492d75a 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=492d75a
[10:51:30] <cradek> awesome, thanks
[10:55:25] <seb_kuzminsky> yeah, thanks dgarr :-)
[11:04:37] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 fb146a0 06linuxcnc Merge branch 'feature/canon-posemath-operators' into circular-blend-arc-experimental2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb146a0
[11:04:38] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 b57e49d 06linuxcnc 10src/emc/task/emccanon.cc 10tests/trajectory-planner/circular-arcs/nc_files/quick-tests/sawtooth.ngc canon: Fix for zero-angle bug in ARC_FEED causing rare maxvel violation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b57e49d
[11:04:38] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 fb27cb4 06linuxcnc 10(17 files in 4 dirs) Housekeeping of circular arc tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fb27cb4
[11:04:40] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 fbb1c27 06linuxcnc 10src/emc/task/emccanon.cc canon: Added compile flag for debug statements * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fbb1c27
[11:04:44] <KGB-linuxcnc> 03Robert W. Ellenberg 05circular-blend-arc-rc3 9291f8a 06linuxcnc 10src/emc/task/emccanon.cc canon: disabled debug output after verifying ARC_FEED changes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9291f8a
[11:05:12] <seb_kuzminsky> wow!
[11:13:09] <cradek> is that a new rebased version? it looks a ton more reviewable
[11:20:52] <seb_kuzminsky> no, it's new stuff on top of the previous
[11:23:16] <cradek> ah ok
[13:01:43] <skunkworks_> oh - yay!
[13:26:26] <skunkworks_> huh - you have to apply garretts patch before linuxcnc will run with this build.. (on 14.04)
[13:38:12] <skunkworks_> http://pastebin.ca/2701562
[13:38:44] <skunkworks_> trying on 10.04 just to make sure it isn't needed
[13:51:44] <cradek> that patch is in 2.5 - I can merge upward for you if it isn't done already
[14:02:41] <KGB-linuxcnc> 03Norbert Schechner 052.6 321bf92 06linuxcnc 03share/gtksourceview-2.0/language-specs/gcode.lang 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_4 - screen 2 "bug" solved and gcode.lang is back * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=321bf92
[14:07:20] <KGB-linuxcnc> 03Norbert Schechner 05master d8fe188 06linuxcnc 03share/gtksourceview-2.0/language-specs/gcode.lang 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_4 - show screen 2 button only sensitive if file exist * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d8fe188
[14:07:20] <KGB-linuxcnc> 03Norbert Schechner 05master 523044b 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=523044b
[14:07:20] <KGB-linuxcnc> 03Norbert Schechner 05master d8cfa09 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d8cfa09
[14:21:29] <cradek> I have never seen a merge of two merges before
[14:22:43] <cradek> I don't think it's wrong, but it's weird
[14:34:33] <skunkworks_> cradek, I don't know. (it worked normally on 10.04) this is robs build which before his latest pushes built just fine (just the 'show hal configuration' didn't work) . now the config picker doesn't load unless I apply dewyes patch.
[14:34:59] <skunkworks_> 14.04
[15:06:28] <seb_kuzminsky> skunkworks_: dewey's tclstubs patch is in 2.5, 2.6, and master, as of this morning
[15:07:29] <seb_kuzminsky> if i was rob ellenberg, i would create a new branch called circular-blend-arc-rc4, pointing at the same commit as -rc3, and rebase -rc4 onto master
[15:07:45] <seb_kuzminsky> -rc3 would stay around for now as a reference, but all new work would be done on -rc4
[15:11:26] <skunkworks_> what would have to happen to get this into master?
[15:12:21] <skunkworks_> motion synced analog out seems to work :)
[15:14:57] <skunkworks_> bbl
[15:19:52] <seb_kuzminsky> to get what into master?
[15:19:55] <seb_kuzminsky> oh wait, he left
[15:28:32] <cradek> I think he's wondering whether 5f36acbeb had been merged upward into master yet, and the answer is yes
[15:53:33] <seb_kuzminsky> hi skunkworks !
[15:54:01] <seb_kuzminsky> you were asking if Trusty support is in master? it is, now
[16:02:38] <memleak> seb_kuzminsky, trusty support? RTAI isn't there yet. are you talking about linuxcnc sim?
[16:04:30] <PCW> presumably the 3.4.55 RTAI kernel will work
[16:05:17] <memleak> ah right, its just not based off the same major release version that trusty uses
[16:06:05] <PCW> The 2.6.122 kernel works with 12.04 so not terribly picky
[16:06:29] <PCW> just no recent hardware support
[16:06:50] <memleak> i see
[16:08:03] <skunkworks> I meant robs planner in 2.7
[16:10:18] <skunkworks> seb_kuzminsky: like what has to happen.
[16:15:52] <skunkworks> I can see testing xyzabcuvw motion.. (only some not all has been tested)
[16:16:23] <skunkworks> (was hoping someone would add bcuvw to the tort.py script.. ;) )
[16:26:49] <cradek> to get rob's planner merged into master, the first requirement is to hear from rob that he's ready
[16:27:17] <cradek> I don't know whether there's a second requirement...
[16:28:03] <skunkworks> that can't be right... ;)
[16:28:05] <cradek> you've done more testing work than any other ten people would do
[16:28:22] <seb_kuzminsky> skunkworks: is it true that rob's tp instroduces no known regressions?
[16:28:54] <cradek> in my opinion, it would be very wrong to dump rob's big changes on a bunch of users without rob saying go
[16:29:15] <skunkworks> the only fly in the ointment that may ruffle some feathers - G0 to Feed motions are exact stop.
[16:29:16] <seb_kuzminsky> i want skunkworks (and any other testers) to say so too
[16:29:28] <seb_kuzminsky> that seems like an improvement to me
[16:29:29] <cradek> yes absolutely
[16:29:55] <cradek> I don't care whether or not that case exact-stops
[16:30:04] <archivist> that is better methinks too
[16:30:04] <cradek> it never has before, which was fine, but it's fine if it does
[16:30:30] <archivist> it was dangerous before
[16:30:34] <seb_kuzminsky> i guess if it obeys the G64 P-word tolerance on G0/feed blends, that's ok too
[16:30:54] <seb_kuzminsky> archivist: what's the danger? (i dont disagree with you)
[16:31:17] <archivist> coming out or into a slot from the side
[16:31:29] <skunkworks> if you are not expecting it to 'blend' it may hit stock unexpectedly..
[16:31:39] <archivist> must wait till inline
[16:31:49] <skunkworks> I really don'
[16:32:26] <skunkworks> I really don't care either way. I would like it to be ini setable.. but if not - oh well.
[16:32:35] <archivist> so I do not think a blend is good between g0 and a controlled move
[16:33:44] <cradek> I'm generally against making things options. you very quickly get combinatorial explosion and untestability.
[16:34:07] <seb_kuzminsky> i'm sympathetic to that line of thinking, but i don't think it's that different from blending one feed into another - in both cases you better have your P-word right or you'll make parts that don't look like you expect
[16:34:07] <cradek> options are appropriate where both alternatives are totally unusable for a subset of people
[16:34:46] <cradek> otherwise, just make a reasonable choice and quit asking people their opinions
[16:34:55] <cradek> see also: bike-shed painting
[16:35:34] <cradek> so if anyone asks me (and they didn't), whichever way rob thinks is best is fine
[16:37:05] <skunkworks> seb_kuzminsky: G64 was switched back to current linuxcnc behaviour
[16:37:15] <seb_kuzminsky> great
[16:37:32] <skunkworks> (no Q - Q=P
[16:37:34] <skunkworks> )
[16:37:54] <seb_kuzminsky> i see that rob is still making many commits per day to circular-arc-blend-rc3, which makes me think he's not done with it yet
[16:40:16] <archivist> I added a move on one bit of code because of the blend (to move g0 the blend out of the material)
[16:41:00] <seb_kuzminsky> i guess if it doesn't break any existing functionality, i'd be ok merging c-a-b into master even if it's still evolving...
[16:41:14] <cradek> it's probably a mistake to ever start or end a G0 while touching the work (especially true if using cutter comp)
[16:41:41] <seb_kuzminsky> or for a G0 to pass through the work! :-P
[16:41:43] <cradek> seb_kuzminsky: you mean with rob's consent, right?
[16:41:50] <seb_kuzminsky> yes absolutely
[16:42:08] <seb_kuzminsky> i was thinking about the "second requirement"
[16:42:38] <cradek> I wonder how tricky the cab+ja4 merge will be
[16:42:49] <cradek> I should attempt it, and find out
[16:42:56] <seb_kuzminsky> we should maybe start thinking about who wants to be RM for 2.7... since this is a 2.7 feature
[16:43:07] <cradek> seb_kuzminsky: might one direction be easier than the other?
[16:43:18] <cradek> hmmm
[16:43:52] <seb_kuzminsky> not sure
[16:44:31] <seb_kuzminsky> i if i was going to work on ja, i'd start by rebasing it onto master (to get past the configs move)
[16:45:00] <cradek> is our meeting 4th saturday? you could propose a method to pick a RM (or propose someone)
[16:45:28] <archivist> I was just outside but the blend put it inside
[16:45:34] <cradek> yeah after all your work, I bet ja4 is pretty movable now
[16:46:34] <boonkerz_> hi
[16:46:45] <boonkerz_> i have compiled linuxcnc
[16:46:49] <boonkerz_> it starts
[16:47:07] <boonkerz_> but after select an maschine the maschine slows down
[16:47:24] <seb_kuzminsky> hi boonkerz_
[16:47:33] <boonkerz_> hi
[16:47:57] <seb_kuzminsky> after selecting a config from the config picker, linuxcnc starts some realtime threads, which uses up a bunch of your CPU time
[16:48:05] <boonkerz_> latency test works
[16:48:12] <boonkerz_> with round 10000
[16:48:22] <seb_kuzminsky> what kind of CPU? what kernel?
[16:48:26] <boonkerz_> yea but its an pentium 4
[16:48:39] <boonkerz_> 2,4ghz i think
[16:48:49] <boonkerz_> kernel is an 3.8.13
[16:49:07] <seb_kuzminsky> is it an rtai kernel?
[16:49:26] <seb_kuzminsky> 3.8.13 is not one we ship
[16:49:39] <boonkerz_> yea rtai kernel
[16:49:42] <boonkerz_> https://www.dropbox.com/sc/o6en5gzkqwxhg5a/dR5-At0aJ2
[16:49:47] <boonkerz_> rtai 4.0
[16:50:14] <cradek> this all sounds normal
[16:50:21] <seb_kuzminsky> some slowdown is to be expected. how bad is it?
[16:50:24] <cradek> check your period settings
[16:50:37] <boonkerz_> very slow terminal is not responsive
[16:50:52] <cradek> especially check your base period setting
[16:50:57] <seb_kuzminsky> good point cradek
[16:51:22] <boonkerz_> where can i find them?
[16:51:22] <cradek> you can find a setting that will make any machine unusably slow, and a p4-2.4 is no speed demon
[16:51:34] <cradek> the ini file, base period setting
[16:52:12] <cradek> you should NOT run any of linuxcnc as root
[16:52:26] <cradek> (I see a sudo in your photo)
[16:52:45] <boonkerz_> yea it was an test :)
[16:53:22] <boonkerz_> is the base period relevant in an sim?
[16:53:30] <boonkerz_> maschine?
[16:53:55] <cradek> sim can mean more than one thing and it's not clear what you are asking
[16:54:51] <boonkerz_> in
https://www.dropbox.com/sc/o6en5gzkqwxhg5a/dR5-At0aJ2#lh:1-20140423_154539.jpg i select sim -> 9axis
[16:55:31] <cradek> that probably doesn't have a base period, but you can look at the config and find out for sure
[16:56:04] <cradek> if you're built for rtai, all configs will still start at least one realtime thread
[16:57:44] <boonkerz_> no base period only servo period
[16:57:57] <seb_kuzminsky> and it's 1,000,000?
[16:58:06] <boonkerz_> yea
[16:58:28] <boonkerz_> axis_9axis.ini
[16:58:37] <seb_kuzminsky> right
[16:58:54] <seb_kuzminsky> try this
[16:59:24] <seb_kuzminsky> run 'halcmd show thread' and pastebin (or dropbox) the output
[16:59:49] <seb_kuzminsky> (while linuxcnc is running and the system is slow)
[17:01:21] <seb_kuzminsky> also 'show funct
[17:01:23] <seb_kuzminsky> '
[17:03:09] <boonkerz_> http://pastebin.com/TKteMtTW
[17:03:13] <boonkerz_> thats wired
[17:03:42] <boonkerz_> i think the rtai slows the clock down or?
[17:09:31] <boonkerz_> http://pastebin.com/raw.php?i=ufrtrkPm
[17:11:32] <seb_kuzminsky> i have no experience with rtai 4, or the custom kernel config you're using
[17:12:11] <seb_kuzminsky> we use a version of rtai based on 3.9, with changes by shabbyx and memleak, and i don't know how that compares to your kernel
[17:12:36] <boonkerz_> ok thats an option :)
[17:13:23] <boonkerz_> ok you use rtai 3.9 with an older kernel?
[17:13:35] <seb_kuzminsky> i'm surprised there's no information in the halcmd show output
[17:14:00] <boonkerz_> yea i think the sheduler slows the computer after start the realtime subsystem
[17:14:11] <boonkerz_> i will look into the rtai options
[17:14:18] <seb_kuzminsky> do you have power management stuff disabled in your kernel config?
[17:14:22] <boonkerz_> yea
[17:14:32] <seb_kuzminsky> hmm, then i'd think rtai wouldn't mess with it
[17:14:54] <boonkerz_> can i start linuxcnc with an option that display debug messages
[17:14:56] <seb_kuzminsky> you can try our kernels if you like, they're available as debs at
http://linuxcnc.org/dists
[17:15:36] <seb_kuzminsky> yes, look at the DEBUG option in the .ini file
[17:15:50] <memleak> this is why we need a linuxcnc branch of RTAI.. because this happpens ;)
[17:16:10] <seb_kuzminsky> memleak: i'm not sure what's happening here yet
[17:16:24] <memleak> still, it would remove confusion.
[17:16:30] <seb_kuzminsky> boonkerz_: you shouldn't use sudo to run linuxcnc or halcmd
[17:16:34] <memleak> the branch is almost done anyway :)
[17:19:25] <memleak> the main tree is too much work for me to keep track of anyway, i have to constantly stay on top of everything because experimental changes get merged, then removed, then something else becomes invented, which breaks something else, its a highly annoying goose chase.
[17:21:14] <memleak> people can still choose to not use the branch i'll be pushing but i'm at the point where i don't want to support something that isn't "THE" branch / tree.
[17:21:29] <seb_kuzminsky> boonkerz_: was linuxcnc up and running when you ran those halcmd commands? if it's not, you'll get empty output
[17:21:55] <seb_kuzminsky> memleak: makes sense
[17:21:59] <boonkerz_> ok question
[17:22:09] <boonkerz_> is only the kernel relevant for linuxcnc
[17:22:31] <memleak> boonkerz_, no. RTAI userspace comes into play as well, greatly.
[17:22:44] <memleak> it lays / lies within /usr/realtime
[17:22:53] <seb_kuzminsky> memleak: i'm worried that if we fork rtai, we'll miss out on the extra eyeballs that the 'main' rtai community provides
[17:23:10] <memleak> i can always merge the changes as needed. its not an issue.
[17:23:59] <seb_kuzminsky> boonkerz_: did you build linuxcnc with a --with-realtime=$RTAI_PATH argument?
[17:24:41] <memleak> i am tired though of keeping on a constant track of every change ever pushed and doing massive commits all the time.
[17:25:15] <boonkerz_> seb no
[17:25:25] <seb_kuzminsky> memleak: yeah, i agree that's exhausting and no good
[17:25:30] <memleak> merging with vulcano, then magma, then custom patches on top of that, which are not compatible with other people's changes, etc, it needs to be more cherry picked and the shabbyx tree doesnt do that.
[17:25:33] <boonkerz_> i think it find realtime because configure is ok
[17:25:39] <seb_kuzminsky> boonkerz_: how did your linuxcnc build find your custom version of rtai?
[17:25:48] <boonkerz_> one moment
[17:25:50] <boonkerz_> i check
[17:25:58] <memleak> shabbyx tree philosophy is merge everything upstream all the time and try and make your own changes without braking things.
[17:26:17] <boonkerz_> ./configure --without-libmodbus --without-libusb-1.0
[17:26:30] <boonkerz_> thats my conf cmd
[17:26:41] <seb_kuzminsky> memleak: right, shabby is trying to stay connected to mainline rtai
[17:27:26] <seb_kuzminsky> boonkerz_: is there anything in your config.log about what rtai it found?
[17:27:30] <memleak> and i personally cant do that at the same time making it work with linuxcnc and actually having a reason backing up why the RTAI tree works with linuxnc (too much magic)
[17:27:56] <boonkerz_> yea as example checking for rtai_sched... /usr/realtime/modules/rtai_sched.ko
[17:28:14] <seb_kuzminsky> ah, so you installed your build of rtai 4.0 into /usr/realtime
[17:28:40] <boonkerz_> yea
[17:28:45] <boonkerz_> default path :)
[17:28:46] <memleak> for example, if there is someone else's improvements to the scheduler and such, or a bug fix, ill commit it, but if someone just decides to re-write some major mechanism with RTAI that affects linuxcnc, i rather leave those changes out
[17:29:03] <memleak> /usr/realtime is the userspace i was talking about
[17:29:37] <seb_kuzminsky> boonkerz_: were you running the 9axis sim config at the time you got the empty output from 'halcmd show' up above? if you're in the config picker, linuxcnc hasn't started yet.
[17:35:24] <boonkerz_> when i start linuxcnc all fine
[17:35:28] <boonkerz_> after config pick
[17:35:30] <boonkerz_> slow
[17:35:38] <boonkerz_> and halcmd show displays nothing
[17:37:18] <seb_kuzminsky> bizarre
[17:44:49] <seb_kuzminsky> boonkerz_: here's what it looks like on my machine (running our debs of memleak's rtai kernel):
http://pastebin.com/TsnFrY5W
[17:45:12] <boonkerz_> ok
[17:45:19] <seb_kuzminsky> the thing i was looking for was time and/or the max-time of the servo thread
[17:45:54] <seb_kuzminsky> in my example it's only 58 microseconds, so doing that once every second shouldn't impact system responsiveness
[17:46:08] <seb_kuzminsky> but if it took 580 microseconds, that'd be half you available CPU time gone
[17:46:34] <seb_kuzminsky> err, i meant "once every millisecond", not "once every second". :-/
[17:58:11] <boonkerz_> ok rtai testsuite latency work
[17:58:19] <boonkerz_> but only as sudo on ubuntu
[17:58:55] <seb_kuzminsky> what about the linuxcnc latency test?
[17:59:45] <seb_kuzminsky> when you built linuxcnc, did you run 'make' and then 'sudo make setuid'?
[18:00:16] <boonkerz_> yea
[18:00:24] <seb_kuzminsky> ok great
[18:00:47] <seb_kuzminsky> try running all your linuxcnc commands without sudo (i dont think that's what's messing things up here, but it's a difference from how we usually do things)
[18:00:55] <boonkerz_> latency test
https://www.dropbox.com/sc/o6en5gzkqwxhg5a/dR5-At0aJ2#lh:0-20140423_154435.jpg
[18:02:49] <seb_kuzminsky> right, that looks fine
[18:04:21] <seb_kuzminsky> what do you get from 'halcmd show threads' while the latency test is running?
[18:04:31] <seb_kuzminsky> the linuxcnc latency test i mean
[18:07:03] <boonkerz_> 991560 YES slow ( 872, 27372 ) 1 timedelta.1 24789 YES fast ( 544, 32940 ) 1 timedelta.0
[18:10:09] <boonkerz_> http://pastebin.com/VxMxu485
[18:10:17] <boonkerz_> that looks strange
[18:10:45] <boonkerz_> in latency test syslog produce more messages
[18:10:55] <boonkerz_> clocksource and so on
[18:12:17] <boonkerz_> can i output message from linuxcnc
[18:12:19] <boonkerz_> step by step
[18:12:34] <boonkerz_> so i can i see which piece produces this?
[18:13:23] <seb_kuzminsky> the DEBUG variable in your .ini turns up the logging inside linuxcnc. the messages show up in $HOME/linuxcnc_debug.txt and linuxcnc_print.txt
[18:13:51] <seb_kuzminsky> there's no easy way to correlate linuxcnc messages with rtai messages in dmesg
[18:14:38] <seb_kuzminsky> yeah, this is starting to seem like something funny's going on with the version of rtai you're using
[18:14:53] <boonkerz_> yea :)
[18:15:04] <seb_kuzminsky> memleak, do you know of any reason rtai 4.0 won't run linuxcnc right?
[18:17:15] <seb_kuzminsky> can you try it with the 3.4.55-rtai-2 image from www.linuxcnc.org/dists/precise?
[18:17:46] <seb_kuzminsky> i'm out of here, i'll read back later tonight
[18:17:47] <seb_kuzminsky> good luck!
[18:18:01] <boonkerz_> yea thanks
[18:18:05] <boonkerz_> i have 14.04
[18:18:06] <boonkerz_> :)
[18:18:25] <boonkerz_> but i can use older kernel i think
[18:18:28] <boonkerz_> we will see
[18:50:00] <memleak> seb_kuzminsky, i dont use the upstream 4.0 branch so no idea.
[18:50:46] <memleak> all i know is that vulcano and magma both have their own issues but i havent spent enough time on 4.0 / vulcano enough to figure out why.
[18:50:55] <memleak> magma is broken because of math rewrite.
[19:05:15] <boonkerz_> sim_spindle: Unknown symbol ceil (err 0)
[19:05:15] <boonkerz_> oO
[19:05:15] <boonkerz_> ok will recompile rtai with math functions
[19:05:15] <boonkerz_> forward looking :D
[20:31:56] <skunkworks> seb_kuzminsky: 'Thanks for the head's up. I think it's ready for merging, especially after the latest fixes. The only unknown right now is if we want INI settings vs. HAL pins. There was a patch for that a while back, but I haven't done anything with it recently.'
[20:32:03] <skunkworks> ^ rob
[20:35:07] <memleak> if 3.10 support hits vulcano branch if it hasnt already, that will break linuxcnc too.
[20:36:03] <memleak> kernel 3.10 support that is
[20:36:53] <memleak> if kernel 3.12 or 3.14 demands changes to RTAI, then linuxcnc rtapi code will need to be adjusted yet again to comply with the new code.
[20:37:24] <memleak> luckily for linuxcnc, RTAI support hasnt gotten that far yet.
[20:38:14] <memleak> so far it's only proc that needs to be changed. it will also be easier what in linuxcnc needs to be changed once the rtai linuxcnc branch goes live.
[20:38:59] <memleak> i think it will make development a lot easier for the rtapi devs once i get everything sorted out.
[20:42:43] <memleak> a very easy to track git repo with minimal changes throughout
