Back
[07:40:04] <jepler> cradek: too many model numbers, so irritating
[09:26:24] <mozmck> seb_kuzminsky: you added mesa-utils as a dependency, but looks like not blt?
[09:34:55] <seb_kuzminsky> mozmck: on wheezy, linuxcnc depends on python-tk, which depends on blt
[09:35:18] <mozmck> oh, I see, hmm
[09:35:30] <seb_kuzminsky> an explicit requirement is probably more technically correct, and may be required on some other distros
[09:35:45] <mozmck> I was testing on xubuntu 14.04
[09:35:49] <seb_kuzminsky> aha
[09:36:01] <seb_kuzminsky> yeah, we dont support that one properly yet :-/
[09:36:08] <mozmck> I'm downloaded jessie right now to see what it is like.
[09:36:30] <mozmck> I notice they have mate and cinnamon live images!
[09:39:35] <seb_kuzminsky> we dont support jessie either :-(
[09:44:31] <jepler> uspace builds and now works well non-realtime with jessie
[09:44:40] <jepler> not sure the deps are 100% correct though
[09:48:12] <seb_kuzminsky> nice, that's a big step
[09:48:23] <seb_kuzminsky> now we just need a packaged rt-preempt kernel for folks to install
[09:48:48] <mozmck> I would think jessie would be close to ubuntu 14.04 in package versions?
[09:49:51] <mozmck> I've got some kernel building machines now I can probably use to help with that.
[13:09:06] <andypugh> Oh this is such fun. I have a comp with modparams that freezes the PC with some combinations of modparams. Luckily it’s a VM or it would be even more frustrating to debug.
[13:19:54] <jepler> andypugh: in uspace you can even attach a debugger to rtapi_app, it's great
[13:20:01] <jepler> and most mesa stuff runs under uspace
[13:20:41] <andypugh> I have only ever worked in kernel space, i don’t even klnow how to use a debugger
[13:26:25] <cradek> andypugh: build for uspace, halrun -I, in another shell gdb /path/to/rtapi_app `pidof rtapi_app`, at (gdb) run, in hal make it crash, gdb will tell you it crashed, at (gdb) bt
[13:26:56] <cradek> bt = backtrace, it will show you the line of code that crashed, and the calls it took to get there
[13:29:40] <jepler> I updated
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?DebuggingRtapi -- the instructions are a bit different if you want to debug uspace with hardware drivers
[13:31:33] <jepler> Zandypugh: go to the end of the (alphabetical) line
[13:31:53] <cradek> oh right, it's continue, not run
[13:32:46] <Zandypugh> I am beginning to wonder if it is allowable to have two RTAPI_MP_ARRAY_STRING entries
[13:33:41] <Zandypugh> (I am also wondering what the effect is of having a semicolon at the end of the line)
[13:40:39] <jepler> I wrote a component that uses RTAPI_MP_ARRAY_STRING twice
http://pastie.org/10116774 and tested it
http://pastie.org/10116775
[13:40:42] <jepler> it works fine on uspace at some recent ref
[13:42:08] <Zandypugh> OK, must be me then
[13:43:09] <Zandypugh> Though I seemed to get afreeze by having the second one and never referring to it. But then I do have a tendency to mak changes then test them without recopmpiling.
[13:43:55] <jepler> when a quick grep showed that, yes, all existing components had at most one I figured it was worth checking
[13:44:01] <jepler> and of course rtai might behave different than uspace
[13:47:41] <Zandypugh> Well, the docs say that the macros are not available in USERspace, so some work might have been done in Uspace.
[13:48:06] <Zandypugh> But then you would have probably noticed yourself doing that?
[13:50:15] <jepler> I guess so
[13:51:06] <jepler> calling everything that's not "real time" "userspace" is problematic when one of your realtimes is userspace :-/
[13:54:16] <Zandypugh> And “user_comps” is a really badly-named source directory....
[14:03:44] <seb_kuzminsky> Zandypugh: i agree
[14:14:13] <jepler> so what should they be called?
[14:14:22] <jepler> free-running components is the best I came up with in my head
[14:20:45] <seb_kuzminsky> i like that better, because it encapsulates the notion that they run in their own threads, not in one of the realtime threads
[14:38:10] <Zandypugh> I spent a long time thinking that they were a sub-class of components submitted by users rather than developers….
[14:40:10] <Zandypugh> Maybe “threadless_comps”?
[14:40:28] <Zandypugh> Too late to bother about it now, though, I think.
[14:40:41] <seb_kuzminsky> never too late to make things better
[14:40:52] <seb_kuzminsky> too late for 2.7, sure ;-)
[14:41:24] <Zandypugh> jepler: Just to check, does the initialisation of a before-the-;; variable in comp run after extra_setup? It seems to…
[14:42:03] <seb_kuzminsky> initialization of global and static variables happens before any code runs
[14:42:17] <Zandypugh> seb_kuzminsky: in halcompile?
[14:42:19] <jepler> seb_kuzminsky: yes but not relevant
[14:42:38] <jepler> this is stuff in the internal struct used by halcompile
[14:42:45] <seb_kuzminsky> oh
[14:42:55] <Zandypugh> I decided I should explicitly initialise some arrays to be sure, and that seems to be undoing my extra_setup :-)
[14:43:01] <jepler> Zandypugh: yes. are you going to need extra-extra-setup?
[14:43:23] <Zandypugh> No, not a problem. I can do the initialisation in extra_setup
[14:43:40] <Zandypugh> Just checking I wasn’t being silly.
[14:44:11] <jepler> with pins and parameters it has to happen in that order, since extra setup can modify personality
[14:44:30] <jepler> with variables, I probably just put it at the end when I added them
[14:46:55] <Zandypugh> It looks that way. There is a loop iterator for each array.
[14:48:50] <jepler> hm, this is not encouraging. A glib client/server benchmark ported to kdbus saw less than a 50% performance increase from kdbus
[14:49:47] <jepler> sync:
https://lkml.org/lkml/2015/4/24/345 async:
https://lkml.org/lkml/2015/4/27/142
[14:49:55] <jepler> er sync is
https://lkml.org/lkml/2015/4/24/315
[14:51:33] <jepler> and the async client throughput was only around 2% higher by my math
[14:51:38] <jepler> (on dbus)
[14:51:44] <jepler> (on kdbus)
[16:23:39] <jepler> Subject: [PATCHv2 0/3] Enable PREEMPT_RT_FULL on arm64
[16:23:44] <jepler> I really wish I could get my hands on an arm64 board
[17:04:43] <seb_kuzminsky> i wish
[17:04:44] <seb_kuzminsky> ~>
[17:05:31] <seb_kuzminsky> i wish so too :-)
[17:11:42] <jepler> what pcw said about the intel compute stick makes me wonder, can you use a typical sd card connector as generic spi? or is the thing that's connected to it too special-purpose for that?
[17:17:43] <seb_kuzminsky> huh, looks like 3.3V SPI
[17:18:38] <jepler> http://elm-chan.org/docs/mmc/mmc_e.html
[17:18:48] <seb_kuzminsky> i wonder if the spi device is exposed by itself, or if it's somehow incorporated into the block device stack and not accessible
[17:18:49] <jepler> sounds like there are two modes, with a 4-bit mode being default
[17:19:03] <seb_kuzminsky> please sir, can i have another nibble?
[17:20:06] <jepler> http://stackoverflow.com/questions/19281662/implement-sdio-to-interface-spi-device
[17:20:12] <jepler> inconclusive to negative on stackoverflow
[17:22:42] <jepler> still, with an fpga no reason you couldn't implement the device side of sdio
[18:21:24] <seb_kuzminsky> f9 launch in 4 minutes:
http://www.spacex.com/webcast/
[18:28:16] <andypugh> up-goer f9 is going to space today
[18:28:30] <seb_kuzminsky> huh, i wonder if that part was supposed to fall off
[18:28:57] <andypugh> Nobody said “what the hell was that"
[18:28:57] <seb_kuzminsky> it hasnt blown up, so... probably?
[18:34:16] <mozmck> jepler: Linus seems to agree with your math on the kdbus performance: "So really. The people who talk about how kdbus improves performance are just full of sh*t"
http://linux-kernel.2935.n7.nabble.com/GIT-PULL-kdbus-for-4-1-rc1-td1085510i280.html
[18:35:47] <seb_kuzminsky> those silly people, don't they know they need to build everything from source using gentoo in order to get the best performance
[18:36:20] <seb_kuzminsky> i wanna know when the falcon 9 heavy demo launch will be
[18:36:28] <seb_kuzminsky> i may try to go to florida for that...
[18:38:04] <seb_kuzminsky> in November they said "July 1 or so"
[18:38:20] <mozmck> hmm, might be there a while then :)
[19:04:17] <andypugh> I have (approximately) finished my hal-pin sequencer. Comments and attempts to breal it welcome:
http://www.ebay.com/itm/NEW-FENNER-6202280-TRANTORQUE-KEYLESS-1-1-16IN-BORE-BUSHING-D333866-/231421339593?pt=LH_DefaultDomain_0&hash=item35e1c967c9
[19:04:22] <andypugh> No, not that
[19:04:48] <andypugh> (copy-paste between VM and Mac is sometimes strange)
[19:06:06] <andypugh> Good job I was last looking at something blameless really.
[19:06:23] <andypugh> http://www.linuxcnc.org/index.php/english/forum/27-driver-boards/28765-another-qwhat-do-i-needq-thread-vmc-retrofit?start=90#58177
[19:13:00] <jepler> andypugh:
[19:13:01] <jepler> W or r: Set the timeout value
[19:13:04] <jepler> I suspect should say W or w
[19:13:15] <andypugh> I think you are right.
[19:14:21] <andypugh> Can I blame troff for hiding the r inside a //fBr//fR ?
[19:15:14] <jepler> umm if you like
[19:15:14] <jepler> The second
[19:15:14] <jepler> sequence wil use the default 10-second timeout.
[19:15:18] <jepler> "will"
[19:15:42] <andypugh> Maybe I should read the generated manpage :-)
[19:16:26] <jepler> so if I have s0s1 then both the outputs are set within the same period? it's when something else, like a d, f, or t comes into it that there's a delay?
[19:16:32] <jepler> s0d1s1
[19:17:13] <andypugh> The order inside a step is not relevant
[19:17:48] <jepler> oh so whatever d, f, or t is in effect that happens at the :?
[19:17:54] <andypugh> so in that example out-1 and out-2 are set in the same period, then there is a 1 millisecond delay before the next step
[19:18:06] <andypugh> Yes
[19:18:35] <andypugh> (and the manpage says hyphen-delimited when it means colon. I kept changing my mind about which stood out best, spaces being verboten)
[19:18:36] <jepler> is d1000f1 sensible to write?
[19:19:02] <jepler> wait 1 second and then wait for 1 to be false?
[19:19:04] <andypugh> Yes. That step will pause for at least 1 second until in-1 is false
[19:19:25] <jepler> do you know if your users want rising or falling events?
[19:19:49] <andypugh> I don’t know if I even have any users.
[19:19:53] <jepler> ah well
[19:20:10] <jepler> you can't spell up/down or rise/fall with the letters that are left over
[19:20:14] <andypugh> But you can set up a rising event by f0:f1
[19:20:26] <jepler> true
[19:20:37] <andypugh> Well, f0:t0 actually
[19:20:40] <jepler> true
[19:21:44] <jepler> Compiling realtime sequencer.c
[19:21:44] <jepler> sequencer.c:53:5: error: unknown type name ‘u32’
[19:21:44] <jepler> u32 set_pins[32];
[19:21:44] <jepler> ^
[19:22:07] <andypugh> Ah, doesn’t that work any more?
[19:22:32] <andypugh> The code does very much assume 32 bits....
[19:22:35] <jepler> those are linux kernel types
[19:23:02] <jepler> in 2.7 and master, the C99 standard types [u]int32_t are what you should write
[19:23:03] <andypugh> So I didn’t want to use the comp “unsigned”
[19:23:17] <andypugh> OK, I will change that.
[19:23:36] <jepler> not sure if that works on 2.6 and earlier
[19:24:01] <jepler> for rtai
[19:24:56] <andypugh> Well, I don’t think that this comp will be in 2.6 so that probaly doesn’t matter.
[19:25:09] <jepler> pin out bit out-# [32:(personality & 0xF)] = 0 "Sequence outputs";
[19:25:09] <jepler> pin out bit out-#-not [32:(personality & 0xFF)] = 1 "Sequence outputs inverted";
[19:25:21] <jepler> at least one of these is likely to be wrong
[19:25:42] <jepler> the 32 part makes me think maybe they should both be & 0x1f (31)
[19:26:38] <jepler> also see man rtapi_module_param for a description of the MODULE_LICENSE strings liked by the kernel.
[19:26:48] <jepler> their convention, which is confusing, is
[19:26:49] <jepler> "GPL" GNU Public License v2 or later
[19:26:49] <jepler> "GPL v2"
[19:26:49] <jepler> GNU Public License v2
[19:27:13] <jepler> I *think* that "GPL v2+", since it's not a string literally recognized by the kernel, causes a kernel license taint
[19:27:49] <andypugh> FF is OK because there is an 8-shift and a check for > 31
[19:28:16] <andypugh> But F was wrong and I simply hadn’t tested more than 16 pins.
[19:28:44] <jepler> anyway, that wraps it up for my substantive comments.
[19:28:54] <jepler> less substantive and possibly nitpicky comments follow.
[19:29:14] <jepler> you use both 'break' and 'return' to bail out of the case statement
[19:29:22] <jepler> personally, I'd flow all the documentation source to 72 columns or so
[19:29:57] <jepler> (though others think a LF should occur after each logically complete unit of documentation, such as sentence, and to a degree I can get behind that .. I just have trouble practicing it)
[19:30:33] <andypugh> I am (largely) flowing at 80 columns
[19:32:41] <andypugh> But I can do 72. I just don’t like the way that, for example, a twice-indented “rtapi_print_msg(RTAPI_MSG_ERR, ….” is basically line-wrapped before it gets to say anything…
[19:33:25] <jepler> oh it's no big deal
[19:33:54] <andypugh> I was using “break” until I noticed that some were inside loops, and I wanted to exit the comp, not the loop.
[19:34:28] <andypugh> The I switched to return but didn’t go back and change the existing breaks.
[19:35:42] <andypugh> I think that they should all be returns, but I wasn’t sure at the beginning if anything would be happening after the switch.
[19:38:05] <jepler> I notice it has a time of around 350 when idle and 770 when running one sequence. that's lower than stepgen.make-pulses with one stepgen, so it seems fine
[19:38:25] <jepler> particularly since this seems intended for servo-thread activities
[19:38:47] <andypugh> If I made the timeout into a HAL pin it could be an arbitrary-pattern step generator :-)
[19:39:43] <jepler> though there are some peaks/spikes, I can't tell if they're just my machine not being realtime or if they correspond to when the outputs are changing or something
[19:39:54] <andypugh> I was wondering if I should make it base-threadable. The only FP bit is the timeout, and that is already stored as int in the data structure.
[19:40:53] <jepler> seems like not
[19:41:06] <jepler> if so you'd need to change your timeouts to be us or ns
[19:41:06] <andypugh> In fact, I will make it all-int just to save CPU
[19:41:17] <jepler> I think that's a fine idea
[19:41:48] <jepler> afk, hope my feedback was helpful
[19:42:06] <andypugh> nS timeouts would make the W and D “commands” very long
[19:42:31] <jepler> yes they would
[19:42:49] <andypugh> I _could_ modify the parser to understand S, ms, nS
[19:43:10] <jepler> tn1000 vs tu1000 vs tm1000 ?
[19:43:46] <jepler> you might note in the docs that it is (presumably) rounded up to the next multiple of the thread rate
[19:44:23] <andypugh> I was thinking T1000mS but of course I can’t do that because I carelessly used S already
[19:45:10] <andypugh> I will make it default to seconds with modifiers for m/n/u
[19:47:39] <andypugh> You can’t hold many nS in an s32 can you?
[19:48:04] <andypugh> Or, rather, you can but they don’t add up to many seconds
[20:07:11] <jepler> no
[20:08:05] <cradek> Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
[20:08:16] <cradek> maybe this wasn't the best choice for kernel-building
[20:17:17] <andypugh> I have decided to store microseconds and accept that nS timeouts will be innacurate
[20:19:05] <andypugh> (I _did_ think about storing the units-used as a bit-code in the higher-order bits and doing the same for the distinction between a delay and a timeout. And now I have typed that is seems like a better idea. But for tomorrow)
[20:21:56] <skunkworks> cradek: for jesse?
[20:22:53] <jepler> skunkworks: a newer kernel to maybe get support for a certain pci parport, I think
[20:25:46] <skunkworks> ah
[20:25:47] <skunkworks> ok
[20:27:42] <cradek> yeah for this silly card
[20:29:45] <cradek> it's doomed to failure but for some reason I can't resist trying
[20:30:22] <cradek> it'd be nice to know if a simple patch adds support
[20:31:16] <jepler> I was flabbergasted to see from this canonical (ubuntu) patch that their kernel takes 41 minutes to build *on a machine with 56 threads*! He offered a patch to get it down to 36.
https://lkml.org/lkml/2015/4/24/617
[20:31:54] <jepler> crazy thing is, from the numbers he gives, he gets only about 800% CPU utilization, a far cry from the 5400% you'd like to see!
[20:31:57] <skunkworks> trying to get the pluto running again?
[20:32:40] <cradek> jepler: ugh.
[20:33:21] <cradek> skunkworks: yeah, it works fine, but I'd like a newer box running it, and for some reason my heart is set on using a cool tiny machine I got from goodwill
[20:33:34] <cradek> ... with only traditional pci slots and no built-in parallel port
[20:36:30] <jepler> and without rebuilding the electronics to get rid of the pluto, though I think it's unknown if the port doesn't work with pluto, or doesn't work with epp at all
[20:43:07] <cradek> yep exactly
[20:45:51] <Tom_itx> spi port?
[20:46:19] <Tom_itx> i thought one of you had a 7i90 running off spi
[20:46:36] <jepler> Tom_itx: that'd be me
[20:46:53] <Tom_itx> does that work ok?
[20:47:05] <Tom_itx> i recently got a 7i90
[20:47:19] <jepler> yes, though I had to modify the spi kernel driver before it had good realtime performance, and the modifications are going to be different for every linux-supported spi interface
[20:47:21] <Tom_itx> using it with parport right now
[20:47:30] <jepler> but once I worked on the driver, it would run for days at 2kHz
[20:47:38] <jepler> if you're on a PC, stick with epp.
[20:47:45] <Tom_itx> i plan to
[20:47:59] <Tom_itx> i got it to replace a 7i43 i popped
[20:48:10] <jepler> https://github.com/jepler/u3-7i90
[20:49:32] <Tom_itx> too bad spi isn't a standard interface
[20:50:53] <jepler> too bad more ARM boards don't have non-USB ethernet
[20:51:09] <jepler> honestly, having worked on both spi and ethernet during the 2.7 cycle, I'm more excited about ethernet
[20:51:32] <jepler> for one thing, you just don't worry much about signal integrity on a modest-length ethernet cable, but that was a headache with spi
[20:51:47] <jepler> for another, many pci nics turn out to have quite decent performance with preempt-rt
[20:54:54] <mozmck> jepler, I can build the ubuntu kernel to deb packages in less time than that on my 8-core AMD. I think about 25 minutes
[20:56:30] <jepler> mozmck: that sounds more like it
[20:57:19] <mozmck> hmm, make deb-pkg is the kernel way of building debs - not ubuntu
[20:58:20] <mozmck> My dual cpu xeon machine takes about 1 minute more with 16 threads, but they are 2.26 Ghz and the AMD is 4 Ghz
[21:00:10] <mozmck> oh, hmm, the message says he made it "parallelize debug module installation" If I turn on debug it takes about 70 minutes with make deb-pkg on the 16 thread machine.
[21:11:57] <Tom_itx> in 2.7 i can remove the references to watchdog in my configs?
[21:12:33] <Tom_itx> the addf and setp lines..
[21:14:20] <Tom_itx> as well as the probe_parport line
[21:26:55] <jepler> Tom_itx: yes I think so
[21:32:18] <Tom_itx> i know early on there were parameters for the TP, is that still the case in 2.7?
[21:36:05] <seb_kuzminsky> Tom_itx:
http://linuxcnc.org/docs/2.7/html/getting-started/index.html#_updating_your_config
[21:37:30] <Tom_itx> i was looking at that
[21:41:10] <seb_kuzminsky> ok cool
[21:41:19] <seb_kuzminsky> if there's something missing let me know and i'll add it
[21:41:22] <seb_kuzminsky> thanks for testing 2.7 btw
[21:41:29] <Tom_itx> i just didn't see anything on the TP there
[21:41:45] <Tom_itx> i haven't tested yet so don't thank me too much :)
[21:41:57] <seb_kuzminsky> the TP shouldn't need any messing with, so it's not mentioned there
[21:42:03] <seb_kuzminsky> heh
[21:42:08] <Tom_itx> still helping the mrs recooperate from surgery so it may be a couple weeks
[21:42:16] <Tom_itx> ok
[21:42:39] <Tom_itx> not much play time here right now
[21:42:53] <seb_kuzminsky> if you *want* to mess with the TP, there are some [TRAJ] knobs to twiddle:
http://linuxcnc.org/docs/2.7/html/config/ini_config.html#sub:TRAJ-section
[21:43:25] <seb_kuzminsky> best wishes on her speedy recovery
[21:43:39] <Tom_itx> yeah i can't recall what i had in the config but i knew there were a few settings
[21:43:45] <Tom_itx> thanks
[21:47:31] <Tom_itx> yeah i have those in the ini commented out
[21:47:33] <Tom_itx> for now
[21:48:30] <skunksleep> 5 min apart.... Lasting for a minute.
[21:49:00] <Tom_itx> ?
[21:49:08] <Tom_itx> ahh
[21:49:12] <Tom_itx> 2nd one?
[21:49:25] <Tom_itx> you're gonna have a long night
[21:50:28] <seb_kuzminsky> https://www.youtube.com/watch?v=r6inaBWSEdk
[21:50:57] <Tom_itx> seb_kuzminsky, no biggie but the settings explanations should match the default values
[21:51:11] <Tom_itx> or i'm sure somebody along the way will get confoozed
[21:52:02] <Tom_itx> ARC_BLEND_RAMP_FREQ is the only one i see really
[21:56:14] <Tom_itx> hmm i see no reason not to upgrade and try it
[21:56:25] <skunksleep> :)
[21:56:48] <Tom_itx> i can install it but it'll be a bit before i'm able to test it again
[21:57:35] <Tom_itx> btw, congrats skunksleep
[21:57:51] <seb_kuzminsky> yeah congrats! you thought you were low on sleep *before* this!
[21:58:23] <cradek> skunksleep: ooh, hope everything comes out ok
[21:58:38] <seb_kuzminsky> these are the ones i made (a few years ago):
http://highlab.com/family/2012.12.13-2/P1010002.jpg
[22:00:30] <skunksleep> So far so good. Heading to the hospital soon..
[22:09:08] <CaptHindsight> skunksleep: "sleep" since you only dream of sleep now while you're awake?
[22:11:28] <Tom_itx> heh
[22:11:37] <Tom_itx> ok 2.7 updates made
[22:20:38] <skunksleep> seb_kuzminsky: awesome!
