Back
[00:21:51] <jepler> libnml/nml/nml.cc: In static member function 'static void* NML::operator new(size_t)':
[00:21:54] <jepler> libnml/nml/nml.cc:114: error: cast from 'char*' to 'int' loses precision
[00:23:18] <jepler> oh, maybe this is simple
[00:40:43] <fenn> buglet: when upgrading from breezy to dapper rtai-config still has gcc-3.4 as the compiler, but the kernel was made by gcc-4.0 so when you go to compile emc it uses gcc 3.4 instead of 4.0
[00:41:30] <fenn> (and the emc modules dont insert)
[00:43:00] <jepler> are there two /usr/realtime* directories? if so, remove it or specify the right one to configure.
[00:45:48] <fenn> oh i spoke wrong
[00:46:15] <fenn> its not the emc modules that fail to insert its the rtai modules, it tries to insert the ones from /usr/realtime-2.6.12-magma (into a 2.6.15 kernel)
[00:47:20] <fenn> and i was looking at the wrong rtai-config, the 2.6.15 one uses "gcc" which points to gcc-4.0 which is right
[00:47:35] <fenn> (although rtai gives a warning while compiling)
[00:52:39] <jepler> did you re-run configure after you changed kernels?
[00:56:09] <fenn> of course
[00:56:22] <fenn> somehow Makefile.inc gets the wrong realtime directory
[00:56:35] <SWPadnos> I saw that as well
[00:56:36] <fenn> i dont understand how that works at all though
[00:56:37] <jepler> are there two /usr/realtime* directories? if so, remove it or specify the right one to configure.
[00:56:49] <fenn> yes there are two.. how do i specify the right one?
[00:56:51] <jepler> basically the configure process is this: look around until you find something, then assume it's right
[00:56:55] <jepler> ./configure --help
[00:56:58] <SWPadnos> it's perfectly valid to have multiple realtime directories though, especially for a developer
[00:57:27] <SWPadnos> it should be possible (though I don't know how) to have configure prefer any RT dir that has the same version as the currently running kernel
[00:57:36] <SWPadnos> rather than the first one found
[00:59:50] <fenn> SWPadnos: on some systems its /usr/realtime and on others its /usr/realtime-2.6.xxx
[00:59:56] <SWPadnos> fenn, you should be able to fix the problem by removing the older RTAI kernel and modules with synaptic
[01:00:04] <fenn> so a simple /usr/realtime-`uname -r` wouldnt work all the time
[01:00:18] <fenn> right
[01:00:26] <SWPadnos> it should still look for all of them, but if one matches .*'uname -r'.*, that would be preferable
[01:00:44] <cradek> I bet it's wise to remove emc, rtai, etc before upgrading
[01:01:18] <SWPadnos> if the RTAI packages were marked as replacements to older version, that would also fix it
[01:01:32] <cradek> true
[01:01:33] <SWPadnos> alex pointed out that having multiple RT dirs is valid though
[01:01:34] <cradek> same with the kernel
[01:01:37] <SWPadnos> right
[01:01:48] <fenn> alex asked me to test upgrading so that's why i'm reporting my problems
[01:02:16] <SWPadnos> well, it looks like that one wasn't just me then ;)
[01:02:37] <fenn> yeah, if it does it on every system we should probably mention it eh :)
[01:02:51] <SWPadnos> I guess so :)
[01:08:26] <fenn> also, /usr/rtlib appears to point to /usr/rtlib so it never gets deleted
[01:09:36] <fenn> its not a problem it just seemed weird
[01:31:04] <fenn> SWPadnos: have you succeeded in compiling emc2 on an upgraded dapper?
[01:32:08] <fenn> am still getting invalid module format errors (this time from rtlib/rtapi.ko)
[01:46:02] <SWPadnos> I did succeed, by removing the older RTAI kernel and module packages with Synaptic
[08:36:41] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:00:55] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:51:53] <Roguish> SWPadnos: a little question off topic? can a bad power supply cause a computer to 'auto' reboot?
[14:52:01] <SWPadnos> yes
[14:52:25] <SWPadnos> it can also cause what looks like rendom program faults or other weird behavior
[14:52:29] <SWPadnos> random
[14:52:38] <SWPadnos> http://www.pcpowercooling.com/
[14:52:59] <Roguish> that's what i have. i thought it might be my kvm, but it's started again.
[14:53:12] <SWPadnos> interesting. how old is the power supply?
[14:53:20] <Roguish> 1/5 year
[14:53:25] <Roguish> 1.5 year
[14:53:44] <SWPadnos> very strange. I've got a supply from that's close to 15 years old
[14:53:52] <Roguish> a very cheap case. so, probably not a quality PS
[14:54:11] <SWPadnos> then you don't have a PC Power & Colling supply in it ;)
[14:54:18] <SWPadnos> cooling, that is
[14:55:34] <Roguish> i've eliminated all 'program' problems, so it has to be hardware. ps, motherboard, or cpu?
[14:55:46] <SWPadnos> run memtest for a day or two
[14:57:03] <Roguish> day or 2? that long?
[14:57:09] <SWPadnos> yep
[14:57:40] <cradek> often problems will show up quickly, though
[14:58:17] <SWPadnos> right - if you';re lucky, you see problems in test 3 or 4, but sometimes things go south after the machine warms up
[14:58:39] <Roguish> 1 gig, in 2 pieces. how about switching the pieces in the slots?
[14:58:49] <SWPadnos> run memtest first
[14:59:02] <cradek> yes, and if memtest fails, take one out at a time and rerun
[14:59:13] <SWPadnos> don't change anything, run memtest, change something if you see an error, rerun test ...
[14:59:22] <SWPadnos> bad to change things before running diagnostic code
[14:59:32] <Roguish> ok. machine is aloways on so i dont' think it's a heat problem.
[14:59:57] <SWPadnos> then you may be able to get away with one or two full passes
[15:01:44] <Roguish> now i gotta find my memtest flopppy
[15:02:04] <SWPadnos> it's probably faster to download it again ;)
[15:02:19] <SWPadnos> do you have an ubuntu CD?
[15:02:32] <Roguish> yes
[15:02:45] <SWPadnos> if you can boot with that, one of the options is memtest
[15:06:55] <Roguish> found it!!!!!!
[15:07:31] <Roguish> also watching the tour de france. last few kilometers of the day's race.
[15:07:50] <SWPadnos> they still had ehough riders? ;)
[15:07:52] <SWPadnos> enough
[15:07:58] <Roguish> oh yeah.
[15:08:41] <SWPadnos> what kind of MB is this?
[15:08:51] <Roguish> intel
[15:09:06] <SWPadnos> in terms of memory - single channel, dual channel, etc
[15:09:10] <Roguish> D865PERL
[15:09:19] <Roguish> dual i believe.
[15:09:35] <Roguish> just booted again. and started memtest.
[15:11:00] <Roguish> i have Memtest86, version 1.65 (fairly new)
[15:11:25] <SWPadnos> do you mean Memtest86+ ?
[15:11:33] <SWPadnos> Memtest86 is at rev 3.2
[15:14:13] <Roguish> thanks, just got it.
[15:15:50] <Roguish> hey, what is the 'minimum' cpu for a emc2? to really run good.
[15:16:19] <SWPadnos> depends on the hardware you have, and how you define "good" for a particular machine ;)
[15:16:39] <SWPadnos> I have a celeron 500 that does just fine with either the Mesa card or a USC from Jon Elson
[15:16:44] <Roguish> my test unit is on an old dell p2, 400. it's running 1 servo ok, but not 2.
[15:17:00] <SWPadnos> it can also do software step generation at ~30 KSteps/sec
[15:17:17] <SWPadnos> though I've never run motors with it, and it's probably jittery at that speed
[15:18:02] <Roguish> i have the m5i20 going. using the mesa 7i33 to get +-10 from the pwm. yaskawa drives and matching motors.
[15:18:03] <SWPadnos> servos with "real" servo cards, or geckos (step pulses)
[15:19:22] <Roguish> with number of axes = 1, the drive and motor are ok. with axes=2, the motors are pretty unstable.
[15:19:55] <SWPadnos> strange.
[15:20:13] <SWPadnos> I'd try the same motor hardware on a faster machine, and if it works, then the P2 is too slow ;)
[15:21:41] <Roguish> that's what i thought. i don't have a faster test machine. probably will pick up a motherboard/cpu combo at Fry's, w/ mem. and drop it in the same case.
[15:22:05] <SWPadnos> anything will do, such as the machine with the memory issue (once it's fixed)
[15:22:33] <Roguish> any ubuntu preferences: intel or amd?
[15:22:48] <SWPadnos> I tend to prefer AMD, but it has nothing to do with ubuntu
[15:23:05] <Roguish> is it the 'wintel' cartel?
[15:23:25] <SWPadnos> partly, but also because the price/performance curve tends to favor AMD
[15:26:35] <Roguish> hey. the yaskawa drive takes a +24v for it's enable and alarm control system. the 5i20 is TTL (right?) i've been bypassing the enable output of the 5i20, but i don't want to. what's the best way?
[15:27:04] <SWPadnos> err - I don't know ;)
[15:27:13] <jepler> a transistor or optocoupler?
[15:28:04] <Roguish> i was thinking opto22, but they're a bit pricey. is there a simple opto circiut?
[15:29:24] <Roguish> i need to order a couple fets from arrow, so i couild get some opto isolator chips too, just don't know what to get.
[15:31:45] <jepler> there are small 4-pin "DIP" optocouplers which might be appropriate and are inexpensive
[15:32:27] <Roguish> gotta name and number?
[15:32:50] <jepler> nope, but I can crack my mouser catalog to look
[15:35:04] <jepler> the single-transistor inverts the signal at the same time it shifts the level. As shown, the optocoupler version inverts too (I think, anyway)
http://emergent.unpy.net/files/sandbox/level-shifter.png
[15:36:09] <Roguish> yeah, i like the isolated one in your picture.
[15:37:18] <jepler> I think if you hook up the input signal where GND is, and VCC where the input signal is, the optocoupler becomes noninverting (current flows through the LED when the input is low, and when the LED lights the output is pulled to GND)
[15:40:02] <jepler> one of the optocouplers on this catalog page might be appropriate.
http://www.mouser.com/catalog/626/86.pdf
[15:41:39] <jepler> http://www.mouser.com/index.cfm?&handler=data.listcategory&D=859-LTV-851&terms=859-LTV-851&Ntt=*859LTV851*&N=0&crc=true
[15:42:58] <jepler> one of the optocouplers on this catalog page might be appropriate.
http://www.mouser.com/catalog/626/86.pdf
[15:43:01] <jepler> http://www.mouser.com/index.cfm?&handler=data.listcategory&D=859-LTV-851&terms=859-LTV-851&Ntt=*859LTV851*&N=0&crc=true
[15:45:59] <Roguish> got bumped off. could you put up your circuit picture link again?
[15:52:55] <jepler> http://emergent.unpy.net/files/sandbox/level-shifter.png
[16:09:40] <Roguish> thanks.
