Back
[00:30:50] <seb_kuzminsky> it's a good day for linuxcnc releases
[01:07:05] <linuxcnc-build> build #170 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/170 blamelist: Robert W. Ellenberg <rwe24g@gmail.com>
[02:19:52] <memleak> ok latency-test works with reasonable jitter now (around 10000)
[02:20:08] <memleak> kernel 3.10 with my RTAI tree
[02:26:40] <memleak> 133 tests, 85 successful, 49 failed, 0 expected
[06:58:15] <memleak> if only there was a .gitignore everything except *.c *.h GNUmakefile.am tomorrow (later on today) ill be working on merging vulcano with the new RTAI tree to bring it up to speed
[07:00:03] <memleak> what do you guys think of an RTAI tree specifically for linuxcnc? im going to sleep now but i'd like to hear you guys's thoughts. a lot of the code others keep writing breaks linuxcnc but i can avoid all that in my new tree
[09:22:47] <cradek> knowing nothing else about this, my thoughts are that divergence from an active project should be avoided when possible, and we'd have to know more about the problem (breakage) to make an informed decision. if we can change linuxcnc to keep up with whatever is going on, and not diverge from the active rtai project, surely that would be better
[09:54:11] <seb_kuzminsky> +1
[10:48:45] <dgarr> skunkworks: Could you test a patch for tclStubsPtr: ( i have built xubuntu 14.04 i386, and halshow works with this):
[10:48:47] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-halsh-initialize-stubs-library.patch
[11:10:35] <seb_kuzminsky> dgarr: cool, thanks for looking into that
[11:10:51] <seb_kuzminsky> do you know if that patch also works with older versions of tcl, like on Lucid and Precise?
[11:12:27] <dgarr> i think it is compatible, the patch works for me on 12.10, i think it was just the missing stubs init call in halsh.c and minor Makefile addition -- maybe jepler could review?
[11:13:33] <seb_kuzminsky> what tcl does 12.10 have?
[11:14:00] <seb_kuzminsky> ah, it's 8.5, just like precise
[11:14:04] <dgarr> 8.5
[11:14:21] <seb_kuzminsky> well that sounds promising
[11:16:23] <dgarr> the changes make halsh.c, Submakefile look like usr_intf/emcsh.cc and its Submakefile which have been around a long time
[11:29:17] <seb_kuzminsky> ah yes, fe844a94118379b04449d5d0dd8957362c832c6a
[11:29:43] <seb_kuzminsky> that makes me wonder, should this change to at some deeper layer, so it's shared by more of our code?
[11:49:10] <dgarr> i've tested the above patch now on trusty14.04(sim), quanta 12.10(sim), and lucid10.04(rt) seems ok to me, skunkworks has a amd64 system i think
[11:50:50] <seb_kuzminsky> ok
[11:51:48] <seb_kuzminsky> if it works for skunkworks, this should go in 2.6... not sure if cradek wants it in 2.5
[12:42:10] <memleak> "if we can change linuxcnc to keep up with whatever is going on" for example the required proc changes. from the looks of it, RTAI is moving way too fast for linuxcnc to keep up all the sudden, more developers are working together, more bugs are being reported, more patches, and time dedicated to the project is rapidly increasing.
[12:44:02] <memleak> a few months ago another change was made to RTAI that was practically a re-write of the RTAI math support, which also broke linuxcnc and is still broken.
[12:46:37] <memleak> in most cases (so far everything except proc) i can re-write anything in RTAI and change it to comply with linuxcnc, but i cant do it the other way around.
[12:48:32] <memleak> most of the changes i made to the shabbyx tree (even master branch) were to make it work better with linuxcnc.
[12:49:28] <cradek> I would sure love it if you could become familiar enough with rtapi to know whether rtai or rtapi changes are most appropriate in these situations
[12:49:52] <cradek> I bet we should err on the side of changing rtapi, for the reasons I opined earlier
[12:50:15] <memleak> i know enough about RTAI to know that most of the changes i've been making should go to rtapi
[12:51:20] <cradek> how can we help you accomplish that?
[12:53:01] <memleak> i cant understand rtapi so it's not on you guys.
[12:53:43] <cradek> it must be the case that you could understand rtapi just fine, seeing as how you obviously understand rtai
[12:54:30] <cradek> I've seen jmk be pretty responsive on the devel list, although he's never in here. maybe he could be a resource for you to help figure out rtapi questions?
[12:56:16] <memleak> ok for an example, the compiler error with kernel 3.10 was saying create_proc_entry is undeclared. RTAI changed that function to all caps, i make the change, still undeclared.
[12:56:26] <memleak> my brain exploded and i gave up.
[12:57:03] <cradek> heh maybe that's a time to share your changes and your errors and ask for help. brains exploding is no good.
[12:58:45] <cradek> I'm surprised rtai does anything with proc... I figured that was kernel changes biting you.
[12:59:38] <memleak> kernel changes forced the change to RTAI userspace's proc code
[12:59:48] <memleak> kernel stuff is never the issue IIRC...
[13:04:23] <memleak> upstream kernel changes that is.
[13:04:34] <memleak> kernel.org reworked proc, which reworked RTAI
[13:07:51] <memleak> cradek,
http://pastebin.ca/2696861 did you see that?
[13:11:53] <asah> anyone have good docs / links for getting ubc-7i80 branch working under preempt ?
[13:12:36] <memleak> isnt ubc-7i80 merged with ubc-3?
[13:12:43] <asah> not sure..
[13:12:50] <memleak> it should be merged.. :/
[13:13:06] <asah> I have ubu 12.04 and running 3.12 kernel.
[13:13:27] <asah> need to build a preempt kernel I suppose?
[13:13:38] <asah> docs for the current methods of doing this?
[13:14:02] <memleak> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
[13:14:43] <memleak> for linuxcnc its just ./autogen.sh && ./configure && make && sudo make setuid && cd ../ && . ./scripts/rip-environment
[13:15:54] <asah> thanks.
[13:16:18] <micges> asah: hold on
[13:17:19] <memleak> is 7i80 the ethernet one? if so preempt_rt doesn't have an RT-net variant i dont think.
[13:18:08] <memleak> not sure if ethernet fgpas work with preempt_rt
[13:18:15] <memleak> *fpgas
[13:18:22] <micges> asah: build 3.12.16 rt-preempt kernel
[13:18:53] <micges> sorry 3.12.15
[13:19:52] <memleak> wget
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.15-rt25.patch.gz && gunzip *rt25.patch.gz then cd into your kernel source, run patch -p1 < /path/to/*rt25.patch configure and compile away!
[13:20:10] <asah> cool… thanks!
[13:20:34] * memleak has done this too many times
[13:21:38] <memleak> for kernel installation just run sudo make install && sudo make modules_install then update grub either via text editor or grub2-mkconfig -o /boot/grub{2}/grub.cfg
[13:22:06] <memleak> some distros simply have an upgrade-grub command.
[13:23:06] <micges> memleak: 7i80 works best under rt-preempt
[13:23:21] <memleak> oh ok good to know
[13:31:07] <cradek> memleak: looks like create_proc_entry is gone from the kernel, and you now use proc_create instead (include linux/proc_fs.h)
[13:31:31] <cradek> probably the rtai folks wrapped that difference so they could use a common (uppercase) spelling
[13:31:44] <cradek> rtapi probably needs a similar wrapper
[13:32:09] <cradek> it's not necessarily the case that we can use rtai's wrapper - that's meant probably just for the rtai code
[13:32:51] <cradek> if you look through rtapi, you'll see stuff like: #if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,17)
[13:33:07] <cradek> something like that is how your wrapper can know which version to invoke
[13:33:27] <cradek> you just have to figure out what kernel version is the cutoff
[13:35:31] <cradek> if you have the rtai history in front of you I bet you can find where someone added that wrapper
[13:35:35] <cradek> that would be a nice reference
[13:38:21] <cradek> http://stackoverflow.com/questions/8516021/proc-create-example-for-kernel-module
[13:53:00] <asah> are you guys disabling all the acpi and apm items
[13:53:27] <asah> for the preempt kernel config?
[13:53:47] <asah> says acpi is required for hi resolution timers?
[14:00:33] <asah> can anyone share a kernel config for 3.12.15-rt ?
[14:00:35] <memleak> acpi enabled, all sub options disabled
[14:01:05] <asah> I can’t find the hi res timer option referenced by :
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
[14:09:31] <memleak> processor type and features
[14:10:14] <memleak> around where it says SMP support
[14:10:18] <memleak> going off memory atm
[14:13:30] <pcw_home> freeby.mesanet.com/rt.config is an example (no idea if it OK for your system)
[14:15:47] <memleak> pcw_home, hello!
[14:16:13] <asah> anyone doing this on 64bit? should I stick to 32 (as pcw has in this config? )
[14:16:37] <memleak> ive used preempt_rt with 64 many times but i get unexpected real time delays every few hours or so
[14:16:43] <memleak> its really flaky for me
[14:17:00] <memleak> do not use it in a production environment where you want true stability
[14:17:19] <memleak> besides, ubc-3 branches are always experimental
[14:17:30] <asah> not in production…. prototyping
[14:17:39] <memleak> in that case perfect!
[14:17:43] <asah> =)
[14:18:13] <asah> looks like pcw is using 3.12.16… happy with that peteR?
[14:18:27] <pcw_home> Yeah so far
[14:20:19] <KGB-linuxcnc> 03Bence Kovacs 052.6 9ca07c1 06linuxcnc 10src/hal/drivers/hal_gm.c Fix: * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ca07c1
[14:20:19] <KGB-linuxcnc> 03Bence Kovacs 052.6 978dfb9 06linuxcnc 10src/hal/drivers/gm.h 10src/hal/drivers/hal_gm.c Feature: * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=978dfb9
[14:20:19] <KGB-linuxcnc> 03Bence Kovacs 052.6 5f18d23 06linuxcnc 10src/hal/drivers/hal_gm.c Version 1.1.2 release: * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f18d23
[14:20:42] <asah> sold!
[14:21:48] <asah> peter, where are you getting your rt patch?
[14:21:58] <asah> using the 3.12.15 one?
[14:40:15] <micges> asah: 3.12.15 will work
[14:49:20] <asah> compiling away...
[14:51:41] <PCW> Yeah pretty sure I patched 3.12.16 kernel with 3.12.15 rt-preemt patch
[14:53:33] <skunkworks> does git apply soemthig.patch work?
[14:54:49] <PCW> for the preemt-rt patch? no idea
[14:55:27] <skunkworks> no - for a patch in general
[14:55:36] <skunkworks> (well - for linuxcnc_
[14:55:41] <PCW> dont know
[14:57:43] <PCW> i just used
[14:57:44] <PCW> cat someoldpatch | patch -p1
[15:26:18] <skunkworks_> dgarr: that patch seems to have fixed the stub issue!
[15:26:28] <skunkworks_> (on 14.04) great work!
[15:30:18] <linuxcnc-build> build #171 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/171 blamelist: Bence Kovacs <bence.kovacs@generalmechatronics.com>
[15:32:07] <seb_kuzminsky> yay
[15:34:16] <PCW> skunkworks_ 7I76E 2KHz for 3 days now using preemt_rt 3.12.15. Ill let it run for a month or so
[15:35:15] <PCW> (running FS vids etc)
[15:36:29] <asah> so the ubc3-dev is the good branch to play with for 7i80 now?
[15:37:31] <PCW> need to ask micges...
[15:37:55] <asah> zultron/ubc3-dev is the one that shows up.
[15:37:56] <asah> actually
[15:38:44] <zultron> asah, that's an outdated branch.
[15:38:57] <micges> asah: use ubc3-7i80
[15:39:02] <asah> will do.
[15:39:18] <zultron> I'll remove it to reduce future confusion.
[15:43:40] <memleak> cradek, thanks!
[15:43:48] <memleak> for the info about proc^
[15:55:40] <cradek> memleak: welcome, hope it helps you nail it
[15:56:17] <KGB-linuxcnc> 05zultron/ubc3-dev 4bb89e0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4bb89e0
[16:09:31] <asah> so, got the kernel built and started to try out 7i80
[16:09:45] <asah> got an error when loadrt hm2_eth
[16:09:58] <asah> user_rtapi_app cought signal 11 - dumping core
[16:10:09] <asah> insmod failed returned -1
[16:12:35] <asah> nevermind.
[16:12:44] <asah> when you add board_mac it works fine. =)
[16:13:00] <PCW> something like
[16:13:02] <PCW> loadrt hm2_eth board_ip="10.10.10.10" board_mac="00:60:1B:10:40:01" debug=1
[16:13:17] <asah> sweet!!!!!
[16:13:37] <asah> so now how do I load my nice bitfile?
[16:13:38] <asah> =)
[16:14:03] <asah> ah, right, you need to gen me one right?
[16:14:17] <PCW> if its custom, yes
[16:15:21] <asah> same one we are using with the SSI and the 7i39.
[16:17:06] <asah> pretty please!
[16:17:24] <PCW> you have a 7i80hd-16?
[16:19:03] <dgarr> skunkworks_: thanks for testing
[16:19:23] <dgarr> seb_kuzminsky: did you want me to push the stubs patch to 2.6?
[16:20:03] <asah> its a 25
[16:20:20] <dgarr> btw, math, loops, conditionals have been available for ini set up of hal since 2009:
http://www.panix.com/~dgarrett/stuff/haltcl.txt
[16:23:14] <seb_kuzminsky> dgarr: it depends, let's find out
[16:23:35] <seb_kuzminsky> cradek: do you want support for ubuntu trusty tahr in 2.5?
[16:25:09] <seb_kuzminsky> halshow compiles but doesnt run with tcl 8.6, which is in trusty
[16:25:20] <seb_kuzminsky> dgarr's patch makes it run right for him and skunkworks
[16:25:58] <seb_kuzminsky> http://www.panix.com/~dgarrett/stuff/0001-halsh-initialize-stubs-library.patch
[16:26:39] <seb_kuzminsky> it's kind of academic at this point, but with the rate memleak's going we may have rtai on a trusty kernel before the end-of-life of 2.5
[16:27:01] <seb_kuzminsky> dgarr: oh right, i forgot about haltcl... nice
[16:27:58] <memleak> trusty kernel?
[16:28:25] <dgarr> the haltcl syntax is almost identidal to halcmd syntax and for little math jobs it is trivial to use it, the xhc-hb04 example sim configuration makes extensive use of the functionality
[16:28:35] <memleak> ill just need help with the linuxcnc side, dont worry about the kernel development or anything.
[16:48:05] <memleak> halrun -R causes segfaults: ~/linuxcnc/scripts/halrun: line 35: 6362 segmentation fault halcmd stop and ~/linuxcnc/scripts/halrun: line 35: 6363 segmentation fault halcmd unload all
[16:48:15] <memleak> latency-test works fine and linuxcnc window shows up fine
[16:48:32] <memleak> RTAPI: ERROR: could not open shared memory (errno=2)
[16:49:10] <memleak> halrun -R works fine
[16:49:45] <memleak> im going to work on merging vulcano with my RTAI tree
[16:50:33] <PCW> asah: freeby.mesanet.com/7i80hd_25_svtp2_si2.bit
[16:50:39] <asah> thanks!
[16:53:48] <memleak> just temporarily until this RTAI stuff gets sorted out can i stick to my little neat RTAI tree?
[16:56:28] <seb_kuzminsky> memleak: my advise would be - do whatever's going to make it easier to merge with paolo in the future
[16:57:35] <memleak> i can merge with paolo again with my small branch
[16:57:40] <memleak> a lot less code to have to merge
[16:58:10] <memleak> wont be a problem
[16:58:16] <memleak> besides vulcano wont change much anymore
[16:59:05] <memleak> i havent seen paolo away for this long before. hes been gone for like 2 months
[16:59:44] <alex_jon1> whee..
http://www.speedtest.net/result/3448025317.png
[17:01:13] <alex_joni> can't wait for new iso's to download :D
[17:02:08] <memleak> im working on an ISO :)
[17:02:12] <memleak> gentoo one though
[17:03:55] <alex_joni> sounds good
[17:18:19] <asah> PCW: looks like there is no 3pwmgens nor ssi in that bit file?
[17:33:13] <PCW> asah: did you power cycle the 7I80?
[17:42:45] <micges> PCW: I think mf3 should inform after flashing that you NEED to power cycle
[17:54:05] <PCW> yes
[18:00:13] <PCW> or I should add the capability of reloading the firmware by command
[18:00:43] <PCW> (doesnt work for PCI but would work for Ethernet)
[18:01:16] <KGB-linuxcnc> 03Chris Morley 052.6 d5686c2 06linuxcnc 10docs/src/config/emc2hal.txt docs: add descriptions for new spindle speed pins. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d5686c2
[18:02:26] <micges> yes I was thinking 5i25 board, I think reload firmware by command on eth boards is somewhere in your TODO
[18:03:01] <PCW> Yeah I need to make a ICAP interface
[18:04:20] <PCW> I think I even left a code for reload FPGA in space 7
[18:04:42] <seb_kuzminsky> cmorley: motion.spindle-speed-out-abs is missing from the motion.9 manpage
[18:04:57] <seb_kuzminsky> and .spindle-speed-out-rps-abs
[18:05:01] <seb_kuzminsky> could you add them?
[18:05:12] <cmorley> oh ok i wil add them...
[18:05:17] <seb_kuzminsky> thanks man
[18:19:27] <KGB-linuxcnc> 03Chris Morley 052.6 0033f78 06linuxcnc 10docs/man/man9/motion.9 docs -add descriptions of new motion pins to man pages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0033f78
[18:19:51] <memleak> 48K lines of code to merge :)
[18:21:17] <memleak> luckily only a few thousand of those need to be modified
[18:21:29] <memleak> should be done in a few days
[18:30:02] <KGB-linuxcnc> 03Chris Morley 05new_pncconf 942969e 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix off by one error with 5i25 GPIO numbering * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=942969e
[18:35:04] <skunkworks_> pcw, is that with the gigabit board?
[18:35:15] <skunkworks_> (awesome)
[18:35:27] <skunkworks_> I have not played with it much yet.
[18:39:36] <PCW> Yes the j1800 one
[18:45:40] <skunkworks_> neat
[18:45:52] <skunkworks_> I am likiing 14.04...
[18:50:54] <PCW> you can move unity's menus to the window decorations and not get repetitive stress on you mouse arm
[19:09:39] <linuxcnc-build> build #172 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/172 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[20:46:01] <linuxcnc-build> build #173 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/173 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[22:23:00] <linuxcnc-build> build #174 of 4017.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/174 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
