Back
[06:26:04] <jthornton> seb_kuzminsky: should I add peters instructions modified for 4.1.20-rt23 to the building LinuxCNC? BTW nice addition to the docs
[06:27:13] <jthornton> http://paste.ubuntu.com/17690231/
[07:37:35] <ikcalB> jepler: tnx very much for your effort - the patch for using `InterpBase* makeInterp()` from out-of-tree works. (my segfault resulted from not initializing the gtk-gl library. pls don't ask, how that code was able to run 3y ago...)
[07:39:33] <ikcalB> as InterpBase does not have attributes, do I really need an instance to work with? atm I'm trying with an uninitialized pointer like `InterpBase *pInterp;` I've just managed to view the preview window itself (far from rendering anything useful)
[07:40:17] <ikcalB> still I don't get segfaults, so idk whether that is going to work without that patch. investigating... just fyi
[07:43:21] <jepler> yes, you will need a real instance of an interpreter to actually perform a preview.
[07:50:32] <jepler> a base class with no data members and all or almost all methods "virtual ... = 0;" is basically the C++ equivalent of an Interface in more modern languages (java/c#)
[07:51:25] <jepler> if you declare 'InterpBase *pinterp;' and then use pinterp->anything() you are dereferencing a NULL or undefined pointer, which will usually net you a crash (not a null pointer exception like in java/c#)
[07:52:45] <ikcalB> got it - new to c++ (as you can easily guess).
[08:01:13] <lair82> Good Morning guys, Is it pretty safe to say that the project has moved away from ubuntu?
[08:01:43] <lair82> I'm cleaning up my notes, and was going to get rid of all ubuntu related stuff.
[08:21:25] <jepler> lair82: I doubt we will ever provide another ubuntu-based install image from linuxcnc.org.
[08:22:45] <jepler> .. it's just not safe to try to base your own system on Ubuntu, because they have become litigous. The latest is that they are demanding a per-installation, per-month fee from a particular cloud hosting provider who offers an "ubuntu" option..
[08:24:59] <lair82> Ok, no problem, I have been building wheezy machines, and am flirting with Mint now, just want to get rid of all the clutter in my notes
[08:25:35] <jepler> from the standpoint of building and installing linuxcnc, every debian derivative is very similar
[08:27:28] <lair82> Is it worth updating my ubuntu machines to debian or mint, or just leave well enough alone?
[08:28:24] <lair82> I have three turning centers that are all at about 2.6.3-2.6.4 and I would like to update them, and they are all three running Ubuntu 10.04
[08:28:37] <jepler> never change a working machine
[08:28:40] <jepler> needlessly
[08:29:09] <jepler> but on the other hand, 2.7.x is the last linuxcnc version that builds on ubuntu 10.04, master branch does not
[08:29:56] <lair82> I don't want too, just curious to see if there is any advantage. 2.7.x is fine, that is where our mills are at, and we see no issues with that.
[08:30:40] <jepler> sure, and we'll probably maintain 2.7.x and fix minor bugs for a year after "2.7+1" becomes a stable release
[08:32:04] <lair82> Ok, I will just update Linuxcnc then, not the OS on those machines, you don't know of anything major that will break my builds going from 2.6.3 to 2.7.4?
[08:32:20] <jepler> we believe that the major differences are in the documentation
[08:32:38] <jepler> http://linuxcnc.org/docs/2.7/html/getting-started/updating-linuxcnc.html#_updating_configuration_files
[08:33:35] <lair82> Ok, I will give it a whirl on the one machine that doesn't run daily, that way if I run into problems I can get them hashed out, and not hold up production.
[08:34:06] <lair82> Thanks jepler
[08:35:41] <pcw_home> Small SSDs are cheap. I would make a new install on a new drive and leave the original drive untouched
[08:35:42] <pcw_home> so you have a fallback until the new system is full operational
[08:36:38] <lair82> sounds good pcw_home
[08:38:17] <lair82> Was going to ask you pcw_home, can I build uspace on mint, using jthorntons build notes, modifying it to use uspace
[08:38:54] <lair82> Just to try to run my 7i80 on a mint control
[08:40:05] <pcw_home> I have used Mint and ubuntu 14.04 without issue
[08:40:27] <lair82> running RT Preempt?
[08:40:32] <pcw_home> yes
[08:41:17] <lair82> Ok, I don't need to update the kernel like I have had to do on my debian right?
[08:41:52] <pcw_home> Ive run preempt RT/LinuxCNC on ubunto 10.04, 12.04,14.04, debian wheezy and Mint (17.2?)
[08:42:12] <jepler> installing rt-preempt is updating the kernel so I'm not sure what you mean
[08:42:16] <pcw_home> you have to install the kernel on all
[08:43:14] <lair82> Ok, cool, I'll give it a try building one, and see how it goes
[08:44:02] <pcw_home> maybe JT will provide SSDs with Mint/LinuxCNC/Preempt-RT preinstalled
[08:44:35] <lair82> jepler, I was referring to this,
http://freeby.mesanet.com/makert4.1.13, thats not the current version, but that is what I am referring to
[08:45:05] <lair82> Fixes latency problems on the MB I am using
[08:45:51] <lair82> That would be sweet!!!!
[08:47:22] <pcw_home> someone who can actually write bash scripts could make a much better Preempt-rt install script
[08:48:59] <jepler> nonononononononon
[08:49:05] <lair82> Hey, it works for me, so it can't be that bad ;)
[08:49:30] <lair82> what?
[08:49:45] <jepler> if you're going to distribute something to users, particularly if you are going to sell media, I believe you really should start with Debian packages hosted on a public website
[08:50:04] <jepler> I would feel really gross if users became mislead and thought they had to pay for their copy of linuxcnc
[08:50:30] <jepler> and shell scripts to install kernels are great for individual users, but they are bad as a system of distributing software
[08:52:13] <lair82> I didn't pay for anything, this was just something to help fix problems with a MB I bought ( not from Mesa ) that was having some serious problems working with mesa boards
[08:52:48] <lair82> pcw freely gave this to me
[08:52:49] <jepler> this is about the prospect of "why not sell SSDs [that contain software not available for download as a debian package]"
[08:53:10] <lair82> Oooohhhhhh, gotcha,
[08:54:49] <jepler> (and I'm not saying that this necessarily violates any software license, but rather saying that it feels gross to me and indicates that there is a gap right now where the kernels the community needs are not debian packaged .. but the scalable solution is to debian package the stuff that is needed .. except we are all overworked in our hobby as it is)
[08:55:34] <lair82> I don't believe JT is out to mislead anyone, or try to make a profit off of it, guys like me could benefit from something like that, I spent all day yesterday trying to build a new SSD for one of the mills I did, that has this MB/OS combo, and is having problems.
[08:57:01] <lair82> And doing the math, 8 hrs of my time, times $60hr for the labor rate charged for me to work on something, is $480 lost, when I could have been out doing something else.
[08:59:18] <lair82> So even if I had to pay $150 ( figuratively speaking, not sure what it would cost) for a SSD already loaded up, that just needed my config dropped on it, and installed into a machine, is completely worth every penny.
[08:59:27] <jepler> I see your point of view.
[08:59:49] <cradek> nobody is the bad guy here, especially JT and PCW. but a system that's installed by scripts and not by packages backed up by a public package repository is a bad solution because it doesn't let the user update it in the normal way. this makes all our lives worse - the users and the folks who support them. it's also important that the user be able to get corresponding source to all the things on their system in the normal way ...
[08:59:55] <cradek> ... (apt-get source).
[09:01:33] <ikcalB> cradek: the good *old*-fashioned way. (pun intended: old != recent / upstream / up-to-date). wait for things to come, reagardings snaps... UGH!
[09:01:37] <cradek> to me this isn't about a hypothetical JT product, it's more important to keep script-installs from becoming widespread, because they are bad for users and maintainers
[09:02:18] <lair82> That is the biggest hurdle that we have seen so far in all the work I do with these, and all the other local shops we deal with that we have showed them our machines, as soon as they see what I have to do to get the software loaded, bugs worked out of problematic MB/SSD/HDD/OS combos, get a config loaded and running, they RUN FOR THE HILLS!!!
[09:03:29] <jepler> afk for some much-needed breakfast
[09:03:34] <lair82> As soon as we say it's free software, their ears perk up, and they start listening, but by the end of the conversation, if I have my back to them, they are usually out the door and leaving the parking lot.
[09:06:23] <lair82> Any way you shake it, using Linuxcnc with what ever break out boards and IO boards, is by far, leagues cheaper than going with any of the big brand names when it comes to converting a big machine over to a new PC based control,
[09:08:20] <lair82> But most shops, at least all the shops around here, just don't have the manpower to have someone learn the programming of the basic OS, figure out what components to purchase, then figure out how to get linuxcnc working properly, and then finally program the machine.
[09:08:37] <archivist> you can do it for them
[09:09:40] <lair82> Ours situation is a little different, my boss was determined to get one running, now we have 5, because we cut our teeth on the first one, and have learned, quickly, along the way.
[09:10:27] <pcw_home> The problem is with Preempt-RT is that there are no recent kernels from debian/ubuntu so if you have
[09:10:29] <pcw_home> anywhere near current hardware, you will get a non working system with the available package kernel
[09:10:53] <lair82> we did, I have a 50x30x30" VMC 15 mins down the road at another shop,
[09:12:22] <lair82> And I still stumble when trying to get things off the ground putting a control together.
[09:17:06] <lair82> Just looked, and boy oh boy, I was way the hell off, JT has got it going on!!!! 80GB 3.5" HD with LinuxCNC/Uspace/RT-preempt using Mint 17.3, $45.00, in stock. I seriously screwed up yesterday.
[09:17:40] <mozmck> nice!
[09:17:50] <lair82> I can't buy that HD for that, bare bones no OS
[09:18:27] <lair82> That would have saved me probably around $400
[09:46:49] <seb_kuzminsky> jthornton: i dont think kernel building info belongs in the new document i made, i want that one to be focused on linuxcnc
[09:47:32] <seb_kuzminsky> kernel building docs are useful, and from this morning's discussion i see that we should host them someplace better than pastebin
[09:48:11] <seb_kuzminsky> maybe the wiki for now? i'm not sure
[09:48:58] <seb_kuzminsky> in the long run i think we should publish kernel debs for preempt-rt like we occasionally do for rtai
[09:49:02] <cradek> if we want ethernet cards to become mainstream we eventually need a preempt kernel we can trust. if they don't stay around we'll want to package one ourselves or snag one that goes by in jessie-backports or whatever
[09:49:10] <cradek> yeah, what seb said
[09:49:41] <seb_kuzminsky> there are some preempt-rt kernels in snapshots.debian.org, right? do any of those work?
[09:50:17] <jepler> seb_kuzminsky: I get OK (100us) latencies with the 4.4-rt kernel that was in jessie-backports
[09:50:24] <jepler> but pcw says they lock up for him and he prefers 4.1
[09:50:37] <jepler> so one portion of the problem is, we don't know what kernel choices work on a wide range of hardware..
[09:52:41] <seb_kuzminsky> http://snapshot.debian.org/binary/?cat=l
[09:52:58] <seb_kuzminsky> there are several -rt kernels to choose from
[09:53:23] <seb_kuzminsky> including a 4.6 one
[09:54:08] <jepler> I haven't tried that one
[09:54:49] <jepler> anyway, one strategy is: get a source package from snapshot.debian.org or debian stretch (testing), build it for jessie, and then put it in the package archives on wlo
[09:54:54] <jepler> somebody just has to do it
[09:55:15] <seb_kuzminsky> i dont know for sure, but i bet we can just copy one of the sdo dscs and build it and put.. yes what jepler said
[09:55:22] <jepler> and you have to pick which kernel version that had an -rt patch that you think will have good hardare compatibiliy
[09:55:38] <lair82> Is that the next flavor, Jessie?
[09:55:47] <seb_kuzminsky> lair82: yeah, jessie is wheezy+1
[09:55:49] <jepler> lair82: "jessie" is the codename of the current debian stable
[09:55:59] <lair82> Aaah, ok.
[09:56:12] <jepler> also known as Debian 8
[09:56:21] <lair82> I didn't honestly mean to start a shit storm,
[09:56:33] <seb_kuzminsky> this is a goodness storm
[09:56:55] <seb_kuzminsky> the lack of a linux-image-rt at linuxcnc.org has been bugging me for a long time
[09:57:03] <seb_kuzminsky> how about this:
[09:57:46] <seb_kuzminsky> let's pick a -rt image from snapshot.d.o, everyone who has time/interest tests it out on some hardware they care about, and if it's good i'll rebuild it for jessie and put it in our deb archive
[09:57:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #57: Hi,... 02
https://github.com/LinuxCNC/linuxcnc/issues/57#issuecomment-227762500
[09:59:00] <seb_kuzminsky> maybe
http://snapshot.debian.org/binary/linux-image-4.1.0-2-rt-amd64/ or
http://snapshot.debian.org/binary/linux-image-4.6.0-1-rt-amd64/
[09:59:02] <mozmck> That means installing jessie right? How many people are running jessie?
[09:59:03] <archivist> how about fixing that bots nick to be shorter "-linuxcnc-github/#linuxcnc-devel-"
[09:59:05] <pcw_home> If you had one 4.1 and one 4.6 I think thats enough (its been enough to run on the 6-7 system Ive tried with)
[09:59:32] <seb_kuzminsky> pcw_home: great
[09:59:57] <seb_kuzminsky> a nice thing with preempt-rt is that linuxcnc binaries are kernel-version-agnostic, unlike with rtai
[10:00:51] <jepler> seb_kuzminsky: I will test on a i5-3320M and a i7-4790k
[10:00:56] <jepler> I am pretty sure 4.1 ran fine on the i5
[10:00:58] <seb_kuzminsky> so you're right, if we need multiple kernels to cover all the hardware we care about, that's fine, because we'd still just publish one uspace deb that works on all of them
[10:01:06] <seb_kuzminsky> jepler: thanks
[10:01:29] <jepler> both tests are going to be amd64, I don't have any 32-bit userspaces around
[10:01:41] <seb_kuzminsky> i've got an old-ish machine i used for rtai kernel testing way back when, i'll test on that tonight after work
[10:01:45] <seb_kuzminsky> amd64 here too
[10:02:10] <jepler> seb_kuzminsky: so basically pull down those packages from snapshot, install, and do a latency-test and kick the tires?
[10:02:12] <seb_kuzminsky> i might have a wheezy 32-bit userspace around, could test it on that too
[10:02:26] <seb_kuzminsky> jepler: yeah i think so
[10:02:36] <seb_kuzminsky> see if all your hardware works
[10:02:43] <seb_kuzminsky> load the system down and see if it crashes
[10:02:46] * seb_kuzminsky shrugs
[10:02:57] <jepler> I'll include info about 4.4 as well, even though based on pcw's experience it seems we can exclude that one from the shortlist
[10:03:40] <seb_kuzminsky> bbl, time for Bike To Work Day
[10:03:53] <jepler> sounds nice, unless it's 115° there or something
[10:04:46] <jepler> bad news, I'm unlikely to make it to the event at Stuart's. I've just learned that relatives will be visiting from Germany that week so it would be super rude to leave town.
[10:05:08] <cradek> booo
[10:05:11] <seb_kuzminsky> argh, bummer
[10:05:27] <jepler> (aside from work obligations that might also stop me taking vacation at that time)
[10:15:54] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: Hi Jeff,... 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-227768141
[12:33:33] <JT-Shop> I only have 32 bit computers so I can test that
[14:42:55] <KGB-linuxcnc> 03andypugh 052.7 72cb686 06linuxcnc 10src/hal/components/carousel.comp carousel.comp: Fix a bad initialisation in index mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=72cb686
[14:45:54] <skunkworks> Yay!
[14:49:26] <skunkworks> zlog,
[15:19:35] <linuxcnc-build> build #886 of 1500.rip-jessie-i386 is complete: Failure [4failed runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/886 blamelist: andypugh <andy@bodgesoc.org>
[15:20:17] <andypugh> I am fairly sure that my one-line change didn’t break that build
[15:21:07] <seb_kuzminsky> yeah...
[15:24:20] <linuxcnc-build> build #4271 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4271 blamelist: andypugh <andy@bodgesoc.org>
[15:46:08] <mozmck> jepler: stuart says the date is still flexible
[16:23:32] <skunkworks> andypugh, I was playing with the carousel comp just now
[16:23:34] <skunkworks> in master
[16:24:30] <skunkworks> I am not understanding the behavior of the jog yet and cannot seem get a good startup procedure.
[16:24:50] <skunkworks> it is 99% there I think - it just acts odd initally
[16:25:48] <skunkworks> if I bring up the machine and jog the carousel - it rotates in the homing direction forever. if I hit the jog button again - it will stop after it find home.
[16:26:06] <skunkworks> then seem to work normally after that.
[16:26:19] <skunkworks> If I do a tool change first - it also works normally after that
[16:27:17] <skunkworks> if it would just stop after finding home - that would work - or better yet - goes back to +1 or -1 Pocket depending on which jog direction you hit
[16:27:33] <skunkworks> if that makes sense
[16:30:33] <skunkworks> http://electronicsam.com/images/matsuura/20160622_153614.jpg
[16:30:57] <skunkworks> still needs some jog buttons, estop, selector switches...
[16:33:05] <skunkworks> hmm - crappy picture
[16:33:23] <skunkworks> http://electronicsam.com/images/matsuura/20160622_153043.jpg
[16:33:34] <skunkworks> little less crappy - barely..
[16:34:43] <cradek> hmm, did you do something unusual to get those dlsym/dlclose build errors?
[16:35:12] <skunkworks> I don't think I specified uspace... (or atleast that is what I did to fix it) during configure
[16:35:19] <cradek> oh ok
[16:36:09] <skunkworks> I did a git pull/ make and it re-reran configure automatically
[16:36:31] <skunkworks> I assume it didn't do --with-realtime=uspace
[16:38:39] <seb_kuzminsky> maybe we should make --with-realtime=uspace the default, if no option is given to configure
[16:47:40] <seb_kuzminsky> currently, running configure with no --with-realtime detects the rtai realtime setup if one exists, and fails if not
[16:48:56] <andypugh> skunkworks: The idea is that it homes then goes to the selected pocket the first time you pick a tool.
[16:52:00] <andypugh> It spends infinity looking for pocket 0 if you enable it with set to zero.
[16:58:13] <skunkworks_> andypugh: I am pretty sure I tried it spe
[16:58:42] <skunkworks_> Setting the tool number first.
[16:58:50] <KGB-linuxcnc> 03andypugh 05master 04b9abd 06linuxcnc 10src/hal/components/carousel.comp carousel.comp: Make homing a bit more intuitive * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=04b9abd
[16:59:47] <andypugh> Hmm, thinking about it, that belonged in 2.7 too, I think.
[16:59:48] <skunkworks_> Oh! I will try it
[17:00:46] <andypugh> skunkworks_: You probably want to put both chnages in, rather than wait for 2.7 to merge up to master
[17:06:25] <skunkworks> I thought jog stuff wan't in 2.7 anyway..
[17:11:50] <skunkworks> andypugh, ok - so close. It stops when it finds the index when you hit the one direction - but if you hit the oposite jog - it then also goes around and finds the index...
[17:12:38] <andypugh> Oh.
[17:13:11] <andypugh> Index is a silly thing. Can’t you fit a graycode thing?
[17:14:15] <skunkworks> heh
[17:15:01] <skunkworks> also - now it homes the opposite direction when you hit the other direction. (it used to home the same direction no matter what jog key you hit) I think
[17:16:56] <andypugh> skunkworks: Can you read through
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/carousel.comp and try to see where it is going wrong?
[17:18:52] <skunkworks> I certainly can try.
[17:18:57] <andypugh> If you hit jog and it isn’t homed then it shoud go to state 10 and move forwards, then state 11. You won’t see state 10 but you can see other states in the HAL parameter
[19:37:03] <KGB-linuxcnc> 03andypugh 05joints_axes15 5fd614e 06linuxcnc 10scripts/update_ini update.ini: Make sure that [TRAJ]MAX_LINEAR_VELOCITY exists * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5fd614e
[21:46:48] <skunkworks> heh - john stevenson can be an equal opportunity meanie..
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/150916
[22:15:07] <jepler> seb_kuzminsky: I have also considered whether --with-realtime=uspace, rather than a configure error, should be the default if no rtai kernel is detected
[22:15:40] <jepler> possibly introducing and making --with-realtime=auto the default, making --with-realtime=rtai do the thing that is done now?
[22:16:53] <linuxcnc-build> build #596 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/596 blamelist: andypugh <andy@bodgesoc.org>
[22:16:59] <seb_kuzminsky> that sounds like an improvement
[22:17:12] <seb_kuzminsky> auto will try to find an rtai first, then fall back to uspace?
[22:17:17] <jepler> I'll try to bank some of my tuits for that if nobody gets to it
[22:17:20] <jepler> um sure I don't care which
[22:17:49] <jepler> though until 2.7 is a distant memory, people who build both will in practice have to remember to specify --with-realtime=uspace
[22:18:02] <jepler> unless we dare to back-port it, saying that configure changes are at least going to be well-tested
[22:18:03] <seb_kuzminsky> i finally made an rtai 5.0~test2 kernel for all the good boys and girls
[22:18:05] <jepler> 'night
[22:18:15] <jepler> are you going to try it on buildbot again?
[22:18:25] <seb_kuzminsky> deb
http://highlab.com/~seb/linuxcnc/ jessie main
[22:18:32] <seb_kuzminsky> it's 3.18.20 this time
[22:18:50] <seb_kuzminsky> i'm going to run runtests in a loop for a week or so before trying it on the buildbot
[22:19:06] <jepler> in a vm?
[22:19:13] <jepler> or on bare metal?
[22:19:23] <seb_kuzminsky> in a vm
[22:19:44] <seb_kuzminsky> 3.16+rtai5~test1 always worked fine on bare metal, as far as i know
[22:19:57] <seb_kuzminsky> it was just in the sometimes laggy vms that it was flaky
[22:24:32] <jepler> I wish that a common VM had a flag which meant: I don't care if this VM keeps real-world time, I want it to get 1 CPU clock per virtualized TSC, etc
[22:25:55] <skunksleep> seb_kuzminsky: is that 64 or 32?
[22:30:00] <jepler> skunksleep: a little grovelling in directory listings suggests "both"
[22:32:59] <seb_kuzminsky> 32 so far, there was a bug in the 64 & i'm rebuilding it now
[22:34:46] <skunksleep> Au. Awesome
[22:35:35] <seb_kuzminsky> i've got a bad feeling about this one, because the version of the 3.18 kernel that rtai supplies a patch for moved backwards, it was 3.18.22 in test1 and 3.18.20 in test2
[22:35:41] <seb_kuzminsky> not confidence inspiring
[22:37:35] <linuxcnc-build> build #595 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/595 blamelist: andypugh <andy@bodgesoc.org>
[23:44:12] <seb_kuzminsky> the first runtest pass on the 3.18 rtai5~test2 kernel worked:
http://paste.debian.net/746471/
[23:46:45] <KGB-linuxcnc> 03Dewey Garrett 052.7 fd7d07c 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: use previously defined open_directory * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd7d07c
[23:47:28] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes15 a3080d6 06linuxcnc 10(7 files in 7 dirs) guis conform to convention for TRAJ vel,accels JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3080d6
