Back
[00:13:51] <alex_joni> I'm beat... going to bed
[00:13:53] <alex_joni> night guys
[00:18:25] <cradek> jepler: I think I did try full-stepping but it worked less well.
[00:18:38] <alex_joni> paul_c: thanks again for the help today, and for the help so far...
[00:20:04] <alex_joni> cradek: hey, can you try the emc2 ./configure?
[00:21:24] <cradek> alex_joni: give me a few minutes
[00:21:41] <alex_joni> not that urgent
[00:21:56] <alex_joni> if my memory serves me right you have a RTLinux install... right?
[00:23:01] <cradek> yes
[00:23:09] <cradek> any special tag to check out, or just the default emc2?
[00:23:25] <alex_joni> the default emc2
[00:23:41] <alex_joni> the autoconf has been moved to the main trunk
[00:25:06] <cradek> Using /usr/bin/rtl-config as the RT signature
[00:25:31] <cradek> this is the only fishy looking thing:
[00:25:32] <cradek> checking for module installation directory... find: /usr/realtime/: No such file or directory
[00:25:35] <cradek> ${exec_prefix}/modules
[00:26:29] <alex_joni> hmmmm
[00:26:35] <cradek> now building
[00:26:41] <alex_joni> I'll look at it tomorrow
[00:26:51] <alex_joni> but it should build anyway..
[00:28:44] <cradek> it does compile and run
[00:28:55] <alex_joni> cool
[00:31:14] <alex_joni> can you find a module called mbuff.o on your system?
[00:33:11] <cradek> /usr/local/src/rtlinux-3.2-pre2/drivers/mbuff/mbuff.o
[00:33:11] <cradek> /usr/local/src/rtlinux-3.2-pre2/modules/mbuff.o
[00:33:11] <cradek> /usr/rtlinux-3.2-pre2/modules/mbuff.o
[00:33:11] <cradek> /lib/modules/2.4.20-rtl3.2-pre2/misc/mbuff.o
[00:33:46] <alex_joni> doesn't rtlinux get installed to /usr/realtime?
[00:33:51] <alex_joni> with a make install
[00:34:01] <alex_joni> make realtime_install or smthg like that?
[00:35:04] <cradek> ln -fs /usr/rtlinux-3.2-pre2 /usr/rtlinux
[00:35:12] <cradek> rtlinux's make install does this
[00:35:21] <cradek> so it's /usr/rtlinux, not /usr/realtime
[00:36:25] <alex_joni> I see...
[00:36:39] <alex_joni> ok then configure needs to check for /usr/rtlinux aswell
[00:36:59] <alex_joni> it does search for mbuff.o but inside /usr/realtime
[00:37:35] <alex_joni> what's $KERNEL_VERS in Makefile.inc ?
[00:43:54] <cradek> kernelvers = 2.4.20-rtl3.2-pre2
[00:43:58] <cradek> there is no KERNEL_VERS
[00:44:53] <alex_joni> this should have worked MODULE_DIR=`(find /lib/modules/${KERNEL_VERS} -name "mbuff.o" -o -name "rtai_shm.o" -printf "%h")`
[00:45:27] <alex_joni> you are right about kernelvers (it's called KERNEL_VERS inside ./configure)
[00:47:20] <cradek> [chris@max emc2]$ find /lib/modules/2.4.20-rtl3.2-pre2 -name "mbuff.o" -o -name "rtai_shm.o" -printf "%h"
[00:47:23] <cradek> [chris@max emc2]$
[00:47:28] <cradek> that does not print anything
[00:47:40] <Imperator_> * Imperator_ waves
[00:47:44] <cradek> hello
[00:48:06] <alex_joni> guess it was a bubye wave
[00:48:08] <alex_joni> ;)
[00:49:06] <cradek> aha
[00:49:28] <cradek> I got a picture of emc2 pulsing the step bit unevenly like I mentioned last time I tried emc2
[00:49:35] <cradek> I will send it to the list
[00:50:05] <alex_joni> dev?
[00:50:08] <alex_joni> or user?
[00:50:21] <cradek> dev I guess
[00:50:24] <cradek> I'm on both
[00:51:36] <alex_joni> me too.. that's why I was asking...
[00:53:28] <alex_joni> strange find -printf %h should have worked
[00:56:00] <cradek> straaaange: if I use -print or -printf it stops working
[00:58:12] <alex_joni> what stops working?
[01:00:06] <cradek> find
[01:01:19] <alex_joni> hmmm... really strange
[01:01:27] <alex_joni> man says printf is ok to use
[01:02:36] <cradek> [chris@max /]$ mkdir /tmp/a
[01:02:36] <cradek> [chris@max /]$ touch /tmp/a/b /tmp/a/c
[01:02:36] <cradek> [chris@max /]$ find /tmp/a -name b -o -name c -print
[01:02:36] <cradek> /tmp/a/c
[01:02:36] <cradek> [chris@max /]$ find /tmp/a -name b -print -o -name c
[01:02:39] <cradek> /tmp/a/b
[01:02:42] <cradek> [chris@max /]$
[01:02:44] <cradek> the problem is with the -o
[01:03:23] <cradek> [chris@max /]$ find /tmp/a -name b -o -name c -print
[01:03:23] <cradek> /tmp/a/b
[01:03:23] <cradek> /tmp/a/c
[01:03:27] <cradek> this is apparently what you need
[01:03:31] <cradek> oops
[01:03:33] <cradek> bad paste
[01:03:44] <cradek> [chris@max /]$ find /tmp/a \( -name b -o -name c \) -print
[01:03:48] <alex_joni> it prints both...
[01:04:00] <cradek> ignore the one without the ()
[01:04:04] <alex_joni> usually there can't be more than one
[01:04:06] <cradek> that was not pasted properly
[01:04:21] <cradek> no, I'm not being clear here
[01:04:23] <cradek> let me explain
[01:04:43] <alex_joni> bear in mind I'm pretty tired ,)
[01:04:49] <cradek> the -print only applies to the -name after the -o
[01:05:09] <cradek> if you want the -print to apply to both the -name, you must put them in (backslashed) parens
[01:06:00] <alex_joni> I see now
[01:06:17] <alex_joni> can you commit this? or I'll do it tomorrow...
[01:07:49] <alex_joni> it's in subsection 3.3 inside configure.in
[01:08:04] <cradek> done - how can I tell if it worked?
[01:08:14] <cradek> oh I see, it should skip the second test
[01:08:40] <alex_joni> yes
[01:08:52] <alex_joni> do a autoconf next
[01:08:57] <alex_joni> it should generate a new ./configure
[01:09:00] <cradek> checking for module installation directory... /lib/modules/2.4.20-rtl3.2-pre2/misc
[01:09:03] <alex_joni> and run that one
[01:09:03] <cradek> that does fix it
[01:09:17] <alex_joni> MODULEDIR should now be right (/lib/modules/
[01:09:30] <alex_joni> beautifull
[01:10:00] <alex_joni> yup
[01:10:16] <alex_joni> now commit both files if you can (configure.in and configure)
[01:10:28] <CIA-3> 03cradek * 10emc2/configure.in: fix find usage
[01:11:02] <CIA-3> 03cradek * 10emc2/configure: fix find usage
[01:11:26] <alex_joni> cia rulez ;)
[01:14:20] <alex_joni> well.. I'm really gone now.. 3 am here
[01:14:26] <alex_joni> night
[01:14:26] <cradek> 'night
[01:33:09] <cradek> how long does it take for my list mail to go through?
[01:33:31] <cradek> I sent it 15 mins ago...
[01:35:25] <paul_c> It's being a bit slow today...
[01:37:21] <cradek> I'd like for you guys to see this before it gets too late
[01:43:15] <cradek> hmm, looks like the mails to -commit are taking many hours
[01:43:21] <cradek> oh well
[01:44:05] <paul_c> You're not sending general postings to emc-commit are you ??
[01:44:10] <cradek> no
[01:44:26] <cradek> just commenting that I just got one that had been delayed several hours
[01:53:19] <paul_c> Oh heck... K.Lux is back...
[02:43:36] <paul_c> cradek: You still up ?
[02:44:19] <cradek> yes
[02:45:01] <paul_c> You realise the next time someone runs autoconf, it will over-write your changes..
[02:45:16] <cradek> no, I checked in both files
[02:45:42] <cradek> don't depend on the emails; they're too slow.
[02:46:17] <paul_c> So the kernel version isn't being reported ?
[02:46:37] <cradek> eh?
[02:46:42] <paul_c> or is it looking in the qrong directory for mbuff.o
[02:46:53] <cradek> scroll back, we discussed it here
[02:47:04] <cradek> he was using find to look for either of those files
[02:47:19] <cradek> he had the find command wrong (it would only report finding the second file)
[02:49:01] <cradek> I sent two mails to emc-devel: the picture of the jittery step output from emc2, and a followup to the unwanted-jog-after-hitting-ESC bug we talked about here a few days ago.
[02:49:17] <cradek> emc1 and emc2 both have this bug.
[02:51:03] <paul_c> I've not had much to do with the low level code in emc2
[02:51:25] <cradek> well I hope someone on the list will be interested
[02:52:02] <cradek> (in both)
[02:52:31] <paul_c> Can you refresh me on the jogging bug
[02:53:18] <cradek> what's your email? I'll send you a copy
[02:55:20] <cradek> ok, sent
[02:57:20] <paul_c> got it
[02:59:03] <paul_c> does it do it while in MDI ?
[03:00:17] <cradek> I'm pretty sure it has to be reading ahead in a program
[03:02:09] <paul_c> would need to boot a 2.4 kernel to try it out..
[03:02:38] <cradek> it does it in emc1 and 2
[03:03:15] <paul_c> Much of the code is the same, so that isn't a suprise
[03:42:30] <markwayne> hi
[13:33:53] <alex_joni> hello
[13:34:36] <alex_joni> hi john
[13:34:55] <jmkasunich> hi alex
[13:35:37] <alex_joni> what's new?
[13:36:00] <jmkasunich> not much with me I'm afraid
[13:36:22] <jmkasunich> busy with a manual machining job
[13:36:50] <alex_joni> i see.. :)
[13:37:07] <alex_joni> I added the IRC logs to linuxcnc
[13:37:17] <jmkasunich> I saw that - thank you very much
[13:37:46] <alex_joni> don't mention it
[13:38:23] <alex_joni> is the compile farm up?
[13:38:31] <jmkasunich> I think so
[13:38:37] <jmkasunich> * jmkasunich KVM's away to check
[13:38:54] <alex_joni> it seems stuck to me (last build on 23.11)
[13:40:30] <jmkasunich> all three slots are up
[13:40:48] <jmkasunich> when was the last commit?
[13:40:53] <alex_joni> last night
[13:41:00] <jmkasunich> hmmmm
[13:41:07] <jmkasunich> * jmkasunich looks at logs
[13:41:14] <alex_joni> but also yesterday too
[13:41:28] <alex_joni> the autoconf has been merged to the trunk
[13:41:42] <alex_joni> and I was eager to see that it completes on the farm
[13:41:53] <alex_joni> ooops
[13:42:04] <alex_joni> sorry... seems that I was still looking at the autoconf tree
[13:42:13] <alex_joni> instead of looking at the trunk ... silly me
[13:43:07] <jmkasunich> ;-)
[13:43:37] <jmkasunich> the logs show two compiles on the trunk, yesterday and about 01:00 today (GMT)
[13:44:05] <alex_joni> yeah...
[13:44:10] <alex_joni> I saw that it fails on Live
[13:44:18] <alex_joni> the GTK stuff doesn't get compiled
[13:44:27] <alex_joni> guess GTK is not figured out corectly
[13:44:35] <alex_joni> can you take a look at what's happening?
[13:44:36] <jmkasunich> but it passed before the merge (I think?)
[13:44:50] <alex_joni> yeah... on the last ./configure it worked
[13:45:16] <jmkasunich> in the build log:
[13:45:23] <jmkasunich> checking for GTK version... 2.0
[13:45:28] <jmkasunich> ./configure: line 1: gtk-config: command not found
[13:45:34] <jmkasunich> ./configure: line 1: gtk-config: command not found
[13:45:36] <alex_joni> yup
[13:46:10] <alex_joni> is it really 2.0 GTK?
[13:46:16] <alex_joni> don't know about Live...
[13:46:24] <jmkasunich> I think so
[13:46:51] <jmkasunich> * jmkasunich looks at the 11/22 autoconf branch build log
[13:47:11] <jmkasunich> hmmm - same message in that one
[13:47:51] <alex_joni> the code is taken from the old ./configure
[13:47:56] <alex_joni> so the error is the same
[13:48:28] <jmkasunich> and same errors when compiling "meter.c" - but for some reason the autoconf branch was logged as "passed", but the trunk one logged as "failed"
[13:49:31] <alex_joni> yeah... i think default rule is different
[13:49:41] <alex_joni> make continued after gtk failures
[13:50:29] <jmkasunich> I think I'd rather have make fail after the first error
[13:51:01] <jmkasunich> anyway, let's dig into it...
[13:51:13] <jmkasunich> I'll have to KVM over to that box
[13:51:16] <alex_joni> let me commit some changes
[13:51:25] <alex_joni> it seems I forgot to add some code
[13:51:30] <alex_joni> the code is only for GTK1.1
[13:51:32] <alex_joni> 1.2
[13:52:01] <alex_joni> give me 5 mins
[13:52:53] <jmkasunich4> ok, I'll start the compile when I see the CIA message
[14:00:55] <alex_joni> * alex_joni forgot to do a cvs up
[14:02:26] <alex_joni> sorry it takes so long, but my connection is crap
[14:02:45] <jmkasunich> that's OK (I'm catching up on my email)
[14:03:45] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/RELEASE-NOTES: File changed. New revision:1.28
[14:06:08] <CIA-3> 03alex_joni * 10emc2/ (configure configure.in): fixed GTK-CFLAGS for GTK2.0 & GTK2.2
[14:06:21] <jmkasunich4>
[14:06:34] <alex_joni> Zathras have sad life, probably have sad death, but at least there is symmetry
[14:06:59] <jmkasunich4> ;-)
[14:07:12] <jmkasunich4> compile started on slot 4
[14:07:43] <jmkasunich> is cradek here?
[14:07:47] <alex_joni> No. Oh. No, noo. No no. You did not meet Zathras. You met Zathras.
[14:07:59] <alex_joni> ;-)
[14:08:54] <jmkasunich> I was suspicious when Garibaldi showed up - but Zathras clinched it
[14:09:28] <alex_joni> lol
[14:10:02] <alex_joni> how does the configure look?
[14:11:47] <alex_joni> hey les
[14:11:55] <les> hello alex
[14:12:27] <jmkasunich4> appears to be working - configure found 2.0, no warning message
[14:12:32] <jmkasunich4> and meter.c compiled OK
[14:12:51] <alex_joni> nice
[14:25:34] <jmkasunich4> the make succeeded, results should be online in a minute or so
[14:25:58] <jmkasunich4> like right now
[14:27:06] <alex_joni> I do have an request for you ... if you got 5 mins
[14:27:10] <jmkasunich> OK
[14:28:10] <alex_joni> the farm script for autoconf tree outputs Makefile.inc
[14:28:18] <alex_joni> if my memory serves me right...
[14:28:26] <alex_joni> could the same be done for the trunk now?
[14:28:42] <alex_joni> if / when we'll get into trouble it makes it a lot easier to debug
[14:28:51] <jmkasunich4> ok, I can do that
[14:29:27] <alex_joni> are you happy with ./configure?
[14:30:09] <jmkasunich> ?
[14:30:48] <alex_joni> * alex_joni thinks about closing the tracker at SF
[14:31:42] <jmkasunich> Oh... sure, close it... IMO, the goal has been reached - any future glitches can be addressed by bug reports
[14:34:08] <jmkasunich> question: should the farm continue to build the autoconf branch?
[14:34:34] <jmkasunich> note - it doesn't build the install branch - that could be done, but it's a bit of a pain
[14:34:45] <jepler> good morning folks
[14:35:20] <alex_joni> "Good. Good. Zathras knew you would come. This way."
[14:35:37] <alex_joni> jmk: we need to talk about make install...
[14:35:51] <alex_joni> best if we get a discussion going on the dev-mailing list
[14:36:25] <jmkasunich> OK
[14:37:04] <alex_joni> if you have the time, you could take a look at make install (from the autoconf_install_0_1 branch)
[14:37:14] <alex_joni> I am actually pretty happy with how it works
[14:37:27] <alex_joni> but that's just me ;)
[14:37:34] <jepler> jmkasunich: I don
[14:37:44] <jepler> jmkasunich: don't think you'll see cradek up this early on a weekend, but maybe I'm wrong.
[14:38:00] <jmkasunich> alex - the old build script for autoconf logged Makefile.inc if ./configure succeeded, if it failed, it logged the config.log instead
[14:38:09] <jmkasunich> is that what you want for emc2head now?
[14:38:10] <alex_joni> yeah
[14:38:16] <alex_joni> that'll do it
[14:38:25] <jmkasunich> ok
[14:38:33] <alex_joni> copy'n'paste the code to emc2head
[14:38:53] <jmkasunich> easier than that - I'll just make emc2head use the same script
[14:39:09] <jmkasunich> one line change in the update script, then run the script on all slots
[14:39:15] <jmkasunich> * jmkasunich goes to do that
[14:39:36] <alex_joni> cool
[14:39:36] <jmkasunich> btw, thanks jepler, I saw his name, but no idea if he was really there
[14:45:56] <alex_joni> BDI-2.18 has no GTK?
[14:46:51] <jmkasunich4> dunno, let me check
[14:47:16] <jmkasunich4> (btw, revised scripts uploaded to all slots - and I kicked off compiles on emc2head to test it
[14:47:54] <alex_joni> great
[14:51:14] <jmkasunich> looks like BDI-2.18 has gtk, but not gtk-devel
[14:51:32] <jmkasunich> so for purposes of compiling, it doesn't have GTK
[14:51:36] <alex_joni> i see
[14:51:48] <alex_joni> ok.. then it's ok to fail
[14:51:57] <alex_joni> the gtk stuff anyways
[14:52:07] <alex_joni> but it's good that the overall build is not failing
[14:52:09] <jmkasunich> right - just skip the GTK stuff
[14:52:12] <jepler> what's using gtk nowadays?
[14:52:13] <alex_joni> yup
[14:52:22] <alex_joni> the halmeter
[14:52:24] <alex_joni> halscope
[14:52:25] <jmkasunich> HAL utilities, like meter and scope
[14:52:41] <alex_joni> nice gimmiks ;)
[14:52:58] <alex_joni> usefull for debug.. but you can live without them
[14:53:07] <jmkasunich> why do you say "nowadays"? is GTK considered old?
[14:53:35] <jepler> I hadn't seen anything more modern than Tk and athena in EMC, that's all. Compared to those, GTK is modern.
[14:54:03] <jmkasunich> most of emc was originally created 5 years ago
[14:54:12] <jmkasunich> I started the HAL stuff last year
[14:56:09] <jmkasunich> I wanted a GUI toolkit that was usable from plain C
[15:00:21] <alex_joni> jepler: do you think there is a better toolkit out there?
[15:02:14] <jmkasunich> morning Ray!
[15:02:21] <alex_joni> hi ray
[15:02:32] <rayh> Hi John. Wow lots of folk.
[15:02:41] <alex_joni> lurkers
[15:02:49] <alex_joni> :-)
[15:03:00] <jmkasunich4> and duplicates....
[15:03:02] <rayh> Heavy wet snow over night. Knocked out the power for 3 hours this morning.
[15:03:07] <jmkasunich4> don't think I need this one anymore
[15:03:08] <alex_joni> and loggers
[15:03:23] <rayh> Almost missed us.
[15:03:38] <alex_joni> snow is great...
[15:04:07] <rayh> alex_joni: I really liked the pic of your yard with the meter of snow.
[15:04:30] <alex_joni> yeah... can't wait to get there
[15:06:01] <rayh> I'm using the SuSE box today. Got the firewall and apache running.
[15:06:13] <alex_joni> using yast?
[15:06:38] <rayh> Yes. I need help with routing though.
[15:06:49] <alex_joni> can you be more specific?
[15:07:06] <alex_joni> * alex_joni liked the yast-firewall up to a point
[15:08:00] <alex_joni> the stuff yast does is pretty ok, but when you need to add/modify something.. it's a nightmare
[15:08:16] <rayh> I'm on a dialup. Got it connected to ppp0.
[15:08:34] <asdfqweg2> What's Suse like?
[15:08:40] <rayh> Works fine on this box but the other network boxes can't reach through.
[15:08:42] <alex_joni> ok... and you want the rest of the LAN to be able to use the connection?
[15:09:00] <alex_joni> if you want I can send you a custom iptables-script
[15:09:03] <rayh> I like quite a bit of it. There are a few differences that tend to confuse me.
[15:09:25] <rayh> alex_joni: That weould be very nice.
[15:09:33] <alex_joni> asdfqweg2: yast is nice, you have almost everything in one place
[15:10:21] <asdfqweg2> * asdfqweg2 is using Mandrake, and is hitting limits of usefulness
[15:11:25] <alex_joni> at the time I started (back at RH5.2) SuSE seemed like a very nice alternative
[15:11:30] <alex_joni> I stuck with it still now
[15:11:52] <alex_joni> now I'm thinking of giving deb a spin... probably the next one I install will be debian based
[15:12:11] <asdfqweg2> I try doing something like compile a new kernel, and it futz' stuff up
[15:12:21] <rayh> Paul has a deb that installs with anaconda.
[15:12:46] <rayh> asdfqweg2: I had the same problem with Mandrake.
[15:13:08] <alex_joni> asdfqweg2: the next BDI will be probably deb based
[15:13:13] <asdfqweg2> I'm going to try debian, next
[15:13:15] <rayh> I even tried patching their own kernel using hand patching. It would work for a while and then the whole system went away.
[15:13:42] <asdfqweg2> Although I might try and see if I can use Knoppix to sidestep the installation tedium
[15:14:09] <rayh> A central configuration tool is the thing I miss most about deb.
[15:14:19] <paul_c> Install knoppix, apt-get 2.4.27-adeos
[15:14:46] <alex_joni> rayh: you can use the deb stuff on suse
[15:14:51] <alex_joni> apt-tools
[15:14:56] <alex_joni> never tried it thou...
[15:15:01] <asdfqweg2> I need to look for deb Sarge on cd
[15:15:32] <asdfqweg2> Yast sounds like Webmin on Mandrake
[15:16:39] <rayh> The major difference is that YaST also handles things like install/remove and hardware config as well.
[15:17:43] <rayh> All of my deb installs have been from Morphix or Knoppix.
[15:18:51] <asdfqweg2> I've tried doing it with Knoppix, and it doesn't let me separate things into different partitions
[15:19:16] <asdfqweg2> I don't know if it's really necessary, but from my experience so far, it's a good idea
[15:19:38] <alex_joni> like /home /boot & such?
[15:19:55] <asdfqweg2> yes
[15:20:41] <alex_joni> not that nice.. ;)
[15:20:59] <asdfqweg2> alex: ?
[15:21:29] <alex_joni> not that nice that you can't separate things into different partitions
[15:21:50] <alex_joni> my /home is on two hdb's
[15:21:53] <asdfqweg2> Well, that was with Knoppix 3.3 - I've ordered 3.6 on cd
[15:22:26] <alex_joni> I downloaded a Knoppix some time ago (over a year or so...)
[15:22:32] <asdfqweg2> and if it still won't let me do it...well, there's gonna be some recoding
[15:22:34] <alex_joni> but I didn't try a newer one
[15:23:22] <paul_c> You might like the next BDI...
[15:24:24] <asdfqweg2> paul: I'm pretty sure I will...both the 2.20b and the Live rc46 are good
[15:24:49] <alex_joni> same here
[15:25:08] <asdfqweg2> although, I like the Live better ;)
[15:26:11] <asdfqweg2> My main gripe with Mandrake is that they're very 'release' oriented
[15:26:58] <asdfqweg2> Installation is nigh painless, but upgrading never works perfectly
[15:28:21] <asdfqweg2> I just put kernel 2.6.9 on here - and I can't use my USB flashdrive anymore :(
[15:29:36] <asdfqweg2> Which ticks me off, because now my PCMCIA is working correctly again :/
[15:30:53] <asdfqweg2> <sigh> Makes me wish I could switch to Studly OS
[15:32:54] <rayh> asdfqweg2: On my knoppix install I made a new user and that /home/xx dir is a separate partition.
[15:34:02] <jepler> alex_joni: I don't have enough experience in many toolkits to say what the better or best toolkit is.
[15:34:14] <alex_joni> I see...
[15:34:20] <alex_joni> well there is a need for a halgui
[15:34:42] <alex_joni> and I was wondering if there is better a simpler way than GTK...
[15:34:48] <jepler> alex_joni: I have way too much experience with Tk (from tcl and Python) and it is just fine for a lot of purposes. This morning I've been struggling to reproduce a Tk window layout in glade as an exercise..
[15:34:56] <alex_joni> * alex_joni has no experience with toolkits
[15:36:02] <jepler> but I'm pretty certain that if my first real GUI experience hadn't been Tk that I'd be singing the praises of something else.
[15:36:13] <alex_joni> I know how you feel...
[15:38:37] <jepler> The biggest problem with Tk is that there seem to be two choices of tree or multicolumn widgets: One, BLT, is written in C, seems to be unmaintained, and is prone to segfaulting. The other, bwidget, is written in Tcl and is *ahem* not speedy.
[15:38:50] <jepler> I'm not sure how actively bwidget is maintained, either.
[15:38:55] <cradek> jmkasunich: about your questions: I would get the rough sound from the steppers on most jogs at any speed. It does also happen while running a program.
[15:39:08] <jepler> good morning cradek!
[15:39:11] <cradek> hello
[15:39:40] <alex_joni> good morning cradek
[15:40:59] <jepler> * jepler goes to have breakfast.
[15:41:08] <cradek> it's pretty early for us USAian night-owl folks
[15:42:00] <cradek> jmkasunich: some jogs sounded right, but it's hard to tell from just sound. Some jogs would sound rough, smooth, rough, smooth, in a pattern like that
[15:42:46] <alex_joni> * alex_joni is gone voting...
[15:43:17] <cradek> so is emc2 working smoothly for anyone? It seems like this is a very apparent problem that everyone would notice immediately if they have it.
[15:44:18] <cradek> (hope I didn't miss jmk)
[15:44:30] <alex_joni> nope.. he should be back soon
[15:45:42] <paul_c> Might be worth doing a build on an RTAI patched kernel.
[15:46:27] <cradek> paul_c: so is the answer to my question yes? you (or someone) is using it with rtai and it works right with steppers?
[15:46:48] <SteveStallings> since there are probably few people who have tried running EMC2 on a real machine, I'll comment. It seemed to run reasonably will on my BDI-live, AMD 1.3 GHz machine with steppers driving a "mini-mill".
[15:46:54] <paul_c> I've not hooked emc2 up to a mill.
[15:47:48] <SteveStallings> ... that should be "reasonably well" and the BDI was RC-46
[15:49:11] <rayh> SteveStallings: could you expand on "reasonably well"?
[15:50:04] <cradek> here's how I think anybody can reproduce it without a mill: build emc2 from cvs, run it, move the jog speed slider up to about 7, jog, look at the step pin with a scope. It looks terrible.
[15:50:46] <SteveStallings> I did not notice anything out of the ordinary with a program running, on the other hand I have always been less than impressed with EMC's response to the jog keys.
[15:51:19] <cradek> SteveStallings: so your steppers sounded "right", just like they do with emc1?
[15:51:45] <SteveStallings> They did sound right to my ear. EMC1 has never been run on the same setup.
[15:52:09] <SteveStallings> My point of comparison has been TurboCNC and Mach2 on the same hardware.
[15:52:38] <cradek> ok, maybe it does have something to do with rtlinux
[15:52:46] <cradek> but we only have 2 datapoints...
[15:53:30] <cradek> no, Paul Fox got this jitter behavior with rtai
[15:53:39] <cradek> i'm running emc2, from cvs. i'm on debian (sarge), just
[15:53:39] <cradek> installed late last week. i'm using an rtai dpkg that i got from
[15:53:39] <cradek> paul (aka bdi-emc). it's a 2.4.27 kernel. the machine is a
[15:53:49] <cradek> (this is from his email 22 Nov)
[15:56:38] <cradek> I think what we need is some of you guys with o'scopes to try this
[15:57:12] <SteveStallings> I'll try next week. Machine is at the office.
[15:58:52] <cradek> I will do more rigorous testing - note all the settings so you guys can reproduce it
[16:00:20] <cradek> has anyone tried to reproduce the bug in my second email (unwanted jog after ESC)?
[16:01:15] <cradek> you can even see it using sim.run
[16:01:15] <SteveStallings> I also planned to try that one.
[16:02:05] <cradek> great
[16:06:00] <rayh> SteveStallings: The lag between pressing or releasing the jog keys is a tickle update thing.
[16:07:05] <jmkasunich> cradek: sorry, I was away for a bit (wife got home, doing chores)
[16:07:25] <jmkasunich> I have run steppers (not on a mill) with emc2, no audible jitter
[16:08:05] <jmkasunich> well - no jitter that I wasn't expecting anyway
[16:08:15] <cradek> ok, that's good (?) to know
[16:08:28] <cradek> I will write up exact steps to reproduce this
[16:08:53] <jmkasunich> the stepgen module "rounds off" the ideal step time to the nearest actual interrupt
[16:08:56] <cradek> but like I said, it was very apparent, so I bet yours won't do it if it seemed to be working right
[16:09:27] <cradek> I understand there is a tiny bit of jitter when it's working right (the pulses shake around a tiny bit when looking at the triggered scope)
[16:09:49] <cradek> but for me it was much more than that as you can see in my email pic.
[16:10:05] <jmkasunich> what was the scope time/div setting in that pic?
[16:10:24] <jepler> cradek: so canned cycles weren't required for the "hit ESC" bug?
[16:10:31] <cradek> jepler: nope
[16:10:45] <cradek> jmkasunich: I don't know, sorry
[16:11:03] <cradek> jmkasunich: I will reply later with the information you asked for in the mail.
[16:11:06] <jmkasunich> ok
[16:11:33] <jmkasunich> I have both halscope and a real scope, but I don't know if I can reproduce the problem
[16:11:36] <SteveStallings> ray - keyboard access vs. the effective buffering of jog moves is a tough problem to solve. Mach2 cheats, jog is a special case and it causes some problems with tuning because people tend to tune by listening to jog, then find that the regular motion engine behaves differently
[16:11:44] <jmkasunich> my main system is running RTAI (BDI-TNG)
[16:12:05] <jmkasunich> I have a compile farm slot running RTLinux (BDI-2.xx), but that has no parport
[16:13:11] <cradek> jmkasunich: we can be fairly sure that at least one person is getting this behavior with rtai
[16:13:20] <jmkasunich> right - paul fox
[16:14:09] <cradek> that makes me happy because I don't want to mess up my perfectly good emc1 setup
[16:14:20] <jmkasunich> there are diagnostic tools in HAL, such as the function execution time parameters, and of course halscope
[16:14:41] <cradek> you would have to walk me through using those
[16:14:43] <paul_c> We could do with some CPU details and base period values
[16:15:18] <rayh> SteveStallings: Interesting. I didn't know that.
[16:15:25] <jmkasunich> cradek: exactly - if you're not familiar with the workings that you are trying to debug, the tools are of limited use... I wish I could reproduce it here
[16:15:39] <rayh> I have tried a separate loop time with jog and it works better.
[16:16:03] <rayh> There is just to much to be done each loop to speed the whole of tkemc or mini up to where the jog response is good.
[16:18:21] <cradek> jmkasunich: ok I am at the machine with scope and steppers at the ready
[16:18:29] <dave-e> is the speed problem related to the tkemc being interpeted?
[16:18:53] <jmkasunich> go ahead and start emc2
[16:19:02] <rayh> dave-e: Yes it is, in part.
[16:19:11] <jmkasunich> and open a couple spare shells
[16:19:38] <rayh> A compiled gui might work quite a bit faster although there is still a lot to be done each time interval.
[16:20:22] <cradek> jmkasunich: ready
[16:20:28] <dave-e> ray--can you link C to tk for time critical parts?
[16:20:32] <rayh> Tickle has a very fast running event loop. If many of the display update things could be transfered to it, then the whole thing would work much quicker.
[16:20:46] <rayh> Yes there is a rather well developed c interface.
[16:20:51] <paul_c> cradek: One quick question - What are the PERIOD & SERVO times ?
[16:20:53] <jepler> How does the speed of the GUI relate to jitter while jogging? That is all happening async from the GUI
[16:21:20] <jepler> there might be percived lag starting and stopping the jog, but that's a separate issue
[16:21:22] <cradek> paul_c: the default from cvs, 0.000050 and 0.001000
[16:21:38] <dave-e> ray--so it could be done with a lot of painful work. ;-)
[16:21:40] <cradek> jepler: I think this is two separate issues
[16:21:43] <rayh> If we could link tickle variables like the widget configuration stuff to C variables...
[16:21:51] <jmkasunich> jepler: there are two conversations going on at once - ray and steve are indeed talking about starting and stoping
[16:22:01] <jmkasunich> (which is common to emc1 and 2)
[16:22:02] <rayh> and then register that variable with the event loop we would gain a lot of speed.
[16:22:09] <jmkasunich> cradek and I are talking about jitter, unique to emc2
[16:22:26] <jmkasunich> perhaps cradek and I should /msg to another window?
[16:22:27] <rayh> It would be more of a state machine.
[16:23:22] <cradek> oh wow
[16:23:25] <paul_c> jmkasunich: Only if you log it...
[16:23:27] <cradek> I am seeing DIR change while jogging!
[16:23:37] <jmkasunich> wtf?"
[16:23:41] <jmkasunich> wtf?~
[16:23:54] <jmkasunich> we'll stay here
[16:24:16] <jmkasunich> * jmkasunich studies "core_stepper.hal"
[16:24:17] <rayh> cradek: With emc1 that would be bad tuning of feedforward.
[16:24:33] <jmkasunich> dir changes during the jog, or only at the end?
[16:24:57] <cradek> during
[16:26:29] <jmkasunich> sorry for delays... I'm making the latest emc2
[16:26:50] <jmkasunich> in one of your shells, cd to the emc2 dir
[16:26:59] <jmkasunich> then do "bin/halmeter &"
[16:27:27] <cradek> I got a good capture of dir changing
[16:27:33] <cradek> give me a minute to photograph it
[16:27:37] <jmkasunich> OK
[16:28:39] <jmkasunich> I'm expecting a guest in about 5-10 mins - they'll only be here for about 15 mins (just some paperwork) - just so you don't wonder if I suddenly dissappear
[16:29:26] <cradek> ok I got a pic of it
[16:29:53] <cradek> I don't have bin/halmeter
[16:30:04] <cradek> halcmd, hal_parport, hal_skeleton
[16:30:35] <jmkasunich> you must be missing either GTK or gtk-devel
[16:31:02] <jmkasunich> bummer - that means you don't have halmeter or halscope - two usefull tools
[16:31:05] <cradek> let me install them and rebuild
[16:32:15] <cradek> installed, rebuilding...
[16:33:08] <cradek> ok, I have halmeter/halscope now
[16:33:08] <jmkasunich> drat - my build of the latest CVS won't run
[16:33:15] <jmkasunich> damn that was fast
[16:33:35] <cradek> fast machine
[16:34:02] <cradek> ok, halmeter running, it shows --- and -----
[16:34:14] <jmkasunich> click on select (or something like that)
[16:34:22] <cradek> ok
[16:34:27] <jmkasunich> you should see three tabs
[16:34:31] <jmkasunich> click on params
[16:34:43] <jmkasunich> look for ones named xxx.time and xxx.tmax
[16:34:46] <jmkasunich> click on one
[16:35:05] <jmkasunich> this is killing me - I need to get my own emc2 running
[16:35:22] <cradek> those aren't there
[16:35:40] <jmkasunich> OK, go to a shell
[16:35:49] <jmkasunich> type "bin/halcmd show param"
[16:35:55] <jmkasunich> that will give you the same list
[16:36:08] <jmkasunich> try "bin/halcmd show param | grep time"
[16:36:18] <jmkasunich> if that comes up blank, something is really wrong
[16:36:20] <cradek> ok there are lots of them
[16:36:42] <jmkasunich> but they don't show up in halmeter?
[16:36:54] <cradek> aha
[16:36:58] <cradek> my fault
[16:37:12] <jmkasunich> did you take my "xxx" literally ;-)
[16:37:24] <cradek> no, but I missed them somehow anyway
[16:37:38] <cradek> I have motion-*time paroprt*time stepgen*time
[16:37:44] <cradek> which family do you want?
[16:37:50] <jmkasunich> ok, the time ones show how long the last execution of each function took
[16:38:02] <jmkasunich> the tmax ones show the longest recorded execution time
[16:38:42] <jmkasunich> we want to look at all of them, look for tmax >= 25uS or so (25000nS)
[16:39:05] <jmkasunich> motion*time will probably be large, it is the servo loop
[16:39:16] <jmkasunich> parport and stepgen should be only a few microseconds
[16:39:24] <jmkasunich> because they run in the fast thread
[16:39:26] <cradek> argh, I have to do them one at a time??
[16:39:56] <jmkasunich> you could also to "bin/halcmd show param | grep tmax" to see all the tmax ones
[16:40:24] <jmkasunich> but for the time ones, meter gives you more of a "dynamic" look at what is happening
[16:42:30] <cradek> for the tmax: they are all 6000-10000 except motion-controller.tmax which is 20096
[16:42:41] <jmkasunich> ok, that's good
[16:43:07] <jmkasunich> still trying to get mine going
[16:44:04] <jmkasunich> dammit..... the math module isn't there
[16:44:22] <jmkasunich> that was working fine before, I'm afraid the autoconfig stuff must have broken it
[16:44:57] <jmkasunich> crap - that means I don't have a working emc2 here
[16:45:10] <cradek> check out the tree from a few days ago
[16:45:18] <jmkasunich> I need to figure out how to do that
[16:45:19] <cradek> or whenever you think it was working for you
[16:45:24] <jmkasunich> * jmkasunich digs out the cvs book
[16:45:29] <jepler> it's snowing (well, just a tiny bit)
[16:45:44] <paul_c> cvs up -D "2 days ago"
[16:45:54] <cradek> cvs co -D "a fortnight ago"
[16:46:26] <cradek> jepler: get used to it! sounds like we're going to get nailed
[16:47:47] <jepler> cradek: yeah, see you at work as soon as it thaws
[16:48:07] <jmkasunich> updated, and making
[16:49:00] <jmkasunich> how much snow?
[16:49:03] <cradek> I have "axis speed" set at 6. sometimes I get a nice even jog. but usually it sounds very rough and I see it randomly reversing the DIR bit on the scope.
[16:49:11] <cradek> 5" tonight
[16:49:20] <jmkasunich> ok, let's try to capture it using halscope
[16:49:42] <cradek> ok, tell me how
[16:50:09] <jmkasunich> guest just arrived, back in 10-15 mins
[16:50:28] <jmkasunich> see hal_introduction.pdf on linuxcnc.org if you want to try yourself
[16:55:10] <cradek> ok I captured parport.0.pin-04-out and pin-05-out
[16:55:14] <cradek> during a rough jog
[16:56:28] <cradek> they don't look at all reasonable
[16:58:58] <cradek> cool, I caught one when it switched from a good jog to bad
[17:02:54] <cradek> jepler: now I hear 8" tonight
[17:03:22] <SteveStallings> away for a while, will remain logging....
[17:03:24] <rayh> Where are we expecting snow?
[17:03:38] <cradek> NE
[17:04:02] <rayh> We got our's last night.
[17:04:04] <cradek> it usually doesn't bother us, we're used to it, but this is the first of the year and it will be relatively big
[17:04:22] <cradek> where?
[17:05:12] <asdfqweg2> ray is in Michigan, right?
[17:06:26] <asdfqweg2> I kinda hope snow stays up near Ray, and doesn't come down to Ohio for a little while :)
[17:06:27] <rayh> Yep. The UP. Near Marquette.
[17:06:41] <alex_joni> * alex_joni completed his civic duties
[17:07:04] <rayh> I'm about 130 miles north of Green Bay, Wisconsin.
[17:08:02] <alex_joni> ray: got that email?
[17:09:22] <rayh> No I didn't. I tested with an email from dave-e and got his.
[17:09:56] <alex_joni> hmmm.. didn't come back either
[17:15:41] <dave-e> got a skiff of snow in Muncie the other day....
[17:15:55] <dave-e> now I'm back trying to adjust for the 3 hr shift.
[17:16:33] <dave-e> no snow here....had been some on the pass (Snoqualamie) and a few remodeled cars but we made it home OK.
[17:16:46] <dave-e> nice warm 20 degrees and sunshine here.
[17:17:17] <dave-e> gotta go ... seeya!
[17:21:03] <cradek> I am also getting "one step forward one step back" regularly at about every 4.5 seconds when sitting idle
[17:21:37] <alex_joni> cradek: that's normal
[17:21:49] <alex_joni> it's the hunt for the zero position
[17:22:04] <alex_joni> * alex_joni was just reading through the logs... math is broken???
[17:22:44] <cradek> jmk said he will be right back
[17:23:26] <alex_joni> I'll have a look at the farm
[17:26:08] <Imperator_> * Imperator_ is back
[17:26:13] <Imperator_> Hi all
[17:26:58] <alex_joni> hello Martin
[17:27:06] <Imperator_> Hi Alex
[17:27:19] <cradek> darn, I have to go
[17:27:25] <cradek> jmkasunich: we'll have to finish working on this later
[17:28:14] <alex_joni> I'll try to fix the math stuff till you're back
[17:37:58] <alex_joni> jmk: say when back...
[17:43:38] <jmkasunich> I'm back - sorry it took longer than expected
[17:45:37] <alex_joni> I'm here for about 5 mins... so no problem
[17:45:45] <alex_joni> only problem cradek had to leave...
[17:45:52] <jmkasunich> yeah, I saw
[17:45:54] <alex_joni> you said math support is broken?
[17:45:58] <jmkasunich> yeah
[17:46:04] <jmkasunich> the old config did the following:
[17:46:26] <jmkasunich> Testing for a suitable libm... Some symbols may be printed.
[17:46:31] <jmkasunich> __errno_location
[17:46:38] <jmkasunich> __isnan
[17:46:44] <jmkasunich> fputs
[17:46:47] <jmkasunich> stderr
[17:46:52] <alex_joni> can you paste me the Makefile.inc ?
[17:46:53] <jmkasunich> Using glibc libm with mathstubs.
[17:47:00] <alex_joni> maybe in a sep. window?
[17:47:10] <jmkasunich> from the latest one, or the older one that works?
[17:47:17] <alex_joni> * alex_joni wonders why libm is needed on rtai ?
[17:47:27] <alex_joni> the module doesn't work?
[17:47:45] <alex_joni> the Makefile.inc from the old ./configure (not autoconf)
[17:47:56] <jmkasunich> ok
[17:53:00] <jmkasunich> pinging paul_c...
[17:54:12] <alex_joni> jmk: what's failing when running?
[17:54:34] <jmkasunich> modules fail to load because symbols like sin, cos, etc are undefined
[17:55:05] <alex_joni> does rtai_libm get loaded?
[17:55:19] <jmkasunich> dunno, let me check
[17:55:36] <jmkasunich> I changed my emc2head tree to 5 days ago to get it to work
[17:55:45] <alex_joni> maybe the order in rtapi.conf is not right?
[17:55:47] <jmkasunich> just did a make in my emc2auto tree, I'll try there
[17:55:52] <alex_joni> ok
[17:56:02] <alex_joni> not really ok...
[17:56:07] <alex_joni> that's the make test one :(
[17:56:21] <alex_joni> try checking out in a different dir
[17:56:30] <jmkasunich> ok - that will take a moment
[17:57:21] <alex_joni> * alex_joni is reading configure
[17:57:49] <paul_c> Sounds like the math test is failing...
[17:58:02] <paul_c> Got the Makefile.inc to hand ?
[17:58:24] <jmkasunich> old one or new?
[17:58:31] <paul_c> both
[17:58:33] <alex_joni> paul: seems that on the old configure libm is used with mathstubs
[17:58:43] <alex_joni> on the new only rtlibm is assumed
[17:59:11] <jmkasunich> I will email both Makefile.inc files to both of you
[17:59:18] <alex_joni> should it work on rtai.24.1.x ? (only with rtai_libm.o ?)
[18:04:36] <jmkasunich> mail is on the way
[18:07:53] <alex_joni> I might be wrong, but I think rtai_math.o is for RTAI3.x and rtai_libm.o is for RTAI24.1.x
[18:08:08] <alex_joni> can you paste me the rtapi.conf from scripts/ ?
[18:08:18] <alex_joni> should only have a few lines
[18:08:52] <jmkasunich> can do
[18:09:40] <alex_joni> there should be a rtai_libm at the end
[18:09:46] <jmkasunich> there is, on both
[18:10:20] <alex_joni> yeah.. but on the old version it wasn't used
[18:10:50] <jmkasunich> I can paste if you want, but there are no differences, except that one doesn't set MAN_DIR, and of course they have different EMC2_HOME directories
[18:10:58] <alex_joni> ok...
[18:11:16] <alex_joni> thing is I have RTAI3 here, and there's rtai_math not rtai_libm
[18:11:39] <jmkasunich> * jmkasunich is trying to test the old one, and do a lsmod
[18:11:41] <alex_joni> do a scripts/realtime start
[18:11:54] <alex_joni> and check if rtai_libm gets loaded
[18:12:20] <jmkasunich> nope
[18:12:50] <jmkasunich> but I was able to successfully do "bin/halcmd loadrt siggen"
[18:12:56] <jmkasunich> (siggen uses sin and cos)
[18:14:23] <jmkasunich> and confirmed that the same process (realtime start, loadrt siggen) fails with the current version
[18:14:50] <alex_joni> well... it fails because the configure assumes that rtai_libm gets loaded
[18:15:02] <alex_joni> and siggen finds sin and cos from there
[18:15:05] <jmkasunich> methinks that on this box at least, the modules themselves should have been linked with standard libm - I'm not sure there is a rtai_libm
[18:15:21] <alex_joni> one has been found
[18:15:32] <alex_joni> please check if it really is there
[18:15:38] <jmkasunich> where?
[18:15:43] <alex_joni> in /lib/modules/$KVER/rtai/
[18:16:00] <alex_joni> e.g. /lib/modules/2.4.18-rtai/rtai
[18:16:15] <paul_c> modprobe rtai_libm
[18:16:48] <jmkasunich> modprobe can't find it
[18:16:56] <alex_joni> how about insmod ?
[18:17:20] <jmkasunich> there is no rtai_libm on this box - the old configure _correctly_ decided to use libm instead
[18:18:30] <alex_joni> please check also: /usr/src/rtai-24.1.10/modules/rtai_libm.o
[18:19:09] <alex_joni> or insmod /usr/src/rtai-24.1.10/modules/rtai_libm.o
[18:20:10] <jmkasunich> ls /usr/src/rtai-24.1.10/modules gives:
[18:20:29] <jmkasunich> rtaisyms schedpref
[18:21:51] <alex_joni> this is the test that successes: if (test -r $RTDIR/modules/rtai_libm.o ) || (test USE_RTLIBM) || (test -r /lib/modules/${KERNEL_VERS}/rtai/rtai_libm.o) ; then
[18:22:13] <alex_joni> $RTDIR = /usr/src/rtai-24.1.10
[18:22:36] <alex_joni> ${KERNEL_VERS} = 2.4.18-rtai
[18:22:54] <jmkasunich> * jmkasunich wonders about USE_RTLIBM
[18:23:10] <alex_joni> that gets et only for RTAI-3.x
[18:23:16] <alex_joni> s/et/set/
[18:23:20] <jmkasunich> I'll add some echos to ./configure around that test (break the three way OR into three individual tests)
[18:23:30] <alex_joni> if (test ${RTS##*/} = rtai-config ) ; then
[18:23:30] <alex_joni> if (test -r $($RTS --module-dir)/rtai_math.o ) ; then
[18:23:30] <alex_joni> USE_RTLIBM=1
[18:23:30] <alex_joni> fi
[18:23:30] <alex_joni> fi
[18:27:15] <alex_joni> any more info from the ./configure output?
[18:29:26] <jmkasunich> hmmmm....
[18:29:53] <jmkasunich> in that three way OR.... the second one passed (even tho USE_RTLIBM is blank)
[18:30:39] <jmkasunich> methinks perhaps ( test USE_RTLIBM ) isn't right, perhaps it should be ( test -n USE_RTLIBM )?
[18:30:43] <jmkasunich> * jmkasunich tries it
[18:31:07] <alex_joni> I'll change it to test USE_RTLIBM=1
[18:31:37] <jmkasunich> -n didn't work
[18:32:14] <alex_joni> place a echo $USE_RTLIBM before the test
[18:32:25] <jmkasunich> did that, that's how I know it's blank
[18:32:30] <alex_joni> hmmm
[18:32:36] <jmkasunich> * jmkasunich double checks it
[18:32:41] <alex_joni> test shouldn't be
[18:33:23] <alex_joni> can't seem to get that behavior on test here
[18:33:48] <jmkasunich> found it
[18:34:01] <alex_joni> yes?
[18:34:02] <jmkasunich> need a $ in front of USE_RTLIBM ??
[18:34:07] <alex_joni> :((
[18:34:51] <alex_joni> now that's emberassing...
[18:35:03] <jmkasunich> we've all done it
[18:35:45] <jmkasunich> make in progress, we'll see how it works
[18:36:11] <alex_joni> ok
[18:37:47] <jmkasunich> much better
[18:38:02] <jmkasunich> the real fix needs to be applied in configure.in, right?
[18:38:11] <jmkasunich> (I was editing configure)
[18:38:48] <alex_joni> yeah
[18:38:55] <alex_joni> then you need to run autoconf
[18:39:01] <alex_joni> and commit configure.in and configure
[18:39:07] <jmkasunich> I don't have a working autoconf here
[18:39:15] <jmkasunich> can you change and commit?
[18:39:59] <alex_joni> sure
[18:43:56] <CIA-3> 03alex_joni * 10emc2/ (configure configure.in): fixed a stupid typo that prevented MATH support for rtai-24.1.x
[18:44:55] <alex_joni> working now?
[18:45:02] <jmkasunich> doing the cvs up
[18:45:43] <jmkasunich> configure looks better, make in progress
[18:47:31] <paul_c> * paul_c is off to feed the animals...
[18:47:48] <alex_joni> paul_c: you have a farm too?
[18:48:02] <alex_joni> so jmk is not alone with his farm...
[18:50:38] <jmkasunich> ok, emc2 is running here now (from latest CVS)
[18:51:08] <jmkasunich> * jmkasunich has to empty the clothes dryer, then I'll try to duplicate cradeks jitter problem
[18:51:15] <alex_joni> nice to hear that...
[18:51:30] <alex_joni> I think I'll leave for a while, get a byte myself...
[18:54:59] <alex_joni> * alex_joni will be back later
[19:00:12] <Imperator_> jmkasunich: im reading at the moment a bit how the motion controller is working
[19:00:26] <Imperator_> there is a lot of stuff commended out
[19:00:39] <Imperator_> when do you want to remove that stuff
[19:01:09] <Imperator_> and about screw error compensation, there is up to now no code for that, or ?
[19:05:09] <jmkasunich> the commented out stuff can be removed once we're convinced we don't need it
[19:05:18] <jmkasunich> some could probably go now, some should stay for a while
[19:05:58] <jmkasunich> the screw error stuff consists of two parts: user space code to build a table, and motion controller code to interpolate the table and generate the compensation
[19:06:10] <jmkasunich> I can do the latter rather easily
[19:06:33] <jmkasunich> the former already exists somewhere, but the table format is very poorly documented
[19:06:53] <jmkasunich> it needs a chapter in Code_Notes describing how it works, and then needs coded to match
[19:07:04] <jmkasunich> on my "to do" list, but not real high right now
[19:07:10] <Imperator_> ok
[19:08:09] <Imperator_> the motion code is writen a bit like code for PLCs
[19:09:30] <jmkasunich> what do you mean?
[19:11:44] <Imperator_> every function is executed and the funktion itself has to decide if it has to be execuded
[19:12:06] <Imperator_> for example homing, that function is executed in every cycle
[19:12:10] <jmkasunich> that is a common way of doing realtime coding
[19:12:25] <jmkasunich> the code runs every mS, whether it has something to do or not
[19:12:52] <Imperator_> ok
[19:13:20] <jmkasunich> a homing sequence may take many seconds, but other stuff must continue to be updated
[19:13:30] <Imperator_> then i do it the same with the gantry stuff
[19:14:05] <jmkasunich> so the homing code maintains it's own internal state information. When it gets called every 1mS, it does whatever it has to do, then returns so that other things can be done
[19:14:47] <Imperator_> jep, i see i was just wondering about that
[19:17:24] <jmkasunich> Ah-HA! I've duplicated cradek's problem... now to investigate
[19:23:20] <jepler> yay
[19:26:55] <jmkasunich> well... if you don't specify stepgen.x.maxaccel, then you get the jitter that he saw
[19:27:10] <jmkasunich> if you do specify an appropriate value, it works fine
[19:28:46] <jmkasunich> (and the CVS versions of the ini file don'
[19:28:55] <jmkasunich> don't specify a value - not his fault)
[19:31:02] <jmkasunich> that gets back to one of HAL's weaknesses - config info
[20:07:53] <jepler> People are always asking about USB devices, mostly parallel port devices to drive steppers with. There are these chips, such as ft252 which have a "clock data out at this rate" mode, and a small buffer (128 bytes). It seems like you could have one of these drive a 4-stepper system as long as you do the USB output in real-time
[20:08:21] <jmkasunich> 128 byte buffer is over 1/8 of a second - that is hardly
[20:08:28] <jmkasunich> hardly "real time"
[20:09:23] <jepler> wouldn't it be a lot less than 1/8 second? But anyway, you don't need real-time feedback from the steppers, so if you could queue up the motions a half hour in advance it would be just fine.
[20:09:42] <jmkasunich> emc writes new data to the parport on every period of the step generation thread - that is every 50uS using the default config
[20:10:25] <jmkasunich> those USB abortions that they call "parallel ports
[20:10:33] <jmkasunich> are nothing of the sort
[20:10:46] <jmkasunich> they should really be called "printer ports", because that is all they are
[20:11:06] <jmkasunich> they add a _huge_ pile of bloat and protocols between the code and the real world
[20:11:41] <jepler> Yeah, it would not be fun to write a USB stack again
[20:12:20] <jmkasunich> a real "parallel port" is accessed with an IN or OUT assembly instruction (possibley contained in a C inb() or outb() function), and the actual output changes "instantly" - ie less than a microsecond later, sometimes much less - 10s to 100s of nanoseconds
[20:12:23] <jepler> but ft252 does have a mode where it could clock out a byte every 50uS as long as its FIFO is kept full
[20:12:42] <jmkasunich> how about home switches, and estop, and etc
[20:13:35] <jepler> The toy I use doesn't have home switches.
[20:14:36] <jmkasunich> still - you are talking about using a non-realtime driver to buffer realtime outputs, send them over a comm link, and have them unbuffered at the other end
[20:14:50] <jepler> The ft252 "bit bang" mode can designate certain bits as inputs, when you read it you would know exactly when the edge of the home switch went up compared to the stepper commands
[20:14:52] <jmkasunich> all I can say (as someone who likes embedded and realtime programming) is YUCK!
[20:15:16] <jmkasunich> of course, I also like the ISA bus instead of PCI ;-)
[20:15:24] <jepler> can't get many computers like that anymore
[20:15:37] <jmkasunich> ISA you mean?
[20:15:40] <jepler> yeah
[20:15:43] <jmkasunich> true enough
[20:16:07] <jmkasunich> and PCI isn't so bad once you get past the discovery stage
[20:16:19] <jepler> anyway, isn't the ISA all on the wrong side of a PCI bridge from the CPU, even on Pentium II-era PCI/ISA machines?
[20:16:46] <jmkasunich> yes, but the "wrong side" of the bridge is still a sub-microsecond delay
[20:17:13] <jmkasunich> 33MHz PCI to 8MHz ISA translation probalby only takes 125-250nS
[20:18:24] <jmkasunich> if you are thinking about optimizing the performance of a 2GHz CPU, 125nS is an eternity (250 instructions), but compared to the latency in something like USB, it's really fast
[20:19:05] <jmkasunich> the problem is that the PC has been optimized out the wazoo for fast "average" performance - pipelines, cache, etc
[20:19:16] <jmkasunich> but those things hurt latency
[20:19:55] <jmkasunich> a 33MHz 80386 can have better latency, because it isn't hurt so bad by things like flushing cache lines and pipelines on every interrupt
[20:20:48] <jepler> Well, the design is perfectly appropriate for stuff like word processing & games (where your worst problems are keeping input, video, and audio in good-enough synch that humans don't notice any problems)
[20:21:24] <jmkasunich> exactly - the PC has been optimized for PC type tasks, not for realtime control
[20:21:30] <jmkasunich> the same is true of USB
[20:22:31] <jmkasunich> there are two reasone why PC based controls beat dedicated controls:
[20:22:48] <jmkasunich> 1) very low cost because of mass production
[20:23:36] <jmkasunich> 2) processing power 10-100 times more than is needed, making some inefficiency for the task tolerable because of massive overkill
[20:24:29] <jepler> Yes, now with the other 90 to 99% of the processing power you need to add real-time CSG preview of the work the mill is doing.
[20:24:50] <jmkasunich> not me
[20:25:39] <jepler> no, not you specifically
[20:25:42] <jepler> "someone needs to add"
[20:25:47] <jmkasunich> I know
[20:27:11] <jmkasunich> but my point was partly that the 90-99% is not available - because the PC architecure isn't optimized for low latency, etc, significant cycles are lost, and it takes a lot more CPU to do things than it would if the hardware was designed specifically for machine control
[20:27:52] <jmkasunich> A dedicated Z-80 can do some things better than a 2GHz P4
[20:28:00] <jmkasunich> simply because it is dedicated
[20:28:44] <jmkasunich> and of course dedicated hardware can do even more
[20:29:08] <jmkasunich> example - LS7166 - encoder counter chip, costs around $10 (I think)
[20:29:32] <jmkasunich> it can count encoder pulses faster and more reliably than software running on a $2000 state of the art PC
[20:29:46] <jmkasunich> hi alex
[20:30:04] <alex_joni> hello
[20:30:18] <jmkasunich> found the cause of the jitter
[20:30:24] <alex_joni> * alex_joni is watching election results...
[20:30:31] <alex_joni> that's GREAT news
[20:30:37] <alex_joni> what is it?
[20:31:01] <jmkasunich> the existing config files (specifically core_stepper.hal) do not set the stepgen.x.maxaccel parameter
[20:31:21] <alex_joni> aha..
[20:31:31] <jmkasunich> the stepgen module contains a "pre-tuned" PID loop, but it gets its "tuning" from maxaccel....
[20:32:06] <alex_joni> and because that was not set... the internal PID went berzerk
[20:32:24] <jmkasunich> emc.ini contains a max accel parameter, but that is in inches per second squared, and the HAL stepgen module is unaware of it - the stepgen maxaccel parameter is in steps/sec^2
[20:32:57] <alex_joni> so maxaccel should get calculated from the value in emc.in
[20:32:58] <alex_joni> ini
[20:33:07] <alex_joni> but first it needs converting
[20:33:09] <alex_joni> right?
[20:34:06] <alex_joni> steps/inch should be known in emc.ini
[20:34:18] <alex_joni> INPUT_SCALE / OUTPUT_SCALE
[20:34:52] <jmkasunich> more complicated than that, unfortunately
[20:35:07] <jmkasunich> right now, emc2 doesn't actually use either INPUT_SCALE or OUTPUT_SCALE
[20:35:18] <alex_joni> I know that...
[20:35:23] <alex_joni> we've been discussing that
[20:35:28] <alex_joni> a few weeks ago
[20:35:30] <jmkasunich> * jmkasunich commits a quick and dirty fix for now
[20:36:59] <asdfqweg2> When does jitter become a problem?
[20:37:05] <alex_joni> always ;)
[20:37:13] <alex_joni> jitter is wrong ...
[20:37:15] <jmkasunich> it's not really jitter here - that is a red herring
[20:37:24] <jmkasunich> it was actually PID instability
[20:38:11] <asdfqweg2> I've been kinda following what's been going on, and I think I had possibly something similar happen to me with emc1
[20:38:46] <asdfqweg2> But that was because I hadn't done the tuning on a per axis basis
[20:39:42] <asdfqweg2> [but I digress]
[20:40:07] <asdfqweg2> I've read about the timing jitter in emc, and seen the charts
[20:40:46] <asdfqweg2> Like I was asking...at what point does jitter become a problem?
[20:40:49] <CIA-9> 03jmkasunich * 10emc2/configs/ (core_stepper.hal xylotex_pinout.hal): added maxaccel values to config data, to correct problems with stepgen instability. Stepgen has a "pre-tuned" PID loop built in, but it gets its tuning from stepgen.x.maxaccel, so that must be a reasonable value
[20:43:33] <asdfqweg2> Never mind that question...I'm tired and not thinking straight
[20:46:39] <alex_joni> jmk: busy?
[20:48:36] <jmkasunich> I'm here
[20:48:58] <jmkasunich> what's up?
[20:49:21] <alex_joni> was wondering if you got time to talk a little bit about what could/should get done
[20:49:42] <jmkasunich> I suppose
[20:49:47] <alex_joni> I added a tracker on SF
[20:50:09] <alex_joni> but I think I should remove it, I managed to get make install work without that one
[20:51:05] <alex_joni> I was wondering what else on a to-do list is
[20:51:14] <alex_joni> HW drivers
[20:51:19] <alex_joni> make install
[20:51:48] <jmkasunich> config issues, I think
[20:52:13] <jmkasunich> documentation, documentation, documentation
[20:53:47] <alex_joni> is there documentation on the autoconf stuff needed?
[20:53:55] <alex_joni> I tried to document the file itself
[20:54:45] <jmkasunich> I haven't read thru the file in detail, but what I've seen so far seems pretty good
[20:55:49] <jmkasunich> configure.in seems _very_ well documented
[20:56:47] <alex_joni> well thank you ;)
[20:56:57] <alex_joni> I tried ...
[20:57:55] <jmkasunich> is Makefile.inc still stored on CVS, or is it now always created locally when you do ./configure?
[20:58:02] <alex_joni> jmk: a LS7166 is a little more expensive ;)
[20:58:11] <alex_joni> Makefile.inc is generated by configure
[20:58:29] <jmkasunich> so the original one has been deleted from CVS?
[20:58:32] <alex_joni> before configure is run, there is no way a clean checkout can be compiled
[20:58:54] <alex_joni> but it's not created from scratch anymore
[20:59:10] <alex_joni> like it was first (using echo > Makefile.inc)
[20:59:29] <alex_joni> now it is created from Makefile.inc.in by replacing the proper values
[20:59:50] <jmkasunich> duh - I forgot about the echo > Makefile.inc stuff - it never was in CVS
[20:59:57] <alex_joni> yup
[21:00:08] <alex_joni> that's why we (me & paul) asked you for both files
[21:00:31] <alex_joni> because both were created on your machine
[21:01:32] <alex_joni> * alex_joni bought some LS7166 with 16 squid / piece
[21:02:11] <jmkasunich> * jmkasunich was just using it as an example - still lots cheaper than a P4 ;-)
[21:02:24] <alex_joni> yeah.. and a thousand time more reliable
[21:02:39] <alex_joni> I used at first some simple counters (24 bit)
[21:02:46] <alex_joni> also HW
[21:03:09] <alex_joni> but the LS just works more reliable (does a lot of filtering & such)
[21:03:23] <jmkasunich> perhaps some comments in README about how we used autoconf, explaining the relationship between configure.in and configure, and between Makefile.inc.in and Makefile.inc?
[21:03:35] <alex_joni> that sounds resonable
[21:03:59] <jmkasunich> maybe it's time for an INSTALL in the top level directory?
[21:04:08] <alex_joni> neah... I disagree
[21:04:13] <jmkasunich> to go with README and COPYING, etc?
[21:04:25] <alex_joni> INSTALL is far from decided
[21:04:42] <jmkasunich> well INSTALL is usually the file where you read installation instructions
[21:04:47] <alex_joni> yeah
[21:04:56] <jmkasunich> (avoids cluttering up README with such details)
[21:04:57] <alex_joni> well right now you have no installation
[21:05:00] <alex_joni> right?
[21:05:13] <alex_joni> but I agree a INSTALL file should get eventually added
[21:05:23] <jmkasunich> but most programs I've downloaded have building and installing instructions both in INSTALL
[21:05:34] <alex_joni> right now it could only say: install issues are not decided yet
[21:05:39] <alex_joni> building too?
[21:05:44] <jmkasunich> yeah
[21:05:51] <jmkasunich> * jmkasunich checls
[21:05:56] <alex_joni> hmmm.. that could be...
[21:05:56] <jmkasunich> * jmkasunich checks
[21:06:13] <alex_joni> checls is just as right as checks for me ;)
[21:07:06] <alex_joni> how is the message at the end of ./configure?
[21:07:15] <alex_joni> does it sound ok to you?
[21:07:39] <jmkasunich> seems OK to me... some purists won't like it - some folks really don't like boxed comments
[21:07:48] <alex_joni> well...
[21:07:55] <alex_joni> it's easy to read like that
[21:08:07] <alex_joni> and to separate it from the normal ./configure output
[21:08:14] <jmkasunich> I like them myself, have used them a lot in my code
[21:09:19] <jmkasunich> I just checked a couple of packages here (IIRC, modutils, etc), and the INSTALL file contains all instructions for building and installing
[21:09:32] <jmkasunich> I'll mail you a couple samples
[21:10:17] <alex_joni> I opened my devel box ...
[21:10:26] <alex_joni> having a look at some sample apps
[21:14:20] <alex_joni> * alex_joni agrees on INSTALL
[21:14:33] <alex_joni> I am reading about make distclean
[21:14:41] <jmkasunich> re: the message at the end of configure...
[21:14:41] <alex_joni> that should get added to Makefile
[21:14:51] <alex_joni> yes?
[21:15:07] <jmkasunich> I'd recommend telling them to do make, followed by a separate line to run it (or install it)
[21:15:25] <jmkasunich> instead of "make && scripts/run"
[21:15:29] <alex_joni> ok
[21:15:33] <alex_joni> compiling: make
[21:15:36] <jmkasunich> they'll likely have to be root to run it
[21:15:42] <alex_joni> running: scripts/emc.run
[21:15:46] <jmkasunich> those details could be in INSTALL anyway
[21:15:54] <alex_joni> emc.run will tell them that they need to be root
[21:16:02] <alex_joni> * alex_joni is starting INSTALL
[21:17:10] <alex_joni> lol... I love this...
[21:17:47] <alex_joni> "If I were you, I would not trust a make install. If you feel courageous, just do make install. It may even do the right thing."
[21:18:02] <alex_joni> taken from INSTALL (wireless-tools)
[21:18:06] <jmkasunich> lol
[21:18:42] <alex_joni> that's so ... appropriate
[21:20:43] <jmkasunich> * jmkasunich has to work on some actual metalworking now ;-)
[21:21:11] <jmkasunich> finishing up the Z-axis ballscrew mechanism for my CNC conversion
[21:21:33] <jmkasunich> which I haven't touched since over a year ago :-(
[21:21:59] <alex_joni> ouch
[21:22:44] <jmkasunich> need to use the machine... the old Z axis mechanism (rack and pinion, like a drill press) has been removed, and the new one isn't finished yet
[21:22:59] <alex_joni> seems that standard is like this: Additionally, the INSTALL, NEWS, README, COPYING, AUTHORS and ./ChangeLog files need to be created
[21:23:16] <jmkasunich> I've been using my Van Norman mill for all milling since then, but it doesn't do small mills will (like 3mm) cause the spindle is too slow
[21:23:38] <jmkasunich> README and COPYING are there already (I think)
[21:23:53] <jmkasunich> the others can wait a while probably
[21:24:46] <alex_joni> yup
[21:27:26] <alex_joni> a GPL-info should be placed at the begining of configure.in... right?
[21:28:19] <jmkasunich> probably
[21:28:36] <jmkasunich> maybe just a one liner:
[21:29:01] <jmkasunich> "this file is released under the GPL, see COPYING for more details"
[21:29:26] <alex_joni> ok.. will add that too
[21:31:12] <paul_c> Most of the files are already in docs - No need to clutter up the root dir with duplicates
[21:31:56] <jmkasunich> ahhh... they are (including an empty INSTALL)
[21:32:31] <jmkasunich> then the top level README should be changed to point the user to the files in /docs
[21:32:47] <jmkasunich> (there is some build info in README that should be moved to INSTALL
[21:32:47] <alex_joni> * alex_joni moves the INSTALL to /docs
[21:33:27] <paul_c> and COPYING can be deleted from the root - It is just duplicate
[21:41:15] <alex_joni> there is a README in docs/
[21:41:31] <alex_joni> should README from the root be removed aswell?
[21:44:30] <paul_c> remove the one in root....
[21:44:35] <alex_joni> ok
[21:44:48] <paul_c> or reduce it to one sentence
[21:45:01] <paul_c> "Please see docs/README"
[21:45:52] <alex_joni> ok
[21:45:53] <jmkasunich> IMO, README in root is the first place folks will look - don't remove it
[21:46:10] <alex_joni> I'll go with the see docs/README approach
[21:46:16] <jmkasunich> you can reduce it to one line, but why not eliminate the one in docs instead
[21:46:28] <alex_joni> because all other files are there
[21:46:41] <alex_joni> INSTALL, COPYING, AUTHORS
[21:47:02] <alex_joni> well.. actually I'm ok with either one
[21:47:14] <alex_joni> either /README or docs/README
[21:47:22] <jmkasunich> many programs have all of those files in the root dir
[21:47:25] <paul_c> hi I just requested to join the emc user group ,but I have received an automatic answer saying there are problems .Can you clear them?
[21:47:25] <paul_c> thanks Mario Zito
[21:47:33] <paul_c> It reduces the cruft in the top level dir.
[21:47:52] <alex_joni> what problems?
[21:48:04] <jmkasunich> true - but don't reduce it to the point that the newbie can't find it
[21:48:23] <alex_joni> paul: what do you think of "If I were you, I would not trust a make install. If you feel courageous, just do make install. It may even do the right thing."
[21:48:24] <paul_c> Ignore the previous lines - cut'n'pasted the wrong bit....
[21:48:47] <jmkasunich> I already replied to Mario, asking him to send the error message he got
[21:49:30] <paul_c> * paul_c added his name to the list and blamed any probs on the SF servers..
[21:50:15] <jmkasunich> I saw that - paul_c is kinder than me
[21:50:57] <jmkasunich> "if you can't do it yourself, I'll be damned if I'm gonna do it for you"
[21:51:28] <paul_c> alex_joni: If "make install" is unpredictable, then it should NOT be enabled
[21:51:48] <alex_joni> paul: that was a quote from another software
[21:51:52] <jmkasunich> he's was quoting from the INSTALL file of another package
[21:52:14] <alex_joni> (wireless-tools)
[21:52:28] <alex_joni> I'd never put such a statement in a file...
[21:52:41] <alex_joni> I'd rather remove the broken functionality
[21:53:10] <alex_joni> ok.. so README in root or in docs/ ?
[21:53:19] <alex_joni> or both for now?
[21:53:19] <paul_c> docs/
[21:53:28] <jmkasunich> with a one-liner in root
[21:54:10] <paul_c> The only need for a README & INSTALL in the top level dir is to keep automake happy.
[21:54:39] <alex_joni> but there is no automake... so ... we can skip this step
[21:54:40] <paul_c> But that can be done by the configure script IF it is needed.
[21:54:45] <jmkasunich> I disagree - they are there to help HUMANS
[21:55:02] <jmkasunich> at least the first README is
[21:55:17] <paul_c> So point them to the docs/
[21:56:30] <jmkasunich> newbie software install process: download, untar, read README, read INSTALL, install.... once they're no longer newbies, they might skip the README and INSTALL steps, but it is at their peril, especially for stuff like EMC that needs a realtime kernel
[21:58:51] <alex_joni> ok I added some info, and changed some.. I'll commit now
[22:03:26] <CIA-9> 03alex_joni * 10emc2/ (configure.in configure README docs/README docs/INSTALL): added/changed some descriptions in README and INSTALL. changed the message at the end of configure
[22:07:16] <alex_joni> does INSTALL sound ok?
[22:07:45] <jmkasunich> copied it from another package?
[22:08:36] <alex_joni> some parts
[22:09:00] <alex_joni> it is a standard INSTALL for autoconf-enabled packages
[22:09:48] <jmkasunich> 3) to run the software issue: scripts/emc.run
[22:10:00] <jmkasunich> should tell them they need to be root
[22:10:26] <jmkasunich> (and maybe why: "because EMC installs kernel modules to handle it's realtime functions")
[22:11:49] <alex_joni> changed
[22:12:13] <jmkasunich> * jmkasunich seems to have misplaced a set of 6" dial calipers
[22:12:38] <jmkasunich> I hate it when that happens - they're probably right in front of my face, but I can't seem to find them
[22:13:18] <alex_joni> * alex_joni hands over a locating device
[22:14:26] <alex_joni> * alex_joni is watching marbles again... ;)
[22:15:08] <jmkasunich> * jmkasunich lost the locating device
[22:16:12] <jmkasunich> found 'em
[22:16:22] <alex_joni> probably it's just next to the caliper
[22:16:49] <alex_joni> * alex_joni wonders who will take a look at make install...
[22:16:51] <jmkasunich> in the box, where they belong - I could of sworn that box was empty 5 minutes ago
[22:17:23] <jmkasunich> * jmkasunich needs to get this ballscrew finished this weekend
[22:17:23] <alex_joni> THEY must have put it there
[22:18:22] <alex_joni> yeah... and paul is busy on the BDI (which is more important than make install right now)
[22:28:38] <alex_joni> * alex_joni is going bye-bye
[22:30:43] <alex_joni> night
[23:57:41] <cradek> jmkasunich: thanks for fixing my bug, I'm going to go test it soon
[23:58:00] <cradek> jmkasunich: I submitted the unwanted-jog-after-ESC to the tracker.