Back
[00:11:23] <jmkasunich> well, about 12 people have told me that I can't read numbers, but we still don't know the guy's accel and velocity limits
[00:11:48] <jmkasunich> I bet his accel is too low for what he's asking it to do, but I'm not gonna speculate till I see the numbers
[00:21:30] <jmkasunich> * jmkasunich pulled a cradek ;-)
[02:05:44] <jmkasunich> I wonder if we can put in some test that will simply and clearly say "hey, dude, you aren't running a realtime kernel"
[02:05:58] <jmkasunich> dunno how many times we've had to interpret that long error listing for someone
[02:11:10] <LawrenceG> maybe a bsod would be more familiar :}
[02:11:53] <LawrenceG> hi John
[02:11:59] <jmkasunich> hi
[02:12:52] <LawrenceG> A little gtk reminder window would be polite
[02:13:14] <jmkasunich> eww
[02:13:20] <jmkasunich> I wasn't thinking of anything GUI
[02:13:29] <jmkasunich> just a message early in the process, and then quit
[02:13:42] <jmkasunich> instead of printing 1000 lines of stuff that they have no clue how to read
[02:15:05] <jmkasunich> actually if I wasn't sort of trying to make some parts, I'd write a wiki page on "how to make grub pick the right kernel"
[02:15:48] <jmkasunich> IIRC it takes a couple of incantations to keep ubuntu kernel updates from resetting the default to the newest (non-rt) kernel
[02:52:56] <cradek> about earlier: we should name our kernel so it's alphabetically before -generic ... or whatever worked on breezy and dapper
[02:53:55] <jmkasunich> I don't think grub sorts alphabetically
[02:54:22] <cradek> well somehow this is a new problem - it would be nice to figure out why
[02:54:25] <jmkasunich> there are those stupid comments that aren't comments in menu.lst, and the updater reads them (among other things), then rewrites menu.lst
[02:54:33] <cradek> yeah I know how it works
[02:54:43] <cradek> but on dapper, -magma always ended up on top, and the default
[02:55:01] <cradek> it was the same on breezy
[02:55:36] <cradek> maybe the last-installed kernel was the default?
[02:56:18] <jmkasunich> ISTR that I had to put the magma kernal at the top of the list on my dapper box
[02:56:38] <jmkasunich> I started with stock dapper and used the install script - I think people with the liveCD aren't having this problem
[02:56:40] <cradek> Linux 2.1.21 1995-01-14 BOOTPARAM(7)
[02:56:47] <cradek> hm, that'll be a useful man page
[02:56:56] <cradek> maybe I am wrong then.
[02:57:20] <cradek> I thought the rt always became default.
[02:58:29] <jmkasunich> looking at the shoptask, -magma is at the top of the list, followed by -52, -51, -29, etc
[02:58:45] <jmkasunich> the ubuntu updates have been sticking the other kernels at the 2nd spot in the list
[02:58:54] <cradek> yep that's how I remember it
[02:58:59] <cradek> I wish that was still the case
[02:59:06] <cradek> no idea how it picks.
[02:59:32] <jmkasunich> what is making it respect the first spot I wonder? if I didn't have a rt kernel, it certainly would be putting the new kernel at the top
[03:00:47] <cradek> man update-grub was not helpful
[03:01:08] <jmkasunich> I was just reading that
[03:02:52] <jmkasunich> there are two no-brainer edits to menu.lst
[03:03:00] <jmkasunich> set timeout to something more than three seconds
[03:03:07] <jmkasunich> and comment out "hiddenmenu"
[03:07:14] <cradek> found it in /sbin/update-grub
[03:07:22] <cradek> there is an immensely complex way of sorting the entries
[03:07:43] <cradek> see CompareVersions()
[03:08:34] <cradek> I bet -magma > -generic > -rtai or something like that
[03:09:34] <jmkasunich> how
[03:09:42] <cradek> later in update-grub it does some kind of insertion sort (I think)
[03:10:02] <jmkasunich> I see code to give weights based on the suffix, but all three of those should get 99 as a weight
[03:10:07] <cradek> I have no idea, I can't follow CompareVersions (and it might be different dapper vs hardy)
[03:10:16] <cradek> are you looking on hardy?
[03:10:17] <jmkasunich> true, I'm looking at dapper
[03:10:40] <jmkasunich> don't have a hardy box here
[03:11:44] <cradek> it is different
[03:12:42] <cradek> http://pastebin.ca/1208938
[03:13:42] <cradek> what is the name of the generic kernel? (no email here still)
[03:14:07] <jmkasunich> 2.6.24-19.41-generic
[03:14:17] <jmkasunich> vs. 2.6.24-16-rtai
[03:14:29] <jmkasunich> its probably the 19 vs 16
[03:14:30] <cradek> http://article.gmane.org/gmane.linux.distributions.emc.user/9245
[03:14:42] <cradek> yeah look at this. the order in "Found kernel" is blindingly obvious
[03:15:58] <jmkasunich> for dapper, our kernel only had 3 numbers
[03:16:05] <jmkasunich> 2.6.15-magma
[03:16:15] <jmkasunich> vs 2.6.15-52-386
[03:17:09] <cradek> maybe "m" > "5"
[03:17:17] <jmkasunich> and yet again, in their blind zeal to make things "easier", the proverbial "they" are fscking with things in a way that takes control away from the user
[03:17:52] <cradek> the hardy comparison is documented - we "just" have to rename our kernel and this recurring problem goes away
[03:18:32] <jmkasunich> rename it how? we'd have to drop the -16?
[03:18:52] <cradek> no I don't think that would do it
[03:19:28] <jmkasunich> # Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST
[03:19:42] <jmkasunich> what if we stuck our entry outside the magic list?
[03:19:56] <cradek> that would not be the debian way
[03:20:05] <jmkasunich> sigh
[03:20:18] <cradek> and I have no desire to do ad-hoc parsing and rewriting of a pseudo-auto-generated config file
[03:20:28] <cradek> that's what update-grub is for
[03:20:39] <jmkasunich> I wasn't about to suggest that
[03:20:40] <cradek> someone else has written all that suck already
[03:20:53] <jmkasunich> more like "edit your menu.lst like so" on the wiki
[03:21:31] <cradek> if your goal is to reduce the users' pain and our having to constantly answer this question, that won't accomplish it
[03:21:36] <jmkasunich> but you are right, that doesn't solve the user's problem, it just solves our support problem by giving us a URL to paste at them
[03:22:36] <cradek> alex_joni: if you rebuild the kernel for that usb driver thingy, let's see if we can figure this out
[03:23:17] <jmkasunich> one of these days I need to get hardy on some computer
[03:23:30] <cradek> my lathe is hardy - it works just fine
[03:23:51] <jmkasunich> yeah, but that was easy, you were starting fresh
[03:23:57] <jmkasunich> my machine is dapper and works
[03:24:00] <cradek> yes it was simple
[03:24:09] <cradek> ah, like my laptop, it'll be dapper for a while still.
[03:25:09] <jmkasunich> this machine is my "main" computer - where I put all my photos and documents, where I do most stuff, it runs my webserver and blog and the compile farm and win95 vm
[03:25:21] <jmkasunich> I sure don't feel like converting it over anytime soon
[03:26:13] <cradek> yeah, just use it for your next project. upgrades suck.
[03:26:54] <jmkasunich> at least I sort of have backup
[03:27:18] <jmkasunich> "sort of" means I run a backup when I remember to, probably once every week or two
[03:27:39] <cradek> I had a drive crash the other day
[03:27:44] <cradek> the machine I ran the mill with
[03:28:00] <cradek> sadly I lost my (10 line) script that sends a program to it
[03:28:12] <jmkasunich> 10 tricky lines, right?
[03:28:34] <cradek> maybe a bit. I don't quite remember how it worked.
[03:28:50] <jmkasunich> sounds like a good reason to convert the mill to EMC2 ;-)
[03:28:53] <cradek> it'll take me 20 minutes to recover, but it pisses me off that I didn't have a copy of it.
[03:29:19] <cradek> all the very trickly autolisp was in my cvs so it's safe.
[03:29:23] <cradek> tricky
[03:29:32] <cradek> losing that would be conversion time for sure :-)
[03:30:00] <jmkasunich> cvs rm trickly_autolisp; cvs commit "time to convert"
[03:30:06] <cradek> ha
[04:04:29] <tfmacz> anyone running emc2 on a dual or quad core cpu?
[04:17:50] <LawrenceG> ted! skype?
[04:18:02] <LawrenceG> tfmacz, skype?
[06:08:29] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9:
[06:08:29] <CIA-40> EMC: This checkin fixes the pwmgen problem reported by Eric Johnson
[06:08:29] <CIA-40> EMC: (cut-n-paste error).
[06:08:29] <CIA-40> EMC: Adds a pwmgen.frequency parameter, so the user can control the pwm
[06:08:29] <CIA-40> EMC: frequency.
[06:08:30] <CIA-40> EMC: Fixes a buglet in watchdog initialization error handling.
[06:08:34] <CIA-40> EMC: Turns off an annoying stepgen debug message.
[06:08:36] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog hostmot2.h pwmgen.c stepgen.c watchdog.c):
[06:08:39] <CIA-40> EMC: This checkin fixes the pwmgen problem reported by Eric Johnson
[06:08:41] <CIA-40> EMC: (cut-n-paste error).
[06:08:43] <CIA-40> EMC: Adds a pwmgen.frequency parameter, so the user can control the pwm
[06:08:45] <CIA-40> EMC: frequency.
[06:08:47] <CIA-40> EMC: Fixes a buglet in watchdog initialization error handling.
[06:08:49] <CIA-40> EMC: Turns off an annoying stepgen debug message.
[07:07:17] <Lerman__> Lerman__ is now known as Lerman
[08:05:01] <ssaneva> hello! =) good morning
[12:09:26] <jepler> tfmacz: the 32-bit realtime kernels do not have *any* support for more than one CPU or core. They will treat a dual- or quad-core machine like a single-core CPU. The 64-bit realtime kernel should work with up to 8 cores, but in my experience it's unstable (crashes once a week or so), so I don't recommend it.
[12:10:11] <jepler> (also there's no live cd for it and I don't recall whether emc-install.sh works or not. you might be stuck doing the apt-get setup and initial install by hand rather than through the script)
[15:49:48] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[18:13:17] <cradek> jepler: I noticed last night that you can't pause during a G95 move...
[18:13:25] <cradek> that was a feature for threading
[18:26:13] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/po/it_axis.po: additional translation updates from Manfredi Leto
[18:27:22] <jepler> .. including a full translation for stepconf:
http://emergent.unpy.net/index.cgi-files/sandbox/it_stepconf.png
[19:25:41] <alex_joni> jepler: seems I didn't get time to work on a new kernel today..
[19:25:53] <alex_joni> but I'll be back on saturday evening, so I hope on sunday
[20:00:01] <alex_joni> hi seb_kuzminsky
[20:00:55] <seb_kuzminsky> hi alex
[20:01:39] <seb_kuzminsky> so it sounds like the following error you were helping me with earlier "went away" without any changes to the driver, just the users playing with the ferror params
[20:05:54] <alex_joni> oh, that's great
[20:07:27] <alex_joni> it's always best if it turns out to be an operator error :)
[20:07:34] <alex_joni> or user
[20:07:50] <seb_kuzminsky> i added the "infinite accel" feature we talked about (maxaccel=0) but maybe it's not needed now
[20:08:37] <alex_joni> it was the case with the software stepgen that you HAD to have some headroom
[20:08:54] <alex_joni> so that only went away when jmkasunich implemented the maxaccel=0/maxvel=0
[20:09:03] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (interp_convert.cc interp_internal.hh rs274ngc_pre.cc): (log message trimmed)
[20:09:03] <CIA-40> EMC: make tool change a bit more flexible. now, at tool change:
[20:09:03] <CIA-40> EMC: if [EMCIO]TOOL_CHANGE_WITH_SPINDLE_ON is not 1, the spindle is turned off.
[20:09:03] <CIA-40> EMC: if [EMCIO]TOOL_CHANGE_QUILL_UP is 1, Z is moved to machine zero (like G0 G53 Z0)
[20:09:05] <CIA-40> EMC: if [EMCIO]TOOL_CHANGE_AT_G30 is 1, the machine is moved to reference point 2 (like G30)
[20:09:07] <CIA-40> EMC: if [EMCIO]TOOL_CHANGE_POSITION is defined, the machine is moved to that position (like the old behavior)
[20:09:10] <CIA-40> EMC: any combination of these settings is acceptable. for instance:
[20:09:59] <alex_joni> seb_kuzminsky: gotta run and pack ..
[20:10:06] <alex_joni> getting up in ~5 hours
[20:10:09] <seb_kuzminsky> see you alex
[20:11:36] <cradek> BigJohnT: would you do your magic with those please?
[20:12:02] <alex_joni> heh, it's getting way easier to write docs these days..
[20:12:05] <alex_joni> right cradek ?
[20:12:08] <cradek> haha
[20:12:20] <seb_kuzminsky> heh
[20:12:27] <cradek> I've also noticed it's easy to add features if I don't ask anyone else first what they think
[20:12:54] <BigJohnT> hi cradek
[20:12:56] <cradek> brb
[20:13:00] <BigJohnT> whats up
[20:14:52] <BigJohnT> * BigJohnT scrolls up and reads
[20:20:21] <BigJohnT> * BigJohnT sends an e-mail to me to remind me to do it.... :)
[20:20:51] <BigJohnT> * BigJohnT goes to look at a Goldwing
[20:27:43] <jepler> cradek: looks interesting .. so on mazak you'd use TOOL_CHANGE_QUILL_UP instead of TOOL_CHANGE_POSITION?
[20:28:04] <cradek> you probably want both
[20:28:09] <cradek> first up, then over to the corner to clear the work
[20:29:07] <cradek> on a manual tool change machine, you might want just up
[20:29:37] <cradek> the BOSS does something like up + G30. you can move the machine where you want and push the "tool changes are here now" button
[20:29:53] <cradek> (but it always goes up first)
[20:30:18] <jepler> for my machine I only want Y and Z to move -- I want the spindle at the front of the machine and as far up as possible, but I don't care much where it is "across"
[20:30:20] <cradek> with emc, to get that, you'd put UP + G30 in the inifile, and then use G30.1 for "tool changes are here now"
[20:30:44] <jepler> (I actually put G28 and the toolchange in that same front position, and use G30 for the TLS location near the back of the table)
[20:30:57] <cradek> a nice addition would be for you to be able to specify which axes move for TOOL_CHANGE_POSITION
[20:31:33] <cradek> but really it probably takes no longer to move X,Y than to move Y
[20:31:52] <cradek> we could also add _AT_G28
[20:32:06] <cradek> but if you had both _AT_G28 and _AT_30, what happens?
[21:02:18] <jepler> you're right about it rarely being longer to move all 3 axes than just Y and Z
[21:02:21] <jepler> the existing is fine for me
[21:08:41] <alex_joni> see you guys on sunday (if I don't find any internet sooner..)
[22:00:12] <cradek> have a safe trip
[22:01:35] <cradek> according to sf emc-commit archives, the last message was on the 15th
[23:34:30] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: oops, finish the leave-spindle-on change
