Back
[09:14:03] <riz_> When it comes to mdi commands. I see that halui takes in mdi_commands[n]. Is this an array of commands whereby multiple commands can be executed at once iwth mdi, or is this just an array to hold a single command?
[09:19:04] <cradek> what are you trying to do?
[09:20:55] <riz_> I'm trying to run multi-line mdi commands
[09:21:17] <riz_> rather than a single command at a time
[09:21:18] <cradek> ah, make a sub, and use halui to issue O<sub> call
[09:21:27] <riz_> I do this in one of my fanuc systems now
[09:22:36] <riz_> So mdi_commands[n] just refers to a single line string of length [n]?
[09:23:17] <cradek> in the ini file, you specify one line per halui-mdi input pin
[09:23:49] <cradek> I don't remember how it's stored in the C and it doesn't matter
[09:24:16] <cradek> mdi commands are one line at a time, whether you type them or they come from the ini file via halui
[09:24:24] <cradek> but that one line can be O-call
[09:24:33] <cradek> and this is the answer to your problem
[09:24:55] <riz_> OK, I see
[09:25:04] <riz_> Thanks. Will try it out
[09:25:19] <cradek> http://www.linuxcnc.org/docs/html/man/man1/halui.1.html
[09:25:44] <cradek> see the mdi section here in the halui docs
[09:26:48] <cradek> also
http://www.linuxcnc.org/docs/html/gcode/o-code.html#_calling_files
[09:26:51] <riz_> OK. I'll check it out
[10:01:10] <ktchk> Hello ubuntu precise rtai linuxcnc 2.5 is there any success road map?
[10:02:37] <cradek> ktchk: this RTAI tree is reported to work with 3.x kernels and run linuxcnc:
https://github.com/ShabbyX/RTAI
[10:03:00] <cradek> ktchk: I have not tried it. if you try it, please report your results here!
[10:05:04] <ktchk> cradek: how about linuxcnc 2.5 can it be complile under rtai3.x?
[10:06:43] <cradek> I think if you can get that rtai built, linuxcnc 2.5 will run under it, but I have not tried it.
[10:07:55] <ktchk> Ok I have a ssd can test on. will come back later.
[10:09:04] <cradek> seb_kuzminsky: hmm, I thought we decided 4th saturday, not last saturday, but I see that's not in the first meeting's minutes
[10:10:51] <cradek> seb_kuzminsky:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?action=browse&diff=1&id=MeetingsOnIRC&revision=7&diffrevision=6
[10:12:29] <cradek> ok I'm not imagining that there was some support for that:
http://meetlog.archivist.info/meeting.php?id=201306
[10:12:58] <cradek> there was no firm decision
[10:14:11] <cradek> seb_kuzminsky: the irc channel topic and
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201308 don't agree so we need to figure this out asap
[10:35:16] <seb_kuzminsky> cradek: darn, i messed it up :-(
[10:37:04] <seb_kuzminsky> ok it seems like the 4th saturday had more support than the last saturday
[10:39:00] <seb_kuzminsky> i updated the wiki, i'll mail out a correction to my earlier announcement
[10:42:54] <seb_kuzminsky> email's away
[10:43:23] <seb_kuzminsky> and i updated my proposal on the 2013 August agenda to say "4th Saturday" instead of "last Saturday"
[10:59:06] <cradek> aha thanks
[10:59:25] <cradek> I didn't know if you had reasons to prefer last over 4th
[11:00:04] <seb_kuzminsky> my only reason is that it makes it 0.1% faster to identify the square to click in in the calendar
[11:00:20] <cradek> I didn't remember that we decided not to decide yet, haha
[11:00:31] <seb_kuzminsky> it's the first one fom the end, not the 4th one from the beginning
[11:01:15] <seb_kuzminsky> i guess the civic thing for me to do last month would have been to send out a broadcast email trying to build consensus for one or the other
[11:01:56] <seb_kuzminsky> i dont actually care which it is, i just want us to pick one so i dont have to think about it any more
[11:02:20] <seb_kuzminsky> oh btw, i built linux 3.4.53 with the shabby/memleak rtai, gonna try booting it on real hardware one of the next couple of nights
[11:02:41] <cradek> jepler said 4th was easier than last for putting in software calendar things - if this is true it's a strong reason I think (I don't use any calendaring stuff)
[11:02:57] <cradek> also I object on principle to calendar being a verb
[11:03:24] <seb_kuzminsky> all the calendars i've used support both "Nth from the beginning" and "Nth from the end", i think
[11:03:32] <seb_kuzminsky> but like i said, i really dont care
[11:04:11] <seb_kuzminsky> and if i'd known people would have a preference for the other way of identifying a saturday i would have chosen it from the start
[11:04:34] <cradek> it's as if you're totally reasonable
[11:04:42] <seb_kuzminsky> heh
[11:04:57] <seb_kuzminsky> only on things that don't matter ;-)
[11:05:38] <cradek> might that be useful for precise? I think precise uses an offspring of 3.2.0
[11:05:50] <seb_kuzminsky> yes i think it will be useful for precise
[11:06:06] <cradek> I am nervous about abandoning the distro's kernel - that's sure led to misery in the past
[11:06:21] <seb_kuzminsky> i've been doing all my rtai testing so far on paolo's 3.5.7 kernel on precise, and haven't run into any kernel/usr problems
[11:06:37] <cradek> skunkworks had network card problems
[11:06:49] <seb_kuzminsky> ah yes, i remember that
[11:06:51] <cradek> and I bet neither of you depend on terrible firmware blobs
[11:07:06] <cradek> stuff like that is where the misery is usually found
[11:07:59] <seb_kuzminsky> i guess we could ask memleak to port his kernel patch to 3.2
[11:08:06] <cradek> but my mind's open about this - I'm not saying it's a dead end or anything
[11:08:23] <seb_kuzminsky> he seems to enjoy that kind of work, and helpful
[11:08:29] <cradek> heck maybe it'd just work? I have no idea how different they are
[11:08:41] <seb_kuzminsky> i think it's worth trying 3.4 on precise
[11:08:44] <cradek> yeah he's awesome
[11:08:49] <cradek> sure, why not
[11:09:10] <seb_kuzminsky> 3.4 is a long-term kernel maintained by greg k-h, unlike 3.2 which is eol-ed and only sporadically maintained by canonical now
[11:09:47] <cradek> I need to find me some newer hardware that can run precise+rtai
[11:10:06] <cradek> oh, it sure makes sense to move to 3.4 if possible then
[11:10:07] <seb_kuzminsky> i'm sad it doesnt run well on your old hardware, and confused, because it runs well on my old hardware
[11:10:19] <seb_kuzminsky> maybe your old hardware is older than my old hardware
[11:10:28] <cradek> yeah I couldn't get it installed on my P4 at all
[11:10:38] <seb_kuzminsky> i ran it on my P4
[11:10:45] <cradek> huh
[11:10:46] <seb_kuzminsky> the one that runs my bridgeport
[11:11:20] <cradek> I also tried an old server class xeon box with no luck
[11:11:32] <cradek> I didn't even bother to try my dual P3
[11:11:40] <seb_kuzminsky> i've also run precise (not rtai) on an old pre-p4 laptop that i gave to my nephew
[11:11:51] <seb_kuzminsky> so weird
[11:11:59] <seb_kuzminsky> what happens when these machines don't work for you?
[11:12:28] <cradek> various wrong things I didn't record carefully :-/
[11:12:41] <seb_kuzminsky> oh, that! i think i heard another bug report like that!
[11:12:43] <cradek> I think one made it to the desktop, but it was weirdly broken somehow
[11:12:44] <seb_kuzminsky> :-P
[11:13:06] <cradek> the other would just do stupid grub tricks like freezing with the rectangle in the corner of the screen
[11:13:36] <cradek> did you install from usb or optical?
[11:14:00] <seb_kuzminsky> usb, musta been
[11:14:03] <cradek> my usb installer was fine - I booted my (newish) desktop from it - but maybe usb+old hardware = doom
[11:14:16] <seb_kuzminsky> ah, that could be
[11:14:28] <seb_kuzminsky> we should find one of those floppy disks or dvds or whatever they were called
[11:14:29] <skunkworks> I remember trying seb_kuzminsky rtai build recently.. I don't remember if it had the same network card issue... (as xenomai)
[11:15:18] <seb_kuzminsky> i remember you tried it skunkworks
[11:15:30] <seb_kuzminsky> you have that fateful nic, rtl 86 something something
[11:15:50] <cradek> you mean the first-known fateful nic
[11:15:58] <seb_kuzminsky> yes :-/
[11:16:01] <skunkworks> right
[11:16:17] <cradek> e1000s for everyone!
[11:16:57] <skunkworks> 8168
[11:17:04] <seb_kuzminsky> that sounds right
[11:17:06] <skunkworks> 8169
[11:17:09] <skunkworks> soemthing like that
[11:17:22] <cradek> I love motherboards with slots - driver is weird? get different card from pile, throw troublesome card in pile (do this in order)
[11:17:23] <seb_kuzminsky> i hereby nickname that nic "cancer"
[11:17:40] <skunkworks> the 8168 driver running the 8168 nic
[11:17:43] <skunkworks> heh
[11:17:51] <skunkworks> the 8169 driver running the 8168 nic
[11:18:21] <skunkworks> nic cancer.. Sounds like a super hero..
[11:18:21] <cradek> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
[11:18:37] <cradek> funny, that's what's in my (mostly slotless) newish desktop
[11:18:37] <seb_kuzminsky> super villain
[11:18:49] <cradek> works fine in lucid and precise
[11:18:55] <seb_kuzminsky> yeah i guess it's the cheapest thing available, so all mb manufacturers use it
[11:19:03] <skunkworks> cradek, sure - just don't add realtime..
[11:19:19] <seb_kuzminsky> well, i think it's "just dont switch away from linux 3.2"
[11:19:23] <cradek> yeah it's not a question of realtime
[11:19:26] <skunkworks> this is zultrons quote..
[11:19:27] <skunkworks> The r8169 driver is finicky when driving an r8168 NIC, and won't drive it at 1Gb in any case. The Xenomai patches break it entirely.
[11:20:09] <cradek> someone has slogged through the mud and made it work in lucid and precise, and we don't benefit from that work when we use a different kernel
[11:20:21] <cradek> oh xenomai is actually what breaks it? I didn't expect that.
[11:20:24] <cradek> shows what I know
[11:20:30] <seb_kuzminsky> if so, rtai breaks it too
[11:21:04] <cradek> I'm sad. it's been so long since linux + wired ethernet was hard to get working
[11:21:08] <seb_kuzminsky> i think the driver worked in older kernels, then someone hacked on it and broke this particular very common hardware, and that went into the newer kernel that both rtai and xenomai are based on
[11:23:34] <skunkworks> If you have an r8168 and networking problems (or want full 1Gb speed), install the correct r8168 driver. The r8169 may be loaded in the initrd, in which case the r8168 cannot be automatically loaded, because the two drivers conflict. To fix this problem, the initrd must be rebuilt to include the r8168.
[11:25:30] <cradek> $ lsmod|grep r8
[11:25:31] <cradek> r8169 62154 0
[11:25:42] <cradek> my precise machine is using r8169 and gigabit works
[11:25:59] <cradek> I didn't do anything special
[11:27:12] <cradek> oh but it's 3.2 which is before the breakage?
[11:27:48] <skunkworks> sorry - I have nothing more to copy and paste..
[11:31:10] <pcw_home> Zultron gave me specific instructions that fixed the 8168 issue on my (D525) test system
[11:31:12] <pcw_home> so he may be the one to ask about 8169/8168 issues
[11:31:23] <skunkworks> it is on the wiki
[11:31:27] <pcw_home> (8168 is newer BTW)
[11:31:43] <skunkworks> wait - I do have one more thing to copy and paste..
[11:31:55] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
[11:34:13] <zultron> the r8169 driver driving the 8168 doesn't work well, only driving it at 100Mb if it works at all.
[11:34:19] <pcw_home> Wonder if the problem is that the 8169 driver thinks its OK with a 8168 (when it clearly is not)
[11:34:39] <zultron> Lots of kernel patches mess it up, even though they don't touch it directly at all.
[11:34:49] <zultron> Xen and xenomai are two examples.
[11:34:59] <pcw_home> yuck
[11:35:04] <zultron> I'd put money on RTAI messing it up, too.
[11:35:28] <pcw_home> yay for equality
[11:35:42] <cradek> zultron: do you know: did this become the case after kernel 3.2.0? I ask because mine works with the precise kernel.
[11:36:48] <zultron> I don't really know, but I do know that the Xen kernel breaks it for 2.6.something.
[11:36:52] <cradek> I am a heavy gigabit user (my home directory and other important things are on nfs) and it's using the 8169 driver
[11:37:07] <cradek> interesting, really old problem then
[11:37:22] <zultron> Yeah. A quick google search turns up LOTS of hits.
[11:37:29] <zultron> It's RealTek's fault. :P
[11:37:42] <cradek> bleh
[11:38:58] <zultron> More annoying is you can't put an 8168 and 8169 NIC in the same host at the same time.
[11:39:49] <cradek> I snap up e1000 cards whenever I see them at goodwill...
[11:42:44] <zultron> That's exactly what I did after figuring out this mess a year ago.
[11:42:52] <cradek> :-/
[11:54:11] <pcw_home> Maybe the 8169 driver should not indicate it works with 8168s...
[11:55:15] <pcw_home> this is an issue with the RTNet driver as well
[11:56:07] <zultron> Yeah, it's hard to believe that with the proliferation of these chipsets that nobody's gotten around to fixing the problem.
[11:57:20] <pcw_home> the 8168 has got to be one of the most common GigE chips on low cost MBs
[11:58:35] <pcw_home> sort of like the next gen RTK8139 (sort of sad that buggy RTK crap pushes out decent chips however)
[12:00:26] <CaptHindsight> it works fine with winders and it's the cheapest, pretty much all the mainboard MBA's care about
[12:00:36] <pcw_home> we tried using some RTK chips in PC/104 Ethernet cards a while ago
[12:00:37] <pcw_home> reliably failed temperature tests
[12:02:36] <pcw_home> They probably fix the bugs in their windows drivers since thats their bread&butter
[12:13:24] <CaptHindsight> the latest R8168 driver is from last month
[12:19:27] <CaptHindsight> been running RTAI and 2.4 kernel all week on this with no issues yet
http://www.gigabyte.us/products/product-page.aspx?pid=3447#sp
[12:19:47] <CaptHindsight> uses RT 8111C
[12:19:56] <cradek> do you mean 3.4?
[12:20:06] <CaptHindsight> heh yeah
[12:20:13] <cradek> aha
[12:20:26] <cradek> ShabbyX git rtai? have you run linuxcnc 2.5 on it?
[12:21:02] <CaptHindsight> pretty sure memleak has, he'll be back later
[12:21:17] <CaptHindsight> it's his system here
[12:21:45] <cradek> cool, ktchk was asking this question earlier, I'd like to hear too
[12:22:01] <CaptHindsight> in fact he developed it all using that board
[12:22:44] <CaptHindsight> latency is still poor on the new AMD Socket FM2 Athlon™/A- Series Processors
[12:23:00] <CaptHindsight> not sure why yet
[12:24:00] <CaptHindsight> I think he's going to get 64 bit working and then work with Lars on the solving the latency issues
[12:25:51] <seb_kuzminsky> well this is appropos:
https://lwn.net/Articles/561327/
[12:25:58] <CaptHindsight> I have access to the AMD emulator for all the cpu's and chipsets, it would be interesting if we find anything in the hardware design that we can recommend to AMD to change to get latency below 1uS or better
[12:31:32] <pcw_home> I would guess that unless all bus master transfers are are disabled/made synchronous with the RT threads I doubt if 1 usec is possible
[12:36:03] <pcw_home> Though a early thread invocation, spin till timer match should get better than
[12:36:04] <pcw_home> 1 usec on most hardware at the expense of 100*maxlatency/threadperiod % CPU wastage
[12:36:09] <CaptHindsight> there was an Atom board that was under 1uS a few years ago
[12:36:24] <pcw_home> 1 usec if no I/O was done...
[12:36:37] <pcw_home> ~50 usec if done
[12:36:42] <CaptHindsight> Padnos used it for something
[12:37:11] <CaptHindsight> speaking of him, what has become of him?
[12:37:30] <pcw_home> Yeah no video
[12:37:46] <CaptHindsight> I never tried the board, only heard about his experience
[22:30:09] <memleak> seb_kuzminsky: i was going to work on a 3.2 RTAI patch anyway, but please note that non-vanilla kernel source (such as the ubuntu kernel source packages) are not meant to be used with RTAI, and a lot of their patches will really impact latency.
[22:31:04] <memleak> RTAI kernel patches should not be used on distro-patched kernels, and if you decide to base the RTAI kernel off Ubuntu, I will not be supporting the kernel work.
[22:31:13] <memleak> It's hard enough working with just kernel.org :P
[22:31:35] <seb_kuzminsky> memleak: hi!
[22:32:16] <seb_kuzminsky> i'm working with the linux-stable repo from kernel.org
[22:32:25] <memleak> hello, sorry I haven't been around all weekend.
[22:32:32] <seb_kuzminsky> 3.4.53 tag on the 3.4.y branch
[22:32:47] <seb_kuzminsky> no problem! it's OK to have a life outside linuxcnc (though it's discouraged)
[22:37:06] <memleak> 3.2 support should hit the tree in a couple days or so.
[22:37:22] <memleak> 64-bit fixes hopefully in the next week or so.
[22:51:58] <seb_kuzminsky> cradek, jepler: remember when we talked about metric vs inch previews in axis, and i promised a screenshot?
[22:52:01] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/metric-vs-inch/Screenshot.png
[22:52:12] <seb_kuzminsky> the program and the tool table file are in the same dir
[22:52:56] <CaptHindsight> yay metric \0/
[22:53:02] <seb_kuzminsky> when i hit run everything works fine, and it cuts exactly like i want (and like the program says)
[22:53:10] <seb_kuzminsky> heh
