Back
[00:42:13] <seb_kuzminsky> aluminum: this channel is for linuxcnc development, you should ask your question somewhere the machinekit people hang out
[00:57:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 bb4b181 06linuxcnc 10tests/halui/mdi/test-ui.py halui test: give halui a few seconds to switch the task mode back * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bb4b181
[07:04:32] <jepler> I filed a "bug" on machinekit's git against their website, which suggests #linuxcnc-devel as a place to go for advice about machinekit.
[07:08:21] <archivist> hehe
[07:40:41] <skunkworks> jepler, so - have you peeked at what is going on over there? Huh?
[07:48:19] <Tom_itx> is that purely for arm?
[08:02:30] <jepler> skunkworks: not really, no
[08:02:54] <micges-dev> Tom_itx: no
[08:03:42] <micges-dev> Tom_itx: they support xenomai which is multi platform
[08:24:49] <skunkworks> micges-dev, how goes jerk planner?
[08:25:20] <micges-dev> finished :)
[08:26:43] <micges-dev> skunkworks: it is tested on gantry plasma cutter
[08:28:12] <micges-dev> and ja4 branch is tested on gantry waterjet, as job was to merge jerk planner to ja4
[08:28:39] <skunkworks> Really? I will pull and do some testing
[08:29:45] <micges-dev> I'll rearange git soon to reflect fixes on place, now I got quick urgent project
[08:29:57] <skunkworks> sounds good
[08:29:58] <cradek> is jerk limiting based on the cradek tp or the rob tp?
[08:30:08] <micges-dev> cradek tp
[08:30:24] <cradek> that's going to make it even slower
[08:30:47] <skunkworks> probably high accelleration machines...
[08:30:54] <micges-dev> cradek: nooo
[08:31:00] <micges-dev> about 2x faster
[08:31:12] <cradek> I don't see how that could be
[08:31:17] <cradek> it adds a new constraint
[08:31:24] <cradek> it must have other improvements too then
[08:31:43] <micges-dev> test machine is 65m/min 5000mm/s2 and 75000mm/s3
[08:32:12] <micges-dev> before that it was 60m/min 2000mm/s2
[08:33:00] <micges-dev> yes new constraint but you can raise rest of them up
[08:33:27] <skunkworks> micges-dev, you have blending working?
[08:33:34] <micges-dev> and machine won't dissasemble itself :)
[08:33:37] <micges-dev> skunkworks: yes
[08:35:29] <cradek> oh ok, you mean you can set the accel higher so the tp limitations are less onerous
[08:35:33] <cradek> that makes sense
[08:35:43] <micges-dev> exactly
[08:49:47] <seb_kuzminsky> jepler: thanks
[09:25:14] <jepler> micges-dev: I'm not sure whether jerk-limited TP should be merged into JAx. Conceptually they are independent, and we might want to ultimately merge one but not the other into master
[09:25:50] <cradek> it can't go into master without being rewritten
[09:25:59] <cradek> and newer jaX are based on master
[09:25:59] <seb_kuzminsky> yeah that's a bummer
[09:27:13] <micges-dev> yeah I know rules on glo, it's my client need to run jerk + ja4
[09:27:37] <micges-dev> I'll push jerk branch only to glo
[09:27:49] <cradek> that would be great
[09:43:29] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 e48b093 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e48b093
[09:44:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 75ec84c 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=75ec84c
[10:02:14] <KGB-linuxcnc> 03Michael Geszkiewicz 052.7 6b09f7f 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: cleanup unused code and leftover from rtnet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b09f7f
[10:02:15] <KGB-linuxcnc> 03Michael Geszkiewicz 052.7 2793426 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c hm2_eth: use defines for all timeouts in driver * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2793426
[10:41:03] <seb_kuzminsky> skunkworks, PCW: did you guys test brian morel's rtai kernel with the baytrail usb fixes?
[10:56:07] <pcw_home> No, let me see if i can find the link and i will test it today
[10:56:29] <seb_kuzminsky> i'm building it right now, i'll have a deb for you to test soonish
[10:59:01] <cradek> yay!
[11:01:37] <pcw_home> if not for that usb issue the J1800,1900,2950 MBs are excellent linuxcnc hosts
[11:03:50] <seb_kuzminsky> :-)
[11:03:53] <seb_kuzminsky> yeah, sounds like it
[11:05:34] <seb_kuzminsky> hrm, a vm i'm using for testing is having strange network trouble
[11:05:53] <seb_kuzminsky> i can use dig to resolve ftp.us.debian.org, but apt says it can't resolve it
[11:06:10] <seb_kuzminsky> my house of cards has a screw loose
[11:10:30] <skunkworks> seb_kuzminsky, yes - it worked for me..
http://electronicsam.com/images/KandT/testing/Screenshot%20-%2010242014%20-%2004:10:32%20PM.png
[11:10:58] <skunkworks> that is on a J1900
[11:20:20] <seb_kuzminsky> skunkworks: great, thanks
[11:20:51] <seb_kuzminsky> the patch that brian morel applied to get usb to work doesn't change the abi, so upgrades should work smoothly for us
[11:26:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 07b9cfe 06linuxcnc 10src/emc/motion/control.c rebrand a realtime warning message from motion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=07b9cfe
[12:08:15] <seb_kuzminsky> here's the apt line for the new kernel:
[12:08:32] <seb_kuzminsky> deb
http://highlab.com/~seb/linuxcnc/rtai-debs wheezy main
[12:08:42] <seb_kuzminsky> the upgrade works smoothly for me
[12:08:56] <seb_kuzminsky> the rtai-modules and linuxcnc packages are unaffected, only linux-image is upgraded
[12:09:35] <seb_kuzminsky> a rip build compiled against the current (old) kernel, version 3linuxcnc, still passes all the tests when run under the new 4linuxcnc kernel
[12:09:44] <seb_kuzminsky> the 2.6.4 deb works before and after the kernel upgrade as well
[12:10:30] <seb_kuzminsky> skunkworks, pcw_home: i'll wait for your reports, then if it still looks good i'll put these new linux-image debs up on wlo
[12:21:40] <PCW> so what do i apt-get?
[12:22:26] <seb_kuzminsky> if you're on a machine that's already running the rtai kernel, run "apt-get upgrade"
[12:22:53] <seb_kuzminsky> if you're on a wheezy machine with some other kernel, "apt-get install linux-image-3.4-9-rtai-686-pae"
[12:35:47] <Tom_itx> PCW did you see the broken link message on your page?
[12:35:58] <Tom_itx> (other channel)
[12:36:38] <PCW> Hmm that didnt change the kernel
[12:38:37] <seb_kuzminsky> you need to reboot too
[12:39:21] <PCW> I mean it updated the preemt-rt kernel but not the RTAI one
[12:39:38] <seb_kuzminsky> hmm
[12:39:56] <seb_kuzminsky> what does 'dpkg -l linux-image-3.4-9-rtai-686-pae' say?
[12:40:08] <seb_kuzminsky> and 'apt-cache policy linux-image-3.4-9-rtai-686-pae'
[12:46:28] <PCW> I needed to apt-get update
[12:47:07] <seb_kuzminsky> ah, yes, i forgot to mention that part...
[12:48:54] <PCW> oops cannot resolve highlab.com
[12:49:54] <seb_kuzminsky> hmm, works for me
[12:50:04] <seb_kuzminsky> ;; ANSWER SECTION:
[12:50:04] <seb_kuzminsky> highlab.com. 0 IN A 71.218.158.216
[12:54:12] <cradek> yeah wfm too
[12:54:25] <archivist> 5 good dns servers
[12:57:20] <archivist> I recommend
http://www.squish.net/dnscheck/v1.html when you want to check all your dns servers are up and running
[13:10:50] <memfrob> IPIPE development started for 3.16
[13:14:17] <memfrob> http://git.xenomai.org/ipipe.git/log/?h=raw-ipipe-3.16
[13:17:51] <memfrob> for what it's worth once it's done ill add 3.16 support to RTAI, only takes about an hour or so once you get used to it.
[13:20:06] <micges-dev> memfrob: heh "takes about an hour or so once you get used to it"
[13:20:24] <micges-dev> memfrob: it's black magic box for me :)
[13:21:59] <micges-dev> seems that you are pretty comfortable with all ipipe stuff, maybe it will move rtai forward
[13:23:13] <CaptHindsight> it's already a fork of RTAI.org
[13:23:55] <CaptHindsight> that project is just about dead
[13:24:35] <jepler> ok now do preempt-rt on 3.16
[13:24:44] <CaptHindsight> it might have updates every few months using memfrobs tree
[13:27:33] <memfrob> IPIPE is a much smaller patchset than preempt_rt
[13:29:26] <seb_kuzminsky> memfrob: what do you think of jepler's idea of writing an rtapi implementation directly for i-pipe, without the need for rtai or rt-preempt?
[13:29:26] <memfrob> preempt_rt patches affect a lot different things within the kernel whereas IPIPE is mainly separate and an "additonal layer"
[13:29:54] <jepler> the thing that would really suck about that would be we'd need our own math library
[13:30:00] <jepler> ask memfrob how fun that's been to maintain :-/
[13:30:31] <memfrob> the RTAI math library in my forked tree is fine. i dont see the problem with just using that.
[13:30:55] <jepler> it's true that it's much better now than it was this spring
[13:31:03] <jepler> there are still some layers which seem ill-conceived
[13:31:09] <memfrob> seb_kuzminsky: i think it's great as long as the rtapi implementation doesnt need a full re-write for every new IPIPE release
[13:31:25] <seb_kuzminsky> depends how much ipipe changes i suppose
[13:32:07] <memfrob> mainly new functions and calls for use with xenomai, most of the changes dont impact RTAI or nor the scheduler
[13:33:24] <jepler> for example, consider sqrt(). w_sqrt.c defines sqrt. It has a K&R style prototype (optionally). This K&R prototype should be deleted
[13:33:35] <jepler> w_sqrt has two implementations, _IEEE_LIBM and another one
[13:33:35] <memfrob> i have to get going ill be back later, the new RTAI tree is great and will not need any changes for quite some time. i say a direct rtapi implementation is a lot of work for the end result
[13:33:40] <jepler> we should get rid of one or the other
[13:33:57] <memfrob> especially now since i made a linuxcnc-specific RTAI tree
[13:34:03] <jepler> the !_IEEE_LIBM case is weird, it sometimes operates via a function __kernel_standard, which is passed the numeric paramter 26 to indicate sqrt
[13:34:13] <jepler> that's just gross
[13:34:30] <memfrob> now if RTAI was broken and i didnt fork it and fix all the bugs, then a direct rtapi ipipe implementation would be almost entirely necessary
[13:34:49] <jepler> so in summary, I mostly ignore the rtai libm grossness when it's sequestered inside rtai
[13:34:54] <jepler> but I don't want that in linuxcnc
[13:35:02] <memfrob> i did that RTAI work for a reason. ;)
[13:36:34] <memfrob> jepler the rtai math library is in such great standing mainly thanks to you
[13:36:49] <memfrob> i just did some minor clean-up to make it a little easier to read
[13:37:14] <memfrob> you did the heavy lifting, i remember you fixed the userspace header in kernel-space problem too, great job!
[13:37:23] <jepler> ah ok, I thought this tree I was looking at was up to date
[13:37:32] <jepler> but several of the problems I mentioned are fixed in your git
[13:37:40] <jepler> is __kernel_standard gone now?
[13:37:45] <memfrob> github.com/ntulinux/rtai
[13:38:00] <memfrob> i believe so, its whatever you did
[13:38:02] <jepler> I know where your git is, I was just looking at something that wasn't your git :-P
[13:38:07] <memfrob> ah!
[13:38:58] <memfrob> ok well i gotta get going, feel free to discuss and ill read the scrollback later
[13:39:24] <jepler> k_standard.c is still in your git. should figure out if it's still used / still should be used
[13:39:54] <jepler> looks unused, I'll prepare a pull request
[13:40:36] <jepler> but I don't think I have a system where I can compile-test it, so take care before merging
[13:42:20] <jepler> extern double __kernel_sin(double,double,int);
[13:42:20] <jepler> extern double __kernel_cos(double,double);
[13:42:28] * jepler wonders how it happens that sin takes three arguments while cos takes two
[13:46:30] <jepler> (whatever else I have to say about the rtai libm's structure, they did take what appear to be technically competent low-level implementations of the various functions)
[13:54:09] <jepler> so anyway, __kernel_{sin,cos} take a pair of arguments that are the "double-double precision" value of the original sin() argument after its reduction modulo pi/2. __kernel_rem_pio2 also returns an argument saying what octant the answer is in, so after reduction either __kernel_sin or __kernel_cos is used. This explains why each one takes a pair of double arguments.
[13:55:30] <jepler> Additionally, sin has a special case for when the second value is known a priori to be zero; this can only happen in the implementation of sin() where no range reduction is required.
[14:32:15] <PCW> OK gigabyte J1800N-D2H works fine with patched RTAI kernel about 7/10 usec on latency test after a few minutes of youtube torture
[14:33:40] <Connor> What Mini-ITX board are we recommended now vs the Atom 525D ?
[14:43:26] <PCW> well the gigabyte J1800N-D2H is looking better!
[14:44:45] <PCW> I should probably try the ASUS J1800I-A
[14:45:06] <PCW> since it has a PCI slot
[14:46:34] <CaptHindsight> what was in the kernel patch to fix the usb problem on the J1800's?
[14:49:04] <PCW> Gigabyte J1800N-D2H works with a 6KHz servo thread on a 6i25/7I77, pretty impressive
[14:50:19] <jepler> CaptHindsight:
https://github.com/brianmorel99/linux-rtai-debian/commit/711b4da8d0e0c12cae6187c209701ae6e29f58ff I think
[14:51:58] <PCW> thats about 3x as fast as a D525 will run
[14:53:21] <CaptHindsight> ah, driver fix
[14:59:38] <cradek> seb_kuzminsky: do you have fixed kernel packages up yet?
[15:11:25] <Connor> So, is that the board we're recommending now ?
[15:11:38] <Connor> It's still a Atom isn't it ?
[15:12:34] <PCW> well Intel has changed the name From Baytrail Atom to Celeron so not sure what it is
[15:13:04] <PCW> but its much faster than the Atoms at the same or lower power
[15:14:15] <jepler> because it needs to re-brand it with a marketing name that's not associated with poor performance. ;-)
[15:14:35] <Connor> yea.. They need to LOOSE the name Celeron.. that name at least in my mind.. means purposely crippled CPU.
[15:15:17] <Connor> jepler: Really. I think Celeron == Poor performance.. unless your being Sarcastic.
[15:15:57] <jepler> Connor: snarky, at least. it's funny, because both "atom" and "celeron" denote poor performance
[15:15:58] <PCW> actually the celeron G1850s and similar are quite fast
[15:16:05] <jepler> or maybe connote
[15:16:21] <PCW> (baby Haswells)
[15:16:59] <Connor> I remember back in the day when they destroyed the pin to the FPU on the SX's
[15:17:19] <Connor> Really were DX's
[15:20:18] <seb_kuzminsky> cradek: not yet, i'll do it tonight & let you know
[15:20:36] <seb_kuzminsky> well, they're up at highlab.com, but not at linuxcnc.org yet
[15:21:01] <Connor> Do we have a WIKI page or something that recommends Mobo's and such for people ?
[15:21:24] <seb_kuzminsky> Connor: yeah, it's on the wiki somewhere, not sure how up to date it is
[15:21:25] <Connor> We kinda stumbled onto the fact that the Atom D525 worked well with LinuxCNC
[15:31:45] <PCW> http://www.newegg.com/Product/Product.aspx?Item=N82E16813138412
[15:31:46] <PCW> is another low power motherboard that works well (but no PCI)
[15:54:11] <PCW> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128698&cm_re=j1900-_-13-128-698-_-Product
[15:54:12] <PCW> I think is what Skunkworks has (it has PCI and dual Ethernet)
[15:58:48] <CaptHindsight> is it worth dusting off Linuxcnc with Fedora? FC21 is supposedly going to include support for several ARM boards
[15:59:04] <CaptHindsight> http://www.phoronix.com/scan.php?page=news_item&px=MTc2MjI
[16:00:34] <jepler> CaptHindsight: I'll review patches for portability to other linux, but I don't plan to use fedora myself
[16:01:16] <CaptHindsight> jepler: yes, I recall your fondness of yum and fedora :)
[16:01:19] <jepler> and given fedora's fast release schedule I sure would not anticipate it being the preferred os distro to base linuxcnc on
[16:02:37] <jepler> now if you were gung ho to port to centos maybe we have a long term support platform worth talking about :-P
[16:03:09] <CaptHindsight> that would be nice
[16:03:59] <CaptHindsight> I recall packaging for Fedora wasn't that simple
[16:06:49] <jepler> I did a tiny bit of rpm packaging back in the days of redhat 5/6/9 and it was certainly different than debian packaging. at the time I sort of understood it
[16:06:55] <KGB-linuxcnc> 03Michael Geszkiewicz 052.7 15be5dc 06linuxcnc 10src/po/pl.po update Polish translation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=15be5dc
[16:07:00] <jepler> but that was 15 years ago, I suppose it's quite different now
[16:08:52] <jepler> (my personal linux history is sls -> mcc -> redhat -> ubuntu -> debian)
[16:10:06] <jepler> oh I guess I was on fedora up to about ... 4 ?
[16:18:19] <CaptHindsight> I guess it's only worth considering if hm2_eth ends up working well enough on ARM
[16:23:07] <skunkworks_> crap - I updated the linux install - it used the new kernel but the install is old enough that the wrong kernel booted.. Didn't get back to it.
[18:08:36] <memfrob> hi all im back!
[18:14:03] <memfrob> jepler did you compile test the k_standard patch?
[18:46:25] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 3ae06ac 06linuxcnc 10src/emc/motion/control.c Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ae06ac
[18:48:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 7dbefb4 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7dbefb4
[19:20:09] <jepler> memfrob: no, I didn't have a system handy to compile-test it
[19:20:22] <jepler> memfrob: and I realize now I didn't touch any Makefiles so the branch is probably broken
[22:20:22] <seb_kuzminsky> this transition period between "raw nml" and lui is pretty awkward
[22:20:54] <seb_kuzminsky> linuxcncrsh accepts "set wait", which causes it to wait for the most recent command to be received or done by task
[22:21:09] <seb_kuzminsky> now it has to check both the 'raw nml' command channel and the lui command channel
[22:24:31] <seb_kuzminsky> i dont think that can work
[22:24:43] <seb_kuzminsky> it'd have to keep track of which channel is the one with a pending command
[22:25:30] <seb_kuzminsky> linuxcncrsh's "set set_wait" works fine, because we can set the wait mode on both channels, and then each command implicitly waits appropriately, independent of which channel it's one
[22:25:42] <seb_kuzminsky> but i can't think of a way to make "set wait" work
[22:25:52] <seb_kuzminsky> until we're back down to one channel
[22:42:25] <seb_kuzminsky> is it bad that i'm working around this breakage (by changing all the tests to use 'set set_wait' instead of 'set wait') and not feeling too bad about it?
[22:42:36] <seb_kuzminsky> omelettes and eggs and all that
[22:42:48] * seb_kuzminsky shrugs and goes to the hackspace
