Back
[00:46:02] <cradek> this scara robot is sure cool
[00:46:12] <cradek> it actually works fairly well
[00:48:01] <jmkasunich> hi guys
[00:48:38] <cradek> hi
[00:49:29] <jepler> hi jmkasunich
[00:49:32] <jepler> hi chris
[00:49:42] <jmkasunich> I was playing with the scara a bit at lunchtime on a sim...
[00:49:48] <jmkasunich> I have one comment about axis:
[00:50:01] <jmkasunich> how come it still jogs when you hit an arrow key, even if you are in MDI mode?
[00:50:09] <jepler> uh oh
[00:50:11] <jepler> that used to work
[00:50:13] <jmkasunich> if that was a real mill I would of busted something
[00:50:38] <jmkasunich> the numberkeypad arrows jog, the other arrows move the cursor
[00:50:55] <jmkasunich> (I tend to use the number pad arrows, never got used to the new keboards)
[00:51:05] <jepler> I never touch the numberpad arrows
[00:51:07] <jepler> particularly on my laptop
[00:51:14] <jmkasunich> lol
[00:51:29] <cradek> jmkasunich: PGA
[00:51:33] <cradek> (heh)
[00:51:51] <jmkasunich> I imagine the current behavior is a feature, since you can both move the cursor and jog the machine that way
[00:52:02] <jmkasunich> but moving the machine from _any_ jog command when in MDI seems wrong
[00:52:12] <jmkasunich> what is PDA?
[00:52:14] <cradek> it must switch out of MDI and back in
[00:52:22] <cradek> 'patches gratefully accepted'
[00:52:59] <jmkasunich> jeez... write a few lines of python and now they think I can figure out axis ;-)
[00:55:40] <cradek> this must be one for jepler - when in the text entry, it looks like it uses the tk default bindings, which must not be what we expect
[00:56:10] <jepler> I wonder if the recent mdi enhancements broke it
[00:56:15] <jepler> I'm distracted right now but I'll look at it soon
[00:56:29] <cradek> :q
[00:56:55] <cradek> no, it's not recent
[00:57:05] <cradek> emc 2.1.0 has this feature too
[00:57:36] <jepler> well crap
[00:57:41] <jepler> here comes the 2.1.1 bugfix release
[00:57:45] <jepler> is it for numpad arrows only?
[00:57:51] <cradek> yes
[00:57:54] <cradek> regular arrows work as expected
[00:58:11] <cradek> but the numpad jogs when typing mdi commands
[00:58:33] <cradek> jmk must be the only person on the planet who uses those
[00:58:44] <jmkasunich> could be
[00:59:01] <cradek> that doesn't make it not a bug of course
[00:59:12] <cradek> talk about strange, I use C-f/C-b
[01:04:25] <cradek> jmkasunich: please test that
[01:04:42] <jmkasunich> will do, stand by
[01:05:46] <cradek> (you're not going to like that the numpad doesn't work for editing the MDI though)
[01:06:06] <jmkasunich> I can deal with that, it might teach me to use the other arrows
[01:06:18] <jmkasunich> jogs in mdi are the real issue
[01:06:27] <cradek> yeah
[01:09:09] <jmkasunich> the fourth axis on the scara config should be C, not A
[01:09:24] <jmkasunich> but I think the only way to get C is to have all 6 ?
[01:09:59] <jmkasunich> (I want to test the joint 3 kins - as you change C the arm should move, and the tip of the tool should stay fixed
[01:11:22] <cradek> yes unfortunately
[01:11:36] <jmkasunich> well, thats just another non-triv issue
[01:11:40] <cradek> yes
[01:11:47] <jmkasunich> reading back I see jeff has already thought of quite a few
[01:12:39] <cradek> for lathe, you define XYZ and AXIS hides Y
[01:12:52] <jmkasunich> how hard would it be to put the preview into the vismach window?
[01:12:54] <cradek> so it's sometimes a problem even with trivkins
[01:13:40] <cradek> the preview or the backplot?
[01:13:42] <jmkasunich> * jmkasunich imagines a vismach model of a bridgeport with stacked rotary tables mounted
[01:13:52] <jmkasunich> either? both?
[01:14:11] <cradek> backplot is probably easier
[01:14:47] <jmkasunich> yeah, backplot wouldn't need to tie in with anything
[01:16:10] <jmkasunich> another way of looking at it - how hard would it be to put the vismach display into the axis preview window? ;-)
[01:16:49] <cradek> I remember thinking that's where it belongs...
[01:17:14] <jmkasunich> well, I don't want to give up the stand-alone version (you know me and non-EMC applications)
[01:17:23] <jmkasunich> but if its implemented as a lib....
[01:18:50] <cradek> like usual jepler is probably the one to answer those questions
[01:19:13] <jmkasunich> he was here not long ago, I was addressing both of you
[01:20:44] <jmkasunich> the keypad fix works
[01:23:13] <jmkasunich> thinking about backplot in the standalone version.... its not as simple as I originally thought
[01:23:44] <jmkasunich> I don't actually know where the tool enpoint is in world coords
[01:23:58] <jmkasunich> and of course, the line needs to be drawn in world coords so it doesn't move
[01:24:43] <jmkasunich> the tooltip is at the end of a stack of transforms, some of which are time-varying
[01:25:57] <jmkasunich> actually, I don't want to draw in world coords, I want to draw in workpiece coords
[01:26:32] <jmkasunich> for scara they are the same, but for a machine with a rotary table (or even a plain mill where the table moves under the tool) they aren't
[01:27:07] <jmkasunich> methinks I should make bportgui.py soon
[01:27:25] <cradek> yeah the whole idea of the preview plot is probably not going to work for some machines
[01:27:28] <jmkasunich> and gantrygui
[01:28:13] <jmkasunich> maybe not
[01:28:35] <jmkasunich> I need to learn more about the GL matrix stack(s)
[01:29:14] <jmkasunich> the general case is a tree of transforms, one branch goes from world coords to tool coords, and one goes from world to workpiece
[01:30:00] <jmkasunich> if I could extract the tool->world and work->world transforms, we could draw into either of those spaces and everything else would happen automagicaly
[01:30:24] <jmkasunich> (preview is drawn in work space - I bet right now you're drawing it on world space)
[01:31:28] <jmkasunich> for backplot, you transform tooltip location (which is fixed in tool space, unless tool length changes) from tool space to world, then to work, and draw the line in work space
[01:31:54] <jmkasunich> each time you update, if old workspace pos != new, you must have moved, draw a line connecting the two
[01:32:11] <jmkasunich> </ramble>
[01:32:45] <jmkasunich> oh, thats interesting
[01:32:49] <jmkasunich> I just shut down EMC
[01:33:14] <jmkasunich> and the vismach display flipped upside down, and python exited with an error
[01:33:50] <cradek> ha
[01:33:53] <jmkasunich> yuck - the defunct python processes are piling up too
[01:34:53] <jmkasunich> the error message was "keyboard interrupt", but I thought one of you guys fixed that
[01:35:57] <cradek> brb
[01:36:09] <jmkasunich> http://pastebin.ca/342042
[01:39:58] <jmkasunich> hmm, I should remember to set expiration times when I pastebin stuff
[01:40:20] <jmkasunich> when they say never they mean it - post 20 is still there, from 34 months ago
[01:45:51] <jepler> cradek: I think "End" needs to be added to that list as well
[01:46:04] <jepler> I guess I can do it
[01:46:07] <jepler> I'm back now, fwiw
[01:46:17] <jmkasunich> gathered that ;-)
[01:48:41] <jepler> so in your view, if I'm using a machvis model of a traditional mill (where the work moves on the table), the preview and the backplot should "move around" on the screen while the base of the mill stays fixed?
[01:48:59] <jmkasunich> well, I dunno
[01:49:32] <jepler> perhaps it should be possible to choose which point to keep fixed: the tooltip, the world, or the work
[01:49:32] <jmkasunich> ideally the model would understand tool, world, and workpiece coords
[01:49:36] <jmkasunich> right
[01:50:00] <jmkasunich> world is overloaded - up till now, world has meant workpiece I think
[01:50:08] <jepler> yes, I think that's right
[01:50:45] <jmkasunich> I'm browsing GL docs, to see if its possible to extract the world->work and world->tool matrices
[01:50:59] <jepler> you can use glGetDoublev(GL_MODELVIEW) to get the matrix at any particular time
[01:51:00] <jmkasunich> given the matrices/transforms you can draw in any space you want
[01:51:37] <jmkasunich> I guess I have to understand when the right time is to grab it then
[01:52:14] <jmkasunich> it has to be done while traversing the tree I think - when you are in the tool "leaf", grab the tool matrix, when you are in the work "leaf" grab that one
[01:52:16] <jepler> I imagine that the machine description would have a (non-displaying) node for "tool" and "work"
[01:52:27] <jmkasunich> which means those leaves need tagged somehow
[01:52:37] <jmkasunich> yeah
[01:53:06] <jepler> you'd start with the identity transform (rather than the one that specifies how the camera is oriented), and traverse the tree doing transformations as normal
[01:53:25] <jepler> the "tool" and "work" objects record the transforms when they are reached in the traversal
[01:53:32] <jmkasunich> right
[01:54:09] <jmkasunich> I _think_ you wouldn't even have to explicitly travers the tree - could the "grab if tagged" code be embedded in the draw method?
[01:54:24] <jmkasunich> actually, thats it - another primitive
[01:54:38] <jmkasunich> who's draw method just grabs the matrix
[01:54:45] <jmkasunich> whose
[01:54:49] <jepler> yes but if it's part of the normal draw procedure, then you have the camera orientation mixed up in it
[01:55:01] <jmkasunich> fooey
[01:55:44] <jepler> that's how I did the "backplot" in this image
http://axis.unpy.net/files/01170693566/scara.png
[01:56:05] <jmkasunich> when did you do that?
[01:56:19] <jepler> but it has the problem that if you rotate or translate (camera movements that are expressed by changing the MODELVIEW) the plot stays fixed with respect to the screen
[01:56:21] <jepler> earlier today
[01:57:08] <jmkasunich> iow, you might as well have been writing pixels directly
[01:57:25] <jepler> though you should be able to take out the original view matrix by right-multiplying the ultimate "work" matrix by the inverse of the initial "view" matrix
[01:57:28] <jmkasunich> infact, maybe you were? the lower left corner of the E isn't hidden by the column
[01:57:49] <jepler> I'm pretty sure it really was in front of the column
[01:57:58] <jmkasunich> yeah, I just figured that out
[01:58:09] <jmkasunich> darned monocular vision
[01:59:08] <jepler> clearly AXIS needs a shutter-glasses mode
[01:59:19] <jmkasunich> I was thinking that too ;-)
[01:59:55] <jmkasunich> better - head tracking, so when you move your head it redraws the view inside the window
[02:00:01] <jepler> uh yeah sure
[02:00:13] <jepler> I'll move that up to the top of my list as soon as someone sends me hardware
[02:00:14] <jmkasunich> "lemme look around that column and see what is back there"
[02:00:22] <jepler> maybe we should just make it work with the "wii" controller?
[02:00:26] <jmkasunich> lol
[02:00:35] <jepler> er, excuse me, "wiimote"
[02:00:50] <jmkasunich> that measures accel, double integration will result in intolerable drift
[02:00:57] <jmkasunich> I think you'll need a wireless GPS hat
[02:01:58] <jmkasunich> a sufficiently twisted person could do head tracking
[02:02:02] <jmkasunich> two webcams mounted on the screen
[02:02:17] <jmkasunich> and a blinking LED mounted in the bridge of the users eyeglasses
[02:02:42] <jepler> why not two LEDs on the edges of the glasses, so you can get orientation too?
[02:02:47] <jmkasunich> yeah
[02:03:11] <jmkasunich> toggle them on alternate frames, and subtract consecutive frames
[02:03:20] <jmkasunich> then you just have to look for the bright spot
[02:03:53] <jmkasunich> * jmkasunich adds another wild idea to the list of "someday I have to try that" projects
[02:03:58] <jepler> the LEDs have to sync with the camera?
[02:04:02] <jepler> sounds like trouble
[02:04:07] <jmkasunich> not "have to"
[02:04:15] <jmkasunich> but it would make image processing loads simpler
[02:04:32] <jepler> I think modern software design happens by assuming processing power is unlimited
[02:05:12] <jmkasunich> if you have two frames from each camera, and you know that in frame 1, led1 is on and led2 is off, and in frame 2, led1 is off, and led2 is on, its easy to spot the leds
[02:05:25] <jmkasunich> background light, etc, would almost be a non-issue
[02:06:34] <jepler> is having 1 camera and 2 LEDs like having 2 cameras and 1 LED?
[02:06:37] <jmkasunich> put it this way - I'm not smart enough to figure it out if they are on all the time (or otherwise unsynced), even if the CPU has the power
[02:06:51] <jmkasunich> the camera would have to be on your head
[02:07:01] <jmkasunich> I think
[02:07:12] <jmkasunich> oh, maybe not
[02:07:32] <jmkasunich> with one led, there are no range clues
[02:07:37] <jmkasunich> but with 2...
[02:08:02] <jmkasunich> except that when the 2 get closer together, it could be because you moved away, or because you turned
[02:08:48] <jmkasunich> maybe with 3 or 4 leds and one camera
[02:08:48] <jepler> hm true
[02:10:04] <jmkasunich> hmm... 2 cameras on the monitor, each with a strong IR led next to it pointing out
[02:10:13] <jmkasunich> and two very small retroreflectors on the corners of the glasses
[02:10:22] <jmkasunich> look ma, no wires (or batteries)
[02:10:24] <jepler> that's a good way to get the flashes synched with the cameras
[02:10:35] <jmkasunich> yeah
[02:11:05] <jmkasunich> you can't tell which end of the glasses is which, but unless they're standing on their head you can make a pretty good guess
[02:12:00] <jepler> use white illuminators and put filters on the mirrors
[02:12:04] <jmkasunich> if the leds are IR, you could put IR pass/vislble block filters on the camera
[02:12:31] <jmkasunich> I think rejection of background light is more important than telling if they are standing on their head
[02:12:36] <jepler> OK OK
[02:12:43] <jmkasunich> ;-)
[02:13:02] <jmkasunich> ok, we got the hard parts worked out, now its just a smop
[02:13:10] <jmkasunich> we'll let cradek do it
[02:13:58] <jmkasunich> ok, where were we.
[02:14:03] <jmkasunich> backplotting
[02:14:37] <jmkasunich> main.update is called each time you want to draw, right?
[02:14:46] <jmkasunich> (is main.update the proper notation?)
[02:14:59] <jepler> yes
[02:15:14] <jepler> I think you mean machvis.update or machvis.py:update
[02:15:31] <jmkasunich> I guess
[02:15:49] <jmkasunich> vismach actually, but thats a nit
[02:15:59] <jmkasunich> update is defined inside vismach.main tho
[02:16:03] <jepler> recently I saw someone sign his e-mail as 'world class nitpicker'
[02:16:13] <jmkasunich> doesn't that mean its vismach.main.update?
[02:16:30] <jepler> ok, yes
[02:16:32] <jmkasunich> or am I missing something basic about python nameing?
[02:17:04] <jepler> you can't actually refer to "update" from the outside of main like that
[02:17:08] <jepler> I don't want to get bogged down in that detail, though
[02:17:16] <jmkasunich> I'm still wrapping my head around this OO stuff, so please be pedantic if you can ;-)
[02:17:26] <jepler> actually, the reason isn't OO
[02:17:32] <jmkasunich> once I understand better we can use shorthand
[02:17:49] <jmkasunich> oh, main isn't a class like Collection and friends
[02:17:54] <jepler> no, it's a function
[02:18:27] <jmkasunich> ah - t is an instance of class O, and that does the good stuff
[02:18:58] <jmkasunich> and there is the call to traverse (in O.redraw)
[02:18:59] <jepler> since you asked for it, let's take the detour to what exactly the 'update' inside 'main' is
[02:19:02] <jepler> http://pastebin.ca/342084
[02:19:05] <jmkasunich> ok, please
[02:19:08] <jepler> I think the technical term is a "closure"
[02:19:28] <jepler> can you guess what the output is without running it?
[02:19:40] <jmkasunich> thinking
[02:20:15] <jmkasunich> add_4 is a funct that adds 4, add_5 adds 5, so the output is 7 and 8
[02:20:20] <jepler> yes
[02:21:14] <jepler> when the 'def add' statement in 'make_adder' is encountered at runtime, it captures the variables defined in 'def make_adder', and can refer to them
[02:21:46] <jmkasunich> n in this case?
[02:21:55] <jepler> yes
[02:22:04] <jepler> in vismach this is happening for the 't' variable
[02:22:26] <jmkasunich> so main first creates an instance of O called t
[02:22:43] <jepler> yes
[02:22:44] <jmkasunich> then creates a function update which invokes t's redraw method
[02:22:48] <jepler> yes
[02:23:05] <jmkasunich> I guess the after method is inherited?
[02:23:14] <jepler> yes, that's a standard method on Tk widget objects
[02:23:39] <jepler> (pyvcp has an 'update' method which does something else entirely, which you can do in python but probably shouldn't)
[02:23:46] <jmkasunich> so update redraws t, then waits 50mS and invokes itself again?
[02:23:50] <jepler> t.after(50, update) means "arrange to call update() after 50ms"
[02:24:04] <jmkasunich> arrange to call, not call
[02:24:06] <jepler> it assumes that you're in the Tk eventloop, which you are because app.mainloop() is called just below
[02:24:13] <jmkasunich> I was wondering how you avoided a stack overflow
[02:24:41] <jepler> indeed, python has no tail-call optimization
[02:25:06] <jmkasunich> cool, I think I understand
[02:25:22] <jmkasunich> dunno if it will stick, but I understand at the moment
[02:25:30] <jmkasunich> now... for capturing matrices
[02:25:36] <jmkasunich> suppose we add:
[02:25:37] <jepler> to integrate this with axis, you'd do most of the same things except call 'app.mainloop'
[02:25:51] <jmkasunich> if hasattr(p, "capture"):
[02:25:51] <jmkasunich> p.capture()
[02:25:57] <jmkasunich> to class Collection
[02:26:03] <jepler> good so far
[02:26:16] <jmkasunich> and then define a primitiive that has (only) a capture method
[02:26:30] <jmkasunich> then we can add that primitive to any place we want in the tree
[02:26:34] <jepler> yes
[02:26:45] <jmkasunich> one at the world level, one at work, one at tool
[02:27:06] <jmkasunich> take the diff between world and work to get rid of the viewport transform
[02:27:21] <jepler> my question is where the capture method stores its information
[02:27:24] <jmkasunich> yean
[02:27:39] <jmkasunich> in C it would be Capture(*place_for_matrix)
[02:27:52] <jepler> let me go find the stuff I did earlier for that backplot
[02:28:03] <jmkasunich> so you could have multiple nodes that store their matrices in different places
[02:29:22] <jepler> http://emergent.unpy.net/files/sandbox/backplot.patch
[02:30:03] <jepler> i gave the "player" object access to the "recorder" object
[02:30:22] <jepler> this isn't quite so simple
[02:30:42] <jmkasunich> ok, more py 101
[02:30:49] <jmkasunich> lets look at recorder and player
[02:31:09] <jepler> sure
[02:31:13] <jmkasunich> self.data = recorder.data is the sharing mechanism?
[02:31:19] <jepler> yes
[02:31:39] <jepler> unless changed by a later assignment, self.data and recorder.data refer to the same object after that
[02:31:47] <jmkasunich> in general, self is (sort of) a struct that is private to the object
[02:31:55] <jepler> but they're not assigned, only modified
[02:31:57] <jmkasunich> kind of like a hal structure has all the pins for an instance
[02:33:08] <jmkasunich> ok, I had to look at vismach again
[02:33:11] <jepler> yes, through "self" you can access all the data on the object. one piece of data on "self" is a reference to the class that "self" is an instance of, and that's how Python does stuff like find a method when you write 't.redraw()'
[02:33:27] <jmkasunich> the arg list for a py funct is _not_ on the class line, its on the __init__ line
[02:34:30] <jepler> yes (but you mean class where you said funct)
[02:34:31] <jmkasunich> right - self contains ordinary private data as I (a C guy) understand it, and it also contains "magic python stuff" for accessing methods (and base class stuff, etc)
[02:34:42] <jmkasunich> right, sorry
[02:35:08] <jmkasunich> when I invoke Sphere(foo,bar), I'm actualy calling Sphere.__init__(foo,bar), right?
[02:35:27] <jepler> python doesn't get as bogged down in public/private as C++ does -- in most cases, you can refer to the same data from inside a class method (e.g., self.x) or outside it (e.g., foo = Foo(); foo.x)
[02:35:40] <jmkasunich> ok
[02:36:07] <jmkasunich> like "t.model = model" in vismach main
[02:36:21] <jepler> the call is Sphere.__init__(<new object>, foo, bar)
[02:36:23] <jmkasunich> IOW, you don't need a method to access every stinkin' field
[02:36:45] <jepler> and the result of Sphere(foo, bar) is also <new object>
[02:37:04] <jmkasunich> ok, I see the self arg to __init_
[02:37:26] <jmkasunich> self is allocated before __init__ is called, thats why init doesn't have to return it, right?
[02:37:32] <jepler> yes
[02:38:04] <jepler> __init__ must return None (having no explicit return statement, or no explicit return value in a return statement, is the same as 'return None')
[02:38:25] <jmkasunich> somewhere between my call to Sphere, and the execution of Sphere.init, stuff gets allocated, and when init returns, the system forces "self" as the return value for the caller
[02:38:33] <jepler> yes
[02:38:49] <jmkasunich> ok, I can grasp that - just a thin little layer in there
[02:39:08] <jmkasunich> back to recorder
[02:39:18] <jmkasunich> self.count is not shared with playback
[02:39:22] <jmkasunich> self.data is
[02:39:30] <jmkasunich> what does the [] mean?
[02:39:35] <jepler> which one?
[02:39:40] <jepler> + self.data = []
[02:39:41] <jepler> this one?
[02:39:44] <jmkasunich> yes
[02:39:52] <jmkasunich> in the class def for Recorder
[02:40:02] <jepler> that's a list with zero elements. 'list' is a mutable container (items can be changed, added or removed)
[02:40:10] <jmkasunich> ok, got it
[02:40:23] <jmkasunich> just like the lists passed to collection and friends
[02:40:32] <jepler> yep
[02:41:04] <jmkasunich> I think there is code in the patch to only capture every tenth time?
[02:41:32] <jmkasunich> or am I misunderstanding count completely?
[02:41:56] <jepler> + if len(self.data) == self.count:
[02:41:56] <jepler> + del self.data[:self.count / 10]
[02:42:02] <jepler> ho boy
[02:42:14] <jmkasunich> len is the number of elements in the list, right?
[02:42:14] <jepler> with lists you can use slice notation
[02:42:39] <jepler> seq[lo:hi] is another list which is composed of [seq[lo], seq[lo+1], ..., seq[hi-1]]
[02:42:52] <jmkasunich> ok
[02:43:00] <jepler> but in this case, it says "delete the first 10% of the list when it reaches the highwater mark"
[02:43:14] <jepler> first == oldest
[02:43:16] <jmkasunich> ok, I can follow that
[02:43:52] <jmkasunich> ah, now I see the call to Recorder has count = 4000
[02:43:57] <jmkasunich> thats a buffer
[02:44:26] <jepler> so data will grow until it gets to be 4000 long, then the first 400 elements will get lopped off
[02:44:35] <jmkasunich> wouldn't it be simpler to delete one at a time once you reach 4000?
[02:44:52] <jepler> that was my premature optimization speaking
[02:44:54] <jmkasunich> or is deleting the first element expensive, and you'd rather do one big one every 400 times
[02:45:06] <jepler> 'del l[0]' is O(len(l))
[02:45:20] <jmkasunich> ah, it has to move them all down
[02:45:28] <jepler> the python list is basically a dynamically allocated array of pointers, plus a bit of bookkeeping information
[02:45:46] <jepler> there's a deque class I could have used that is efficient for deleting at the start
[02:45:49] <jepler> but I wrote this instead
[02:45:57] <jmkasunich> ok, lets move on (we can debate the merit of using a circular buffer later)
[02:46:02] <jepler> like I said, it was probably premature optimiation
[02:46:11] <jmkasunich> heh, we all do that
[02:46:37] <jmkasunich> ok, you get the transform
[02:46:39] <jepler> copying 3999 pointers 200 times a second? that's nothing to a modern computer. and yet I worry about it
[02:46:52] <jepler> I get the transform, and pull off the 3 elements that correspond to the XYZ translation
[02:46:56] <jmkasunich> you slice out the x,y,z parts
[02:46:56] <jepler> and stuff it on the end of data
[02:47:18] <jmkasunich> the if....
[02:47:30] <jmkasunich> not self.data means "data in the buffer"
[02:47:31] <jepler> negative indexes mean "from the end"
[02:47:45] <jmkasunich> and point = self.data[-1] means "not same as last time"
[02:47:50] <jepler> right
[02:47:59] <jmkasunich> print was for debugging?
[02:48:06] <jepler> empty containers are false when used as booleans
[02:48:12] <jepler> yep
[02:48:19] <jmkasunich> container ~= list
[02:48:21] <jmkasunich> ?
[02:48:50] <jepler> container is an abstraction -- strings, lists, tuples, dicts, sets, and a bunch of other things are all containers
[02:49:03] <jmkasunich> ok, but in this case its a list
[02:49:09] <jepler> yes
[02:49:18] <jmkasunich> because you created it with [], and added to it with append ?
[02:49:43] <jepler> because I created it with []
[02:49:46] <jmkasunich> ok
[02:49:56] <jmkasunich> does each point occupy 3 spaces or 1
[02:49:59] <jmkasunich> I'm thinking 2
[02:50:01] <jmkasunich> 1
[02:50:04] <jepler> yes, 1 space
[02:50:07] <jmkasunich> point is a list too, isn't it
[02:50:27] <jmkasunich> data is a (max) 4000 element list of 3 element lists?
[02:50:31] <jepler> yes it's probably a list, though it might be a tuple. (a tuple is basically an immutable list)
[02:50:44] <jmkasunich> ok
[02:50:55] <jepler> which it is depends on what glGetDoublev and there's no reason to worry about that right now
[02:50:57] <jmkasunich> key point, its an object not three objects
[02:51:25] <jepler> yes
[02:52:06] <jmkasunich> ok, playback I think I pretty much get
[02:52:16] <jepler> it's only the 'if .. del' that keeps self.data from growing beyond 4000 items. nothing about self.data is inherently limited to 4000
[02:52:43] <jmkasunich> more optimization, you don't want to wind up with a million lines
[02:53:05] <jepler> actually it was even more pragmatic than that: I had to have a way to clear the old points, because of the way they stick to the screen
[02:53:15] <jepler> 4000 is about 2 runs of the axis splash screen worth of points
[02:53:23] <jmkasunich> hmm, at 5mS, thats only 20 seconds
[02:53:34] <jmkasunich> (assuming its constantly moving)
[02:54:18] <jmkasunich> duh, 50mS - 200 seconds
[02:54:19] <jmkasunich> slipped a digit
[02:54:23] <jepler> oh yep
[02:54:40] <jepler> that sounds more like it
[02:54:58] <jmkasunich> * jmkasunich was thinking in servo loop timeframes, not graphics redraw timeframes
[02:55:06] <jmkasunich> 5mS would probably bring it to its knees
[02:55:16] <jmkasunich> and is pointless with 60Hz video refresh
[02:55:18] <jepler> yes
[02:55:23] <jepler> I was typing exactly that
[02:55:41] <jepler> actually with hardware opengl I bet it could do 60fps easily
[02:55:52] <jepler> it is a very simple "scene" compared to a video game
[02:56:00] <jmkasunich> yep
[02:56:21] <jmkasunich> thats what I was telling cradek when we were talking about this a couple days ago
[02:56:27] <jmkasunich> he had doubts about the update speed
[02:57:07] <jmkasunich> is the backplot in axis similar to this? or something completely different?
[02:57:14] <jepler> because we don't have any hardware opengl to choose from
[02:57:55] <jepler> it's fairly different
[02:58:05] <jepler> I actually use "C" code to capture the position and make the opengl draw calls
[02:58:05] <jmkasunich> well, I'm running a RT kernel (and I _think_ no hw GL) and the scara config loads my cpu to maybe 20% or so
[02:59:07] <jepler> I hate to do this to you, but it's time for me to do the dishes and feed the cats
[02:59:12] <jepler> I'm guessing I won't make it back tonight
[02:59:19] <jmkasunich> thats ok
[03:00:15] <skunkworks> btw the puma hal demo was really cool.
[03:00:33] <jmkasunich> thanks
[03:00:43] <jmkasunich> the scara one works with emc, thats even cooler IMO
[03:01:45] <skunkworks> I have not had time to try it. Should reboot into linux and update. I heard jepler and virtual cutting with it. nice
[03:02:27] <skunkworks> z.\\\
[03:02:45] <skunkworks> oops. I ment jepler and alex virtually cutting with it.
[04:03:39] <jmkasunich> jepler: you are back?
[04:06:48] <jmkasunich> jepler:
http://pastebin.ca/342184
[04:07:03] <jmkasunich> obviously I'm missing something about globals
[04:08:58] <jmkasunich> dang, musta missed him
[04:12:11] <jmkasunich> well, capture is getting called...
[04:40:01] <jmkasunich> woot - got all three matrixes into the "O" object
[07:34:17] <jmkasunich> how the fsck do you copy a list in this damn language!?
[07:43:37] <jtr> Google gives me this:
http://www.jimbrooks.org/web/python/ - look for PruneList
[07:45:08] <jtr> the next example on the page copies a 2d list.
[07:45:40] <jmkasunich> thank you
[07:46:10] <jmkasunich> I've been doing py for about a week, and am discovering all the quicks the hard way
[07:46:19] <jmkasunich> I did list1=list2
[07:46:47] <jmkasunich> and whenever I modfied an element in list1, it fscked up list2 which I didn't want to change
[07:46:53] <jtr> I personally know zip about python. I was amazed at the progress you made with the robot.
[07:47:44] <jmkasunich> I'm trying to to a backplot now
[07:48:01] <jmkasunich> damn 3D tranforms are kicking my ass
[07:50:48] <jmkasunich> finally
[07:51:05] <jmkasunich> list1 = list2[:] did the trick
[07:51:29] <jmkasunich> I have a python tutorial/reference here, but I searched and searched with no luck
[07:57:24] <jtr> It often happens that way. I'm finally learning how to google and get useful results.
[08:00:00] <jtr> bad thing is, I know it's just me. :/
[10:15:53] <jmkasunich> damn - I have to get up for work in about 2 hours
[10:16:36] <jmkasunich> jepler: backplot works with moving viewpoint, and moving workpiece
[10:16:47] <jmkasunich> play with scara joint 4 to tilt the table while cutting
[10:17:05] <jmkasunich> goodnight
[11:12:05] <A-L-P-H-A> goodmorning
[13:06:05] <jepler> jmkasunich: whee, cool
[13:06:55] <jepler> now how does this fit in (if at all) with the existing plots in axis?
[13:10:40] <jepler> hi skunkworks
[13:11:33] <skunkworks> Hi jepler. How is it in genius programmer land? :)
[13:11:41] <jepler> I dunno
[13:11:43] <jepler> I'm still trying to wake up
[13:12:06] <skunkworks> car started - so that is better than yesterday.
[13:12:13] <jepler> I assume it's colder up there than down here
[13:12:45] <jepler> looks like the low was 14F here
[13:12:52] <jepler> according to NWS
[13:13:33] <skunkworks> only -5F here
[13:14:35] <skunkworks> atm. yesterday it was below -20F
[13:16:28] <jepler> yuck
[13:16:53] <jepler> looks like they're not predicting below 0F all week here
[13:16:54] <skunkworks> more off topic - the first couple that saw the house are offering full price+ for our house. Now we have another offer and is sounds like after today we will have 3. Unreal. we thought we would have to beg people to look at the house.
[13:17:21] <jepler> great
[13:17:25] <skunkworks> very
[13:17:25] <jepler> maybe you'll unload it in a hurry
[13:17:44] <skunkworks> That would be great. less stress is good ;)
[14:44:37] <cradek> http://timeguy.com/cradek-files/emc/cnc.rar
[14:44:56] <cradek> ^^ this is petr's config and gcode sample I think
[14:45:06] <cradek> does someone know how to extract it?
[14:45:17] <cradek> % file cnc.rar
[14:45:17] <cradek> cnc.rar: RAR archive data, v1d, os: Win32
[14:50:45] <jepler> unrar-free - Unarchiver for .rar files
[14:50:45] <jepler> unrar-nonfree - Unarchiver for .rar files (non-free version)
[14:50:57] <jepler> from universe and multiverse, respectively
[14:51:25] <cradek> oh hey look at that
[14:51:47] <skunkworks> I hate rar.. it is so mac
[14:52:21] <cradek> Extracting SURFACE.NC Failed
[14:52:22] <cradek> 1 Failed
[14:54:09] <cradek> I do have multiverse on, but -nonfree won't install
[14:55:03] <cradek> deb
http://us.archive.ubuntu.com/ubuntu/ dapper universe multiverse
[14:56:29] <jepler> unrar-nonfree installed fine on install2 but I don't know if it will handle your file
[14:57:18] <cradek> yayyy
[14:57:41] <jepler> and let me just give a big "fuck you" to non-free file formats
[14:57:48] <cradek> no shit
[14:58:26] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/ncfiles/
[14:59:38] <cradek> thanks skunkworks
[15:00:46] <skunkworks> no problem. windows to the rescue ;)
[15:02:09] <jepler> that's no rescue
[15:03:32] <skunkworks> this is what I do in my spare time
[15:03:33] <skunkworks> http://www.electronicsam.com/images/hdmag.jpg
[15:04:36] <jepler> what am I looking at?
[15:04:40] <jepler> mag .. nets?
[15:05:54] <skunkworks> yes hard drive magnets - from all the hardrives that have failed around here. - sorry about the crappy picture
[15:06:39] <jepler> must be from a phone or something?
[15:21:24] <skunkworks> I wish - my phone takes some 'decent picture' but I forgot my memeory card so I don't have an easy way to get the pitures off. this was done with a webcam
[15:32:04] <jtr> skunkworks: what did you use to open that? IE7 asked if I wanted to look for something online to open it...
[15:32:18] <jtr> I said NO
[15:32:40] <jepler> jtr: ha ha you use IE?
[15:33:28] <jtr> The official corporate build on the new laptop - so far...
[15:33:51] <jepler> yuck
[15:34:37] <jtr> I'm sitting here with three laptops, mine (dapper), their old one (w2k), and the new one (XP)
[15:39:00] <jtr> Migrating data while trying to get a high priority job out. Added Cygwin for cvs for work code.
[15:40:44] <jtr> Between that and having most of my mail in mbox format, (corp std is M$) it was suggested I migrate data myself.
[15:50:35] <skunkworks> winrar is the program. it isn't free though but lets you use it after it expires
[15:52:32] <jtr> Thanks. I haven't seen that file type before, maybe I'll never need it.
[15:53:07] <SWPadnos> I think 7zip also does RAR
[15:53:33] <jtr> 7Zip?
[15:55:16] <jtr> Googled it, thanks.
[17:00:17] <cradek> hi ray
[17:01:09] <rayh> Hi Chris
[17:01:17] <rayh> Got the disks. Thanks.
[17:01:20] <cradek> did you see the robots yet?
[17:01:23] <cradek> welcome
[17:01:35] <rayh> No?
[17:01:47] <cradek> the one with the * I tested - the others I didn't
[17:01:54] <cradek> on trunk, run puma or scara configs
[17:02:45] <rayh> ah. Okay I'll have to cvs up.
[17:02:47] <cradek> jepler and jmk decided that good simulation would be the key to fixing up the non-trivkins stuff
[17:03:22] <cradek> puma barely works at all, scara is somewhat usable
[17:03:29] <rayh> O see.
[17:03:45] <rayh> I saw that alex got a note from Sagar.
[17:04:11] <cradek> yes
[17:04:15] <rayh> Are the kin issues related to the way we run them as modules?
[17:04:34] <cradek> no, the problems are joint/axis assumptions throughout emc
[17:04:41] <rayh> I've got a copy of his final paper someplace here.
[17:04:46] <cradek> the module loading works great
[17:04:49] <rayh> ah.
[17:05:11] <rayh> another of those machine logic things.
[17:06:16] <rayh> What is your take on how we should handle task planning?
[17:06:41] <cradek> I haven't given it enough thought to have a strong opinion yet
[17:08:46] <rayh> I see that you have worked in several of the task specific source files.
[17:09:53] <cradek> doing anything that involves the message passing touches a lot of layers
[17:10:07] <rayh> Yes it does.
[20:46:55] <alex_joni> hi guys
[20:50:11] <A-L-P-H-A> hi alex_joni.
[22:18:14] <erDiZz> jepler, there is a "FIXME no support for.." simulated interrupts and semaphores in sim_rtapi.c, are these not necessary at the moment?
[22:40:06] <jmk2> help
[22:40:27] <jmk2> no
[22:40:43] <jmk2> yes
[22:42:42] <jmk2> oops
[22:43:16] <jmk2> * jmk2 took newbie pills today (using cmd line client for the first time)
[22:44:09] <rayh> wah! you're brave
[22:45:22] <jmk2> erDiZz: currently EMC2 and HAL use only the shared memory and RT task services of RTAPI
[22:45:41] <jmk2> hi ray
[22:46:02] <jmk2> seen the scara yet?
[22:46:36] <alex_joni> hi ray
[22:48:01] <jmk2> next project for vismach is either a bport or a sherline with a rotary table
[22:48:43] <rayh> Hi guys. Yep I saw the scara. nice stuff.
[22:48:55] <alex_joni> * alex_joni goes to bed
[22:49:00] <alex_joni> good night all
[22:49:02] <jmk2> goodnight alex
[22:49:40] <rayh> Night alex.
[22:49:44] <alex_joni> jmk2: just remembered
[22:49:44] <jmk2> rayh: the visualization stuff should help work the kinks out of non-triv lins
[22:49:48] <jmk2> kins
[22:49:56] <alex_joni> the scara kins shows one of the kins problems
[22:49:57] <jmk2> and even simpler configs like xyza
[22:50:07] <rayh> Seems like it should.
[22:50:08] <alex_joni> when you move joint3 that moves axis C.. right?
[22:50:13] <jmk2> right
[22:50:14] <erDiZz> jmk2, got that
[22:50:30] <alex_joni> but the cartesian coords are XYZA
[22:50:33] <jmk2> we don't want to be forced to configure A and B just to get C
[22:50:36] <rayh> I got some really jumpy motion with scara.
[22:50:42] <alex_joni> jmk2: yeah that
[22:50:46] <rayh> Didn't have time to figure out what was going on.
[22:50:56] <alex_joni> rayh: jumpy motion?
[22:50:58] <alex_joni> on what?
[22:51:05] <jmk2> rayh the display updates 10 times a second, maximum
[22:51:36] <jmk2> if the system is heavily loaded, or uses software open GL, it could be a lot slower
[22:52:09] <jmk2> the image works just like the older backplots, it samples machine position
[22:52:28] <jmk2> so it can be jerky even tho the actual movement is smooth
[22:54:29] <rayh> Oh. I saw the arm represented by axis 0 jump 180.
[22:54:43] <rayh> Probably an artifact of the command I gave it.
[22:55:10] <jmk2> rayh was that after homing perhaps?
[22:55:20] <alex_joni> jmk2: I had that too
[22:55:31] <alex_joni> under certain circumstances (while jogging in carth.)
[22:55:35] <rayh> Yes exactly. And mdi commands.
[22:56:00] <alex_joni> this is probably a kins problem (need a flag to remember how the arm is bent)
[22:56:01] <jmk2> I'm about 99% certain the image is accuratly displaying what is coming out of EMC
[22:56:20] <jmk2> there is a flag already
[22:56:20] <alex_joni> there are positions where there are more than one solution to the inversekins
[22:56:30] <alex_joni> is one enough?
[22:56:37] <alex_joni> I think it also depends on join3
[22:56:48] <rayh> When I get the chance, I'll offset g55,6,7,8 and try a single plot in each quadrant.
[22:56:48] <rayh> Right.
[22:56:55] <jmk2> joint 3 is explicitly specfified by coord C
[22:57:03] <jmk2> so it doesn't result in ambiguity
[22:57:19] <jmk2> the only ambiguity is which way the "elbow" is bent
[22:57:24] <alex_joni> I think if(joint[1]<90) is the problem
[22:57:41] <alex_joni> the way the config is now.. joint 1 can rotate -360/+360
[22:57:44] <alex_joni> maybe that's too much ?
[22:57:52] <jmk2> I said there was a flag, didn't say it was implemented correctly ;-)
[22:57:57] <rayh> Might be.
[22:58:12] <rayh> oh, waiving the flag again eh.
[22:58:26] <alex_joni> capture the flag?
[22:58:39] <rayh> that's it.
[22:58:45] <jmk2> those kins are from saghar a while back
[22:59:02] <jmk2> and the definitions of the angles weren't commented
[22:59:03] <rayh> Right. They worked well for his grad paper.
[22:59:18] <jmk2> maybe 90 degrees was a critical point the way he defined them, but is wrong they way I did
[22:59:37] <jmk2> (I studied the code, and added comments saying how it appears to work)
[23:00:24] <alex_joni> jmk2: the iflags is only set in forwardkins
[23:00:41] <jmk2> and used by inverse
[23:00:44] <alex_joni> not sure that is even called in teleop mode
[23:01:11] <jmk2> dunno about you, but I have tones of learning to do before I can competently work on non-triv stuff
[23:01:16] <jmk2> tons
[23:01:35] <alex_joni> I probably have that too.. but I'm in denial right now :D
[23:01:46] <jmk2> unexplored territory, and probably badly busted in the motion controller
[23:01:51] <alex_joni> I just found the craziest building project ever :)
[23:02:00] <rayh> Yep. Both Fred and Till can probably help with it.
[23:02:03] <alex_joni> buildroot :D
[23:02:17] <jmk2> teleop, non-triv kins homing, the whole thing needs checked
[23:02:33] <alex_joni> rayh: Fred is only a bit slow in email replies
[23:02:41] <rayh> I used to know something about buildroot.
[23:03:17] <alex_joni> ok, off to bed now
[23:03:35] <jmk2> I think vismach + sim mode will be very handy
[23:03:37] <jmk2> goodnight
