Back
[12:43:38] <andypugh> Has anyone tried to run stepper_gantry in JA3 recently? It seems to be hanging for me (in a VM) after complaining that halui pins are being created in already-allocated memory.
[14:47:35] <zultron> Ah, time for new kernel packages!
[14:50:00] <micges> zultron: at machinekit ?
[14:52:19] <zultron> Yes, I'd put Debian packages there. It'll be a week before I'll have time to get to it, though....
[14:54:19] <micges> zultron: just let us know, I will check if any of bugfixes improves/changes rtnet support and behaviour
[14:54:51] <micges> (for new fancy mesanet 7i80 and 7i76E boards)
[14:56:02] <zultron> I haven't been following; it looks like the i-pipe patch is for 3.8.something?
[14:56:25] <micges> yes
[14:56:43] <micges> also for 3.10 but they didn't included it
[14:57:09] <zultron> I was hoping for a 3.10, under the impression that out-of-the-box beaglebone support would be included.
[14:57:50] <zultron> Then my same Debian source packages could be used to build bb kernels.
[14:58:55] <micges> zultron:
http://www.xenomai.org/pipermail/xenomai/2013-October/029289.html
[15:00:56] <mhaberler> hi folks
[15:00:58] <zultron> Ah, well looks like Charles contributed something to support bb under 3.8, so maybe that'll help.
[15:01:35] <zultron> Hi mhaberler! You happen to know if beaglebone can run linux 3.8 out-of-the-box?
[15:01:46] <zultron> Or is that not until 3.10?
[15:02:20] <mhaberler> no, not all of the patches are upstream yet
[15:02:33] <mhaberler> you mean an unpatched torvalds kernel?
[15:02:37] <mhaberler> that: no
[15:02:44] <zultron> Yes, that's what i meant.
[15:02:49] <zultron> They are with 3.10, aren't they?
[15:02:56] <mhaberler> working on
[15:03:05] <zultron> Oh, not yet? :-/
[15:03:18] <mhaberler> I havent tried, it might
[15:04:00] <zultron> How hard is it to compile 3.8 or 3.10 for bb? What else is needed, besides vanilla linux tarball?
[15:04:03] <mhaberler> actually the robert nelson repo goes up to 3.12:
https://github.com/RobertCNelson/linux-dev
[15:04:27] <zultron> Huh. I'm so behind.
[15:04:44] <mhaberler> this repo is the base, look at omap-builder there - Charles forked it for the xenomai patches
[15:05:31] <mhaberler> this is the recipe for the bb latest kernel Charles uses:
https://github.com/cdsteinkuehler/linux-dev/tree/3.8.13-bone27-xenomai
[15:05:36] <micges> heh, seems that I'm also behind
[15:06:39] <mhaberler> micges: and now for something completely different ;) what I didnt understand about the 7i80 patches:
[15:06:52] <mhaberler> were these meant to keep PCI mode running?
[15:07:30] <micges> yes
[15:07:42] <micges> it's just additional low level driver
[15:07:55] <micges> now there are hm2_7i43 hm2_pci and hm2_eth
[15:08:01] <mhaberler> meaning if the 7i80 branch fails my mesa cards I can shout at you?
[15:09:11] <micges> no? :)
[15:09:32] <micges> which branch which card, I'll reproduce it
[15:09:57] <mhaberler> ok, I just played janitor and rebased on ubc3 but didnt fire up gdb
[15:10:06] <mhaberler> I'll try to reproduce
[15:10:13] <zultron> Well, this is the script that patches the kernel in Charles's repo:
https://github.com/cdsteinkuehler/linux-dev/blob/3.8.13-bone27-xenomai/patch.sh
[15:10:30] <zultron> Hundreds of patches. :P
[15:12:36] <mhaberler> I think these guys are targeting 3.12 for mainline, but defacto it doesnt make any difference for us
[15:13:03] <zultron> Looks like my debian packages won't build for beaglebone without a lot of modification, and at that point, we'd have to consider switching to Charles's repo to build our x86-arch kernels.
[15:13:20] <mhaberler> not sure this is needed
[15:13:24] <zultron> No, but it's nice.
[15:13:41] <mhaberler> that repo cds/linux-dev can build debs
[15:14:01] <mhaberler> build_deb.sh and tools/rebuild_deb.sh
[15:14:17] <mhaberler> its all done
[15:14:44] <zultron> Yes, that's what I meant. Before a lot of work to integrate bb builds into my autobuilder stuff, I'd need to look at just using his repo to build x86-arch debs (& throw my stuff away).
[15:15:02] <mhaberler> the 2.6.3 xenomai release also should have clean Xenomai Raspberry patches by Paul Corner
[15:15:20] <zultron> Sweet.
[15:15:48] <zultron> I've seen those contributions now and again on the Xeno list.
[15:17:42] <mhaberler> micges: just to make sure: I build the 7i80 branch, my pci cards are supposed to be still working?
[15:18:01] <micges> yes
[15:18:32] <mhaberler> good, wasnt sure; did you create any changes since the wiki article?
[15:18:59] <micges> skunkworks did few minor changes
[15:19:09] <mhaberler> and those are .. where?
[15:19:16] <mhaberler> private bin?
[15:19:35] <micges> I mean wiki changes
[15:19:40] <mhaberler> ah
[15:19:48] <micges> osrry didn't understand at first
[15:19:59] <micges> driver is the same
[15:20:12] <mhaberler> anyway I'll retry then with the pci mesa cards, likely my fault
[15:20:16] <micges> I have changes locally that will be released in a week or so
[15:20:37] <mhaberler> I guess I'll wait for those
[15:21:00] <mhaberler> but if they dont break existing code I think they could go into master
[15:21:28] <micges> like I said I didn't change anything but this branch is q'n' dirty setup and I didn't check any pci board on it
[15:21:46] <micges> those are optimalisation changes
[15:21:57] <micges> to use few packets per servo cycle
[15:22:08] <micges> fewer
[15:23:00] <mhaberler> do you have any suggestions for rt-preempt beyond plain udp sockets?
[15:23:19] <micges> no
[15:23:47] <mhaberler> I havent found a good userland ethernet driver method which runs on vanilla kernels; most of that stuff is for sniffing (r/o)
[15:24:01] <micges> I even can't compile rt-preempt properly for tests
[15:24:15] <mhaberler> hm?
[15:24:35] <micges> devel machine glitches
[15:24:58] <mhaberler> ah. this one performs pretty well:
http://static.mah.priv.at/public/rt-preempt/
[15:25:08] <mhaberler> (3.10.4)
[15:25:09] <micges> thanks I
[15:25:14] <micges> 'll try
[15:25:59] <mhaberler> what route would you go for preempt: udp sockets or raw userland ethernet?
[15:26:59] <micges> I did only kernel sockets, seems to be quite fast
[15:27:11] <micges> ksocket at sourceforge
[15:27:59] <mhaberler> that is in-kernel sockets
[15:28:53] <micges> if all is now userspace I would try udp sockets
[15:28:59] <mhaberler> thats an alternative for rtai or whoever would use xeno-kernel
[15:29:00] <mhaberler> aja
[15:29:19] <mhaberler> probably best to do a timing round first
[15:29:29] <micges> sure
[15:30:10] <mhaberler> I doubt all this rtnet mumbo-jumbo buys you a lot on a quiet port which only has a 7i80 at the other side
[15:30:16] <micges> silly thing is that functions needed to support 7i80 under xenomai are under lxrt, aka rtai usperspace
[15:31:22] <mhaberler> I see this under the angle 'which chance does this code have to go mainline', and with rtnet thats a bit fuzzy
[15:33:03] <mhaberler> the xenomai folks have a clear vision and work in progress with cobalt, but not sure if the rtnet stuff will come along
[15:34:13] <mhaberler> the basic issue is - we'll have more of these peripherals, and I'd like to see a way to talk to them across flavors
[15:34:37] <micges> so maybe raw ethernet packets? less usage of linux network stack so maybe better latencies
[15:35:13] <mhaberler> yes, that was my idea, but I havent seen a mainline/mainline-likely method which can be used
[15:35:23] <mhaberler> netmap wont make it, too much resistance
[15:36:29] <mhaberler> it's a pity, performs very well but didnt play the linux crowd properly
[15:36:52] <micges> I'll see raw packets again after driver optimalisations
[15:37:03] <mhaberler> ?
[15:37:14] <micges> it will eventially be 1+1 or 1+2 packets per servo cycle
[15:37:14] <mhaberler> oh you mean look at
[15:37:36] <mhaberler> right, and that kind of udp doesnt warrant a stack
[15:37:37] <micges> now it's 4 to 6 per cycle
[15:38:03] <micges> yes
[15:39:26] <mhaberler> have you ever looked at ethercat? Sascha is a very talented guy, he's pushing this (the german machining industry has progressed to bus interfaces already ;) but I am unsure how the net i/o is done, need to look
[15:41:35] <micges> yes I have but I don't know about licence of use ethercat in slaves
[15:41:56] <mhaberler> different issue; just curious on how they push packets
[15:44:12] <mhaberler> btw I have keyboad coord mode jog during pause working fine
[15:44:35] <micges> can't wait for it!
[15:44:58] <mhaberler> I wonder what teleop is good for once this is done
[15:46:54] <mhaberler> the more I think of it the whole mode switching business could be replaced by selecting one of several kins (really two -trivkins for joint jog and the real one for the rest)
[15:48:20] <mhaberler> I though about modules exporting 'method tables' (rtapi variant of _vtab) to do that, which would cover your on-demand module function call too
[15:49:29] <micges> interesting
[15:51:13] <mhaberler> the issue aint the naming, its arg types - the signature if you will
[15:51:37] <mhaberler> not much use without params
[20:27:37] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll 56aa746 06linuxcnc 10src/ 10(5 files in 2 dirs)
[20:27:37] <KGB-linuxcnc> Use the new function-global busy flags and set thing up so that negative offset mean earlier in time.