Back
[00:01:43] <memleak> I haven't touched rt-preempt in awhile it looks like you fixed the false positive page fault issue with rt-preempt in linuxcnc in the "rtapi/rt-preempt: adapt for new status and exception handling" have you tested this?
[00:02:54] <memleak> if latency is still in the few hundred microsecond range at least the annoying errors are finally gone.
[00:06:34] <mhaberler> not sure what you mean by 'testing' - this commit reports per-thread status and hence doesnt report meaningless pf's of the main thread which are irrelevant and expected
[00:06:55] <memleak> awesome!
[00:07:18] <mhaberler> as for latency, I suggest to try 3.10-x-rt - your purported latency guesses are off by more than an order of magnitude
[00:08:34] <memleak> last time i tried preempt-rt with linuxcnc i was using 3.8 a few months back
[00:08:55] <memleak> a lot has changed it seems?
[00:09:19] <memleak> everyone i was working with had terrible latency numbers as well, along with "meaningless page faults"
[00:09:57] <memleak> if they were in fact were meaningless and latency is still bad, we can at least rule out that the bad latency was caused by page faults\
[00:10:19] <memleak> *if they were in fact meaningless
[04:03:48] <awallin> why do I get this dmesg output when closing the latest 'master': [ 9363.689867] axis[27523]: segfault at 98 ip 0000000000473ba8 sp 00007fff420e9450 error 6 in python2.7[400000+239000]
[04:29:32] <memleak> because as opposed to the application closing with an actual exit status, it seg faults itself to death.
[04:31:05] <memleak> the application terminates "unexpectedly" when you would expect it to close.
[04:32:39] <memleak> i'm sure it's a well known issue here.
[04:34:44] <awallin> ok..
[04:36:40] <memleak> i'm not sure how to fix it, nor do i know which commit introduced it, but it's harmless. i just ignore it.
[04:39:28] <memleak> maybe it doesn't do it with python 2.6 but i haven't bothered to test it.
[04:40:41] <memleak> if you're on debian or ubuntu you can have several python installations at once, just be sure to set python 2.6 as the default when launching linuxcnc if you're willing to try it out.
[04:53:11] <awallin> I'm just running sim on my desktop (ubuntu 13.04) - but it's not a big deal anyway..
[04:53:47] <memleak> yeah, a little dmesg pollution never hurt anyone :)
[05:26:04] <memleak> i accidentally sent an email out to the emc mailing list as opposed to the RTAI one.. sorry about that...
[05:26:34] <awallin> is there still life in RTAI ? :)
[05:27:00] <memleak> tons!
[05:27:16] <memleak> i've been revamping and developing on it like mad, trying to save the projec
[05:27:21] <memleak> *project
[05:28:43] <mhaberler> awallin: if you want to know, attach with gdb like 'gdb -p <axis pid>', and continue, then close
[05:29:09] <awallin> memleak: care to elaborate on xenomai/RTAI and why you are saving rtai?
[05:30:15] <memleak> I'm not a Xenomai expert and I didn't want to become one since I already knew RTAI inside and out.
[05:30:55] <memleak> Figured I might as well contribute hundreds of commits toward RTAI instead of learning from a bunch of folks who felt like reinventing the wheel (instead of improving on RTAI)
[05:32:09] <memleak> I really don't like the Xenomai folks much so I didn't want to contribute or learn about the project. I like RTAI because of it's performance and as for the OCD folks who want clean code, you can cosemetically clean up a source tree without impacting RT performance, but the Xenomai devs beg to differ.
[05:33:15] <memleak> I personally have been cleaning up the RTAI source and making it much more easier to read, develop and improve upon, and actually lowered latency jitters by at least 20% as compared to where it was before I started working on RTAI.
[05:40:32] <memleak> awallin, just yesterday I think it was I got 64-bit working with RTAI with no problems so far. I really enjoy working on RTAI, it's a lot of fun. Not many people feel like developing with it either so that leaves me to do all the fun stuff :)
[05:41:20] <awallin> ok, well it's nice to have alternatives. now there's xenomai for a number of ARM boards also which is nice.
[05:41:58] <awallin> did you see the news about the latest National Instruments controller using rt-preempt? I guess they figured rt-preempt performance is enough..
[05:43:36] <memleak> PREEMPT_RT and RTAI are the only things I'd ever use. Xenomai to me is the awkward middle man. PREEMPT_RT is even cleaner than Xenomai, with similar performance as well.
[05:45:06] <awallin> luckily we have rtapi in between, so any rt-applications built with HAL will transfer over as long as we have rt-kernels. For the ARM boards that come out every month it seems compiling rt-kernels is not so trivial
[05:45:15] <memleak> and much more stable as well, considering a lot of the official kernel devs work on the scheduling code.
[05:45:42] <awallin> is there such a thing as preempt_rt on ARM?
[05:46:38] <memleak> yes and powerpc
[05:47:37] <memleak> it's much further ahead too if you don't count HPET
[05:47:57] <awallin> hpet?
[05:48:15] <memleak> not HPET.. high-resolution timer option
[05:48:25] <memleak> high precision event timer != high res timers.. forgot about that
[05:52:09] <memleak> people have preempt_rt working on many ARM boards such as OMAP 34xx and 44xx at91 series as well.
[05:52:34] <memleak> not sure about all the details though.
[05:52:51] <memleak> its 5:30 i need to get some sleep now, take care awallin.
[05:54:32] <awallin> see you!
[08:49:56] <seb_kuzminsky> hello friends, i'm back!
[08:54:20] <cradek> hi!
[09:05:15] <skunkworks> How was the trip?
[09:18:59] <andypugh> Hi Seb
[09:21:23] <skunkworks> andypugh: john stevenson wanted to get a hold of you. (on hobbing)
[09:21:27] <skunkworks> Do you have contact details for Andy ?
[09:21:29] <skunkworks> I have nearly the same setup on my mill but Andy's is better in various ways and I'd like to contact him.
[09:21:53] <andypugh> Yes, we are in communication.
[09:22:25] <andypugh> It was his setup that had me asking about capeless BBB boards.
[09:22:37] <skunkworks> ah - cool
[09:23:39] <andypugh> He currently has a simple divider box that drives a stepper from the hobbing spindle. It looks like it isn't good at ramping in and out as it loses position if he stops the spindle. I susepct that a LinuxCNC installation is rather overkill to fix that.
[09:38:47] <andypugh> skunkworks: How did you choose the IP addresses for your 7i80?
[09:39:15] <andypugh> I am getting: rtapi_app_main(hm2_eth): -97 Address family not supported by protocol
[09:42:39] <pcw_home> The 7I80 has 3 IP-address options
[09:42:41] <pcw_home> 0 hardwired to 192.168.1.121
[09:42:43] <pcw_home> 1 Set in EEPROM (mesaflash will do this)
[09:42:44] <pcw_home> 2 bootp
[09:43:11] <andypugh> Yes, but the rtnet driver seems to need two IP addresses.
[09:43:16] <pcw_home> mode 3 will be DHCP when i get around to it
[09:43:35] <pcw_home> well you need to set in host interface address
[09:43:49] <pcw_home> set the
[09:43:56] <andypugh> I think that is the bit that I don't understand.
[09:45:42] <pcw_home> it set in rtnet.conf
[09:45:50] <pcw_home> its
[09:52:02] <archivist> andypugh, hard to wean jon stevenson off steppers and mach :(
[09:53:17] <andypugh> Yes, I know. He seems to have forgotten that he asked me the same question a few years ago and then completely failed to reply to my lengthy response.
[09:54:32] <archivist> he visited me at the clockworks, and I meet him helping on the Arc Eurotrade stand
[09:57:18] <andypugh> He seems to have a link to them:
http://www.arceurotrade.co.uk/Catalogue/New-Products/Stevensons-ER32-Collet-Blocks
[09:58:45] <archivist> well yes, more than a link
[09:59:42] <archivist> casual helper and occasional supplier
[10:00:46] <archivist> he was supposed to be developing their chinese cnc lathe stuff....but mach getting in the way I think :)
[10:01:24] <andypugh> I have to say that those hexagonal collet blocks look really useful for knocking up a quick hex if your lathe and mill don't both already do it automatically :-)
[10:01:24] <archivist> I have reminded him and boss there about linuxcnc
[10:02:30] <archivist> boss there is friendly :)
[10:03:40] <andypugh> Their drip-feed oilers are about 50% of the cost of anyone elses. And about 25% of the quality. So now I have two sets
[10:04:03] <andypugh> (ie, an arc-eurotrade set and a set that don't look out of place on the Rivett)
[10:04:29] <andypugh> To be fair, the nasty ArcEuro ones are 100% functional.
[10:08:01] <archivist> I need to set up a drip feed for this bevel making :)
[10:17:21] <andypugh> G-code drip-feed or oil drio-ffed?
[10:19:52] <archivist> oil for the cutter
[10:20:46] <archivist> the machine is too open and indoors in a bedroom, so flood lubrication is not on
[10:22:10] <andypugh> My solution is to no longer refer to the "project room" as a "bedroom" :-)
[10:22:36] <archivist> room....house
[10:40:42] <skunkworks> andypugh: you set it in the scripts/\
[10:41:19] <andypugh> Yes, but how do I know what numbers to choose?
[10:42:43] <skunkworks> oh - I set the host as 192.168.1.1
[10:43:26] <skunkworks> althouh I think it can be whatever as long as it is in the same subnet
[10:44:28] <skunkworks> remember to rmmod the existing nic driver before trying to run the rtnet one
[10:45:03] <andypugh> I thought I had found the problem when I remebered that, but I hadn't.
[10:45:27] <andypugh> rtapi_app:2412:user rtapi_app_main(hm2_eth): -97 Address family not supported by protocol
[10:46:20] <andypugh> Was your PC networked at the time?
[10:46:45] <andypugh> Maybe the problem is that the PC is connected to my network (by Wif)
[10:47:06] <andypugh> And did you have the 7i80 connected directly, or via a router?
[10:49:04] <skunkworks> yes
[10:49:17] <skunkworks> I had a intel pro/100 that I was using
[10:49:19] <andypugh> which?
[10:49:28] <skunkworks> directly
[10:50:19] <andypugh> I wish I had the slightest idea what the error message means
[10:50:43] <skunkworks> I don't think I had that error
[10:51:19] <skunkworks> your on the cutting edge... :)
[10:55:34] <andypugh> Yes, but so were you and it worked for you.
[10:55:48] <andypugh> So I demand that you are the expert
[10:56:49] <skunkworks> heh
[10:56:51] <skunkworks> sorry
[10:57:15] <skunkworks> it only sort of worked (and that was on 10.04)
[10:57:39] <skunkworks> I could control gpio - but it was spitting out encoder errors
[10:58:00] <skunkworks> even if I told it there was 0 encoders
[11:39:29] <seb_kuzminsky> pcw_home: does the 7i80 implement zero-conf ip and multicast dns? that's by far the easiest way to get a device onto an IP network and find it from other machines on that network
[12:25:17] <zultron> Hi seb_kuzminsky! Welcome home. ;)
[12:27:36] <zultron> I think for rtnet, it's best to have a dedicated ethernet port on the controller for a point-to-point link.
[12:27:40] <zultron> Passing packets through a switch will affect latency.
[12:27:50] <zultron> So using the static IP address scheme is as good a way to do it as any.
[12:41:30] <seb_kuzminsky> hi zultron :-)
[12:41:43] <seb_kuzminsky> yes static ip will work fine in that situation
[12:42:09] <seb_kuzminsky> only problem would be if that ip was also in use on some other network the controller's connected to
[12:42:24] <seb_kuzminsky> but we'd have that same problem with zeroconf ip, so... <shrug>
[12:42:57] <seb_kuzminsky> i like zeroconf+mdns because it just about always Just Works, and you dont have to set or look up any configuration
[12:47:53] <seb_kuzminsky> there was a great google tech talk about it, let me see if i can dig it up...
[12:48:23] <seb_kuzminsky> https://www.youtube.com/watch?v=ZhtZJ6EsCXo
[12:49:10] <zultron> Oh yeah, that could quite realistically be a problem, such as multiple 7i80s attached.
[12:49:54] <andypugh> Well, you can re-program the 7i80 to a different fixed number.
[12:50:12] <zultron> Right, but at that point one starts wishing for something automatic. :)
[13:24:11] <ahofer> Hi
[13:26:02] <ahofer> is it possible to crosscompile linuxcnc from x86 host for arm target? (RT-Preempt - Kernelspace)
[13:40:59] <CaptHindsight> ahofer: yes, but I'm not sure if there is a good howto posted yet
[13:46:30] <ahofer> hi CaptHindsight, thank for answer, where can i find some information?
[13:49:14] <CaptHindsight> ahofer: what arm target?
[13:49:35] <CaptHindsight> beaglebone black?
[13:50:21] <ahofer> no, pandaboard OMAP4460..
[13:52:11] <CaptHindsight> I'd start with the Panda forums
[13:54:56] <CaptHindsight> http://www.eewiki.net/display/linuxonarm/PandaBoard#PandaBoard-ARMCrossCompiler:GCC
[13:58:35] <CaptHindsight> ahofer: just doing this for fun and experience?
[14:12:35] <ahofer> thx, i know these site, i have allready installed a gcc crosscompiler, my problem is i compile allways with (ARCH:=arm ...) for kernelmodules i must link 'KDIR' to target Kernel source.. But the in the linuxcnc project this is not so easy..
[14:18:15] <andypugh> ahofer: I think somone reported that they had good results with the Yocto tools.
[14:18:45] <ahofer> I am a embedded system student in Vienna, i will write a spi driver.. to communicate with a STM32 same like the picnc
[14:32:03] <CaptHindsight> ahofer: cross compiling linuxcnc will probably end up being lots of work, how about just using the BBB and the working Linuxcnc image?
[14:32:22] <CaptHindsight> then you can just focus on writing your driver
[14:34:36] <ahofer> yes, that is the way i do it now, write some code and copy to the pandaboard and compile it on the board..
[14:36:15] <andypugh> Cross-compiling for embedded systems is what Yocto is meant for, it it probably worth a look.
[14:36:16] <ahofer> I need allways my hardware, so therefor i would ask for possible crosscompile...
[14:36:22] <CaptHindsight> lots of people that generally only use open source even give up and use code sorcery when it come to x86 to arm cross compiling
[14:36:54] <memleak> you can cross compile pretty much everything with crosstool-ng very easily by modifying your PATH.
[14:37:38] <memleak> export PATH="your/crosstool-ng/toolchain:/$PATH"
[14:38:21] <andypugh> But! But! Yocto is the project of a friend of mine, so is clearly the best solution :-)
[14:39:47] <andypugh> https://www.yoctoproject.org/about
[14:40:35] <CaptHindsight> but nonono
http://crosstool-ng.org/
[14:40:50] <archivist> bias++
[14:41:00] <CaptHindsight> lol
[14:41:30] <andypugh> Well, I have to say that crosstool looks a lot more like an open-source project. The Yocto web page is a bit too shiny.
[15:07:02] <ahofer> oke, i will check these
[15:08:47] <ahofer> night
[15:15:33] <micges> hi guys
[15:15:55] <mhaberler> hi Michal
[15:16:06] <micges> I don't have much time
[15:16:22] <mhaberler> you somehow knew what was coming ;)
[15:17:02] <micges> :)
[15:17:24] <micges> first there is no 7i80 support on rtai becouse there is lack of task_join() and TASK_JOINABLE flag while creating rt task
[15:17:48] <micges> after few attempts it's only reason for now
[15:18:00] <mhaberler> ego te absolvo
[15:18:34] <mhaberler> read the ml today?
[15:18:35] <micges> when I've some time I'll look at new 7i80 support branch and correct wiki if needed
[15:18:39] <mhaberler> fine
[15:19:01] <mhaberler> probably something trivial
[15:19:18] <andypugh> I haven't even figured out where the code is that is raising the error message I see.
[15:19:35] <mhaberler> you cant do this with printk ..
[15:19:43] <micges> mhaberler: I've something small now that I must care about
[15:19:48] <mhaberler> I know
[15:19:50] <micges> in first place
[15:19:57] <mhaberler> how's the family doing?
[15:20:00] <micges> andypugh: it's 99% config error
[15:20:04] <andypugh> I am not trying.
[15:20:22] <mhaberler> anyway, dont do it - just direct us
[15:20:30] <mhaberler> looked like a networking issue to me
[15:20:41] <micges> mhaberler: very well
[15:20:53] <andypugh> micges: I thought so. But I think I need clues on how to do basic stuff like select compatible IP addresses.
[15:21:22] <micges> mhaberler: I've got rtnet test pc around, it will be by the way
[15:21:56] <mhaberler> I could do, too, but it means reworking the haystack
[15:22:27] <mhaberler> however, if any promises to read a gdb tutorial..
[15:22:32] <mhaberler> any=andy
[15:22:33] <andypugh> I couldn't find the error message in the code, so I think it is a truncated version of 124 EAFNOSUPPORT
[15:22:48] <micges> andypugh: I've got this problem every time I resume working with 7i80
[15:23:50] <micges> did you set hardcoeded ip?
[15:23:50] <mhaberler> I wish we could do this with a generic (rtos-independent) userland ethernet access method, but I dont see any candidate yet; netmap sees severe resistance from the kernel folks
[15:23:56] <andypugh> mhaberler: I can't help thinking that gdb is the wrong way to start looking for something that is probably a config error.
[15:24:16] <mhaberler> well, there is always divination
[15:24:41] <micges> andypugh: try using mesaflash first to get acces to 7i80
[15:24:44] <mhaberler> but I just took it as an opportunity to show that it can be done now
[15:25:07] <micges> if it will work and you know net numbers then rtnet will work also
[15:25:45] <micges> mesaflash have option to search 7i80 on current netmask
[15:25:47] <andypugh> micges: I don't even understand the question. Ar eyou asking if I set the config to suit the hard-coded IP, or if I hard-coded an IP to suit the config?
[15:26:49] <micges> err I mean set jumper onboard to hardcoeded ip and change config to use it
[15:27:20] <andypugh> I think I will probably just give up and move onto something else. I don't need the 7i80, I have no plans for it, and seem to have wated an entire weekend trying ti make it work.
[15:28:07] <micges> andypugh: ok, just tell me what pc hardware you have?
[15:28:19] <andypugh> I was only experimenting to see if I could advise someone on the forum on how to set one up, and what was involved. Well, I think I have concluded that he is on his own :-)
[15:30:26] <andypugh> Intel Atom DN2800 connected to my network via a WiFi card (IP 192.168.0.171) and then with the Ethernet socket connected directly to the 7i80, jumpered for hardcoded IP of 192.168.1.121. The standard kernel chose the e1000e ethernet driver, so I chose rt_e1000e.
[15:33:46] <micges> try remove wifi, use only one eth directly to 7i80, then set local ip to 192.168.1.1 netmask 255.255.255.0, use mesaflash to connect to 7i80
[15:34:33] <micges> mesaflash is using standard eth intefrace so should work on proper inet config
[15:35:26] <micges> andypugh: don't relay on gnome network config creator, try adding new fresh connection with proper data
[15:37:28] <micges> mhaberler: one more thing, what is ub2 status? it has frozen rtapi api?
[15:37:47] <mhaberler> yes
[15:37:55] <mhaberler> but it didnt change to start with
[15:38:22] <micges> ok
[15:38:37] <mhaberler> it's safe to code against it, it wont break
[15:38:38] <andypugh> micges: OK, I can try that, though as I normally use that machine headless it isn't particularly convenient to remove all network connections
[15:39:32] <micges> andypugh: it's too early to test 7i80 on that kind of setup then :)
[15:39:51] <mhaberler> chicken!
[15:39:59] <andypugh> It too early for _me_ to test it, perhaps.
[15:40:26] <micges> mhaberler: ok, I'll reply on ml on ub2-7i80 progress
[15:40:32] <mhaberler> thanks
[15:40:34] <micges> andypugh: for driver
[15:40:50] <mhaberler> I'll dig out my 7i80 and reconnect it
[15:41:07] <micges> ok see you guys
[15:41:11] <mhaberler> cu!
[15:41:46] <mhaberler> btw: the ubc* branches will rebase until further notice
[15:47:43] <pcw_home> For any real time 7I80 application, it will need its own Ethernet connection
[15:47:44] <pcw_home> so setting up a standard IP address/netmask should not be much of a burden
[15:47:46] <pcw_home> and you can use bootP now and DHCP when I get around to adding it
[16:00:21] <andypugh> What sets the G0 speed in a JA3 system? I can't get anything to G0 faster than 60 units per minute. Though they will jog at 6000
[16:20:26] <pcw_home> andypugh: are you trying the hm2-ethernet driver with a shared Ethernet MAC?
[16:22:00] <pcw_home> It needs it own MAC (or you need to unload the normal driver before the RTNet is loaded)
[16:22:15] <pcw_home> RTNet driver
[16:24:04] <andypugh> I don't even know what you mean by a shared MAC
[16:24:31] <pcw_home> Do you have one or more ethernet connections on your host PC?
[16:24:51] <pcw_home> The 7I80 needs its own for RTNet
[16:26:18] <andypugh> There is only one ethernet port. I unloaded the driver.
[16:29:38] <pcw_home> OK and you have something like:
[16:29:39] <pcw_home> IPADDR=192.168.1.1
[16:29:41] <pcw_home> NETMASK=255.255.255.0
[16:29:42] <pcw_home> in your rtnet.conf file
[16:33:46] <andypugh> There is no mention of any requirement to edit rtnet.conf in the Wiki page. (But Yes)
[16:34:23] <pcw_home> yes at the minimum the driver will likely need to be changed
[16:34:55] <andypugh> There is a LinuxCNC script that seems intended to handle that part.
[16:34:59] <pcw_home> can you start RTNet?
[16:35:32] <pcw_home> that way you can try rtping and check communications
[16:35:54] <pcw_home> is the Xenomai?
[16:36:07] <pcw_home> is this
[16:37:28] <pcw_home> http://www.rtnet.org/doc.html
[17:12:01] <cradek> andypugh: my correctly-working ja3 config:
http://timeguy.com/gitweb?p=linuxcnc.git;a=blob;f=configs/sim/axis/rdelta.ini;h=eb71af560ee89ca502dd9fe25759fb95781b58c0;hb=ebca97b92c903688f3639ca3726b6590b4499abe
[17:12:31] <cradek> maybe you can find which piece you are missing
[17:13:55] <andypugh> It all looks much the same.
[17:14:51] <andypugh> I am a bit puzzled that your JOINT velocities and AXIS velocities are so similar.
[17:15:01] <andypugh> Sorry, I mean, so different.
[17:15:27] <cradek> the joints are rotary so they're degrees
[17:26:01] <cradek> it takes a lot of degrees to move something like an inch
[17:26:19] <cradek> did you run my config? It's a cool setup that I really oughta build.
[17:27:05] <skunkworks> cradek: your delta?
[17:27:20] <cradek> upside-down delta
[17:27:24] <skunkworks> cool
[17:28:03] <cradek> hm I need to rebase upside-down on to the new ja3 which has my new fixes
[17:28:37] <Tom_itx> is it a rostock?
[17:29:01] <cradek> no, it's based on rotary joints, and rostock is linear joints
[17:29:39] <cradek> I am not aware of any existing machine like what I've thought up, which probably means it's a bad idea for some reason I haven't yet figured out
[17:36:58] <skunkworks> cradek - like this?
https://www.youtube.com/watch?v=5MOSnFSx8JQ
[17:38:29] <cradek> that's a rotary delta, but mine is weirder
[17:38:34] <skunkworks> heh
[17:40:55] <skunkworks> andypugh: my wife wonders how you pronounce your last name.
[17:41:50] <andypugh> Just like the first name "Hugh"
[17:42:14] <skunkworks> Thanks
[17:42:56] <KGB-linuxcnc> 03chris 05upside-down 102bc52 06linuxcnc 10configs/sim/axis/rdelta.ini 10configs/sim/axis/sim_rdelta.hal 10src/emc/kinematics/rotarydeltakins-common.h 10src/hal/user_comps/vismach/rotarydelta.py * Upside-down delta configuration
[17:42:56] <KGB-linuxcnc> 03chris 05upside-down c0f4d6b 06linuxcnc 10configs/sim/axis/rdelta.ini 10src/hal/user_comps/vismach/rotarydelta.py * Represent rotaries more precisely
[17:43:20] <cradek> there, now you can see it actually working right
[17:59:36] <andypugh> cradek: Which branch did they go into?
[18:00:54] <skunkworks> andypugh: this is what I was getting on 12.04
[18:00:55] <skunkworks> http://pastebin.ca/2410089?srch=rtnet
[18:02:00] <andypugh> skunkworks: That seems to be solved in the branch that Michael posted a link to earlier today.
[18:02:34] <andypugh> You need to "git remote add" the mah repo then fetch it.
[18:06:57] <skunkworks> I will try it monday
[18:06:59] <skunkworks> cool
[18:25:41] <skunkworks-> andypugh: this is the error I was getting on 10.04
http://pastebin.ca/2410829?srch=encoder+hostmot+error
[18:26:33] <andypugh> That's an interesting one
[18:28:55] <andypugh> So, did you?
[18:33:17] <skunkworks> heh - I tink it is an issue with the 7i80 driver
[18:33:50] <skunkworks> http://pastebin.ca/2410789?srch=7i80
[18:35:10] <skunkworks> That last one - I am sure I loaded all the rtnet modules manually
[18:36:09] <skunkworks> (I hadn't really thought I could search pastebin.cs
[18:36:13] <skunkworks> (I hadn't really thought I could search pastebin.ca)
[18:48:13] <andypugh> cradek: I didn't really get what was diferent about it compared to a normal delta
[18:48:49] <andypugh> (I am also puzzled about why it has 3 joints and 9 axes)
[19:28:08] <KimK_2> skunkworks: Sorry I missed Andy, I was going to ask him about his solution to the grub2 menu? But I guess I can just try it and see if I overlooked a sub-menu choice. BRB.
[19:33:56] <KimK_2> No, 55-rtai was not hiding in a sub-menu. I can only select (for sda2) 51-generic and 51-generic (recovery).
[20:18:03] <cradek> andypugh: it has the motors and table on the same platform, instead of requiring a hollow and spindly frame structure between motors and table. the extra six joints and axes were just for testing ja3. the kins just passes them through unmodified.
[21:04:38] <memleak> KimK_2: if you modified grub.cfg you'd be much further ahead days ago.
[21:05:39] <memleak> it's the only way I roll with grub anyway.
[21:06:59] <memleak> don't be afraid to rm the file and start over, it loads a lot quicker too when there is only about 7 lines or so as opposed to 300 lines of useless grub bloat and unneeded modules.
[21:10:52] <KimK_2> memleak: Hi! Oh, I don't mind, you never know what might be happening out there. Like, how's your RTAI coming along, lol? This one is runnable on the plain 12.04, and I won't have the Mesa card for a few days anyway, so it's OK.
[22:18:00] <CaptHindsight> KimK_2: RTAI 64bit is working now
[22:23:10] <memleak> RTAI is soon to have kernel 3.10 support as well.
[22:23:16] <memleak> 32 and 64-bit
[22:25:12] <CaptHindsight> not sure what's next, RTAI for 3.8 kernels and above? Linuxcnc on Allwinner $5 multicore ARM soc's? <1 second power-on to login AMD mini-itx boards for Linuxcnc?
[22:26:19] <memleak> RTAI supports 3.8 (and 3.8.13) already but linuxcnc doesn't play well the new kernel headers (uapi and such) RTAI runs just as well on 3.8 than all the other 3.x kernels though
[22:28:19] <memleak> I've been looking over the RTAI code for ARM and the infrastructure is nice but the hardware / chip support is lacking.
[22:29:04] <memleak> Paolo has it working on ARM for _his_ ARM board, but nobody else with an ARM board tends to bother porting theirs to RTAI.
[22:29:34] <CaptHindsight> do you know which ARM board he has (0r ARM soc is on it)?
[22:30:31] <memleak> AT91
[22:37:29] <memleak> after reviewing the AT91 code more, it actually looks like it's based off RTAI 3.5 not _kernel_ 3.5 which is a 4 year difference..
[22:39:01] <memleak> 2.6 and 2.4 work with RTAI but not 3.x based
[22:39:08] <memleak> (for ARM) ^
[22:53:22] <CaptHindsight> i-pipe from xenomai for Allwinner A10
http://www.xenomai.org/pipermail/xenomai/2013-February/027801.html
[22:55:08] <CaptHindsight> aren't these results similar to the BBB?
[22:55:41] <CaptHindsight> so where's the big benefit of the PRU's?
[22:59:19] <pcw_home> Lacking a FPGA, an attached processor (the PRU for example) is the next best thing (for stepgens etc)
[23:00:40] <pcw_home> I wonder if the parallela will survive. Seems like a fantastic machine kit platform
[23:01:39] <pcw_home> Imagine 16 1GHZ PRUs with floating point
[23:03:44] <CaptHindsight> the allwinner a20 quad cores are ~$6, add a low cost FPGA
[23:04:54] <pcw_home> A20 is dual, you mean A31?
[23:05:10] <CaptHindsight> I lost track :)
[23:05:32] <pcw_home> The A20 cubie boards are out
[23:05:54] <CaptHindsight> yeah A31
[23:06:09] <pcw_home> (A20 is pin-pin compatible with the A10)
[23:06:23] <pcw_home> I do like the parallela though
[23:06:52] <CaptHindsight> yeah, was trying to justify the price
[23:07:25] <pcw_home> they are lot cheaper than I can buy the parts
[23:07:26] <CaptHindsight> or a high volume application 100K's-1M+
[23:08:25] <pcw_home> Alwinner and low end FPGA is probably the best there (Or sitara if the PRU will do what you need)
[23:09:05] <pcw_home> though you lose base performance with the Sitara
[23:12:39] <pcw_home> ~ Pentium 2 speed has been mentioned for BBB not sure how accurate that is
[23:12:40] <pcw_home> but rather depressing if a user interface is driven
[23:16:52] <CaptHindsight> XC6SLX4-TQG144BIV1305 how many gates is that?
[23:17:46] <CaptHindsight> ~$7
[23:18:55] <CaptHindsight> XC6SLX9-2TQG144C $10
[23:21:25] <pcw_home> Thats the one we use one the 5I25/6I25
[23:22:39] <pcw_home> enough space for a lot unless you have more than 8 or so axis
[23:23:08] <CaptHindsight> for a consumer 3D printer appliance an A20 + XC6SLX9-2TQG144C would be more than enough
[23:23:53] <pcw_home> Yes I would think
[23:27:53] <pcw_home> might be overkill as well unless you need a lot of special I/O
[23:30:07] <CaptHindsight> make a kitchen sink board, and leave out what's not needed for different versions
[23:30:40] <pcw_home> there are pin compatible slx4 and slx9 versions
[23:31:00] <CaptHindsight> XC6SLX4-TQG144BIV1305 is $7
[23:31:41] <pcw_home> yeah thats one if you need that many I/O pins. If cramped you could use a CSP
[23:32:29] <CaptHindsight> $3 savings for 100K+ boards makes sense
[23:34:03] <CaptHindsight> since the board stuffing part is where the screw-ups tend to occur, it best to have one layout and then just not stuff what's not needed
[23:35:09] <CaptHindsight> it also helps when a PCB vendor tries to cut corners, you can discover the problem right away
[23:35:41] <CaptHindsight> how it works in China anyway
[23:37:24] <pcw_home> Those must be low volume FPGA prices, (not much different than our couple 100's prices)
[23:37:50] <CaptHindsight> yeah, was just checking the overstock sites
[23:37:53] <pcw_home> at 100K you talk to Xilinx
[23:38:43] <CaptHindsight> nah, you find someone that already buys in high volume and ride on their orders
[23:39:46] <pcw_home> even Xilinx does that (why one of our spartan3 cards with 2M chip is the same price as 1M)
[23:40:50] <pcw_home> rumor was that the 2M chip was used in a plasma TV so millions made
[23:41:38] <CaptHindsight> makes sense
[23:41:51] <pcw_home> sleeepy.... 'nite
[23:41:55] <CaptHindsight> me to
[23:41:58] <CaptHindsight> zzzz