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