Back
[00:16:43] <cradek> dpkg-shlibdeps: warning: diversions involved - output may be incorrect
[00:16:43] <cradek> diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa
[00:16:51] <cradek> uhh
[00:18:55] <cradek> emc2-sim installed, running sim/axis gives me: _tkinter.TclError: unknown color name "\#008080"
[01:49:13] <cradek> never mind
[01:55:05] <cradek> hmm, something has badly broken halshow
[02:04:27] <SWPadnos> could it be halcmd?
[02:04:47] <cradek> yeah, I'm pretty sure it is
[02:05:04] <cradek> working on another problem first right now
[02:12:14] <SWPLinux> oh man. VMWare is unbelievably slow with debugging turned on (booting the emc2 liveCD)
[02:12:18] <cradek> http://pastebin.ca/320091
[02:12:41] <cradek> err
http://pastebin.ca/320092
[02:12:58] <cradek> with a real cd, or just from the iso?
[02:13:09] <SWPLinux> the iso
[02:13:12] <cradek> huh, booting from the iso always seemed pretty fast to me
[02:13:19] <cradek> what debugging?
[02:13:29] <SWPLinux> it should be, but I can see the screen updates in the boot (geaphical) screen
[02:13:33] <SWPLinux> graphical
[02:13:58] <SWPLinux> it was like watching interesting fade effects
[02:14:37] <SWPLinux> once in X, running EMC took about a second
[02:14:55] <cradek> heh
[02:15:35] <SWPLinux> and I can spin chips in realtime
[02:15:42] <cradek> cool
[02:17:07] <SWPLinux> I wonder what $searchbase and $searchstring were in halshow
[02:17:54] <cradek> just click anything (I clicked "threads")
[02:21:17] <SWPLinux> was this sim/axis?
[02:21:25] <cradek> yes
[02:21:59] <SWPLinux> oops - I don't have the halcmd fix from yesterday
[02:22:05] <SWPLinux> one sec
[02:22:10] <cradek> oh does yours work? :-)
[02:22:18] <SWPLinux> no - it doesn't start :)
[02:23:47] <SWPLinux> hmmm. now it doesn't compile. one sec more
[02:27:31] <SWPLinux> ok - luckily I get the exact same message
[02:27:37] <cradek> yays
[02:35:20] <SWPLinux> hmmm. it's never getting correct results from halcmd - the tree has no '+' signs in it
[02:35:55] <cradek> I guess the output was different before...?
[02:36:39] <SWPLinux> I don't see any recent changes that change the output of show (I think)
[02:38:45] <SWPLinux> hmmm - unless there were some errors in the strings passed to halcmd that are now refused by the improved error checking of replace_vars
[02:42:29] <cradek> I think halcmd in noninteractive mode is printing to stderr
[02:43:02] <SWPLinux> ok - so it's the logging changes then?
[02:43:06] <SWPLinux> you think
[02:43:11] <cradek> logging?
[02:43:23] <cradek> I didn't keep up on all the things you guys were changing in it.
[02:43:25] <SWPLinux> the changes to RTAPI_PRINT_*
[02:43:44] <SWPLinux> that's in hal_lib / RTAPI
[02:43:54] <cradek> is that how halcmd prints everything?
[02:44:07] <SWPLinux> some stuff, for sure. I don't know about "everything"
[02:44:35] <cradek> rtapi_print()
[02:44:52] <SWPLinux> yep
[02:48:11] <SWPLinux> hmmm - rtapi_print goes to stdout. it's rtapi_print_msg that can go elsewhere
[02:48:27] <SWPLinux> or nowhere
[02:49:10] <cradek> print_thread_names() calls rtapi_print(), and I am getting everything on stderr
[02:49:52] <cradek> I think you're mistaken, they both call rtapi_msg_handler the same way
[02:50:18] <SWPLinux> there's a preprocessor #if ... #else ... #endof that protects a pair of comments ...
[02:50:27] <SWPLinux> that's in rtapi.h, not ulapi.h
[02:50:33] <SWPLinux> err - .c
[02:51:00] <cradek> I don't follow at all
[02:51:06] <cradek> are you in 2.1 branch?
[02:51:14] <SWPLinux> no, TRUNK
[02:51:18] <cradek> I'm at rtai_rtaip.c:466
[02:51:27] <cradek> oh, duh
[02:51:33] <SWPLinux> that's right. for RT, it goes through the handler
[02:51:55] <SWPLinux> line 248 in rt_ulapi.c
[02:52:07] <SWPLinux> gah. rtai_ulapi.c
[02:53:02] <cradek> oh, I get it
[02:53:11] <cradek> I was trusting tags to give me the right one :-/
[02:53:16] <SWPLinux> heh
[02:53:42] <cradek> I still don't see why I'm getting stderr
[02:53:50] <cradek> explain it to me like I'm dumb please
[02:54:18] <SWPLinux> no - that leads me to think that halcmd is getting linked against the RT version of rtapi instead of the user version
[02:54:35] <SWPLinux> (no - I agree that I don't see why you're getting stderr)
[02:58:47] <cradek> rtapi/sim_common.h:126
[02:59:05] <SWPLinux> well, that would do it
[02:59:45] <cradek> cwstdout
[02:59:47] <cradek> err
[02:59:49] <SWPLinux> ok - yeah. "common" functions in sim (because there's no RT), yet they normally do different things
[03:00:09] <SWPLinux> oh - so the vi command to change a word is cw huh? :)
[03:00:17] <cradek> yep
[03:00:26] <SWPLinux> wq is teh only one I know :)
[03:00:38] <SWPLinux> or q!
[03:02:59] <SWPLinux> are those things in the header file so every program gets its own copy of rtapi_msg_handler?
[03:03:10] <cradek> (that fixes it)
[03:03:34] <SWPLinux> right - I wonder what happens to "RT" modules under sim ...
[03:03:34] <cradek> I have nfc.
[03:04:06] <cradek> they run in rtapi_app
[03:04:30] <SWPLinux> but the user comps don't, so I guess they each get a copy
[03:04:41] <SWPLinux> that .h file is kinda .c-like
[03:07:59] <SWPLinux> on a separate note, Synaptic in the fresh install of the emc2-liveCD tells me that TTT is obsolete
[03:08:10] <SWPLinux> is that now packaged with EMC2?
[03:08:23] <cradek> no, it's just in the same repository
[03:08:30] <cradek> what version do you have?
[03:08:42] <SWPLinux> 3.0-2
[03:08:51] <cradek> hmm, same here
[03:09:00] <SWPLinux> this is the emc2 liveCD downloaded yesterday, and not yet upgraded
[03:09:26] <SWPLinux> it's in the Synaptic category "Installed (local or obsolete)"
[03:09:33] <SWPLinux> so maybe local, not obsolete ...
[03:09:45] <cradek> I don't know what any of that means
[03:10:08] <SWPLinux> hmmm - maybe it isn't in the repositories, so it's considered a local install
[03:10:14] <SWPLinux> I
[03:10:28] <cradek> oh, it's not in the dapper directory
[03:10:34] <SWPLinux> I'm assuming that's what teh category means (ie, that thingsare only removed from repositories when they become obsolete)
[03:10:37] <cradek> but I installed it on the livecd anyway
[03:10:43] <SWPLinux> ah. ok
[03:10:53] <cradek> it's in the breezy repo
[03:11:11] <SWPLinux> I'm not sure if it'll be faster to upgrade then install vmware tools, or install the tools before the upgrade and reinstall them after
[03:11:18] <SWPLinux> probably option 2
[03:11:35] <cradek> you think the upgrade will nuke the tools?
[03:11:47] <SWPLinux> I expect the kernel version to change (unless it doesn't)
[03:12:10] <cradek> if you installed the livecd, you have the rt kernel already, and it won't change
[03:12:31] <SWPLinux> ok - tools first then, for sure
[03:12:32] <cradek> apt-get upgrade at the shell will tell you what it's going to do before it does it
[03:13:10] <SWPLinux> true - no linux-* or kernel-* to upgrade (duh)
[03:15:18] <SWPLinux> heh - I guess I need to go for emc2-dev first anyway - no compiler ...
[03:16:09] <cradek> can you hold off for a sec? I'm updating the repo
[03:16:45] <SWPLinux> no prob. it's a VM, and I'm doing the dev work on the host machine in sim
[03:16:51] <cradek> done :-)
[03:16:55] <SWPLinux> oh :)
[03:17:12] <SWPLinux> I'll reload the package list later then :)
[03:17:14] <cradek> please apt-get update, and see if synaptic is satisfied about truetype-tracer
[03:17:26] <SWPLinux> just "got" what you said
[03:17:53] <SWPLinux> will do. the kernel source download will take a bit to finish
[03:18:50] <cradek> aha I found it
[03:19:16] <SWPLinux> who -what - where?
[03:19:31] <cradek> I found the thing you're talking about in synaptic - and it's fixed
[03:19:40] <SWPLinux> ok. cool
[03:43:47] <jepler> I had this in my local tree but apparently hadn't checked it in:
http://pastebin.ca/320166
[03:43:54] <jepler> I think it is the fix for this halshow problem
[03:45:34] <jepler> what part of debuglevel doesn't work in 'installed'?
[03:47:50] <jepler> I suppose I should test it for myself.
[03:53:12] <jepler> ah
[03:53:13] <jepler> emc.error: emcStatusBuffer invalid
[03:53:13] <jepler> emc.error: emcStatusBuffer invalid
[04:01:25] <jepler> now (with the changes I've checked in) halshow works for me with sim, and debuglevel works for sim/installed
[04:01:43] <jepler> 'night everyone, whereever you are
[04:01:50] <SWPLinux> yep - halshow works correctly here as well
[04:01:54] <SWPLinux> night. thanks
[05:21:35] <SWPLinux> hmmm - jmk - is vmware slow as molasses to boot your emc2 guest? (but fast enough once booted)
[05:22:07] <jmkasunich> yeah, kind of
[05:22:23] <jmkasunich> especially the part after it switches out of text mode but is still doing startup things
[05:22:32] <jmkasunich> you can see the scroll as those messages print
[05:22:40] <jmkasunich> (IOW, very slow graphics update)
[05:22:55] <SWPLinux> I can see it repainting the boot screen - scrolling is like a worm crawling up the screen
[05:22:57] <SWPLinux> yep
[05:23:03] <jmkasunich> yeah, that
[05:24:23] <SWPLinux> but I can spin models in AXIS in realtime (like 3dChips - haven't tried any megabyte models yet)
[05:26:17] <jmkasunich> K'zan doesn't seem as electrically astute as I first thought
[05:26:34] <jmkasunich> not sure if its safe to have her rebuilding power supplies or not
[05:26:48] <SWPLinux> hah - not sure myself
[05:27:16] <SWPLinux> I've been wondering if we shuold be reminding her to unplug before fiddling with stuff ...
[05:30:06] <jmkasunich> If the pics show a hackable circuit, I'm tempted to send her one of these cap banks
[05:30:31] <jmkasunich> the caps are already mounted on a PCB, paralleled
[05:32:54] <jmkasunich> 40000uF if I did the math right
[05:34:42] <SWPLinux> 40800, I'd say
[05:34:51] <jmkasunich> I rounded
[05:34:57] <SWPLinux> heh :)
[05:35:30] <SWPLinux> did you have those at CNC workshop?
[05:35:37] <SWPLinux> (I'd think they would have sold well)
[05:35:40] <jmkasunich> no
[05:35:52] <jmkasunich> they are literally bandsawed off of a larger board
[05:36:11] <jmkasunich> and I only have three
[05:37:10] <SWPLinux> well - I suppose $5-10 would be reasonable for them (if you have the room / load capacity in your truck :) )
[09:27:44] <A-L-P-H-A> that was fun...
[09:28:15] <A-L-P-H-A> logger_dev, bookmark
[09:28:16] <A-L-P-H-A> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-01-18.txt
[12:36:36] <alex_joni> alex_joni is now known as jail_oxen
[12:36:58] <jail_oxen> jail_oxen is now known as alex_joni
[16:44:22] <alex_joni> jepler: with HEAD I am getting this error:
[16:44:24] <alex_joni> STEPGEN: Channel 2: The requested maximum velocity of 28000 steps per second is
[16:44:26] <alex_joni> STEPGEN: The maximum number of steps possible is 10111 per second
[16:46:49] <jepler> is it a correct error?
[16:47:04] <jepler> I mean, is the information accurate?
[16:47:24] <alex_joni> yeah, but the error message is not complete
[16:47:28] <alex_joni> it feels trunkated
[16:47:38] <jepler> oh I see now what you're saying!
[16:52:07] <jepler> appears rtai_rtpai has BUFFERLEN 80
[16:52:32] <jepler> sim (where I tested) has 1024
[16:53:12] <jepler> cradek: can you re-word the message so it fits in 80 characters?
[16:53:24] <jepler> otherwise .. increase the size of that buffer?
[17:01:06] <alex_joni> jepler: remember that wobbly thing I asked you about?
[17:01:12] <alex_joni> I am testing it now on my machine..
[17:01:28] <jepler> the thing with siggen?
[17:01:32] <alex_joni> yea
[17:01:46] <alex_joni> I need a really high amplitude (I think) to cause it to send a step
[17:02:30] <alex_joni> at 800 steps/unit I need about 0.02 amplitude to see a step
[17:02:53] <jepler> that should be about 16 steps worth?
[17:03:17] <alex_joni> something like that I think
[17:03:37] <alex_joni> what's 20m/div as a scale for halscope?
[17:03:52] <jepler> each div is 20 milliunits
[17:04:09] <jepler> a div is from one row of dots to the next
[17:04:09] <alex_joni> so if my signal is 2 divs amplitude
[17:04:19] <alex_joni> that's 40 milliunits.. right?
[17:04:25] <jepler> yes
[17:04:34] <alex_joni> I requested 0.02 so twice that is 0.04
[17:04:42] <alex_joni> ok, that works :)
[17:09:28] <alex_joni> but it's still odd that I need such a high value
[17:10:16] <alex_joni> wonder if it's related to some internals of stepgen
[17:10:40] <jepler> it works like I expect here
[17:10:50] <alex_joni> and you get a pulse from stepgen ?
[17:10:54] <jepler> if I have amplitude = 1/800 (.00125) then it steps to 1 count and -1 count
[17:11:01] <jepler> according to stepgen.0.rawcounts
[17:11:06] <jepler> er, 2/800
[17:11:11] <jepler> er, 1/800
[17:11:25] <alex_joni> I looked at Zstep (which was connected to stepgen.0...)
[17:11:27] <jepler> if I have 1/1600 (.000625) then it steps to 0 count and -1 count
[17:11:58] <jepler> yep if I scope stepgen.0.step I get steps
[17:12:15] <alex_joni> this is running TRUNK?
[17:12:20] <jepler> yes on sim
[17:12:33] <jepler> did you set stepgen.0.position-scale ?
[17:12:35] <alex_joni> hmmm..
[17:12:38] <jepler> setp stepgen.0.position-scale 800
[17:12:59] <cradek> jepler:
http://pastebin.ca/320595
[17:13:04] <alex_joni> oh.. thought it's set from the ini..
[17:13:05] <jepler> http://pastebin.ca/320593
[17:13:15] <alex_joni> jepler: seems it's 200..
[17:14:08] <alex_joni> err.. no, the right one is ok
[17:14:14] <alex_joni> 05 float RW 800 stepgen.2.position-scale
[17:14:23] <jepler> cradek: the first line will be shown to the user, the second two only in dmesg?
[17:14:59] <jepler> otherwise I think the user has to hit OK 3 times :-(
[17:15:06] <cradek> jepler: hahaha
[17:15:11] <alex_joni> jepler: only one appears here
[17:15:17] <jepler> alex_joni: one onscreen and 2 in dmesg?
[17:15:25] <cradek> I don't see why that would be the case
[17:15:27] <jepler> or both onscreen in one dialog box?
[17:15:31] <jepler> which gui?
[17:16:08] <alex_joni> I get one line on the GUI
[17:16:15] <alex_joni> and 3 in the terminal where i started emc
[17:16:16] <alex_joni> jepler: tkemc
[17:16:31] <jepler> would be in dmesg if you were on realtime
[17:16:34] <alex_joni> but I have different INPUT_SCALES
[17:16:39] <alex_joni> the others might be info only
[17:16:41] <alex_joni> STEPGEN: Channel 2: The requested maximum velocity of 28000 steps per second is
[17:16:44] <alex_joni> STEPGEN: The maximum number of steps possible is 10111 per second
[17:16:46] <alex_joni> STEPGEN: The maximum number of steps possible is 10111 per second
[17:17:01] <alex_joni> the first one is in a dialog
[17:17:21] <jepler> I think that's some kind of floating-point issue
[17:17:59] <cradek> well I don't know how to get all that information in 80 characters
[17:19:30] <cradek> jepler: can we have different build-dep depending on the package? I think sim needs pth-dev but the others don't
[17:19:44] <alex_joni> jepler: I can confirm.. I am seeing a change for rawcounts
[17:19:50] <alex_joni> but I don't see a step
[17:19:57] <jepler> alex_joni: are you halscoping in the fast thread?
[17:20:08] <alex_joni> in servo
[17:20:14] <alex_joni> hmm.. maybe that's why :)
[17:20:18] <jepler> maybe!
[17:22:01] <SWPadnos> how about "STEPGEN(2): The MAXVEL setting %d Hz exceeds the max attainable rate %d"
[17:22:39] <SWPadnos> (or whatever the actual parameter name is)
[17:23:03] <cradek> well it's an improper combination of scale, maxvel and base period that causes the error
[17:23:33] <cradek> it's hard to express that
[17:24:05] <SWPadnos> "STEPGEN(2) The error we want to report exceeds the RT message length"
[17:24:19] <alex_joni> how about "Error 15!"
[17:25:31] <alex_joni> bbl
[17:26:02] <cradek> HP basic/UX error 713 is "request not supported by dev."
[17:27:11] <cradek> haha error 977: "statement or cmd too complex."
[17:27:49] <jepler> STEPGEN: Channel 0: The requested step rate of 5599Hz is not attainable
[17:27:48] <jepler> STEPGEN: Channel 0: The maximum step rate is 847Hz
[17:27:48] <jepler> STEPGEN: To fix, you must reduce MAX_VELOCITY, INPUT_SCALE, or BASE_PERIOD.
[17:27:48] <jepler> STEPGEN: Otherwise, following errors will result.
[17:28:10] <jepler> (in this case, I have a stupid BASE_PERIOD)
[17:28:30] <cradek> does this all show up onscreen?
[17:28:37] <jepler> no, only the first line
[17:29:03] <jepler> STEPGEN: Channel 0: The requested step rate of 5599Hz is not attainable [OK]
[17:29:51] <cradek> they'll never see the rest then, and they'll always bother us on irc or the lists
[17:30:09] <cradek> maybe a URL instead? </bad idea>
[17:31:33] <alex_joni> STEPGEN: buy some hardware to generate pulses that fast
[17:31:52] <alex_joni> jepler: I ended up with this:
http://dsplabs.cs.utt.ro/~juve/blog/index.cgi-files/sandbox/core_stepper.hal
[17:32:07] <SWPadnos> STEPGEN: Your machien is teh sukc!
[17:32:29] <alex_joni> bbl..
[17:54:14] <SWPadnos> heh - that's one fix :)
[17:58:11] <awalli1> .
[19:49:36] <jepler> in light of jmk's comments in e-mail, I wonder about changing the message to:
[19:49:36] <jepler> "The maximum step rate is %dHz. You must reduce the maximum velocity, the "
[19:49:36] <jepler> "scale, or the thread period. Otherwise, following errors will result.\n",
[19:50:28] <jepler> (top line unchanged)
[19:51:21] <SWPadnos> hmmm - the term "following error" is relatively EMC-specific
[19:51:28] <SWPadnos> I wonder if there's a more generic term
[19:51:45] <cradek> I sympathize with his position but I am not convinced we should take it out.
[19:52:21] <SWPadnos> when is this error generated?
[19:52:22] <cradek> I'd grumble each time a new user says "I got this message but I don't understand what to do"
[19:52:44] <SWPadnos> yeah - there's a disticnt conflict between generic-ness and user-friendliness
[19:52:45] <cradek> when you turn machine on
[19:53:39] <SWPadnos> hmmm
[20:01:39] <cradek> jepler: with installed sim, debuglevel doesn't exit when you exit emc
[20:02:14] <jepler> cradek: it doesn't with run-in-place either.
[20:02:18] <jepler> cradek: neither does emctop
[20:02:50] <jepler> cradek: we should be passing -x ("scripts too") to pidof, and add it to the list of programs to kill at shutdown, but I don't know if pidof -x works everywhere
[20:47:58] <alex_joni> * alex_joni hides in here
[20:49:10] <SWPLinux> heh
[20:55:02] <cradek> jepler: is there a good reason for those to be separate processes?
[21:12:15] <jepler> cradek: I imagined that someone would spring to add them to the menu in tkemc
[21:12:22] <jepler> <1/3 wink>
[21:12:40] <alex_joni> * alex_joni blinks
[21:13:04] <SWPLinux> * SWPLinux stinks
[21:13:05] <SWPLinux> oops
[21:15:38] <alex_joni> * alex_joni is happy to have a cold
[22:50:01] <alex_joni> cradek: is the last blending fix you put there, not a v2_0_branch backport candidate?
[22:50:54] <cradek> nope, it's 2.1 specific
[22:52:43] <alex_joni> ok..
[22:53:07] <cradek> I figured it might be time to start testing 2.1
[22:53:36] <alex_joni> ha