Back
[00:00:52] <jmkasunich> we're getting pizza ;-)
[00:16:31] <cradek> new emc2, emc2-dev, axis (1.2a2) packages in the breezy repository
[01:01:00] <SWPadnos> ok - back
[01:25:50] <SWPadnos> well, on my laptop with BDI 4.2x (kernel 2.6.9-adeos), I can run BDI at 24 uS PERIOD, and there's no slowdown in the GUI.
[01:26:31] <SWPadnos> Running EMC2 with stepgen at BASE_PERIOD=50 uS, the machine is basically unusable, though it doesn't quite crash
[01:27:17] <SWPadnos> I can see individual lines of text in konsole being drawn in parts, desktop icon lables are drawn as the shadow first then the text, etc.
[01:27:42] <SWPadnos> the CPU is a PIII 1 GHz, 512M RAM
[01:27:58] <SWPadnos> video is a Rage mobility. I'm not sure if it's shared memory or not
[01:33:17] <SWPadnos> looking at the tmax times (which are reported on this BDI, luckily):
[01:33:30] <SWPadnos> parport.0.read.tmax = 16762
[01:33:40] <SWPadnos> parport.0.write.tmax = 19276
[01:34:04] <SWPadnos> stepgen.make-pulses.tmax = 15086
[01:34:25] <SWPadnos> and that's over 50 uS total, so there's at least one problem
[01:34:36] <SWPadnos> those parport numbers look exceedingly high to me
[01:39:50] <SWPadnos> I'll be around if you have any questions. doing misc chores though, so I may not respond immediately
[01:46:54] <SWPadnos> ok, now this is just wacky. after a while running (but not actually executing any programs or anything), parport.0.write.tmax is now 7028277 (!)
[01:48:26] <SWPadnos> either this kernel isn't providing correct times, something is really screwed up on this computer (possible, it's a laptop), or there are gremlins in the parport code
[02:03:10] <jmkasunich> wow
[02:04:50] <jmkasunich> running stepper-inch here tends to bog things down a bit too
[02:06:13] <SWPadnos> I changed hal_parport.c so that parport.write is a null function (only sets port=arg, does no outb), and tmax is still 14248
[02:06:42] <SWPadnos> this time, the nasty function is motion-command-handler.tmax, at 6996430
[02:07:09] <jmkasunich> that implies that something is interrupting the RT code that takes about 7mS
[02:07:24] <SWPadnos> again, this is a laptop, so some weird things may be going on, but the BDI kernel doesn't have apm / acpi support, AFAIK
[02:07:26] <SWPadnos> yes it does
[02:10:26] <jmkasunich> I'm getting 17uS for parport read, 20 for write
[02:10:32] <jmkasunich> (tmax)
[02:10:43] <jmkasunich> 13uS for makepulses
[02:10:48] <SWPadnos> that's what I get, for the most part
[02:10:55] <SWPadnos> a couple microseconds more, maybe
[02:11:05] <SWPadnos> but that's a long time for two outb instructions
[02:13:06] <jmkasunich> scoping the .timee params to see typicals
[02:14:12] <jmkasunich> between 7.5 and 8uS most of the time
[02:14:36] <SWPadnos> ok - there's definitely something wrong with the laptop. now several of the tmax params are 7-ish ms
[02:14:54] <jmkasunich> something in the background
[02:15:23] <SWPadnos> yeah, but what can be "background" ro RT tasks?
[02:15:26] <SWPadnos> to
[02:15:34] <jmkasunich> an interrupt
[02:15:49] <jmkasunich> one that adeos/rtai isn't catching somehow
[02:15:50] <SWPadnos> or shared video, on that machine (possibly)
[02:16:01] <jmkasunich> not for 7ms
[02:16:10] <SWPadnos> nope
[02:18:10] <jmkasunich> my best estimate of "typical" base thread execution is 40uS when the scope is sampleing in that thread
[02:18:33] <cradek> my laptop would crap out (missed realtime deadlines) whenever the processor fan turned on or off
[02:18:44] <cradek> no bios settings or kernel settings would fix it
[02:19:01] <cradek> I still say laptops are useless for emc, even though some people seem to be able to use them
[02:19:28] <jmkasunich> some laptops are useless
[02:19:38] <jmkasunich> with no reliable way of knowing which ones
[02:19:40] <SWPadnos> it's an interesting data point though, that the BDI emc works perfectly at 24 uS, and emc2 doesn't work at 50 uS
[02:19:51] <SWPadnos> on the same machine, same kernel, same boot
[02:19:54] <jmkasunich> well, hal does add some overhead
[02:20:10] <cradek> we've long known that emc2 can't run as tight as emc1
[02:20:14] <SWPadnos> yes, but I hope it isn't that much
[02:20:16] <cradek> I didn't know it was a factor of 2 though
[02:20:16] <jmkasunich> it seems worse lately
[02:20:29] <SWPadnos> I think it is worse lately, I just can't pinpoint when it started
[02:21:16] <SWPadnos> it's not an ADEOS / kernel version thing, because I'm seeing this on an older BDI (middle of last year)
[02:21:53] <cradek> if we weren't in kernel space, we could profile
[02:22:06] <cradek> I wonder if we could come up with something that would give a similar kind of information
[02:22:14] <SWPadnos> tmax ;)
[02:22:16] <jmkasunich> and if the profiling code didn't add time
[02:22:24] <jmkasunich> tmax and time
[02:22:28] <SWPadnos> you can measure how much time it adds
[02:23:24] <jmkasunich> jeez, 51uS for ddt !?!
[02:23:51] <SWPadnos> hmmm - on my "normal" emc machine, I'm now getting an error that librs274.so cannot be opened (with axis, after full make, and axis install)
[02:24:13] <cradek> rip or install?
[02:24:24] <SWPadnos> methinks something in RTAI / RTAPI has changed, and task switching is slightly fubar'ed
[02:24:27] <SWPadnos> RIP
[02:24:50] <jmkasunich> I'm gonna take a look at just running stepgen alone
[02:24:57] <jmkasunich> parport alone, etc
[02:26:27] <SWPadnos> I'm recompiling, just to be sure that I did all the right stuff (--enable-run-in-place ... )
[02:26:39] <cradek> SWPadnos: in your axis directory, sudo rm -r build, then env EMCROOT=.... python setup.py build, look for this line:
[02:26:42] <cradek> g++ -pthread -shared build/temp.linux-i686-2.4/extensions/gcodemodule.o -L/usr/src/emc2/lib -lrs274 -lnml -lm -lstdc++ -o build/lib.linux-i686-2.4/gcode.so -Wl,-rpath,/usr/src/emc2/lib
[02:27:00] <cradek> the -rpath should be your emc2's lib directory
[02:27:07] <SWPadnos> ok - in a couple of minutes, once the emc2 build finishes
[02:29:23] <jmkasunich> 5uS typical for sum2
[02:29:32] <jmkasunich> all it does is add a couple floats
[02:29:45] <jmkasunich> I have a hunch
[02:29:50] <cradek> in my config I have 9 ddt
[02:29:54] <cradek> 3 for each axis
[02:30:09] <jmkasunich> but they're in the 1mS thread, so not so noticable
[02:30:09] <cradek> or is it 2?
[02:30:15] <cradek> ah
[02:34:36] <SWPadnos> yes, the rpath looks correct
[02:34:57] <cradek> ldd /usr/lib/python2.4/site-packages/gcode.so
[02:35:03] <cradek> python2.3?
[02:35:06] <cradek> wherever it is
[02:35:08] <SWPadnos> argh
[02:35:09] <jmkasunich> where do the kernel headers live?
[02:35:29] <SWPadnos> ok, the configure option is "--enable-run-in-place", right?
[02:35:34] <jmkasunich> yes
[02:35:34] <cradek> yes
[02:35:55] <jmkasunich> the final messages from configure will reflect that if it was recognized
[02:35:57] <cradek> jmkasunich: are you asking me?
[02:36:04] <jmkasunich> asking anyone who knows
[02:36:14] <SWPadnos> well, now I get an error with the emc script: /usr/local/share/emc/tcl/bin/pickconfig.tcl: No such file or directory
[02:36:18] <cradek> /usr/src/linux-headers-[version]
[02:36:30] <jmkasunich> thanks
[02:36:40] <cradek> SWPadnos: look in Makefile.inc and check RUN_IN_PLACE
[02:36:47] <cradek> I bet you didn't get it set
[02:37:15] <SWPadnos> true enough
[02:37:26] <cradek> type caarrreeeffullllly
[02:37:40] <SWPadnos> aaarrrrgggghhhh!!!
[02:37:47] <SWPadnos> run-in=place
[02:37:55] <SWPadnos> bastards
[02:38:09] <SWPadnos> whoever put two keys next to each other should be shot
[02:39:26] <SWPadnos> ok, now I'm back to this error:
[02:39:38] <SWPadnos> /Project/emc2/bin/milltask: error while loading shared libraries: librs274.so: cannot open sharedobject file: No such file or directory
[02:39:56] <cradek> are you sure your cvs is updated?
[02:40:03] <cradek> a devel checkout, not anon?
[02:40:10] <SWPadnos> absolutely devel
[02:40:17] <cradek> I'm sure I fixed this
[02:40:21] <SWPadnos> this was running before, I'm not sure why I recompiled
[02:40:41] <cradek> in Makefile.inc what is LIB_DIR?
[02:41:05] <SWPadnos> well, it's not up to dat, Entries shows 1.52, and the last commit brought it to 1.55
[02:41:18] <cradek> aha
[02:41:20] <SWPadnos> (Makefile)
[02:41:44] <SWPadnos> maybe I should try better to remember which machine I actually did the cvs up on ;)
[02:42:30] <cradek> as jmk says, EBKAC
[02:42:33] <cradek> haha
[02:42:44] <SWPadnos> heh - I see a Problem with that :)
[02:42:54] <SWPadnos> or, no problem, I guess
[02:43:44] <SWPadnos> cradek, do you know what made your kernel provide timing information to RTAI?
[02:43:57] <SWPadnos> the older BDI does, I think BDI 4.30 doesn't
[02:44:19] <cradek> SWPadnos: no, but any interested party could surely wade through the kernel configs
[02:45:15] <SWPadnos> surely they could
[02:45:25] <jmkasunich> fscking RTAI crap shit trash
[02:45:40] <cradek> looks like jmk found the problem
[02:45:47] <SWPadnos> heh
[02:45:54] <jmkasunich> the calls to rtapi_get_time (which translate into calls to RTAI) are taking far longer than the actual code
[02:46:13] <cradek> whee.
[02:46:38] <jmkasunich> and the recent change is because until cradek started asking about overrun detection, I knew they didn't work well anyway, so I had them commented out
[02:46:44] <SWPadnos> heh
[02:46:53] <cradek> oh so it's my fault
[02:46:55] <SWPadnos> rdtsc is a serializing instruction, I think
[02:47:01] <SWPadnos> that may be part of the problem
[02:47:06] <jmkasunich> its not rdtsc at all
[02:47:10] <SWPadnos> good
[02:47:14] <jmkasunich> its what rtai does before/after that
[02:47:28] <jmkasunich> I replaced the calls to rtai with calls to the rdtsc macro itself
[02:47:35] <SWPadnos> multiply / divide (several times)?
[02:47:39] <jmkasunich> (so the results are in clocks, not ns)
[02:47:49] <jmkasunich> numbers less than 1000 for sum2
[02:48:22] <jmkasunich> then I kept the rdtsc for the calulations, but uncommented the calls to RTAI, and the numbers became 9000+
[02:48:36] <cradek> ouch
[02:48:39] <SWPadnos> damn
[02:48:41] <jmkasunich> so we're taking a 5-7uS hit at everh HAL function
[02:48:42] <SWPadnos> in cycles, or ns?
[02:48:49] <jmkasunich> 9000 is cycles
[02:48:55] <jmkasunich> about 6-7uS
[02:49:26] <SWPadnos> well - I guess we now know. good job
[02:49:32] <cradek> yeah nice find
[02:50:10] <jmkasunich> rtapi_get_time calls rt_get_cpu_time_ns()
[02:50:26] <jmkasunich> which apparently is a horrible pig
[02:51:03] <jmkasunich> so timing is going away again
[02:51:04] <SWPadnos> as I recall, all that did was call the kernel get_time_ns, which was rdtsc + scaling
[02:51:12] <SWPadnos> or get_cpu_time_ns
[02:51:18] <SWPadnos> it didn't look that bad
[02:51:26] <jmkasunich> that blows my mind - why would the authors of a REALTIME OS make the function you call to measure time so fscking slow
[02:51:46] <jmkasunich> well, somewhere in there is something ugly
[02:53:12] <jmkasunich> I'm sorely tempted to change rtapi_get_time to return time in clocks, use rdtsc, and say fsck it
[02:53:20] <SWPadnos> yep - just do that.
[02:53:33] <jmkasunich> I'm afraid of portability issues tho
[02:53:35] <SWPadnos> we can find a way around my dual-core issue when the time comes
[02:54:05] <SWPadnos> apparently, it's there on all Pentium chips, and possibly the 486 as well
[02:54:14] <jmkasunich> on that issue: I seem to recall designing RTAPI so that on a SMP box it runs all RT tasks on the same CPU
[02:54:23] <jmkasunich> dunno how that works on dual core
[02:54:37] <cradek> I think dual core == SMP
[02:54:53] <SWPadnos> it may work, in which case the RT tasks would always read the same TSC
[02:54:55] <jmkasunich> its not on 486 I don't think, but I'm not worried about those, they're old even by my standards
[02:54:59] <jmkasunich> what about AMD, etc>?
[02:55:10] <jmkasunich> (although it seems to work fine here)
[02:55:12] <SWPadnos> amd has it
[02:55:30] <SWPadnos> the problem is that the TSCs on dual-cores aren't synced on the Athlon X2 or the Opteron
[02:55:42] <jmkasunich> I think instead of changing rtapi_get_time, I'll add rtapi_get_clocks to the API
[02:56:08] <SWPadnos> I wouldn't bother with that. The whole reason for get_clocks would be to get the time
[02:56:28] <jmkasunich> just to make it clear to the caller that he isn't getting ns
[02:57:14] <SWPadnos> I think I was the main opponent to using rdtsc, but I think the potential problems (in a couple of years) aren't anywhere near as important as the performance gain today
[02:57:30] <SWPadnos> make it ns though (not sure exactly how to do that)
[02:57:49] <jmkasunich> can't do that
[02:58:01] <SWPadnos> even a divide is faster than rt_get_...
[02:58:07] <jmkasunich> at least not for version 2.0
[02:58:19] <jmkasunich> the problem is getting the cal factor
[02:58:19] <SWPadnos> can't do what?
[02:58:35] <SWPadnos> right -cat /proc/cpuinfo | grep MHz
[02:58:42] <jmkasunich> what is the system clock? it ain't easy tpo find out in a portable way
[02:59:31] <SWPadnos> 'cat /proc/cpuinfo | grep MHz' should be pretty portable across all Linux systems
[02:59:38] <jmkasunich> how do you get it from /proc into the rtapi kernel module
[02:59:44] <SWPadnos> one sec
[02:59:52] <jmkasunich> (especially if its a deb, you can't compile it in)
[03:00:06] <cradek> yeah I had that idea for about 5 seconds
[03:00:31] <SWPadnos> does it need to be compiled in?
[03:00:43] <SWPadnos> you can dereference something pretty quickly
[03:00:54] <jmkasunich> it needs to be available to the internals of rtapi.ko
[03:01:08] <jmkasunich> hmm, I guess you could pass it as an insmod parameter
[03:01:16] <jmkasunich> one more thing for the realtime script to do ;-)
[03:01:19] <SWPadnos> heh
[03:01:55] <SWPadnos> it's probably somewhere in the kernel already - else they wouldn't be able to do get_cpu_time_ns
[03:02:13] <jmkasunich> you don't want to go there
[03:02:23] <jmkasunich> I was reading, and my head almost exploded
[03:02:30] <SWPadnos> heh
[03:02:42] <cradek> I bet you can get it from sysctl(2)
[03:02:43] <jmkasunich> CPUs that slow the clock during the idle task, CPUs that stop the clock during the idle task
[03:02:58] <jmkasunich> kernel code that resyncs the TSC every time the idle task exits
[03:02:59] <SWPadnos> yes - those are a problem
[03:03:09] <jmkasunich> truly sick shit for someone used to embedded
[03:06:08] <SWPadnos> well - the kernel has do_gettimeofday
[03:06:18] <SWPadnos> returns a timeval
[03:07:00] <jmkasunich> look at rtai_rtapi.c line 529
[03:07:18] <jmkasunich> I used do_gettimeofday, it caused problems on some systems, alex commented it out
[03:07:34] <SWPadnos> hmmm
[03:08:08] <SWPadnos> http://lxr.linux.no/ident?i=do_gettimeofday
[03:08:41] <SWPadnos> it's in this file (for 1.6.11)
http://lxr.linux.no/source/kernel/time.c
[03:08:45] <SWPadnos> 2.6.11
[03:09:05] <jmkasunich> alex didn't say what kind of problems
[03:09:19] <jmkasunich> maybe it's not suitable to call from a RT task
[03:09:39] <SWPadnos> could be, or it's just not there sometimes
[03:09:41] <cradek> yeah that's a lousy comment
[03:10:13] <SWPadnos> looking at time.c, it seems that the function isn't defined if CONFIG_TIME_INTERPOLATION isn't true
[03:11:45] <jepler> when speaking of RTAI, what is "immediate mode"?
[03:12:33] <SWPadnos> whoops. bedtime.
[03:12:44] <SWPadnos> see you guys later (like Thursday)
[03:12:58] <cradek> ok goodnight
[03:13:36] <SWPadnos> http://lxr.linux.no/source/arch/i386/kernel/time.c#L95
[03:14:25] <jepler> SWPadnos: see you
[03:14:30] <SWPadnos> see you
[03:14:38] <SWPadnos> SWPadnos is now known as SWP_Away
[03:35:28] <jmkasunich> ahhhhhhh, thats better
[03:35:46] <jmkasunich> running stepper-inch, the system is FAR more responsive now
[03:35:54] <cradek> cool
[03:37:11] <jmkasunich> parport read is about 2500 clocks, write is about 5200, stepgen-makepulses is about 400
[03:38:35] <jmkasunich> I think over 80% of the time in the RT threads was being spend in that damned time measuring function
[03:39:44] <cradek> I'm glad you found it
[03:39:49] <jmkasunich> me too
[03:40:03] <jmkasunich> emc2 was starting to get a bad reputation
[03:40:48] <jmkasunich> now... do I announce to folks that HEAD has a fairly important fix in it, or do we need to do some further checking of the build system before we cause a stampede to CVS?
[03:41:23] <cradek> wait a bit, jepler's looking for a problem that's maybe in pickconfig
[03:41:51] <jmkasunich> I'm gonna commit my changes, the commit message won't cause a rush
[03:41:57] <cradek> ok
[03:42:19] <jmkasunich> but answering the folks who say "why do I need to set BASE_PERIOD to 200uS", that will cause a rush
[03:42:54] <cradek> yeah...
[03:49:06] <jmkasunich> hmm - I actually thought about the bug you just fixed, but it was in the middle of something else and I forgot about it
[03:49:47] <jmkasunich> now I just have to hope that rdtsc is implemented on all the compile farm slots
[03:52:09] <cradek> ?
[03:52:15] <cradek> what bug I just fixed?
[03:52:45] <jmkasunich> oh, it was jepler
[03:52:53] <jmkasunich> duplicate dirs in configs-path
[03:53:09] <cradek> ah
[03:54:25] <jepler> I think rdtsc exists on true pentiums, and anything newer from intel. It at least exists on K6es and newer from AMD. Not sure about oddballs.
[03:55:19] <cradek> wonder if I should make new packages now
[03:55:33] <jmkasunich> dunno
[03:55:47] <jmkasunich> I'd let the compile farm run thru its paces first
[03:55:52] <jmkasunich> * jmkasunich goes to start it
[03:56:36] <cradek> chris@buster2:/usr/src/emc2$ scripts/emc
[03:56:36] <cradek> sed: -e expression #1, char 0: no previous regular expression
[03:56:36] <cradek> Machine configuration directory is ''
[03:56:36] <cradek> Machine configuration file is ''
[03:57:49] <jmkasunich> did you hit cancel or OK?
[03:58:05] <cradek> neither, this is before that
[03:58:08] <cradek> I see the problem
[03:59:08] <cradek> jepler's change has an unintended consequence when emc is run with no args
[03:59:13] <jepler> cradek: oops!
[03:59:50] <jepler> you want me to fix it
[03:59:50] <jepler> ?
[03:59:58] <cradek> I'm already typing commit
[04:00:12] <cradek> done
[04:00:32] <jepler> thanks
[04:00:59] <jmkasunich> interesting time behavior here... parport write is very consistent at about 5200 clocks, but a couple times a second it jumps to 12000 clocks or more
[04:02:39] <cradek> jmkasunich: does it sometimes do more than one outb?
[04:02:51] <jmkasunich> it always does the same number
[04:02:55] <jmkasunich> which is 2
[04:03:04] <jmkasunich> one to the data port, one to the control port
[04:03:15] <jmkasunich> HAL provides all the outputs, even if they aren't in use
[04:03:35] <cradek> emc1 would skip the outbs if those outputs had not changed
[04:03:37] <jmkasunich> I can get flurries of the long ones when I move the mouse
[04:03:47] <cradek> huh
[04:04:52] <jmkasunich> one reason for things to get long during other activity is cache
[04:05:09] <jmkasunich> if the only thing running is RT code, it remains in cache from one thread execution to the next
[04:05:11] <cradek> jepler: can you make doubleclick work while you're in there?
[04:05:23] <jmkasunich> if lots of user space stuff is going on, cache gets overrwitten
[04:06:47] <jmkasunich> that probably accounts for the small scale jitter
[04:06:59] <jmkasunich> there is a hard floor at about 5100 clocks
[04:07:31] <jmkasunich> then a distribution of runs that vary from 5100 to about 5300 (most under 5125)
[04:09:20] <jmkasunich> then nothing between 5400 and 12000
[04:09:42] <jmkasunich> 12000 to 15000 happen maybe 1% of the time
[04:09:51] <jmkasunich> when very active
[04:11:45] <jmkasunich> drat
[04:11:56] <jmkasunich> jepler used [ file normalize ]
[04:12:09] <jmkasunich> that isn't available on older tcl (pre 8.4)
[04:12:12] <cradek> oops
[04:12:42] <jmkasunich> dunno if thats a factor or not for emc
[04:13:13] <cradek> do you have any idea what tcl versions are on what bdis?
[04:13:20] <cradek> obviously it's ok for ubuntu
[04:13:28] <jmkasunich> I'm trying to figure out what I have here
[04:13:40] <jmkasunich> tclsh --version and similar doesn't work
[04:14:05] <cradek> chris@buster2:~$ tclsh
[04:14:05] <cradek> % info tclversion
[04:14:05] <cradek> 8.4
[04:14:27] <jmkasunich> same here
[04:14:31] <jmkasunich> I'll check the farm
[04:16:01] <jmkasunich> BDI-2.x has 8.0, BDI-TNG has 8.3, BDI-Live has 8.4
[04:16:18] <cradek> so it's fine right now?
[04:16:23] <jmkasunich> yeah
[04:16:37] <jmkasunich> -2.x and -TNG are on the chopping block IMHO
[04:17:37] <cradek> and it's looking worse and worse for them as work continues
[04:20:21] <jmkasunich> quite a weekend
[04:20:41] <jmkasunich> 45 commits "yesterday" (CIA is on UTC I think)
[04:20:54] <jmkasunich> 122 so far this month
[04:22:07] <cradek> wow
[04:23:03] <jmkasunich> http://cia.navi.cx/stats/project/emc
[04:23:25] <jmkasunich> we've averaged a commit every 7.5 hours for almost a year and a half
[04:23:44] <cradek> new emc2, emc2-dev, emc2-axis packages in the breezy repository (again)
[04:23:50] <jmkasunich> cool
[04:24:13] <cradek> hope I got everything in there
[04:24:41] <jmkasunich> compile farm is happy (two slots anyway), so my rtapi change didn't bust anything
[04:24:49] <jmkasunich> its a shame we can't actually test on the far
[04:24:52] <cradek> great
[04:24:57] <jmkasunich> I can't see any way to automate it tho
[04:25:19] <cradek> you could insert and remove a module, but that's a lousy test.
[04:25:46] <jmkasunich> the only real test would be to start emc and run 3dchips or something
[04:25:52] <cradek> yeah.
[04:26:01] <cradek> probably can't do that automated.
[04:26:08] <jmkasunich> and even that only tests a fraction of the system - only one gui, only one config
[04:26:30] <jmkasunich> as far as you can tell, the current HEAD will compile and run both in place and installed?
[04:26:37] <cradek> yes
[04:27:04] <jmkasunich> we need to make a tarball while it is pseudo-stable, before the next wild session like these last few days
[04:27:22] <jmkasunich> and we need to communicate some changes, like --enable-run-in-place
[04:27:25] <cradek> maybe it's better to make tags
[04:27:41] <jmkasunich> the timing bug is significant enough that I want to announce the fix
[04:27:41] <cradek> there's nowhere to put a tarball where people will look for it.
[04:27:54] <jmkasunich> alex was/is hosting daily tarballs
[04:28:04] <jmkasunich> but you're right, gotta point people to them
[04:28:10] <cradek> yeah, but I don't think anyone is using them unless cvs breaks
[04:28:38] <jmkasunich> tags can be moved, right?
[04:28:43] <cradek> sure
[04:28:55] <jmkasunich> so we could have a tag TESTING, that always points to the latest reasonable stable thing
[04:29:07] <cradek> yes I think we could
[04:29:17] <jmkasunich> and a wiki page that tells testers both how to get it and compile it, and what to expect
[04:29:45] <cradek> IMO that's what my debs are for
[04:29:45] <jmkasunich> "foo is known not to work, but bar and baz should, if they don't please report it"
[04:30:04] <cradek> I make a new one when I think something important has changed, and everything's in a sane state
[08:23:47] <alex_joni> cradek: just fyi, make tgz is not working at the moment, we might want to add that back
[08:24:23] <LawrenceG> HiAlex... latest debs are not working either
[08:24:51] <alex_joni> LawrenceG: yes they are, since last night
[08:25:07] <LawrenceG> logo var is missing from pickconfig.tcl
[08:25:16] <LawrenceG> and my config dirs are empty
[08:25:54] <LawrenceG> /etc/emc2/sample-configs/stepper has NO files
[08:27:01] <LawrenceG> if fixed logo var by adding >>set logo ""<< at line 36 of pickconfig.tcl
[08:28:02] <LawrenceG> I seem to be missing emc2-wizard.gif as well which shoed up the logo error
[08:28:29] <LawrenceG> showed
[08:29:29] <LawrenceG> Those files must not be in the debs.... I removed and installed emc2 several times even a fresh deb download
[08:30:30] <LawrenceG> I was hoping to test the timing fixes on this old 200mhz unit
[08:45:34] <LawrenceG> I can see the files in the deb, the config dirs get created, but the ini files are not being placed into the directories
[08:46:50] <LawrenceG> To test, uninstall emc2 and rm -rf /etc/emc2, then reinstall deb
[08:57:17] <alex_joni> where did you get the debs from?
[08:57:35] <LawrenceG> cradek: In case you didnt catch above.... latest emc2 debs contain but do not install any sample configs... /etc/emc2 has sample dirs, but no contents... a du /etc/emc2 shows only 52 blocks
[08:57:53] <LawrenceG> from the .ro repository
[08:58:06] <alex_joni> dunno, not sure, probably not fully done yet
[08:58:13] <alex_joni> * alex_joni has a plane to catch in an hour
[08:58:28] <LawrenceG> np.... I need to get to bed... 1am here
[08:58:53] <LawrenceG> I had a version from a couple of days ago working
[08:59:07] <LawrenceG> lots of changes this weekend... good show
[09:09:22] <alex_joni> indeed
[09:49:48] <alex_joni> * alex_joni goes away for a while
[09:49:54] <alex_joni> alex_joni is now known as alex_joni_away
[12:35:02] <cradek> LawrenceG: if you dpkg --purge emc2 and then apt-get install emc2, do you get config files?
[17:16:07] <cradek> ok I think I reproduced the problem, not sure if I understand it fully
[17:16:17] <cradek> if you apt-get remove emc2, it preserves the configuration files in /etc
[17:16:32] <cradek> if you remove them with rm, it also preserves that (?)
[17:17:28] <cradek> so ... don't do that
[17:17:45] <cradek> dpkg --purge emc2 and then reinstall should fix your problem
[18:10:09] <LawrenceG> cradek: Thanks... that has restored the sample ini's. When running stepper-inch, /usr/bin/milltask errors out when trying to load librs274.so.. a search of my hd does not find this file anywhere
[19:11:46] <cradek> LawrenceG: I fixed that - updated packages available
[19:22:40] <LawrenceG> cradek: Thanks... downloading now
[19:24:36] <cradek> LawrenceG: should be smooth from here on - alpha19 was the first package I made with the new build system.
[19:25:37] <LawrenceG> cradek: np... hope I havent been a pest... the deb idea is fantastic....
[19:26:08] <cradek> not at all, I really appreciate your testing and good bug reports
[19:26:43] <cradek> you are helping make this smooth for when we make the big release
[19:26:52] <LawrenceG> yea... the more people that can try out the new stuff, the faster its gets stable
[19:28:55] <LawrenceG> running cds now in sepper_in YEA!!
[19:29:02] <cradek> yay!
[19:31:30] <LawrenceG> it runs quite well on a P200.....
[19:32:10] <cradek> great, jmk made an important fix yesterday that should have made it run much faster (reduced BASE_PERIOD possible)
[19:37:14] <LawrenceG> axis-sim seems to be another story... I get a blank axis window and 100% cpu usage forever...maybe some update is being scheduled faster than it can run... no errors on cmd line
[19:38:11] <cradek> hmm
[19:38:19] <cradek> can you run other opengl programs like glxgears?
[19:38:26] <LawrenceG> buy faster computer
[19:40:48] <LawrenceG> that could be the problem..... glxgears comes up, runs a few revs and stalls out... hmm this is an old matrox card
[19:41:29] <cradek> I'm surprised, but Mesa, the software GL renderer, might have trouble on such a slow machine
[19:41:35] <LawrenceG> I get an update about every 20 seconds... xorg is the cpu hog
[19:41:54] <cradek> hmm, doesn't seem like it should be that slow.
[19:43:33] <LawrenceG> its so slow I can see it rendering each face of each tooth!
[19:44:53] <LawrenceG> let me check my xorg config and see what is turned on
[19:45:14] <cradek> you could try turning off DRI
[19:47:52] <LawrenceG> hmmm I notice in the Module sectopn, that I am loading GLcore... that may be the matrox accellerator
[19:48:13] <LawrenceG> as I understand it, that may be bad with RT?
[19:48:20] <cradek> no, that's fine I think
[19:48:36] <cradek> but try commenting out Load "dri"
[19:48:39] <cradek> if you have it
[19:48:56] <cradek> also if your screen depth is 24 or 32, change it to 16
[19:49:13] <LawrenceG> ok its there... should I comment out the dri mode 0666 as well?
[19:49:23] <cradek> I don't think it matters
[19:50:12] <LawrenceG> default depth is 16
[20:00:51] <LawrenceG> strange.... tried a few more setting combinations... no real change... glxgears runs about 3 revs and thenslows to a crawl. The good news is that its not an EMC2 problem. Cheers... gotta run... doing tax stuff today... would rather be making chips :}
[20:01:08] <cradek> ok good luck with taxes
[20:01:51] <LawrenceG> I may try another video card later
[20:33:19] <rayh> cradek: I've got both installed and rip versions of testing here. I like what I see of it. I've got a couple of questions about halconfig in relation to the "new world order."
[20:37:08] <cradek> ok shoot
[20:37:23] <cradek> rayh: did you make install, or use the deb?
[20:37:31] <rayh> make install
[20:37:47] <rayh> I don't have ubuntu yet. This is 4.30 bdi
[20:37:51] <cradek> ok
[20:38:02] <rayh> from a couple hours ago.
[20:38:28] <rayh> My vision for halconfig was that it would be able to start, without HAL or EMC running.
[20:38:31] <cradek> btw I am working on making the update friendlier - I hope to get it to show the changelog for the new version of the packages before you decide to update (like the system packages do)
[20:38:47] <rayh> Oh. Good.
[20:38:58] <cradek> ok
[20:39:12] <cradek> does that still require a running hal and halcmd?
[20:39:27] <rayh> aside On the make install. Should there be a make uninstall?
[20:39:31] <cradek> I'm still fuzzy about how halconfig works
[20:39:55] <cradek> the problem with make uninstall is that it can't determine whether you have modified files (like configs). Typically packages do not have a make uninstall.
[20:39:56] <rayh> Details are not critical right now.
[20:40:24] <cradek> ok I'll let you ask the questions and I'll try to answer them
[20:40:33] <rayh> It's been a long time since I ran an MS system but there was a package remover.
[20:40:59] <cradek> make install is from a time before package management - if you use the deb packages, you can certainly remove them cleanly
[20:41:31] <rayh> If halconfig found am rt system it would offer to start an empty HAL
[20:41:31] <cradek> I see people using make install only on systems that don't have package management, or are so out of date there aren't packages
[20:42:22] <rayh> I guess I was thinking I'd like to remove the installed version.
[20:43:15] <rayh> No matter
[20:43:16] <cradek> you'll have to do that by hand then - /usr/local/etc/emc2, /usr/local/share/doc/emc2? a few files in /usr/local/bin, a few files in /usr/local/lib
[20:43:44] <cradek> we could write a make uninstall if we decide it's necessary
[20:43:45] <rayh> What halconfig did was start realtime or the most basic demo script.
[20:44:12] <cradek> ok so you want it to be able to do a realtime start
[20:44:23] <cradek> does it have to do anything else?
[20:44:55] <rayh> Once realtime is going, it drops into ordinary halconfig mode with tree and all.
[20:45:12] <cradek> ok
[20:45:20] <cradek> so it needs to know two things: where is realtime, where is halcmd
[20:45:22] <rayh> But what I seem to be missing on the installed version is a way to get halconfig to start.
[20:45:46] <jepler> Isn't halconfig on $PATH when running installed?
[20:45:48] <rayh> The installed version is fairly easy to find these.
[20:45:51] <cradek> currently it knows neither of those things: the halcmd location comes from the environment
[20:45:58] <jepler> er, halcmd
[20:46:05] <rayh> What isn't easy is to find and start halconfig.
[20:46:13] <cradek> jepler: only when a child of the emc script
[20:46:29] <cradek> jepler: oh I reread, you're right
[20:46:35] <rayh> I see two immediate choices.
[20:46:58] <cradek> rayh: if you want the user to invoke halconfig directly, it should go in the bin dir
[20:47:15] <cradek> rayh: currently it's off in some script directory
[20:47:16] <rayh> rip out the environmental testing and always start it from tkemc, mini, axis. etc.
[20:47:36] <rayh> That choice is easy.
[20:48:26] <cradek> we might rename it to emc-halconfig and put it in bin, for instance
[20:48:43] <cradek> we intend to have emc-configuration or something like that to run setupconfig
[20:48:50] <rayh> True.
[20:49:21] <cradek> now, you do not need root privs to start realtime, so that is not a problem
[20:49:47] <cradek> I don't see any big stumbling blocks, just some playing with the installation is necessary
[20:49:49] <rayh> But if it's installed, I don't need the startup testing for things like MS and rtxx
[20:50:17] <cradek> I don't follow - what are MS/rtxx
[20:50:34] <rayh> Those are tests at the start of halconfig.
[20:50:45] <cradek> let me pull it up
[20:51:17] <rayh> I guess the real question I have is how does halconfig fit in with other scripts like setupconfig.
[20:51:44] <rayh> BTW I really like the new look of the chooser.
[20:51:58] <cradek> sounds like setupconfig and halconfig are very similar - we want the user to be able to run them without emc running
[20:52:05] <rayh> the tree widget is great.
[20:52:19] <cradek> so they will be in the path (and there will be menu entries on the system Apps menu to start them)
[20:52:26] <cradek> great, I like it too, very much
[20:52:36] <cradek> it's an elegant solution to multiple config directories
[20:53:16] <rayh> Okay. That works.
[20:53:30] <cradek> rayh: already with installed, if you copy a config into your home directory ~/emc2/configs/configname, it will show up on the chooser
[20:54:04] <cradek> rayh: setupconfig will do just that (and there is also a system-wide config directory)
[20:54:13] <rayh> That's great.
[20:54:49] <cradek> your personal configs show up on top, then the systemwide configs, then the samples on the bottom
[20:55:20] <rayh> jmk was talking about user configurable things. will display color and font be a part of this like they are with other linux apps?
[20:55:43] <jepler> The color and font selections for Tk applications are customizable through the X resource database
[20:56:15] <jepler> but Tk is not "themeable" in the modern sense
[20:56:16] <rayh> Ah we we have never been very successful at keeping that location for TkEmc alive.
[20:57:34] <rayh> It does require work on the "option" database for each display.
[20:58:04] <cradek> tk is sometimes finicky when you markedly change font sizes for instance
[20:58:23] <cradek> but things like colors are easy to change
[20:58:30] <rayh> Yep. Font is better in 8.5 but ...
[20:58:57] <rayh> What I'm thinking of is a .myconfig file in the users home directory.
[20:59:20] <cradek> there is a standard X way of doing that involving a file in the home directory called .Xresources
[20:59:36] <cradek> it would then be handled without any special code in tkemc
[20:59:58] <cradek> have you had a lot of requests for this kind of customization?
[21:00:32] <rayh> Some. More like help it looks bad.
[21:00:58] <jepler> chew chew chew
[21:01:03] <cradek> maybe we need to work on the defaults a bit then
[21:01:17] <cradek> but "help it looks bad" doesn't help us much, does it
[21:01:42] <rayh> These come from several sources. One is KDE's config all apps alike.
[21:02:06] <cradek> yeah, but we won't have that kind of themability without a total rewrite of the guis.
[21:02:20] <cradek> to me, that doesn't seem like an important goal right now.
[21:02:34] <cradek> we would have to ditch tcl/tk and start over.
[21:02:39] <rayh> KDE does it now to tkemc. Mini is already close to their default colors and fonts.
[21:03:23] <cradek> KDE themes show up in tkemc?? There must be something at work I don't know about.
[21:04:25] <jepler> cradek: KDE writes some X resources
[21:04:27] <rayh> I know nothing about how it works but it does change bg, fg and some fonts.
[21:04:42] <cradek> ok, that much is easy
[21:04:53] <cradek> getting 3D buttons etc. is impossible
[21:05:54] <cradek> maybe getting rid of the blue, in favor of a more standard gray look, would help
[21:06:34] <rayh> I guess I was thinking less about hard coded stuff than an approach to user configuration.
[21:07:01] <rayh> TK has color choosers and font choosers and such.
[21:07:06] <cradek> like jepler said, that's already possible with X resources but it's hardly friendly.
[21:08:10] <cradek> you could definitely make a preferences screen and write the results to a file in the user's home directory to be read when tkemc starts
[21:08:46] <rayh> Okay. I'll salt that away for a later release.
[21:08:47] <jepler> but .. but .. the X resources database already exists!
[21:09:27] <jepler> the answer to "our GUIs look terrible" should not involve "let's write another GUI application to solve that problem"
[21:10:25] <rayh> Good thought.
[21:11:32] <cradek> I'm pretty sure I would duck out of any gui-improvement part of the project; I put that energy into AXIS. That's not to say I think it shouldn't/couldn't be done.
[21:11:39] <jepler> we should strategically add a few configuration options (like using a non-bold font by default, and some white backgrounds), after which Tk looks a lot more modern .. at least like a win95-era program.
[21:12:09] <cradek> yes, that might help a surprising amount.
[21:12:26] <rayh> All of that can be done in TkEmc.
[21:12:29] <cradek> I think sometimes "sensible defaults" are better than all the configurability in the world.
[21:12:42] <cradek> yep
[21:13:10] <rayh> Then we would just need to replace snapshots of the old with the new.
[21:13:17] <rayh> In several hundred places.
[21:13:24] <cradek> including the splash screen
[21:13:59] <rayh> ouch.
[21:14:23] <cradek> no problem. alex said the splash screen was a quick hack (but I think it's really good)
[21:15:11] <rayh> Would TkEmc be editable by a user in the installed emc2?
[21:15:27] <cradek> using sudo, it sure is
[21:16:55] <cradek> if a user customizes it and then installs a new deb, the deb install will give an option of keeping the customizations or using the new distributed file
[21:17:03] <rayh> phone
[21:23:47] <alex_joni_away> alex_joni_away is now known as alex_joni
[21:23:51] <alex_joni> hello
[21:24:39] <cradek> hi alex
[21:24:42] <cradek> I thought you were away
[21:26:54] <alex_joni> * alex_joni couldn't stay away
[21:26:57] <alex_joni> :-P
[21:27:13] <alex_joni> I'm in the hotel right now, it's good that wireless works
[21:27:25] <cradek> yay
[21:27:46] <cradek> the new config selector looks and works great
[21:27:47] <alex_joni> btw, you've got mail
[21:28:37] <alex_joni> it already did last night
[21:29:40] <alex_joni> cradek: got my email?
[21:29:50] <cradek> yes, looking
[21:30:00] <alex_joni> ok, eager to know what you think
[21:31:07] <cradek> I like 06
[21:31:45] <alex_joni> like.. like? or really like?
[21:32:12] <rayh> Hi alex.
[21:32:13] <cradek> it looks nice
[21:32:19] <alex_joni> hi ray
[21:32:22] <cradek> I like the globe thing
[21:32:55] <alex_joni> how about the logo?
[21:33:37] <cradek> it's cute but I think the pengiun should have a tool of some kind
[21:33:44] <cradek> or just safety glasses?
[21:33:47] <cradek> something
[21:33:50] <alex_joni> yeah, something
[21:33:55] <alex_joni> btw, I like 06 better too
[21:34:04] <alex_joni> rayh: care to look at a picture?
[21:34:13] <alex_joni> 500kB about
[21:34:24] <rayh> Sure send it on.
[21:34:30] <alex_joni> email?
[21:34:32] <rayh> or send a link
[21:34:44] <alex_joni> link is better I think, let me put it someplace
[21:34:48] <rayh> k
[21:38:06] <cradek> http://timeguy.com/cradek-files/emc/linuxCNC_06.jpg
[21:38:27] <alex_joni> thanks chris
[21:38:27] <cradek> unfortnately it's huge because someone made a jpg when it should have been png
[21:38:37] <alex_joni> don't want to abuse the wireless here
[21:38:43] <alex_joni> cradek: you can convert :D
[21:38:52] <cradek> it's too late, it'll look terrible
[21:39:10] <alex_joni> probably so
[21:39:37] <cradek> I assume this is not the final content... the part about viruses is silly
[21:39:53] <alex_joni> that's taken from the current site
[21:40:04] <cradek> uh I assume this is not the final content... the part about viruses is silly
[21:40:06] <alex_joni> I just pointed him some URL to take sample data from
[21:40:20] <alex_joni> cradek: :-)
[21:40:59] <alex_joni> cradek: it will be a CMS, so you can fix what you don't like :P
[21:41:14] <cradek> I think putting safety goggles on the logo would be just enough of a twist to make it cute/funny
[21:41:39] <alex_joni> how about we collect some ideas, and I'll get back to the designer
[21:41:42] <alex_joni> and we'll see
[21:41:45] <cradek> sure
[21:42:18] <cradek> also
http://timeguy.com/cradek-files/emc/linuxCNC_08.jpg but I don't care for it much
[21:42:53] <cradek> I particularly dislike the out-of-focus macintosh keyboard
[21:43:43] <alex_joni> I don't really like it either
[21:43:50] <alex_joni> I mean it's ok, but barely
[21:44:52] <jepler> I prefer 06 too
[21:45:50] <alex_joni> hi jeff
[21:46:26] <jepler> hi alex
[21:46:48] <alex_joni> greetings from germany
[21:51:15] <jepler> how's germany?
[21:51:35] <alex_joni> nice so far, but it's dark ;)
[21:52:21] <jepler> Yes, at this time of night it probably is
[21:53:05] <jepler> you should come to the US .. it isn't dark yet, except in metaphor
[21:53:31] <rayh> Where are you in Germany, alex_joni
[21:53:33] <alex_joni> lol, I'm not scared of metaphor-typed dark
[21:53:48] <alex_joni> rayh: near freiburg (near switzerland and france)
[21:54:09] <rayh> Ah.
[21:54:20] <alex_joni> south-west
[21:54:59] <rayh> Right.
