Back
[00:02:24] <skunkworks> I suppose I need a deadband velocity..
[00:06:36] <skunkworks> odd
[00:29:10] <jepler> hm, I can't get screw comp to work either
[00:29:14] <jepler> in 2.1.6
[00:29:17] <jepler> haven't tried trunk
[00:30:48] <jmkasunich> I can take a look at it in a bit
[00:31:00] <jmkasunich> (after I get back from the grocery store)
[00:31:16] <jepler> scoping axis.0.backlash-corr
[00:32:06] <jepler> in halmeter it sometimes shows -0, but it never shows a nonzero number
[00:32:44] <jmkasunich> I have no clue how the comp file gets from disk thru userspace to the kernel module
[00:32:55] <jmkasunich> if its in the kernel module, I'm sure I can figure out whats wrong
[00:34:31] <cradek> jmkasunich: there's an EMCMOT call for each entry in the table
[00:35:06] <cradek> jepler: (do you see it load the table if you watch the EMCMOT calls?)
[00:35:16] <jepler> cradek: I haven't done that yet
[00:35:52] <jepler> curse C for not allowing an extra comma here: f(a,b,c,)
[00:35:55] <cradek> I ask that because experience says that task is more likely to be screwed up than jmk's code
[00:36:07] <jepler> while allowing: int x[3] = {a, b, c,};
[00:38:23] <jmkasunich> cradek: your faith in my code is gratifying, if perhaps a bit optimistic
[00:38:37] <jmkasunich> that code has never been really tested to my knowledge
[00:39:10] <cradek> but, to say that it's better than task is not necessarily a huge compliment
[00:39:35] <jepler> compute_screw_comp: entries=0
[00:41:51] <jepler> it looks like no entries get to compute_screw_comp
[00:42:53] <jmkasunich> so either task isn;t issuing the commands, or command.c isn't processing them correctly
[00:43:44] <jepler> cradek: how do I watch emcmot commands?
[00:44:16] <cradek> echo 99 > /proc/rtapi/debug or somesuch
[00:44:31] <jmkasunich> echo 4 will do it
[00:44:50] <jepler> I feel silly for asking, but how do I make it happen early enough?
[00:45:06] <cradek> I guess you have to do it right after loading realtime
[00:46:15] <jmkasunich> add a loadusr command before the loadrt motmod line in the hal file?
[00:46:18] <jepler> SET_JOINT_COMP for joint -1211510801
[00:46:27] <jmkasunich> heh, that can't be good
[00:46:27] <cradek> hmm
[00:46:56] <cradek> what's that smoke? is that a gun?
[00:46:58] <jmkasunich> funny, I thought I checked most joint specific commands for valid joint numbers
[00:49:05] <jmkasunich> I do
[00:49:14] <jmkasunich> line 349ish
[00:49:46] <jmkasunich> if the joint num isn't valid, it sets "joint" to NULL, which results in the command doing nothing thanks to line 1414
[00:49:51] <jepler> yeah
[00:49:52] <jmkasunich> (looking at HEAD)
[00:50:23] <jepler> @@ -767,6 +769,7 @@ int usrmotLoadComp(int axis, const char
[00:50:21] <jepler> emcmotCommand.comp_forward = fwd;
[00:50:21] <jepler> emcmotCommand.comp_reverse = rev;
[00:50:21] <jepler> }
[00:50:21] <jepler> + emcmotCommand.axis = axis;
[00:50:26] <jepler> emcmotCommand.command = EMCMOT_SET_JOINT_COMP;
[00:50:37] <cradek> that ought to help
[00:50:44] <jmkasunich> a bit
[00:51:43] <jepler> I'll let one of you test and commit .. I just screwed up my source tree with so many rtapi_print_err that I'd accidentally check one in..
[00:52:13] <jmkasunich> cvs diff
[00:53:19] <jmkasunich> * jmkasunich goes for groceries
[00:56:46] <jepler> also that will mean someone else tested it too
[01:55:48] <jmkasunich> the testing is the part I was trying to avoid
[01:55:59] <cradek> I was just working on that too
[01:56:12] <cradek> I haven't figured out the format of the file yet
[01:56:25] <jmkasunich> there are two
[01:56:25] <cradek> there are two "type"s
[01:56:44] <jmkasunich> nominal_value forward_value reverse_value
[01:56:46] <jmkasunich> and
[01:57:02] <jmkasunich> nominal_value forward_correction reverse_correction
[01:57:44] <jmkasunich> I don't know which is type 0 and which is type 1
[01:57:54] <jmkasunich> nor am I sure that forward comes before reverse
[01:57:55] <cradek> where do you specify the type?
[01:57:59] <jmkasunich> ini file
[01:58:04] <cradek> nom, fwd, rev
[01:58:12] <cradek> type 1 is the trims
[01:58:29] <cradek> type 0 is the actual values
[01:59:02] <cradek> crap my checkout is on a branch
[01:59:18] <jmkasunich> nineaxis?
[01:59:23] <cradek> yeah
[01:59:59] <cradek> haven't decided whether to merge all that or not
[02:00:19] <jmkasunich> the comp fix is just that one line, right?
[02:00:23] <cradek> yes
[02:00:28] <jmkasunich> I can do it here
[02:02:35] <jmkasunich> should we put comp into one of the sim configs?
[02:02:43] <jmkasunich> (I have to edit something to test anyway...)
[02:02:45] <cradek> on trunk, sure
[02:03:53] <jmkasunich> sim servo maybe?
[02:04:02] <cradek> sure
[02:06:41] <jmkasunich> well, thats a bug...
[02:06:59] <jmkasunich> if the comp file doesn't exist, it tried opening it again and again
[02:07:11] <jmkasunich> 10 times, then it gives up
[02:07:18] <jmkasunich> I guess thats not fatal
[02:07:30] <jmkasunich> at first I thought it would keep going and going....
[02:07:53] <cradek> uh 10?
[02:08:06] <cradek> I don't see that here
[02:08:06] <jmkasunich> yeah 10
[02:08:19] <jmkasunich> task 0x80508a0 period = 50000 ratio=1
[02:08:19] <jmkasunich> task 0x80508c4 period = 1000000 ratio=20
[02:08:19] <jmkasunich> PID: installed 3 PID loops
[02:08:19] <jmkasunich> SIM_ENCODER: installed 3 simulated encoders
[02:08:19] <jmkasunich> ENCODER: installed 6 encoder counters
[02:08:19] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:21] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:22] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:25] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:27] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:28] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:34] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:34] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:38] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:38] <jmkasunich> can't open compensation file screwcompX.dat
[02:08:40] <jmkasunich> emc/usr_intf/emcsh.cc 3738: can't connect to emc
[02:08:44] <jmkasunich> Shutting down and cleaning up EMC2...
[02:08:44] <jmkasunich> MOTION: cleanup_module() started.
[02:08:46] <jmkasunich> at approximately 1 second intervals
[02:09:08] <cradek> boggling
[02:16:34] <jmkasunich> well crap
[02:16:43] <jmkasunich> doesn't appear to be working
[02:17:04] <cradek> do you think it loads the table right?
[02:17:34] <jmkasunich> no clue, haven't begun to debug
[02:18:55] <jmkasunich> * jmkasunich smacks himself upside the head
[02:19:08] <jmkasunich> <-- looking in dmesg for messages, on a sim system
[02:19:33] <cradek> heh
[02:19:37] <cradek> whee sim
[02:19:51] <jmkasunich> theres no /proc/rtapi
[02:19:58] <jmkasunich> how am I supposed to change the message level?
[02:20:19] <cradek> umm
[02:21:43] <cradek> sim_common.h:5
[02:23:11] <jmkasunich> * jmkasunich smacks himself upside the head again
[02:23:33] <jmkasunich> I think I hadn't saved the fix when I did the build/test
[02:23:52] <cradek> oops
[02:24:28] <jmkasunich> much better
[02:24:46] <cradek> comping?
[02:24:48] <jmkasunich> yep
[02:24:54] <cradek> wheee
[02:25:19] <cradek> did you write all that but never test it?
[02:25:32] <jmkasunich> * jmkasunich hides
[02:26:03] <cradek> no I'm not giving you a hard time - I'm just amazed that you could write it so it worked without any testing/rewriting
[02:26:44] <jmkasunich> well, I'm not sure it works
[02:26:59] <jmkasunich> there are non-zero numbers, but I have no idea if they are the right non-zero numbers
[02:27:36] <jmkasunich> although it kinda seems right
[02:27:46] <cradek> slick
[02:30:30] <jmkasunich> I'm declaring it "good"
[02:30:37] <cradek> that's great
[02:30:48] <cradek> gonna say so on the list, or pretend it worked all along? :-)
[02:30:59] <jmkasunich> I'll say so
[02:31:06] <cradek> we can put it in 2.1.7 too then
[02:31:16] <jmkasunich> now lets see if I can not bork up the commit
[02:31:39] <jmkasunich> (I have lots of fpga crap in progress on this checkout, but if I commit from the right spot it should work)
[02:33:32] <jmkasunich> and now the backport
[02:36:52] <jmkasunich> why does the changelog have peoples names above some lines?
[02:37:20] <cradek> dch does that. just delete those lines, or I will later
[02:40:08] <jmkasunich> odd - the commit mail arrived here, but CIA missed it
[02:40:21] <jmkasunich> anyway, 2.1 is fixed now
[02:44:17] <jmkasunich> heh, thats funny
[02:44:39] <jmkasunich> thunderbird's spellchecker doesn't have "internet" in its dictionary
[02:45:13] <cradek> that's because it's spelled intarweb
[02:47:29] <jmkasunich> mail sent
[02:47:43] <jmkasunich> now you are on the hook to release 2.1.7
[02:48:47] <cradek> excellent
[02:49:00] <cradek> I wonder about ppmc though
[02:49:22] <jmkasunich> Jon thinks its OK, and that stuart is having noise probs
[02:49:44] <jmkasunich> we may not know for sure until the next time you are in wicheta
[02:50:57] <cradek> I really, really doubt stuart and jon both had extra indexes every .020 inches, while going in only one direction, because of noise.
[02:51:31] <cradek> doesn't that seem just a bit unlikely to you too?
[02:51:34] <cradek> (but nmfp)
[02:52:02] <cradek> (and, the lack of filtering on the index seems like a firmware bug to me)
[02:52:04] <jmkasunich> yes, it does seem peculiar
[02:52:16] <jmkasunich> but theres nothing in the driver that would cause the problem
[02:52:38] <jmkasunich> unlike the pluto or 5i20 the firmware isn't part of EMC
[02:52:45] <cradek> yeah it's probably firmware if anything
[02:52:47] <jmkasunich> closed source hardware - fsck it
[02:53:28] <cradek> yeah. that's my only problem with the ppmc stuff. it is very appealing other than that
[03:10:47] <skunkworks> how come when I command the pid to 1.6666 - the velocity returned from the encoder is < 1.666? like 1.4 (encoder velocity into the feedback of the pid)
[03:11:33] <cradek> because of the granularity (integer counts per cycle divided by cycle time)
[03:11:38] <skunkworks> ah
[03:11:43] <skunkworks> so it is an issue ;)
[03:12:23] <cradek> yeah that output is not real useful
[03:19:22] <skunkworks> so you said :)
[03:19:56] <skunkworks> done with that - time for bed. Night.
[03:20:10] <cradek> goodnight
[03:20:47] <skunkworks> (barry got his tube pulled out today.) So far so good.
[03:21:12] <cradek> yay
[03:21:16] <cradek> what a trooper
[03:22:39] <skunkworks> stitches out next monday
[03:22:49] <skunkworks> now - really time for bed.
[04:40:35] <legoman> hi, where would I submit a bug/problem?
[08:14:02] <alex_jon1> alex_jon1 is now known as alex_joni
[12:08:57] <skunkwork> linuxcnc.org is down.
[12:09:05] <skunkwork> hmm - logger is still running
[12:09:18] <skunkwork> logger_dev: bookmark
[12:09:18] <skunkwork> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-07-10.txt
[12:11:24] <skunkwork> It is just the linuxcnc.org page that is down.. (joomla!)
[12:11:54] <skunkwork> wiki and logger is up
[12:12:12] <jepler> as are non-joomla pages on the main website, e.g.,
http://linuxcnc.org/docs/2.1/html/man/man9/stepgen.9.html
[12:13:52] <skunkwork> right
[12:13:57] <skunkwork> morning jepler
[12:14:23] <skunkwork> I tried a bit of velocity control last night - didn't work great ;)
[12:28:20] <jepler> hm -- I can't reproduce this reported problem:
http://pastebin.ca/612442
[12:28:23] <jepler> tried 2.1 and TRUNK
[12:29:32] <jepler> cradek: oh, I see you were copied on that message as well
[12:50:28] <cradek> yeah, I wonder if explaining how it's supposed to work will "fix" the bug report
[12:52:53] <jepler> grngrngnrg Jack Ensor is asking again about starting axis maximized
[12:53:21] <jepler> hi cradek
[12:54:06] <jepler> I am guessing that the ubuntu/gnome window manager simply doesn't have a "start this application maximized" preference
[12:55:19] <jepler> "Every time I start beast, it has forgotten it's window
[12:55:19] <jepler> position. Talking to the metacity developers, remembering window
[12:55:19] <jepler> position is not a job for the window manager, but for the application.
[12:55:19] <jepler> "
[12:55:24] <jepler> http://www.mail-archive.com/beast@gnome.org/msg00023.html
[12:55:33] <jepler> wow, if they believe that they really are dumbasses
[12:55:39] <jepler> "the job of the window manager is not to manage windows"
[12:55:52] <jepler> "it's, umm, look -- a pterodactyl!"
[13:00:52] <jepler> (
http://bugzilla.gnome.org/show_bug.cgi?id=81108)
[13:09:30] <jepler> halcmd: setp conv-s32-float.0.in -1
[13:09:30] <jepler> halcmd: show pin *.in
[13:09:30] <jepler> Component Pins:
[13:09:30] <jepler> Owner Type Dir Value Name
[13:09:30] <jepler> 3 s32 IN 4294967295 conv-s32-float.0.in
[13:09:53] <jepler> oddly enough, 'halcmd getp' prints -1
[13:09:55] <jepler> (64 bit machine)
[13:13:35] <jepler> oh it's just a typo
[13:13:44] <jepler> the case of halscope seems to be a bit more subtle
[13:13:47] <jepler> (they both display a large number for s32 -1)
[13:18:41] <skunkwork> http://www.linuxcnc.org/ is back up :)
[16:06:27] <skunkwork> is swpadnos on vacation?
[16:36:17] <cradek> on vacation from us at least
[16:47:23] <skunkwork> :) I am sure that is needed from time to time
[19:52:13] <alex_joni> hi guys
[19:57:15] <alex_joni> greetings from athens
[19:59:05] <skunkwork> Nice.
[20:06:09] <alex_joni> jepler: this might help Jack Ensor:
http://www.extremetech.com/article2/0,1697,2140149,00.asp
[20:20:17] <jepler> alex_joni: I've never heard of that program before
[20:20:21] <jepler> but by all means, suggest it to him
[20:30:17] <cradek> hm, xwit doesn't do maximize
[20:30:40] <cradek> alex_joni's find is better
[20:31:44] <jepler> it appears that icccm didn't even have maximize
[20:32:08] <cradek> ok that explains it
[20:33:06] <jepler> http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2456788
[20:33:15] <jepler> "Maximization is a very old feature of window managers. There was even a ZoomedState in early ICCCM drafts."
[21:34:52] <alex_joni> good night all