Back
[00:59:09] <jmkasunich> hi y'all
[00:59:55] <skunkworks> Hey - how have you been?
[01:00:37] <skunkworks> Nice pictures from your new camera
[01:00:56] <jmkasunich> thanks
[01:03:40] <jmkasunich> "Version 2.6.15-23.35:
[01:03:40] <jmkasunich> This IS the final dapper kernel. There have been many kernels like this, but
[01:03:40] <jmkasunich> this one superceeds them all"
[01:06:19] <fenn> there are many kernels like this, bus this one is mine
[01:07:41] <fenn> it is my life. i must master it as i must master my life. without me the kernel is useless. without the kernel i am useless.
[01:10:24] <jmkasunich> ;-)
[01:48:57] <cradek> hi guys
[01:50:38] <SWPadnos> hi
[01:59:07] <cradek> did you see CL since noon?
[01:59:35] <cradek> it no longer sucks :-)
[02:00:07] <SWPadnos> some time after Teusday, I'll actually have the time to boot a Linux machine again ;)
[02:03:15] <cradek> well wtf. the lube thing works here
[02:03:44] <SWPadnos> different computer?
[02:03:44] <cradek> nope, not all the time. good (I guess)
[02:03:47] <cradek> yes
[02:03:55] <cradek> it usually works here, rarely works on the other one
[02:04:03] <SWPadnos> oh good. repeatable intermittent operation is really what you want
[02:04:09] <cradek> what irritating bugs
[02:04:12] <SWPadnos> heh
[02:04:30] <SWPadnos> isn't there some NML monitoring program?
[02:05:08] <SWPadnos> to see if the messages are not getting sent, lost in "transmission" , or ignored
[02:05:23] <cradek> I wish I knew how to debug it easily
[02:05:33] <cradek> I pretty much don't
[02:05:38] <SWPadnos> have you looked at RCSlib lately?
[02:05:48] <cradek> no
[02:05:49] <SWPadnos> there may be helpful utilities there
[02:06:23] <SWPadnos> http://www.isd.mel.nist.gov/projects/rcs/
[02:06:47] <SWPadnos> someone recently posted that link on the Geckodrive list, message subject "sdk for realtime on c++"
[02:06:56] <SWPadnos> I kind of set him straight ;)
[02:07:49] <cradek> wow that's some impressive misunderstanding
[02:08:06] <SWPadnos> heh
[02:08:36] <SWPadnos> he was talking about making a Windows program that would issue step/dir pulses on a parallel port, but have a somewhat tailored front end for bonehead users
[02:14:36] <fenn> sure, just run wine :P
[02:54:54] <SWPadnos> diplomatic :)
[02:55:15] <cradek> haha
[02:55:20] <cradek> seems very honest to me
[02:55:25] <SWPadnos> yep, very
[02:55:32] <SWPadnos> 2 funny 4 me
[02:57:56] <cradek> speaking of terrible ideas, I just added a trivial "quill up" input bit to halui. It just sends an mdi command and is intended to be hooked to a button. (BOSS has this). Should I check it in, or keep my kludges to myself?
[02:58:29] <SWPadnos> hmmm
[02:58:49] <jmkasunich> what happens if you aren't in MDI mode?
[02:58:55] <cradek> it switches to mdi
[02:58:56] <SWPadnos> what if you made it so it would issue any command with MDI - use some text or label attribute to set the command string
[02:59:11] <cradek> halui doesn't have text or labels
[02:59:23] <SWPadnos> oh right. I'm thinking of pyvcp
[02:59:26] <SWPadnos> hmmm
[02:59:28] <cradek> it's nasty, forget it
[02:59:48] <SWPadnos> ok. I think something that can do the arbitrary command thing would be great
[02:59:52] <cradek> it's great for knee mills, but inappropriate as a general purpose gui function
[03:00:01] <cradek> ui
[03:00:12] <SWPadnos> but G0Z0 hardcoded may not be all that useful esewhere
[03:00:23] <cradek> G0 G53 Z0
[03:00:30] <jmkasunich> the ability to map a button to a user specified MDI command is much more interesting
[03:00:36] <SWPadnos> same differential ;)
[03:00:41] <cradek> of course it is more interesting
[03:00:44] <SWPadnos> heh
[03:00:57] <jmkasunich> perhaps [HALUI] cmd1="G0 G53 Z0" cmd2="foo", etc
[03:01:13] <cradek> bleh
[03:01:16] <SWPadnos> MDICMD
[03:01:21] <SWPadnos> so much better that waty
[03:01:24] <SWPadnos> way
[03:01:29] <jmkasunich> for item_in_halui_section, export HAL pin
[03:01:54] <SWPadnos> one more thing to stick in some single file uber-config-format
[03:02:22] <cradek> huh, halui does read the ini already, that's clearly the way to do it
[03:02:28] <jmkasunich> I was just proposing an (optional) section in the existing ini file
[03:02:32] <cradek> right
[03:02:53] <SWPadnos> sure - it's the easiet path to that functionality
[03:03:35] <SWPadnos> but then you need the HAL pin name (or just halui.mdifunc.0.in ...)
[03:03:53] <SWPadnos> but that's not safe if someone adds a function
[03:03:56] <SWPadnos> ...
[03:07:55] <fenn> or any set of hal signals to an arbitrary command and arguments
[03:08:27] <fenn> scuse me. hal component that sends a nml command or shell command or whatever
[03:10:05] <fenn> you'd have to have at least one bit "trigger"
[03:11:32] <fenn> and a load time specified number of argument pins
[03:23:00] <fenn> i guess you can send any nml command with emcsh... ...
[03:42:49] <SWPadnos> cool!
[03:43:06] <SWPadnos> maybe I should think of some more things to request tonight :)
[03:50:38] <cradek> the hardcoded max makes me a little unhappy, but it was easy
[03:53:06] <SWPadnos> eh - easy enough to increase, and probably not too terrible to make dynamic
[03:53:46] <cradek> now I wonder why I used %02d if they are 0-9
[03:53:55] <SWPadnos> planning for the future
[03:54:10] <SWPadnos> when someone makes it go to 11
[03:54:22] <cradek> ok, that's a good answer
[03:54:44] <SWPadnos> the thing that concerns me is that the pin naming is automatic
[03:55:04] <SWPadnos> which requires that you add only to the bottom of the list, or all your buttons do the wrong thing
[03:55:31] <cradek> what do you propose?
[03:55:46] <SWPadnos> one of 3 things:
[03:55:58] <SWPadnos> MDI_COMMAND1= blah blah
[03:56:07] <SWPadnos> MDI_COMMAND = 1:blah blah
[03:56:22] <SWPadnos> (or better, = "pinname:blah blah"
[03:56:22] <SWPadnos> )
[03:56:35] <cradek> pin name would be nice
[03:56:41] <SWPadnos> or something else I don't remember at the moment
[03:56:57] <SWPadnos> oh - separate values:
[03:57:04] <SWPadnos> MDI_COMMAND_NUM = 1
[03:57:11] <SWPadnos> MDI_COMMAND = yadda yadda
[03:57:18] <SWPadnos> but that's not so nice
[03:57:29] <cradek> MDI_COMMANDS = QUILL_UP REFERENCE_POINT CLEAR_POINT
[03:57:36] <cradek> QUILL_UP = G0 G53 Z0
[03:57:42] <SWPadnos> heh
[03:57:46] <cradek> => halui.quill-up
[03:57:55] <cradek> I'm not entirely kidding
[03:58:17] <cradek> that might be a bit baffling though
[03:58:43] <SWPadnos> yeah, and where do all the macro names and functions come from?
[03:58:46] <cradek> I meant there would also be REFERENCE_POINT = G28 etc etc
[03:58:49] <SWPadnos> or were those placeholders?
[03:58:56] <SWPadnos> ah, ok
[03:59:02] <cradek> those are lines in [HALUI]
[03:59:13] <SWPadnos> sort of a second pass through the relevant ini sections
[03:59:33] <SWPadnos> symbol pass then substitution pass
[03:59:43] <cradek> yeah
[03:59:55] <cradek> I don't want to do that tonight
[04:00:02] <SWPadnos> indeed
[04:00:03] <cradek> maybe someone will make it better
[04:00:09] <SWPadnos> nice start though
[04:00:10] <cradek> (it already does what I will want)
[04:00:15] <SWPadnos> and it works for you (tm) :)
[04:00:26] <cradek> right
[13:03:23] <cradek> wow, hotmail sure sucks (looking at cmorley's message)
[13:04:46] <jepler> I hope that whoever takes on the task of making the next live CD can find some packages to sacrifice in order that emc2-dev and build-essential can be added
[13:08:17] <jepler> on a fresh livecd install, the packages listed in the following file are the ones needed to build new emc2 components:
http://emergent.unpy.net/index.cgi-files/sandbox/emc2-development-packages.txt
[13:08:32] <jepler> 16 packages, about 20MB of download
[13:08:43] <jepler> .. and an additional 120MB of disk space used
[13:10:17] <cradek> jepler: I'll try to do that when I make a new cd after 2.2 (because the repos will change again)
[13:10:27] <cradek> 20MB sounds pretty easy actually
[13:10:42] <jepler> it's 120MB installed though
[13:10:49] <cradek> oh, right
[13:10:52] <cradek> ouch
[13:11:00] <cradek> not so easy
[13:11:17] <jepler> you could put them in .deb files not in the livecd image?
[13:11:24] <jepler> I don't know if that is easy or hard..
[13:11:47] <cradek> I'm not sure either
[13:13:03] <cradek> -rw-r--r-- 1 root root 669M 2007-06-07 20:39 emc2-ubuntu6.06-desktop-i386.iso
[13:13:28] <jepler> how long is a stick^W^W^W^Wbig is a CD?
[13:13:28] <cradek> are new CDs 700?
[13:13:38] <jepler> They have 700 printed on the packaging but I dunno what that means
[13:14:17] <jepler> http://www.osta.org/technology/cdqa7.htm
[13:14:35] <jepler> not sure if 74 or 80 minute is the most common size
[13:15:32] <jepler> it must be 80 minute, the byte size in 2048-bytes-per-sector mode is about 703 * 2^20 bytes
[13:15:53] <cradek> I have both sizes, I think 700s are the ones you can buy today
[13:16:32] <cradek> so I have 30 compressed MB without removing anything
[13:16:59] <jepler> yes that seems to be the case
[13:18:28] <cradek> Need to get 174MB of archives.
[13:18:31] <cradek> arg
[13:19:16] <cradek> never mind, it's fast today
[13:21:38] <cradek> removing openoffice would free up a LOT of space... it's easy to pick the things I don't care about, harder to pick the things nobody cares about
[13:22:28] <SWPadnos> I wonder if it's really necessary to have a fully-functional "desktop computer" for the EMC2 liveCD
[13:22:47] <cradek> easy to pick the things SWPadnos and I don't care about...
[13:23:34] <SWPadnos> heh
[13:23:43] <SWPadnos> must keep Samegame though
[13:25:02] <cradek> wow, there are 14 variants of "en" l10n
[13:29:28] <jmkasunich> i10n?
[13:29:34] <jmkasunich> I thought it was i8n?
[13:29:44] <cradek> i18n, l10n
[13:29:56] <cradek> localization
[13:29:58] <jmkasunich> oh
[13:30:06] <jmkasunich> ASCII dammit
[13:30:27] <jmkasunich> * jmkasunich looks for his time machine
[13:30:51] <jmkasunich> crap, I really have to clean up this basement, can't find anything
[13:38:37] <cradek> hmm, in my email I meant that holeprobe.ngc could be written, not that it exists
[13:39:22] <cradek> that one in NIST does a rapid down... not what I would write
[13:39:23] <cradek> but, it's close
[13:50:31] <cradek> -rw-r--r-- 1 root root 689M 2007-09-01 08:50 emc2-ubuntu6.06-desktop-i386.iso
[13:50:36] <cradek> easy
[14:27:08] <skunkworks> SWPadnos: that is impressive... according to my email client - you answered rolands question before he asked it :)
[14:27:28] <SWPadnos> oops. I tried to wait
[14:27:32] <SWPadnos> don't tell anyone
[14:28:06] <SWPadnos> on my client, his was at 9:53 and mine was at 10:06
[14:28:20] <SWPadnos> does yours tell you when you actually received the mail, or when it was sent?
[14:29:07] <skunkworks> heh - mine client says your email was 9:06 and his was 9:22.
[14:29:35] <skunkworks> when it was recieved at the mail server
[14:29:45] <SWPadnos> odd
[14:34:50] <skunkworks> SWPadnos:
http://www.electronicsam.com/email.JPG
[14:34:52] <skunkworks> :)
[14:35:18] <SWPadnos> oh, no wonder. Outlook Express
[14:35:25] <skunkworks> heh
[15:48:24] <jepler> so yeah there's a missing message...
[15:48:39] <SWPadnos> where?
[15:48:55] <SWPadnos> ah - from #emc :)
[15:48:55] <jepler> using halui to resume and axis to pause
[15:51:01] <cradek> just for fun try xemc
[15:55:29] <jepler> xemc has the same bug
[15:56:12] <jepler> mixing pause/resume between xemc + axis works
[15:56:20] <jepler> so, which UI has the bug?
[15:56:34] <cradek> very good question
[15:56:39] <cradek> halui?
[15:56:46] <SWPadnos> sounds like it's halui if xemc+axis work
[15:58:35] <jepler> could be
[15:58:58] <jepler> but it's never the command from halui that is "dropped"
[15:59:17] <SWPadnos> ah, so you can pause with halui but not resume with axis
[15:59:42] <SWPadnos> but if you pause with xemc (and maybe mini / tkemc) you can resume with axis
[15:59:58] <jepler> looks like when axis and xemc are running, they end up using sequence numbers that are not nearby
[16:00:20] <jepler> but when axis and halui, or xemc and halui, they end up using sequence numbers that are nearby
[16:00:47] <jepler> hm something's not right here -- xemc says that Z is some huge number
[16:01:03] <cradek> maybe they should all start their SNs somewhere random
[16:01:20] <SWPadnos> that would randomly fail if that's the problem
[16:01:43] <jepler> there's got to be some correct way for multiple commanders to manage SNs
[16:01:52] <jepler> where can I read the documentation on that?
[16:01:58] <cradek> ha
[16:01:59] <SWPadnos> RCS handbook ;)
[16:03:00] <jepler> oh -- looks like I mixed emc2.1 xemc in with emc2.2
[16:03:06] <cradek> we could assign a range to each gui
[16:03:07] <SWPadnos> userspace programs could start with their PID numbers
[16:03:07] <jepler> it's a wonder it works as well as that
[16:03:51] <jepler> or with their PID numbers in the upper bits of the SN, I've tossed around that idea before
[16:03:53] <cradek> axis gets 1-100, xemc gets 101-200, etc
[16:04:12] <jepler> but there's got to be a correct way, not just one where they'll step on each others' toes less frequently
[16:05:18] <SWPadnos> what would the failure mode be? that a UI sees a return seriel number that matches its command serial number (or whatever it expects), but that it's actually from another process?
[16:05:18] <cradek> since they're only compared for equality, each gui only needs a few serial numbers to use
[16:10:06] <SWPadnos> I think it would be a PITA to keep track of all commands "in flight", even for a single GUI
[16:10:36] <SWPadnos> unless you always wait for commands to complete
[16:11:35] <jepler> in this case, the problem seems to be that task never receives the 'pause' command from AXIS because it is sent with the same sequence number as the prior "resume" from halui
[16:12:53] <cradek> I was able to do that on purpose when I was fixing (?) this before, but I had to try hard
[16:13:12] <SWPadnos> it depends on how much stuff you do in between
[16:13:51] <cradek> so this is just a plain old SN clash? nothing unexpected is happening?
[16:14:24] <SWPadnos> does anyone know how the SN is used in NML? is it used to discard duplicate messages?
[16:14:27] <cradek> I mean, if you do some stuff in one gui for a while to get higher SNs, it all starts working?
[16:14:34] <cradek> SWPadnos: yes
[16:14:50] <cradek> and, to see when your command was received, so you know you can send the next one
[16:15:05] <jepler> halui constantly copies emcStatus->echo_serial_number into emcCommandSerialNumber, and uses ++emcCommandSerialNumber as the next sequence number
[16:15:36] <cradek> oh.... that's not good.
[16:15:38] <jepler> if the other program is incrementing its last issued serial number every time, this will tend to make them end up at the same serial number
[16:16:04] <SWPadnos> I'm assuming it's OK to overflow
[16:16:10] <cradek> I can see where someone might think that's a good way to get a new serial number, but they'd be wrong
[16:16:50] <SWPadnos> wait a sec - cradek, you said you need to check to see if your laast command was received so you can send the next one
[16:16:59] <SWPadnos> that's optional, isn't it?
[16:17:16] <SWPadnos> (a good idea, but not required, since it should be a message queue)
[16:17:22] <cradek> it's a queue of one
[16:17:31] <SWPadnos> hmmm
[16:17:42] <cradek> so, yes you ought to wait
[16:17:46] <SWPadnos> xemc doesn't check to see that the message was received
[16:17:53] <SWPadnos> unless it's in the send function
[16:18:13] <SWPadnos> nope - it just does emcCommandBuffer->write()
[16:18:24] <jepler> 2006-08-06 00:48:51 <cradek> I don't understand the SN handling with saveEmcCommandSerialNumber
[16:18:40] <jepler> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2006-08-06.txt
[16:19:08] <SWPadnos> history repeats itself
[16:21:09] <cradek> bbl
[16:21:15] <SWPadnos> see ya
[16:22:42] <SWPadnos> oh. I should head out also. bbl
[16:30:00] <jepler> static int next_serial(pyCommandChannel *c) {
[16:30:00] <jepler> - return ++c->serial;
[16:30:00] <jepler> + if(c->s->peek() == EMC_STAT_TYPE) {
[16:30:00] <jepler> + return c->serial = c->s->get_address()->echo_serial_number + 1;
[16:30:00] <jepler> + } else {
[16:30:03] <jepler> + return ++c->serial;
[16:30:05] <jepler> + }
[16:30:08] <jepler> }
[16:30:10] <jepler> ^^ by making axis do the same as halui, this particular problem "goes away"
[16:30:27] <jepler> it's tempting to try: static int next_serial(pyCommandChannel *c) { return lrand48(); }
[16:30:48] <jepler> er, static int next_serial(pyCommandChannel *c) { return c->serial = lrand48(); }
[16:36:08] <jepler> that seems to work about as well..
[16:36:23] <jepler> though you get these printed with debugging turned on:
[16:36:23] <jepler> libnml/cms/cms_dup.cc 475: CMS_DISPLAY_ASCII_UPDATER: int 1219898729 is too large. (Use type long.)
[16:36:32] <jepler> if (encoding) {
[16:36:33] <jepler> if (x > 9999999 && warning_count < warning_count_max) {
[16:36:33] <jepler> warning_count++;
[16:36:33] <jepler> rcs_print_error
[16:36:33] <jepler> ("CMS_DISPLAY_ASCII_UPDATER: int %d is too large. (Use type long.)\n",
[21:56:55] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[23:10:32] <cradek> jepler: there's a thing in axis.tcl that sets wm minsize to the natural size of the window. but, after that usually some widgets are unpacked which makes it smaller. Can that minsize setting happen afterward?
[23:26:15] <jepler> cradek: probably...
