Back
[01:29:03] <rayh> Hey SWPadnos
[01:29:31] <SWPadnos> hi Ray
[06:41:37] <SWPadnos> hiya jmk.
[06:41:41] <SWPadnos> go to bed :)
[06:41:51] <jmkasunich> about to
[06:41:57] <SWPadnos> good plan
[06:41:59] <jmkasunich> I just got ubuntu working
[06:42:03] <jmkasunich> with cradek's help
[06:42:05] <SWPadnos> cool!
[06:42:09] <jmkasunich> and installed the emc2 deb
[06:42:12] <SWPadnos> amd64 or i386?
[06:42:22] <jmkasunich> and checked out and compiled the cvs source
[06:42:25] <jmkasunich> i386
[06:42:29] <SWPadnos> ok
[06:42:31] <jmkasunich> I have a sempron, not a 64
[06:42:51] <jmkasunich> I had fits with my network card, needed to use noapic to get it to work
[06:43:20] <SWPadnos> interesting. Ubuntu is usually quite good about drivers
[06:43:39] <SWPadnos> though I guess they can't tell every possible problem combination
[06:43:59] <jmkasunich> strange thing is cradek has the same NIC (its on the mobo, not a card) and his is fine
[06:44:11] <SWPadnos> BIOS revisions?
[06:44:15] <jmkasunich> might be some bios config combination, we messed with that a little
[06:44:19] <cradek> different MBs
[06:44:27] <SWPadnos> that wouldn't help
[06:44:33] <SWPadnos> (go to bed)
[06:44:39] <cradek> I suspect jmk's MB is just buggy
[06:44:48] <cradek> linus rants about that somewhat on mailing lists
[06:44:53] <jmkasunich> my mobo is a SY-KT600 btw
[06:45:11] <SWPadnos> lots of people can't stand VIA chipsets
[06:45:15] <cradek> goodnight guys
[06:45:21] <SWPadnos> see you later
[06:45:27] <jmkasunich> night
[06:46:37] <SWPadnos> well - I've go to hit the hay - got a 9:00 AM meeting tomorrow to blow up some balloons
[06:46:54] <SWPadnos> (nichrome wire is fun :) )
[06:48:52] <SWPadnos> SWPadnos is now known as SWP_Away
[06:59:10] <jmkasunich> jmkasunich is now known as jmk_sleep
[08:21:40] <alex_jon1> alex_jon1 is now known as alex_joni
[17:51:10] <rayh> rayh is now known as rayh-away
[17:51:25] <jmk_sleep> jmk_sleep is now known as jmkasunich
[18:11:11] <jmkasunich> cradek: did you notice Gene Heskett's comment on the dev list about the dmesg buffer length? Is that an issue on your kernel or do you have a larger buffer?
[18:14:00] <cradek> mine is also 14, the ubuntu default
[18:14:10] <cradek> but my /var/log/dmesg has everything from line one
[18:14:35] <jmkasunich> ok
[18:15:10] <jmkasunich> I just recalled the old line about "smart folks learn from their mistakes, really smart ones learn from other peoples mistakes"
[18:16:28] <cradek> I wish you had pointed that out a half hour ago - I'm in the middle of a build to fix that symlink problem
[18:18:02] <cradek> ok, I changed it, rebuilding
[18:18:32] <jmkasunich> I was eating breakfast a half hour ago, sorry ;-)
[18:18:45] <cradek> no problem, I wasn't serious
[18:19:18] <alex_joni> jmkasunich: *hint* : he never is
[18:19:27] <alex_joni> even if he tries
[18:19:30] <alex_joni> cradek: :P
[18:21:49] <alex_joni> oh, another thing..
[18:21:56] <alex_joni> I brought Tasks to life
[18:22:09] <alex_joni> https://sourceforge.net/pm/?group_id=6744
[18:22:17] <alex_joni> I think it's better to keep the TODO in there
[18:22:34] <alex_joni> we can set-up dependencies and schedules & people working on stuff
[18:23:54] <jmkasunich> nice
[18:24:51] <alex_joni> have a look around, and if you like it, I'll move all the TODO over there
[18:25:32] <cradek> is there provision for closing the task when "Percent Complete" hits 80%?
[18:26:42] <jmkasunich> lol
[18:27:19] <jmkasunich> I like the dependencies thing
[18:27:31] <jmkasunich> release emc2 can be made dependent on other things
[18:29:59] <alex_joni> I already made it dependent on the univpwm
[18:30:07] <alex_joni> only 3 things are already there..
[18:41:09] <jmkasunich> are you going to add all the TODO items?
[18:41:23] <jmkasunich> I can add some if you like (save you a little work)
[18:42:40] <cradek> oh good, when I change it to Tasks For: cradek, they all disappear
[18:42:50] <jmkasunich> we can fix that
[18:43:09] <alex_joni> cradek: that's very easy to fix
[18:43:10] <alex_joni> :P
[18:43:11] <jmkasunich> I see he is already adding them
[18:43:15] <jmkasunich> he = alex
[18:43:17] <alex_joni> jmkasunich: almost done with them
[18:43:21] <jmkasunich> ok
[18:43:54] <alex_joni> there are the ones about licensing (CL & m5i20_HM5-4E.h), but I think I'd rather waste the time doing the actual fix
[18:44:19] <alex_joni> cradek: I think there's a bug we need to investigate before release
[18:44:37] <cradek> which is that?
[18:44:45] <alex_joni> if emc2 is running, then you select puter shutdown on ubuntu it totally hangs the machine
[18:45:08] <cradek> doctor doctor! it hurts when I do this!
[18:45:17] <cradek> sorry
[18:45:19] <jmkasunich> then don't do it
[18:45:50] <alex_joni> jmkasunich: same for reboot, or logout
[18:45:58] <cradek> logout??
[18:46:02] <alex_joni> yup
[18:46:07] <alex_joni> gnome logout
[18:46:08] <jmkasunich> I was joking, I do agree its a bug
[18:46:20] <alex_joni> anything involving X I think
[18:46:33] <jmkasunich> dunno why it would be X related
[18:46:48] <alex_joni> X might not shut processes down as it should
[18:47:39] <jmkasunich> the cleanup after shutdown of emc is done by the run script
[18:47:43] <alex_joni> * alex_joni tests some more..
[18:47:48] <jmkasunich> and starts after the gui returns
[18:48:00] <jmkasunich> if the script gets killed before the gui... no cleanup
[18:48:02] <alex_joni> well, I see all gnome stuff go away, but tkemc is still there
[18:48:28] <alex_joni> I think the script traps kill, and does a shutdown
[18:49:03] <jmkasunich> I guess my first question is what is locking it up? modules removed in the wrong order, some user process, or ??
[18:49:21] <jmkasunich> modules removed while RT code is still running ;-/
[18:49:47] <jmkasunich> do you get a kernel oops or panic? or just a freeze
[18:54:47] <alex_joni> freeze
[18:55:03] <alex_joni> nothing that helps me figuring out
[18:55:29] <alex_joni> btw, the new emc2 deb was already waiting for me this morning ;)
[18:55:35] <alex_joni> updating is sooo easy
[19:00:47] <alex_joni> hrmmm.. odd
[19:01:03] <alex_joni> I had another session on ssh watching /var/log/messages
[19:01:08] <alex_joni> nothing appeared in there..
[19:01:27] <jmkasunich> won't appear there unless it gets written to disk
[19:01:33] <alex_joni> probably
[19:01:46] <alex_joni> I'm rebooting now, maybe something did get written
[19:01:53] <jmkasunich> you might try removing "quiet" from the kernel line in /boot/grub/menu.lst
[19:02:01] <jmkasunich> that way it will appear on the text console
[19:02:09] <alex_joni> what text console ;)
[19:02:26] <jmkasunich> then do ctrl-alt-F1 to the text console, and try a shutdown -h while emc2 is running
[19:02:36] <alex_joni> ahh.. I see
[19:04:42] <alex_joni> no emc-shutdown stuff in /var/log/messages
[19:04:46] <alex_joni> doing the console stuff now
[19:09:54] <alex_joni> not very helpfull..
[19:10:03] <alex_joni> * Switching to runlevel: 0
[19:10:11] <alex_joni> * Sending processes the TERM signal
[19:10:23] <alex_joni> * Stopping GNOME Display Manager
[19:10:26] <alex_joni> ---
[19:10:28] <alex_joni> and that's about it
[19:10:31] <alex_joni> it hangs then
[19:10:56] <jmkasunich> did you get kernel messages on bootup?
[19:11:05] <jmkasunich> or when you started emc2?
[19:11:18] <alex_joni> yup
[19:11:33] <alex_joni> well, I had to login
[19:12:12] <alex_joni> but I saw the BLOCKS: installed 6 differentiators message
[19:12:13] <jmkasunich> lemme try something
[19:12:14] <alex_joni> and SCOPE_RT
[19:12:17] <jmkasunich> ok
[19:12:18] <alex_joni> those were the last 2
[19:12:33] <jmkasunich> no removal messages, not surprising
[19:12:40] <jmkasunich> no oops or panic either
[19:12:47] <jmkasunich> I suppose that is good ;-/
[19:12:48] <alex_joni> right
[19:12:54] <alex_joni> did you kill the runscript?
[19:13:12] <jmkasunich> ?
[19:13:35] <jmkasunich> I didn't do anything, I was commenting on what you said abouyt blocks and scopert
[19:13:36] <alex_joni> oh, thought you were seeing it too
[19:13:58] <alex_joni> right
[19:14:01] <jmkasunich> I'm not gonna try (this is the ubuntu box, I don't feel like rebooting)
[19:14:11] <jmkasunich> I was just gonna see what normal messages I get
[19:14:45] <alex_joni> so the problem I'm seeing is that emc2 doesn't get shutdown
[19:14:51] <alex_joni> no idea what causes the lockup
[19:17:05] <alex_joni> I'll try killing the runscript next
[19:19:21] <alex_joni> ook, killing the runscript leaves emc running ;)
[19:19:30] <alex_joni> all components are still there, and they work
[19:19:52] <jmkasunich> what happens when you close the gui?
[19:21:53] <alex_joni> nothing .. stuff gets left behind
[19:21:59] <alex_joni> but nothing bad
[19:22:59] <jmkasunich> does emc get cleaned up (RT modules removed, RTAI removed, etc)?
[19:23:19] <alex_joni> no
[19:23:30] <alex_joni> of course not
[19:23:35] <alex_joni> but machine is still ok
[19:23:54] <alex_joni> the next run cleans everything up
[19:27:21] <alex_joni> cradek: you around?
[19:27:57] <cradek> yes
[19:28:10] <alex_joni> cradek: spotted another cause of problems on ubuntu
[19:28:15] <cradek> uh-oh
[19:28:24] <alex_joni> if emc script crashes, and GUI gets killed, emc stays loaded
[19:28:38] <alex_joni> the next run of emc would bring everything down, and it would work ok
[19:28:49] <alex_joni> IF the user had a chance to answer Y to the answer
[19:28:59] <alex_joni> to the question
[19:29:01] <alex_joni> duh
[19:33:19] <alex_joni> cradek: get what I mean?
[19:33:59] <SWP_Away> SWP_Away is now known as SWPadnos
[19:35:25] <cradek> sorry, reading back
[19:36:29] <cradek> so you mean it stops and asks a question?
[19:36:41] <alex_joni> yeah, the runscript does that
[19:36:51] <cradek> is that a feature?
[19:36:54] <alex_joni> maybe we can add a timeout
[19:37:10] <alex_joni> and if the user doesn't press 'n' the cleanup gets done anyways
[19:37:23] <alex_joni> cradek: it was a feature
[19:48:46] <alex_joni> let me try to do that
[19:56:37] <rayh-away> rayh-away is now known as rayh
[20:04:03] <alex_joni> cradek: still around?
[20:04:27] <cradek> yes
[20:04:37] <cradek> but I'm not working on that bug...
[20:11:58] <alex_joni> yeah I know.. I am.. will commit a bash foo thingie
[20:12:03] <alex_joni> maybe you can eyeball it
[20:13:15] <cradek> ok
[20:16:29] <alex_joni> < echo -n "EMC is running -- restart it? [y/n] "
[20:16:30] <alex_joni> < read input
[20:16:30] <alex_joni> ---
[20:16:30] <alex_joni> > echo -n "EMC still running -- Want to restart it? (default is yes) [Y/n]"
[20:16:31] <alex_joni> > if read -t 5 input; then
[20:16:32] <alex_joni> > input=n
[20:16:34] <alex_joni> > else
[20:16:37] <alex_joni> > input=y
[20:16:39] <alex_joni> > fi
[20:18:29] <SWPadnos> what happens if I answer Y?
[20:18:38] <alex_joni> same thing
[20:18:40] <SWPadnos> (or N) - either will have the same result, no?
[20:18:42] <alex_joni> I think?
[20:18:49] <cradek> doesn't look right to me
[20:18:50] <alex_joni> let me try
[20:19:02] <SWPadnos> any input will have one result, no input will be the other result
[20:19:24] <SWPadnos> you want to not modify the var if the user enters something
[20:19:27] <alex_joni> SWPadnos: right :(
[20:20:03] <cradek> read -t 5 input || input=Y
[20:20:09] <SWPadnos> just take out the input=n case, or change the prompt to say "press enter to unload now", so that any entry continues immediately
[20:20:22] <cradek> case $input in [Yy]*) do the yes thing; *) do the no thing; esac
[20:20:37] <alex_joni> cradek: testing now
[20:21:17] <SWPadnos> if the read times out, you get a nonzero return?
[20:21:26] <alex_joni> yup
[20:21:27] <cradek> timeout = returns false
[20:21:32] <SWPadnos> ok
[20:27:33] <SWPadnos> jmkasunich, are you seeing any difference in univpwm_load vs univstep_load?
[20:27:47] <SWPadnos> it seemed to me that the only file that needs to change is univxxx_motion
[20:28:30] <jmkasunich> agreed, but we had a short discussuon about that (we = alex and me with Jon listening in) and decided that two dirs is less confusing for the users, even tho the files are almost identical
[20:28:43] <jmkasunich> maybe some of the files could go in common later
[20:28:57] <SWPadnos> ok - I was thinking along the lines of stepper_{inch,mm}
[20:29:17] <SWPadnos> two inis, two *motion, everything else the same
[20:29:50] <alex_joni> yeah, but same hardware there
[20:29:57] <alex_joni> different products here
[20:30:17] <SWPadnos> these are different products, but use the same driver and almost all configuration
[20:30:30] <SWPadnos> (and the same board, other than the FPGA configuration EEPROM)
[20:30:35] <SWPadnos> but either way is cool with me
[20:55:21] <rayh> rayh is now known as rayh-away
[20:59:28] <staggerlytom> hello all
[21:05:54] <staggerlytom> how can I use the LED widget in halvcp? it seems it cannot be the child of any other widget.
[21:10:07] <jmkasunich> the LED widget isn't done yet
[21:10:15] <jmkasunich> so you can't use it at all, sorry
[21:10:19] <staggerlytom> ok
[21:15:28] <staggerlytom> jmk: the rest worked fine & the pack idea is familiar from the tcltk part of emc. (you oughtta get feedback ).
[21:44:36] <alex_joni> ok guys, going to bed now
[22:11:14] <SWPadnos> so that's got the univpwm ready for tuning / refinement?
[22:11:26] <jmkasunich> think so
[22:11:31] <SWPadnos> cool
[22:11:54] <SWPadnos> it's mostly changes to univpwm_motion + changing the ini to load it, right?
[22:12:18] <jmkasunich> yeah, only those two files
[22:12:34] <SWPadnos> ok - I suspected as much
[22:12:41] <jmkasunich> we probably should revisit the common files issue, it is kinda dumb having two copies, but for now...
[22:13:04] <SWPadnos> yep
[22:13:33] <SWPadnos> make a configs/library dir (or use common), and allow for hardware-specific sub-configs there (or ladder ...)