Back
[00:31:54] <steve_stallings> steve_stallings is now known as steves_logging
[00:33:48] <jmkasunich> jepler: can you point me at any docs that describe how the axis/vismach mouse based viewpoint rotation works?
[00:34:06] <jmkasunich> it seems I can rotate around my model's X and Z axes, but not around Y
[00:34:24] <jmkasunich> for a horizontal spindle machine that is a bit limiting
[00:40:38] <jepler> jmkasunich: jas
[00:41:21] <jepler> jmkasunich: I think it happens in the file lib/python/rs274/OpenGLTk.py, function glRotateScene
[00:41:40] <jmkasunich> * jmkasunich looks
[00:41:42] <jepler> jmkasunich: the rotation is based around euler angles, you get two angles from the mouse coordinates
[00:41:47] <jepler> glRotatef(snap(lat), 1., 0., 0.)
[00:41:47] <jepler> glRotatef(snap(lon), 0., 0., 1.)
[00:43:14] <jmkasunich> so we're trying to position the viewer using latitude and longitude
[00:43:35] <jepler> basically
[00:43:43] <jmkasunich> but the axis of the globe is aligned with Z
[00:43:50] <jepler> yes
[00:44:01] <jmkasunich> instead of being vertical wtr to a human looking at the machine
[00:44:21] <jepler> you could experiment with hard-coding the two vectors you want
[00:44:25] <jmkasunich> sounds like all I need to do is rotate the machine
[00:44:33] <jepler> that might work too
[00:45:01] <jepler> anyway, the code could be changed around so that the axes are settable, just like min/max latitude
[00:45:21] <jmkasunich> how are the initial values of lat and lon determined?
[00:45:52] <jepler> in class Opengl's init
[00:46:06] <jepler> self.lat = 0
[00:46:08] <jepler> self.lon = 0
[00:46:15] <jmkasunich> hmm
[00:46:30] <jepler> t = O(app, double=1, depth=1)
[00:46:33] <jepler> you could set it just below here
[00:46:43] <jepler> just after that you'd write: t.lat = ...; t.lon = ...
[00:47:12] <jmkasunich> I just rotated my model so that the machine's "up" (which happens to be Y) is pointing at world "up" (Z)
[00:47:21] <jmkasunich> and now panning works fine
[00:47:37] <jepler> is this about panning or about rotating?
[00:47:40] <jmkasunich> (fine = intuitively, you can move up/down, and spin around the vertical axis
[00:47:44] <jmkasunich> rotating, sorry
[00:47:55] <jmkasunich> moving the viewer around the machine
[00:48:23] <jmkasunich> the "hmm" is because the initial viewpoint is now from straight above the machine
[00:48:41] <jmkasunich> I'm used to lat = 0 being the equator, poles are +/- 90
[00:48:50] <jmkasunich> is lat = 0 straight up in opengl?
[00:49:31] <jmkasunich> I guess its not opengl, its OpenGLTk.py
[00:49:56] <jepler> I think you're right that in that code 0 is the "north pole"
[00:51:01] <jmkasunich> so, I could change lat to conform to the traditional globe definition, but that would break other things
[00:51:06] <jepler> yes it would
[00:51:25] <jmkasunich> or I could figure out how to let each caller of the opengltk lib specify an initial lat and lon
[00:51:48] <jepler> I think you can just write 't.lat = <initial lat value>' in vismach right below t = O(...)
[00:52:35] <jmkasunich> ah
[00:52:44] <jepler> but in a minute I'll have a way that script using vismach can set it
[00:52:48] <jepler> because they all want different things
[00:53:22] <SWPadnos> what can we get in two minutes? :)
[00:54:27] <jmkasunich> btw, what is HUD?
[00:54:33] <SWPadnos> heads up display
[00:54:41] <SWPadnos> ie, the data overlaid on the 3D model
[00:54:52] <jmkasunich> thats what I thought
[00:55:01] <jmkasunich> but I don't think I've ever seen it
[00:55:17] <SWPadnos> doesn't AXIS use the same 3D library?
[00:55:34] <jepler> HUD is something specific to vismach
[00:55:37] <jmkasunich> HUD is defined in vismach.py
[00:55:39] <SWPadnos> oh
[00:55:42] <jepler> axis has a different way of doing its DRO overlay
[00:55:44] <SWPadnos> in that case - nevermind me
[00:55:49] <jepler> I think HUD is used by some hexapod visualization that fenn did
[00:55:56] <jepler> huh why are my changes having no effect?
[00:57:38] <jepler> (I'm wrong about just being able to set lat and lon there)
[01:03:20] <jmkasunich> class OpenGL has a set_latitudelimits method, does it need method(s) to set lat and lon as well?
[01:05:02] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/OpenGLTk.py: allow calling code to control the rotation vectors
[01:05:09] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: allow calling code to control the rotation vectors and initial orientation
[01:05:10] <jepler> example: main(model, tooltip, work, 1500, rotation_vectors=[(0,1,0),(0,0,1)], lat=90, lon=45)
[01:05:43] <jmkasunich> thank you very much
[01:05:48] <jepler> (not a particularly useful example, mind you)
[01:06:19] <jmkasunich> actually, I'm not sure why you made the vectors user settable
[01:06:44] <jepler> originally it sounded like that was the solution
[01:06:48] <jmkasunich> I guess that would let me avoid rotating my model to align it with world coords
[01:06:57] <jmkasunich> did you mean to leave the prints in there?
[01:08:01] <jepler> of course nolt
[01:08:02] <jepler> not
[01:08:24] <jmkasunich> so far I've just looked at the diff
[01:08:44] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: remove debugging print
[01:08:50] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/OpenGLTk.py: remove debugging print
[01:09:24] <jmkasunich> why does set_viewangle() need to call RotateScene? can't it just set lat and lon?
[01:10:16] <jepler> glRotateScene actually does the dirty work
[01:10:27] <jmkasunich> but the dirty work was being done before
[01:10:29] <jepler> setting lat and lon directly has no effect until the next rotation
[01:10:37] <jepler> .. next mouse event with the right button pressed
[01:11:22] <jmkasunich> I think I see - it isn;t actually possible to set the initial values of lat and lon before the first rendering, so when you do set them, you need to re-render?
[01:12:08] <jepler> yeah
[01:12:13] <jepler> I'm not sure why the "after" is necessary
[01:12:18] <jepler> (or that it's sufficient)
[01:12:30] <jmkasunich> I was gonna ask you what after means
[01:12:31] <jepler> there's some other detail of the initialization that I'm overlooking
[01:12:53] <jepler> it causes the code to be called after no less than 100ms, during the course of regular event handling by Tk
[01:13:43] <jmkasunich> how is the handling of lat and lon initial values different than "latitudelimits"?
[01:14:54] <jepler> setting latitude limits has no immediate effect, so there's no need for any of those shenanigans
[01:15:02] <jmkasunich> ok
[01:17:29] <jmkasunich> someday I'll wrap my head around the combination of OO and event loops
[01:17:48] <jepler> when you decide to try, don't look at my code
[01:17:56] <jepler> it's not the greatest at anything except working mostly
[01:18:18] <jmkasunich> to be honest, that someday is probably a long way from now - I have other things I'd rather do
[01:21:17] <jmkasunich> trying to understand - the lambda tells python to evaluate "t.set_viewangle" when the t.after "triggers" instead of when t.after is initially invoked?
[01:24:50] <jmkasunich> seems to work nicely
[01:24:56] <jmkasunich> the vectors take a bit of getting used to
[01:25:29] <jmkasunich> the 2nd vector is the "up" axis (the one that goes thru the poles of the globe in the lat/lon mental model
[01:25:35] <jmkasunich> I'm not sure what the first one is
[01:26:50] <jmkasunich> but it sure looks like anything other than 1,0,0 gives very non-intuitive results
[01:27:19] <jmkasunich> jepler: would you mind if I redid your vector change so you specify a single "up" vector, instead of a pair
[01:27:35] <jepler> sure
[01:28:39] <jmkasunich> hmm, this is more complex than I thought
[01:28:50] <jmkasunich> the 2nd vector alone isn't "up" either
[01:31:16] <jepler> well now you're in geometry and I'm really helpless there
[01:32:13] <jmkasunich> well, I'm just playing around now, seeing what different combos do
[01:32:22] <jmkasunich> twisting my brain it is
[01:32:47] <jepler> the other thing you might want to vary -- but can't -- is whether lat or lon is applied first
[01:33:29] <jmkasunich> the order seems to be right for what I'm trying to do
[01:33:53] <jmkasunich> I want to be able to visualise the user/camera as being able to move up/down, and walk around
[01:34:30] <jmkasunich> left-right mouse motion should just spin the model around a vertical axis, and that's what it does
[01:34:50] <jmkasunich> something tells me if the order was reversed it would do weird things
[01:38:09] <SWPadnos> you can test it by swapping the order of the rotation vectors
[01:38:38] <SWPadnos> (you will, of course, have a hard time because mouse movement won't correspond to model movement :) )
[01:41:19] <jmkasunich> I'm trying hard to wrap my brain around the default orientation
[01:41:45] <jmkasunich> I should probably make a model with three colored rods representing the three axes
[01:42:15] <jmkasunich> if I set the vectors to 100 010, I get the Y axis as "up", and the XZ plane is the ground
[01:42:47] <jmkasunich> or not
[01:43:02] <jmkasunich> I was testing with initial lat = 45, bad choice
[01:44:01] <jmkasunich> ok, with 100 010, lat and lon both zero, I start out standing on the XZ plane, looking along the Z axis
[01:44:18] <jmkasunich> left right mouse movement spins around Y (as expected)
[01:44:35] <jmkasunich> up/down moves me above or below the plane
[01:45:33] <jmkasunich> that rotation doesn't take place around the model's X axis, it is around an axis perpendicular to the eye-model line, and horizontal
[01:46:20] <jepler> maybe it makes more sense to do what you did at first: just rotate the model so that it works well with the one style of rotation available..
[01:46:33] <jmkasunich> that was where I was going
[01:46:45] <jmkasunich> but I was having trouble
[01:46:54] <jmkasunich> I just went back to the original vectors, lat and lon zero
[01:47:40] <jmkasunich> the initial view is the same - I'm on the XZ plane, looking along Z
[01:48:22] <jmkasunich> mouse left/right spins around the object Z axis
[01:48:49] <jmkasunich> duh, ok, I think I understand now
[02:08:20] <jmkasunich> jepler: still here?
[02:10:55] <jmkasunich> there is a sign error somewhere, but I'm having trouble deciding where
[02:11:26] <jmkasunich> I made a model with nothing but three arrows for the three axes, red/green/blue for XYZ
[02:11:43] <jmkasunich> if the initial lat and lon are zero, I find myself staring at the point of the blue/Z arros
[02:12:19] <jmkasunich> with green (Y) pointing down and red (X) right
[02:13:10] <jmkasunich> if I move the mouse up, after 90 degrees, green (Y) is pointing at me, blue/Z is pointing up, red X is still pointing right
[02:13:28] <jmkasunich> since I moved up, I assumed that direction is positive latitude
[02:13:55] <jmkasunich> so I set initial latitude to +90 and expected to see the same thing, Y at me, Z up, X right
[02:14:19] <jmkasunich> instead, Y is away from me, Z is down, and X is right
[02:15:11] <jmkasunich> I could "fix" this by inverting the initial lat value, but I'm not sure that is right
[02:16:15] <jmkasunich> going back to the lat = lon = 0 case, if I'm somewhere out on the +Z axis looking at the origin, and we have a right handed coord system, shouldn't +Y be up and +X be right? I have Y down and X right
[02:18:58] <jmkasunich> lol - I just found a bug in CylinderY() - it makes a cylinder pointing the wrong direction along the axis
[02:19:06] <jmkasunich> so it was building a left-handed coordinate system
[02:19:41] <jmkasunich> (the test = put a box at the end of each arrow)
[02:46:58] <CIA-37> EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/vismach.py: fix bug in CylinderY() - cylinder pointed wrong direction along axis - also fix invocations of CylinderY()
[02:46:58] <CIA-37> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/ (5axisgui.py maho600gui.py max5gui.py): fix bug in CylinderY() - cylinder pointed wrong direction along axis - also fix invocations of CylinderY()
[02:49:25] <jmkasunich> looking at the invocations, that bug should have been apparent before - when you have to start a cylinder at -18 to butt it against a box that ends at +18, the mental bug detector should go off
[02:49:52] <jmkasunich> (I wrote most of those invocations - it's my mental bug detector that needs fixed)
[02:52:33] <jmkasunich> back to lat and lon
[02:53:42] <jmkasunich> ok, lat = lon = 0, starts out looking at the sharp end of the Z arrow, Y is up, X is right
[02:54:03] <jmkasunich> mouse up, rotates so that you are looking at the dull end of the Y arrow, Z up, X right
[02:54:17] <jmkasunich> exactly what you'd expect
[02:54:31] <jmkasunich> since I moved the mouse up, I set lat = 90
[02:54:55] <jmkasunich> and behold, I'm seeing the sharp end of Y, Z points down, X right
[02:57:18] <jmkasunich> sure enough, moving the mouse up actually makes lat go down
[02:58:00] <jmkasunich> I guess that makes sense
[02:58:18] <jmkasunich> mouse up means viewer is moving down from the north pole, so latitude should be getting smaller
[03:02:55] <jmkasunich> yay, got the initial view and rotations working they way I want
[03:39:59] <cradek> oh I didn't think about this machine being sideways...
[03:41:07] <jmkasunich> did you see the screenshot I just posted?
[03:41:11] <jmkasunich> yes, you did
[03:41:12] <jmkasunich> duh
[03:44:48] <KimK_IA> I looked at your screenshot too, very nice. Is that vismach?
[03:44:54] <jmkasunich> yes
[04:32:21] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: make pretty columns instead of using tabs (which never look right)
[11:52:24] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/index.tmpl: add ladder section to html docs
[12:07:43] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/index.tmpl: that looks better
[12:28:42] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Master_User.lyx index.tmpl): minor edits
[12:28:46] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/GPLD_Copyright.lyx: minor edits
[12:59:49] <alex_joni> hi samco
[13:26:49] <skunworks> Hi alex
[13:26:54] <skunworks> How is it going?
[13:26:59] <alex_joni> pretty good
[13:27:14] <alex_joni> started working on the electric wiring in the app.
[13:27:51] <skunworks> Boy - it has been a while. You found a place?
[13:28:35] <skunworks> how is the wiring? Old?
[13:28:35] <alex_joni> yeah, bought an app. 1 month ago
[13:28:49] <alex_joni> not all is old, but I still want to replace everything
[13:28:56] <alex_joni> it's only 2-wire
[13:37:16] <skunworks> scary ;)
[13:37:36] <alex_joni> yup :)
[13:38:18] <skunworks> A good portion of my house is cloth wiring.
[13:38:21] <skunworks> 2 wire
[13:44:06] <alex_joni> well.. since the app is empty I can easily irp it all out, and redo
[13:44:10] <alex_joni> rip
[13:44:45] <skunworks> nice
[13:44:46] <alex_joni> but it's not very easy (doing this on brick walls ;)
[13:44:52] <skunworks> eww
[13:45:00] <skunworks> how is it run now?
[13:45:17] <alex_joni> inside the wall in old metalic tubes
[13:45:29] <alex_joni> which I'm replacing with plastic
[13:45:57] <alex_joni> bbl.. running home to do some more work on this
[17:03:50] <SWPadnos> cradek, did you ever do that linuxcnc.org backup (in case I decide to move to the unlimited plan)?
[18:04:15] <cradek> SWPadnos: I will run one tonight, and also right before you make any change, if you let me know.
[18:04:24] <SWPadnos> ok, thanks
[18:04:49] <SWPadnos> haven't done it, and I'm not sure if/when I will - just wondering what had happened with it
[18:06:10] <alex_joni> do they still have openings?
[18:08:37] <SWPadnos> dunno. I think it may have been two different offers
[18:08:47] <SWPadnos> one for new customers, the other for current subscribers
[18:09:28] <alex_joni> might be..
[18:09:36] <alex_joni> anyways, I didn't see anything yet
[18:09:43] <alex_joni> any changes I mean
[18:09:58] <SWPadnos> oh- as far as actually moving your account over?
[18:10:39] <alex_joni> yeah, they updated the info all over the panel, but nothing more
[18:18:28] <SWPadnos> looks like the offer is still open
[18:18:52] <SWPadnos> I have another friend with an account - I'll have to see if the forums have been screwed up or if the move has been done yet
[20:02:25] <skunworks> logger_dev: bookmark
[20:02:25] <skunworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-20.txt
[20:12:06] <micges> in emcmodule.cc axis["inpos"] is updated when jogging axis
[20:12:34] <micges> but doesn't update while in MDI mode
[20:12:38] <micges> is this correct ?
[20:16:20] <micges> gn all
[20:34:42] <jepler> micges: yes, it's purely for the "free planner". It is emphatically not a "this axis is not moving at this time" flag to use to reduce hold current or the like.
[20:37:11] <skunworks> Jepler: did you troubleshoot the following error on plutostep?
[20:37:51] <jepler> skunworks: no, I have no idea what went wrong
[20:38:17] <skunworks> heh - yecky
[20:38:52] <skunworks> it has only happened once so far though - right?
[20:39:35] <jepler> yes
[20:39:42] <jepler> I'd be happier if it happened every time :-P
[20:40:06] <skunworks> yes - those are a lot easier to find.