Back
[00:39:55] <jepler> JT-Hardinge: master, please.
[00:40:40] <jepler> skunkworks: I have no idea, it was the first *.comp file I ran across
[00:41:56] <jepler> andypugh: it'll probably lead to simpler code if you don't go to the trouble of separating the hal and non-hal items. I'd do it the simple way at first, and revise it if that turns out to be warranted.
[00:47:46] <jepler> fwiw, comp also mixes hal items and non-hal items in a single structure, and hal_malloc's the whole thing
[02:04:54] <skunkworks> weird... what was in it?
[02:05:22] <jepler> skunkworks: looks like something to do with gear change
[02:05:32] <skunkworks> huh - cool
[02:08:16] <skunkworks> did you see my latest version? spindle lock is added -
http://www.youtube.com/watch?v=KplU8hkI0AQ
[02:08:26] <skunkworks> emc is awesome
[02:09:48] <jepler> very nice.
[07:09:42] <CIA-2> EMC: 03cmorley 07v2.4_branch * rb2f01c3f2730 10/src/emc/usr_intf/pncconf/pncconf.py: fix external jogging buttons option on lathe configs
[16:09:30] <ries_> ries_ is now known as ries
[18:03:24] <andypugh> Is the HAL shared memory the same size as the memlock_size? Or are they unrelated things?
[18:05:33] <cradek> I think they are related - I think the hal block has to be locked
[18:05:41] <jepler> andypugh: they are related. all real-time shared memory has to be less than the memlock limit. other examples of real-time shared memory users are halscope, halsampler, and halstreamer
[18:06:20] <andypugh> I guess the real question is: How much trouble should I go to to move a potential 1k of data out of shared memory into normal memory.
[18:06:28] <SWPadnos> about none
[18:06:38] <cradek> yeah, I think 0 is the right answer here
[18:06:45] <SWPadnos> the memlock size is in the range of 20M
[18:07:17] <andypugh> Good :-) that means that my data structure can stay logical.
[18:08:05] <andypugh> Though I have just noticed that half of it will be used to set up the TRAM, and then never accessed again.
[18:15:40] <jepler> I wouldn't worry too much about 1kB of shared memory usage
[18:18:45] <jepler> that said, maybe we should have an API to allocate real-time-accessible memory that is not shared and does not come out of the HAL shared memory area. We could also make it free automatically, unlike kmalloc.. the documentation would read something like this:
http://emergent.unpythonic.net/files/sandbox/rtapi_malloc.3rtapi.html
[18:21:50] <andypugh> What is the situation with conventional variables in RT code? Are they freed on function exit, or not at all?
[18:22:44] <jepler> you mean variables like the 'int x' in 'int f() { int x; x=3+3; return x; }'
[18:22:51] <jepler> ?
[18:22:58] <andypugh> I am guessing that rtapi_malloc would be for dynamically allocated arrays and the like?
[18:23:07] <andypugh> Indeed.
[18:24:08] <andypugh> But also variables inside structs which are "inside" the hotmot2_t struct too.
[18:24:10] <jepler> space for x is allocated on the stack at the beginning of the call to f, and then that space on the stack is freed when f returns. The total amount of stack space is also limited--I think it might be as little as 4kB
[18:24:59] <jepler> if x was a struct instead of an int, it would be the same -- stack space allocated at the start of the call to f, and freed at the return from f
[18:25:47] <NTU> hey guys! I just successfully completed my HOWTO on making your own EMC + RTAI Live CD image on Arch Linux. It works now and has been tested:
http://neo-technical.wikispaces.com/livecd
[18:26:00] <jepler> NTU: cool
[18:26:17] <NTU> I also updated the EMC package for Arch and integrated it into GNOME instead of being forced to launch it via terminal
[18:26:48] <jepler> feel free to add a link to it from our wiki--maybe on the Installing EMC2 page.
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2
[18:27:17] <NTU> I don't know how to update wikis via svn or cvs or anything like that. Isn't that how its set up?
[18:28:11] <jepler> no, you edit the wiki through your web browser. to get an "edit text of this page" link at the bottom of each wiki page, just follow the steps from here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps
[18:28:41] <psha> NTU: 'link at the bottom' exists only on wiki pages with 'cgi-bin' in URL :)
[18:30:02] <andypugh> This is probably a hugely complicated subject but: The main hostmot2 driver kmallocs "hm2" which is a hostmot2_t struct. A pointer to that structure is passed around between every part of the hostmot2 driver tree. It mainly "contains" a bunch of pointers to all the other driver stuff. I guess that everything pointed to by hm2 is static for the life of hm2? Or do I need to kmalloc or declare as static any variables I wa
[18:30:03] <andypugh> be persistent?
[18:34:17] <jepler> andypugh: the short answer is "yes". For instance code like this is bad, because a pointer to a local variable is passed around after the function has exited and the local variable doesn't exist anymore: void f(struct st *data) { int i; data->foo = &i; }
[18:34:52] <jepler> after f returns, a statement like *(data->foo) = 3; is bad code, because the thing it points at (i inside the function f) doesn't exist anymore.
[18:38:16] <andypugh> I don't think there is any of that going on in the hostmot code (not even the bits I have written). But I will bear it in mind.
[18:38:48] <jepler> NTU: this seems crazy and I don't know why it would be necessary:
[18:38:48] <jepler> -CXXFLAGS := $(INCLUDE) $(OPT) $(DEBUG) -DULAPI $(BITOPS_DEFINE)
[18:38:52] <jepler> +CXXFLAGS := $(INCLUDE) -O0 $(DEBUG) -DULAPI $(BITOPS_DEFINE)
[18:39:17] <NTU> seg fault..
[18:39:21] <NTU> trust me
[18:40:37] <jepler> I doubt it's the right solution..
[18:41:10] <andypugh> The web page does go to some lengths to disavow any claims of elegance :-)
[18:41:18] <jepler> do you have any way to test any of the drivers that are modified by this? sed -i 's/pci_find_device/pci_get_device/g' *.c
[18:42:49] <NTU> like do i have a machine that i use right now to test it?
[18:43:19] <jepler> as in, do you have any of those cards so you can test that the change doesn't break the driver
[18:44:32] <NTU> i personally have no motion control cards, i do software stuff. my dad (L84Supper) is the one to ask.
[18:44:57] <jepler> from what I can read about pci_get_device vs pci_find_device, this one has a chance of being right:
[18:45:01] <jepler> - while((i < MAX_DEVICES) && ((pDev = pci_find_device(MOTENC_VENDOR_ID, MOTENC_DEVICE_ID, pDev)) != NULL)){
[18:45:04] <jepler> + while((i < MAX_DEVICES) && ((pDev = pci_get_device(MOTENC_VENDOR_ID, MOTENC_DEVICE_ID, pDev)) != NULL)){
[18:45:30] <jepler> the other two smell wrong, because there's nothing that decreases the reference count of the returned device
[18:47:33] <NTU> hmm
[18:48:24] <jepler> see
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2010-06-20.txt around 22:12 or so
[18:49:18] <jepler> actually, on reflection even the motenc code is wrong in the unlikely event that you find a machine where you can install more than MAX_DEVICES of them!
[18:49:51] <NTU> ok.
[18:50:21] <NTU> well.. i could do an ugly hack to the kernel to bring back the pci_find_device API but it wont be pretty
[18:50:29] <NTU> and i might break something else
[18:50:34] <NTU> im nota super C programmer.
[18:50:49] <cradek> for a while there was a kernel option. is it gone now?
[18:50:54] <NTU> yes
[18:50:55] <jepler> cradek: welcome to the future
[18:51:05] <jepler> 2010-06-20 07:26:19 <madsci44> i guess in linux kernel 2.6.34 and beyond there is no more CONFIG_PCI_LEGACY and hence no more pci_find_device
[18:51:09] <cradek> the future is inevitable
[18:51:50] <jepler> I'm all for fixing this, I'm just not sure about the details and hate to mess with drivers I can't even test :-/
[18:52:06] <cradek> yuck
[18:54:21] <andypugh> There was somebody on here with a Motenc card a while back. I seem to recall doing something with the source code and asking him to see if it worked. On reflection I don't think he ever did, so I suppose that makes him a bad choice to check this, too.
[18:55:28] <jepler> and motenc is the common card
[18:55:37] <jepler> I don't know the last time I actually heard of somebody with a vti or opto_ac5
[18:55:42] <jepler> s/common/"common"
[18:58:45] <andypugh> Odd how things slip your mind. I added an encoder-velocity pin to the motenc driver, sent the patch to Don Stanley, asked Motenc for a card for testing, then totally forgot about it for 6 months.
[18:59:49] <NTU> jepler: regarding the flags, I could test -O2 out
[19:00:16] <NTU> -O0... would it effect performance much?
[19:01:23] <jepler> I missed out on what the original problem was
[19:01:34] <NTU> sincos failed.
[19:01:46] <NTU> because the make install DESTDIR wasnt /usr
[19:03:28] <NTU> ./configure --prefix=/usr; make; sudo make install works fine but the PKGBUILD and EMC didnt mix
[19:06:36] <jepler> does the configure result for sincos and/or __sincos change when you specifiy a different --prefix?
[19:07:05] <tom3p> part
[19:07:26] <NTU> no idea.. let me get my EMC build scripts set up
[19:07:39] <jepler> I get this regardless of --prefix (I tried no prefix, --prefix=/usr, and --prefix=/left/field)
[19:07:42] <jepler> checking for sincos... yes
[19:07:44] <jepler> checking for __sincos... no
[19:07:56] <NTU> right i know what youre talking about
[19:08:21] <NTU> and no its not prefix that does it
[19:08:35] <NTU> its the make install DESTDIR=${pkgdir} that does
[19:08:55] <NTU> then you run pacman -Uf *.xz to install the .xz package, then it wont start
[19:09:04] <NTU> i got backtrace before via gdb.
[19:09:10] <NTU> want me to get you it?
[19:09:31] <jepler> is it the one that shows sincos recursively calling sincos?
[19:09:45] <NTU> i dont know i forget its been awhile
[19:11:17] <jepler> hm
[19:11:28] <NTU> recompiling with stock flags..
[19:11:34] <jepler> I don't see what DESTDIR's got to do with it .. fwiw, we use DESTDIR when building the debian packages too
[19:11:37] <jepler> (cd src; export DESTDIR=`pwd`/../debian/tmp; $(MAKE) $@)
[19:12:12] <NTU> yeah its very strange
[19:13:50] <NTU> yup its broken :)
[19:15:17] <NTU> trying to find the coredump now
[19:17:58] <NTU> http://pastebin.ca/1966087
[19:18:10] <NTU> backtrace
[19:18:25] <jepler> at the configure step, what did 'checking for sincos' and 'checking for __sincos' result in?
[19:18:58] <NTU> checking for sincos... no checking for __sincos... no
[19:20:03] <jepler> OK.
[19:20:45] <jepler> sincos is a gnu extension to the C standard library
[19:20:52] <jepler> for whatever reason, configure thinks it's not available on your system
[19:21:09] <jepler> so it includes the function in src/libnml/posemath/sincos.c, which implements sincos in terms of sin() and cos()
[19:21:45] <jepler> unfortunately, it appears that your optimizer believes your system does have sincos, and furthermore it is able to optimize the body of that function into a single call to sincos
[19:22:00] <jepler> .. that makes sincos into a function that simply calls itself recursively!
[19:22:10] <NTU> ah
[19:23:27] <jepler> you might try adding -std=gnu99 to CFLAGS and not change $(OPT) .. see if that changes the detection status of sincos
[19:23:41] <jepler> otherwise, let's look next at the config.log by where it's trying to detect sincos
[19:26:47] <NTU> still both no
[19:29:41] <NTU> http://pastebin.ca/1966106
[19:29:45] <NTU> enitre log
[19:29:53] <NTU> conftest.c:(.text+0x7): undefined reference to `__sincos'
[19:30:27] <jepler> is your system a glibc system, or something else like uclibc?
[19:30:39] <NTU> glibc
[19:31:59] <NTU> http://repos.archlinux.org/wsvn/packages/glibc/repos/core-i686/
[19:32:11] <jepler> does libm on your system really not have sincos? something like c$ readelf -s /usr/lib/libm.so | grep sincos
[19:32:18] <jepler> .. shows 3 lines of output on an ubuntu system
[19:32:29] <jepler> .. for the double, float, and long double variants of sincos
[19:32:41] <NTU> 55: 00011c40 58 FUNC WEAK DEFAULT 12 sincosf@@GLIBC_2.1
[19:32:41] <NTU> 59: 00019480 58 FUNC WEAK DEFAULT 12 sincosl@@GLIBC_2.1
[19:32:41] <NTU> 204: 0000aca0 58 FUNC WEAK DEFAULT 12 sincos@@GLIBC_2.1
[19:34:13] <jepler> > #
[19:34:14] <jepler> configure:5944: cc -o conftest -march=i686 -mtune=generic -O2 -pipe -Wl,--hash-style=gnu -Wl,--as-needed -lm conftest.c >&5
[19:34:41] <NTU> i didnt touch the makefile other than the std thing
[19:34:42] <jepler> weird, it has -lm *before* the source file
[19:34:49] <jepler> where is -Wl,--as-needed coming from?
[19:35:12] <NTU> oh i think i have -g3 set
[19:35:21] <SWPadnos> is it strange that those three functions are not the same size on my machine (but are for NTU)?
[19:35:56] <NTU> arch uses latest version of glibc maybe ubuntu uses legacy version ;)
[19:36:07] <SWPadnos> nope, in fact I've got 2.2.1 here
[19:36:11] <SWPadnos> err, 2.2.5
[19:36:19] <NTU> ??
[19:36:45] <NTU> thats from 02
[19:36:56] <NTU> mine is 2.12.1
[19:37:27] <SWPadnos> hmmm
[19:38:04] <NTU> lots changed in 7 years
[19:38:05] <SWPadnos> well, the readelf output says GLIBC_2.2.5 where yours says 2.1
[19:38:30] <jepler> --as-needed together with the questionable order of arguments on the link line are what makes sincos not be detected.
http://pastebin.ca/1966117
[19:38:53] <jepler> (that's on an ubuntu 10 system)
[19:41:39] <NTU> -Os is always flaky
[19:41:47] <jepler> maybe try with this patch, which gets -lm to the right part of the commandline in configure:
http://emergent.unpy.net/files/sandbox/0001-config-try-to-fix-as-needed-vs-sincos-build-problem.patch
[19:42:13] <NTU> id get kernel panic with RTAI on a 64 bit system if i set -Os on the kernel (optimize for yes=y)
[19:42:15] <NTU> 8size
[19:42:20] <NTU> typoes.. ugh
[19:48:03] <NTU> still no sincos
[19:50:14] <NTU> the cflags work fine though
[19:51:15] <NTU> the only part im concerned about is the pci_get/pci_find
[19:51:39] <NTU> i might be able to revive the old API though
[19:54:08] <NTU> we could just wait and see how it goes, then if it doesnt work, whoever has that controller can just post some debug info.
[19:54:41] <jepler> did you regenerate configure after applying that patch?
[19:55:00] <NTU> yep wiped the whole srcdir clean
[19:55:08] <jepler> pastebin the configure log again?
[19:56:45] <NTU> configure:5955: cc -o conftest -march=i686 -mtune=generic -O2 -pipe -Wl,--hash-style=gnu -Wl,--as-needed -lm conftest.c >&5
[19:57:52] <NTU> http://pastebin.ca/1966151
[19:58:25] <jepler> configure:5977: gcc -o conftest -g -O2 conftest.c -lm >&5
[19:58:33] <jepler> on my system that change moved -lm after conftest.c
[19:58:34] <jepler> weird
[20:01:14] <NTU> since you seem to know more about this stuff than i, you can try building the disc yourself in a vm or something and try more stuff out
[20:01:20] <NTU> im a bit over-worked atm
[20:01:30] <jepler> I'm in the same club
[20:02:40] <NTU> im just glad i got most of it done, latency-test works, emc launches
[20:34:29] <micges> cradek: last commit to master is for G10 L11 only?
[20:38:35] <cradek> int to_fixture = block->l_number == 11;
[20:38:40] <cradek> if ( to_fixture
[20:38:45] <cradek> if you mean this, then yes
[20:55:47] <skunkworks> http://www.youtube.com/watch?v=2j2WgH9Y81k
[20:55:53] <skunkworks> read the discription :)
[20:58:01] <cradek> wow that's a tiny end mill
[20:59:28] <micges> cradek: sorry didn't read diff carefully
[21:00:56] <cradek> no problem!
[21:16:50] <morficcell> morficcell is now known as morficmobile
[22:12:08] <andypugh> I wonder: can the hm2 TRAM functions read/write to HAL shared memory, or do they need to map to kernel memory?
[22:12:58] <SWPadnos> they're accessed from a kernel module, which can access any memory in the system
[22:13:15] <andypugh> So it doesn't matte then?
[22:13:24] <SWPadnos> don't you pass a pointer to where you want the data transferred to/from?
[22:13:30] <andypugh> Yes
[22:13:41] <SWPadnos> ok, then that pointer can point into HAL memory
[22:13:53] <SWPadnos> I don't know if that's a bad idea for some reason :)
[22:14:09] <andypugh> All the other modules register kmalloc-ed memory with TRAM
[22:14:29] <SWPadnos> there may or may not be a good reason for that
[22:14:42] <SWPadnos> it may be an attempt to not clutter up HAL memory ...
[22:14:45] <andypugh> I guess I should keep it consistent
[22:15:07] <andypugh> (I am halfway through restructuring now anyway)
[23:18:09] <andypugh> The 8i20 has something like 20 status/fault bits. Should I break them out into named bit pins, or just leave them as hex ints?
[23:46:27] <andypugh> This is a bit of a puzzle:
[23:47:15] <andypugh> How to take a hal_float_t with a range of +/-1, convert to a signed 16 bit int, and load that into the MSW of a U32..