#emc-devel | Logs for 2008-03-21

[06:27:04] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/ (m7i43_hm2.comp m7i43_hm2.h): this adds support for Up/Down output from pwmgen
[14:49:36] <jepler> you know, now that we don't support breezy anymore, we might be able to get rid of the custom opengl wrapper and Tk Togl widget shipped with emc. python-opengl works fine in dapper (I haven't tested it in hardy yet)
[14:53:44] <jepler> hmmmm, python-opengl's license is problematic -- it says it's subject to "SGI Free Software License B" which has recently been the subject of controversy in the debian project concerning xorg's opengl support as well.
[14:53:49] <jepler> I hate software.
[14:54:13] <cradek> f----
[14:55:28] <skunkworks> yeck
[14:55:39] <jepler> so -- forget it
[15:35:12] <CIA-22> EMC: 03jepler 07v2_2_branch * 10emc2/debian/ (changelog emc2.files.in rules.in): include license statement for Togl
[15:53:05] <cradek> jepler: I've found a bug in the biarc version of truetype-tracer for which we've both lost the source.
[15:53:52] <cradek> jepler: so, can you fix it?
[15:58:04] <cradek> oooh, and an arc bug in emc (for a small but humongous radius arc)
[15:58:16] <cradek> AXIS previews it correctly!
[15:59:04] <cradek> * cradek covers his eyes and pretends not to have seen this
[16:00:31] <SWPadnos> small but humongous. interesting
[16:02:10] <SWPadnos> ah, small arc length, humongous radius (ie, a short straight line :) )
[16:03:39] <cradek> yes
[16:04:24] <SWPadnos> sorry - it takes a few extra seconds (if I'm lucky) before I've had coffee
[16:19:37] <cradek> haha, auto-assigned to jmkasunich
[16:22:02] <SWPadnos> oooh - I like that feature :)
[16:31:48] <cradek> I bet the bug is deep in posemath. I haven't done the first bit of looking for it.
[16:33:25] <SWPadnos> hmmm
[16:33:37] <SWPadnos> all that math is done with doubles I think
[16:36:34] <SWPadnos> in single-precision-float-land, you can't get anywhere small with that i value
[16:37:18] <SWPadnos> if the radius is calculated by sqrt (i^2+j ^2), j^2 is too small to change the result
[16:37:26] <SWPadnos> (for singles anyway)
[16:39:07] <cradek> the exact radius doesn't matter (it probably won't move one encoder count or step anyway), but I'd prefer it to end at the right place instead of in north dakota, which I think is where it was headed
[16:40:09] <cradek> or, if we can't handle it for some fundamental reason, we could just reject it
[16:40:11] <SWPadnos> hmmm - with calculator, sqrt(bignum^2+0.25) = bignum
[16:40:26] <cradek> sure
[16:40:52] <cradek> the radius will almost exactly match the I value, that's not a surprise at all to me
[16:41:05] <SWPadnos> sure, but it screws up the trig
[16:41:56] <cradek> you must be seeing someting I'm not :-)
[16:41:56] <SWPadnos> note: I haven't finished my first cup of coffee yet :)
[16:43:07] <cradek> want me to reassign it to you? :-)
[16:43:12] <cradek> I happily will
[16:43:45] <SWPadnos> err - I don't think I said that ... :)
[20:18:28] <seb_kuzminsky> i'm working on getting my m7i43_hm2 driver into the 2.2 branch...
[20:18:51] <seb_kuzminsky> since i'm currently working in TRUNK, i'm trying to add it to the emc2.deb there first
[20:19:22] <seb_kuzminsky> but the TRUNK emc2.deb wouldnt build for me, there are some files installed in debian/tmp that dont get moved to the package directory
[20:19:32] <seb_kuzminsky> i've got a patch that fixes this but i'm not sure if i should commit it
[20:19:56] <seb_kuzminsky> is the emc2.deb package building on TRUNK for other people? am i missing something here?
[20:21:58] <seb_kuzminsky> what, everyone is in RL? :-p
[20:24:11] <fenn> rawr
[20:24:35] <seb_kuzminsky> hey
[20:24:44] <fenn> you can edit debian/rules to remove the lines the error out (files in debian/tmp not supposed to be there blah blah)
[20:24:52] <alex_joni> can you pastebin the patch?
[20:25:16] <fenn> or just fix it, that works too :)
[20:26:09] <seb_kuzminsky> http://pastebin.ca/951979
[20:26:51] <seb_kuzminsky> seems pretty straightforward, I'm just worried I'm missing something about TRUNK vs the other branches, or peoples territories or something
[20:27:03] <seb_kuzminsky> being the junior code monkey around here... ;-)
[20:27:46] <seb_kuzminsky> if that patch flies, there's a follow-up one that adds my drivers and manpages
[20:31:22] <alex_joni> seb_kuzminsky: looks great to me, just go ahead
[20:31:29] <seb_kuzminsky> ok thanks!
[20:31:35] <alex_joni> those have probably been added only recently
[20:31:45] <seb_kuzminsky> yea probably so
[20:31:48] <alex_joni> seb_kuzminsky: btw, if it's something as trivial as this you don't have to ask
[20:31:53] <seb_kuzminsky> thanks for the sanity check
[20:31:58] <alex_joni> btw.. TRUNK usually only gets built before a release
[20:32:04] <alex_joni> built as in debs
[20:32:11] <seb_kuzminsky> gotcha...
[20:32:16] <alex_joni> so during releases it might get out of sync ;)
[20:32:20] <seb_kuzminsky> hey wasnt there a buildbot and test server running?
[20:32:27] <alex_joni> compile only
[20:32:36] <alex_joni> but maybe we can extend that..
[20:32:46] <alex_joni> linuxcnc.org/compile_farm/
[20:32:53] <alex_joni> gotta run for a while now .. bbl
[20:33:12] <seb_kuzminsky> ok ttyl
[20:34:38] <CIA-22> EMC: 03seb 07TRUNK * 10emc2/debian/emc2.files.in: This makes emc2.deb build again
[20:47:28] <jepler> seb_kuzminsky: the .deb "target" doesn't get tested much on TRUNK, so stuff like that creeps in and doesn't get fixed.
[20:48:02] <jepler> thanks for doing it!
[20:48:24] <jepler> cradek: looking more closely at that debug output, it has
[20:48:24] <jepler> dot=1.000000000
[20:48:28] <jepler> circle {angle=6.283185307, radius=999999998.999999881, spiral=0.000000000}
[20:48:57] <cradek> dot from center to start and end?
[20:49:06] <cradek> same as equal atan2s
[20:49:09] <jepler> pmCartCartDot(circle->rTan, rEnd, &dot);
[20:49:09] <jepler> dot = dot / (circle->radius * circle->radius);
[20:49:26] <cradek> yep
[20:49:40] <jepler> except it must be less robust than atan2 for some reason .. I hate numeric programming.
[20:49:41] <cradek> I think for some reason rTan is how they spelled "start"
[20:51:12] <cradek> jepler: you pretty much square to get the dot, so I bet it gets crappy faster
[20:53:01] <jepler> since this arc can be in any plane, I don't see how to get the arguments I'd use with atan2..
[20:55:02] <cradek> instead of angle=0, just compare the endpoints for equality?
[20:55:13] <cradek> isn't that the actual test we want here?
[20:55:23] <jepler> hm you have to come see this one
[20:55:28] <cradek> oh no
[21:01:12] <jepler> gcode of the day:
[21:01:12] <jepler> G0 X0 Y0 Z0
[21:01:13] <jepler> G2 Y1 I99999999 F100
[21:01:13] <jepler> G1 X1
[21:01:13] <jepler> M2
[21:03:03] <jepler> when I tried to get rid of the artificial CIRCLE_FUZZ (which breaks circles less than about 1e-6 radians) I got something that is maybe worse from the program above. http://emergent.unpy.net/files/sandbox/g2-and-position-discontinuity.png
[21:11:50] <alex_joni> bah.ngc :D
[21:13:39] <cradek> is a .5" position jump or an unwanted 0.2 lightyear radius circle worse?
[21:14:53] <alex_joni> is the position jump on the g1 ?
[21:15:06] <cradek> yes
[21:15:10] <fenn> 0.2 nanolightyear :)
[21:16:03] <alex_joni> lightyearsecond
[22:28:47] <fenn> if stuff is for the gui, why is it in [traj]?
[22:30:52] <SWPadnos> I think there was a discussion about adding separate limits for the TP as well
[22:31:07] <SWPadnos> maybe they're there so there would only be one setting, once that's done ...
[22:31:27] <cradek> it will also be found if you put it in [DISPLAY]
[22:32:06] <seb_kuzminsky> ugh i'm spending more time relearning CVS than hacking
[22:33:18] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
[22:33:33] <alex_joni> seb_kuzminsky: maybe ask for pointers instead of reading tons of manuals?
[22:34:39] <alex_joni> hmm.. I just had a thought..
[22:35:04] <alex_joni> how about ini_axis looks for joint_0, if it doesn't find it it looks for axis_X, and if that fails too, then for AXIS_0
[22:35:19] <seb_kuzminsky> alex_joni: I'm not having ini problems (yet)... i'm testing my merge from trunk to v2_2_branch before committing
[22:35:21] <alex_joni> that way we keep compatibility with older configs too
[22:35:51] <alex_joni> seb_kuzminsky: sorry.. this was not related to you ;) .. it's an older talk for cleaning up joints & axes
[22:36:09] <alex_joni> every once in a while something turns up, which reminds me how mixed up it is..
[22:36:15] <fenn> * fenn mumbles something about [DISPLAY] MAX_LINEAR_JOG
[22:36:47] <alex_joni> fenn: I think it should be part of [JOINT_[0..9]]
[22:37:01] <alex_joni> MAX_JOG and DEFAULT_JOG
[22:37:07] <fenn> so the slider would change depending what joint is selected?
[22:37:13] <alex_joni> then you can set it for each joint
[22:37:16] <SWPadnos> that's great for joint jogging, but not so helpful for teleop
[22:37:17] <fenn> and what about teleop
[22:37:19] <alex_joni> that's up to the GUI designer
[22:37:25] <alex_joni> in AXIS_X..
[22:37:40] <alex_joni> X,Y,Z .. W
[22:38:06] <alex_joni> I'm still not sure how a nice GUI would look like..
[22:38:13] <fenn> i hear flat interfaces are all the rage
[22:38:26] <fenn> more buttons == more fun!
[22:38:31] <alex_joni> having 9 sliders is messed up, and changing the slider when selecting a joint/axis is odd too
[22:38:43] <cradek> I want it to look like [the control I'm used to] which is the only good one
[22:38:52] <alex_joni> not the boss?
[22:38:55] <cradek> sorry, trolling
[22:39:00] <cradek> arg
[22:39:04] <cradek> the boss is not great.
[22:39:05] <alex_joni> F2. ?
[22:39:11] <alex_joni> * alex_joni is kidding :)
[22:39:48] <alex_joni> cradek: anyways, I'm not considering changing AXIS or encouraging that
[22:40:55] <alex_joni> hmm, atm FO doesn't affect jogs right?
[22:41:03] <cradek> yes it does
[22:41:27] <alex_joni> hmm.. so that's a general jog speed override :)
[22:42:51] <seb_kuzminsky> later, all
[22:48:46] <alex_joni> jmkasunich: how does this sound? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?action=browse&diff=1&id=IniChanges&revision=13&diffrevision=12
[22:51:39] <SWPadnos> if kinematics modules are extended to have a joint init callback (even if all it does is provide the number of required/allowed joints), then any kins module can be properly supported without explicit init code
[22:52:28] <SWPadnos> genhexkins requires and allows 6 joints, so 0-5 must all be present, and 6+ wouldn't be allowed (disallowing extras is optional)
[22:53:04] <SWPadnos> genhexkins also "suggests" 6 cartesian axes, since the kinematics can support XYZRPW
[22:53:23] <alex_joni> you'd think so
[22:53:26] <SWPadnos> heh
[22:53:35] <alex_joni> but RPW aren't valid g-code coordinates
[22:53:53] <SWPadnos> eh - XYZABC or whatever you want to call the TOV rotations
[22:53:53] <fenn> ABC
[22:55:03] <SWPadnos> actually, some checking can be done as to whether the kins module selected can actually support the COORDINATES in the ini file
[22:59:31] <SWPadnos> I think kinematics could be used to implement lathe diameter vs. radius mode
[23:00:32] <SWPadnos> then again, there would be no way to switch. hmmm
[23:03:40] <jmkasunich> oh, joints and axes again
[23:03:43] <jmkasunich> my favorite
[23:05:32] <fenn> lathe diameter vs radius mode is an interpreter issue, end of story.
[23:15:41] <jmkasunich> cradek: what do I have to do to get that short huge arc bug off of my name?
[23:15:55] <jmkasunich> fix it? ;-)
[23:16:05] <jmkasunich> (I hope not, wou;dn't know where to start)
[23:16:10] <jmkasunich> l
[23:20:11] <alex_joni> * alex_joni heads to bed
[23:20:15] <alex_joni> good night all