Back
[02:12:40] <jmkasunich> good evening
[02:18:11] <jepler> hi jmkasunich
[02:18:18] <jmkasunich> hi
[02:19:29] <jmkasunich> <jepler> "now how does this fit in (if at all) with the existing plots in axis?"
[02:19:41] <jmkasunich> wanna talk about that?
[02:21:12] <jepler> sure, I'll probably be around for at least a half hour or so
[02:21:30] <jepler> I think it would be very neat to put the machine model in the AXIS preview window (optionally)
[02:21:47] <jmkasunich> I'd like to retain the abilitiy to run a vismach window separately from axis (and from EMC)
[02:21:59] <jepler> sure, agreed
[02:22:07] <jmkasunich> but I also think it would be great to be able to replace the cone with a machine model
[02:22:36] <jmkasunich> as for how to do that, I haven't a clue
[02:22:43] <jepler> I think I can handle that, technically
[02:23:09] <jmkasunich> btw, I think I'd like to rename pumagui and scaragui
[02:23:10] <jepler> I think I can offer to keep the work, the world, or the tool tip "in place" as everything moves around
[02:23:23] <jepler> sure, I am not thrilled with the names
[02:23:41] <jmkasunich> pumavis.py, scaravis.py, etc crossed my mind
[02:23:51] <jmkasunich> also not sure where they should live
[02:24:13] <jepler> the source files? yeah, good question
[02:24:24] <jmkasunich> I can easily see people hacking on them to customize for their machine
[02:24:26] <jepler> but we have a lot of freedom to move them until we release 2.2.
[02:24:38] <jmkasunich> yeah
[02:24:49] <jmkasunich> we don't want to do it too many times tho, cvs doesn't like that
[02:24:55] <jmkasunich> (loses history I think)
[02:24:59] <jepler> yeah
[02:25:06] <jepler> so we should stew for awhile and then pick the correct answer
[02:25:12] <jmkasunich> right
[02:25:25] <jmkasunich> thats why I brought it up - to start the stewing
[02:25:45] <jmkasunich> I actually thought about sticking them in the configs tree
[02:25:53] <jmkasunich> put scaravis with the scara config
[02:26:19] <jepler> does that work out, in terms of halcmd's search procedure for 'loadusr'?
[02:26:26] <jmkasunich> no clue ;-)
[02:26:32] <jmkasunich> just tossing out ideas at the moment
[02:27:24] <jmkasunich> when an ini file specifies a var or nml file, its assumed to be in the config dir
[02:27:32] <jmkasunich> hal files two for that matter
[02:27:46] <jmkasunich> but I don't know how loadusr works....
[02:28:03] <jmkasunich> I think the current dir during startup _is_ the config dir
[02:28:16] <jepler> unless there's a bug in the kinematics module, the AXIS backplot and the vismach backplot would be the same, wouldn't they? if that's true, then for the usual case of machine-visualization-in-axis I'd stick to the current way of generating the backplot
[02:28:18] <jmkasunich> so loadusr foo should search there first, then search some path
[02:28:43] <jmkasunich> I don't know about that
[02:28:48] <jmkasunich> (them being the same)
[02:29:07] <jmkasunich> did you try tilting the scara worktable half way thru milling the splash screen?
[02:29:12] <jmkasunich> you get bent words
[02:29:29] <jepler> how do I do that?
[02:29:38] <jmkasunich> (which is what would happen on a real machine)
[02:29:57] <jmkasunich> setp scaragui.0.joint4 <something>
[02:30:09] <jepler> hmm
[02:30:27] <jmkasunich> I used touchoff to get the words about 1" above and approximately centered on the table
[02:30:33] <jmkasunich> then tilted it while machining
[02:31:32] <jmkasunich> vismach can properly display things like milling on the outside of a pipe, if the pipe is mounted to a rotary table and turns during cutting
[02:31:40] <jmkasunich> no clue how axis would deal with that
[02:31:44] <jepler> ok
[02:31:44] <jmkasunich> (or emc itself for that metter)
[02:32:07] <jepler> I am now convinced the vismach backplot will be better for those cases
[02:32:21] <jmkasunich> vismach has the advantage of telling you what would actually happen, but it really doesn't know how or why
[02:32:28] <jmkasunich> a preview in vismach would be a nightmare I think
[02:35:10] <jepler> AXIS records position from the stat buffer in a thread that isn't even running python code
[02:35:29] <jepler> it would have to switch to recording HAL joint positions
[02:35:30] <jmkasunich> I wonder what coordinate system that is in?
[02:35:39] <jepler> XYZ
[02:35:45] <jmkasunich> yeah, but what xyz?
[02:36:07] <jmkasunich> machine base (the good old earth)? worktable? G5x offset?
[02:36:09] <jepler> worktable
[02:37:03] <jepler> (the g-code coordinates with g5x and g92 offsets applied)
[02:37:46] <jmkasunich> iow, "this is where you told the tool to go (or more precisely, this is where the TP told it to go, with corner rounding, etc)
[02:37:59] <jepler> right
[02:38:08] <jmkasunich> any errors or such in kins would not show up there
[02:38:15] <jepler> right
[02:38:25] <jmkasunich> vismach says "heres where it actually is, after kins"
[02:38:30] <jmkasunich> ideally of course they match
[02:38:57] <jmkasunich> but for 4 or more axis work, the vismach approach is much simpler
[02:39:26] <jmkasunich> at the expense of not being able to do previews, or limit checks, or check the extents of the program, or.... a lot of things that axis can do
[02:40:03] <jmkasunich> this might well be a case of two different tools for two different jobs
[02:40:20] <jmkasunich> if you have real iron, vismach has little or no purpose
[02:40:48] <jepler> I hope it doesn't sound too cynical to say that I almost think of this as a marketing feature
[02:40:55] <jmkasunich> heh
[02:41:31] <jmkasunich> if it lets us get a better grasp on dealing with >3 axis machining, that will be good enough for me
[02:41:48] <jmkasunich> basically, with only a little work, every developer can have a shop full of machines now
[02:42:04] <jmkasunich> rotary axis mounted on a bridgeport table, sure, we can do that
[02:42:21] <jmkasunich> gantry mill with a 2 axis gimbaled cutter, we can do that
[02:42:43] <jepler> I'm quite impressed with the "look" of the machines you did so far
[02:43:13] <jmkasunich> pov-ray experience kicked in
[02:43:43] <jmkasunich> basically, vismach gives us a limited but capable subset of pov-ray's language
[02:43:59] <jmkasunich> and because it uses python, you can do a lot of custom stuff as needed
[02:44:51] <jepler> yeah -- I always missed in POV the ability to drop into a "real" language as needed
[02:45:05] <jepler> they tacked on some kind of macro thing in the later versions after I quit trying to be a raytrace artist
[02:47:24] <jmkasunich> the language has really grown - its a complete programming language now
[02:47:32] <jmkasunich> but thats an aside
[02:48:02] <jmkasunich> for our needs, this approach is better - we added the shape and transform primitives to a real language
[02:48:35] <jmkasunich> btw, thanks for the time spent walking me through stuff last night, it really made a difference
[02:49:59] <jepler> I guess I need to figure out how to make vismach able to take "live" HAL data for the standalone, or "canned" data for integration with AXIS
[02:56:24] <jmkasunich> can I nag you about something?
[02:56:30] <jepler> sure, what's that?
[02:56:40] <jmkasunich> you offered to make scaragui get D1, D2, etc from the command line
[02:56:46] <jepler> oh yeah
[02:56:53] <jmkasunich> I don't know how to do argv/argc stuff in py
[02:57:09] <jmkasunich> and although it would be a good learning expernience, I need to sleep one of these nights
[02:57:18] <jepler> sys.argv is like C main's argv .. len(sys.argv) is like C main's argc
[02:57:23] <jepler> but my offer to do it still stands
[02:57:30] <jmkasunich> thanks
[02:58:12] <jepler> do you think that anyone who customizes it would change all the numbers, except in rare instances?
[02:58:18] <jmkasunich> I've really enjoyed working on this - learning a new language and doing the 3d matrix stuff that I haven't toucned in about 10 years has got the brain juices flowing
[02:58:27] <jepler> so I don't need to provide a way to customize just d4, for instance?
[02:58:26] <jmkasunich> but I gotta stop staying up so late
[02:58:40] <jmkasunich> probably
[02:58:47] <jmkasunich> I was reading about py function calls
[02:59:09] <jmkasunich> there is a syntax where you can do func(foo=3,bar=5) and all the others use their defaults
[02:59:45] <jepler> yeah
[02:59:47] <jmkasunich> does that seem like a good choice for the command line? or should is just be "scaravis 123 543 423 125"
[03:01:04] <jepler> I was going to write "scaravis 123 543 423 125"
[03:02:04] <jepler> but scaravis d1=123 ... would be more documenting, assuming that 'd1' means something to a person with a scara
[03:03:33] <jmkasunich> yeah
[03:04:19] <jmkasunich> and it should
[03:04:26] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/kinematics/scarakins.c?rev=1.4
[03:04:36] <jmkasunich> they are documented there
[03:04:57] <jmkasunich> at some point as the scara config stabilized, that should be pulled into lyx
[03:05:22] <jmkasunich> maybe we could even take a screenshot of the simualtor and use gimp to draw the dimensions right on the machine
[03:08:50] <jepler> my straight lines aren't straight! (when the simulation's dimensions don't match the kinematics)
[03:09:48] <jmkasunich> not surprising
[03:10:14] <jepler> nope
[03:10:26] <jmkasunich> I think if you scaled both arm lengths by the same amount, you'd get a scaled but straight result
[03:10:33] <jmkasunich> but if the ratio of their lengths changes, all bets are off
[03:14:15] <jepler> loadusr -W scaragui d2=200 d4=300
[03:14:18] <jepler> OK I'll do it like this
[03:14:32] <jepler> special bonus: you can write 'd2=3*4*5' if you want
[03:14:49] <jmkasunich> they are treated as expressions?
[03:14:50] <jmkasunich> cool
[03:15:00] <jepler> for setting in sys.argv[1:]: exec setting
[03:15:06] <jmkasunich> heh
[03:15:08] <jepler> soooo easy
[03:15:45] <jmkasunich> does that mean you could even do "scaragui foo=30 d2=foo*0.5 d4=foo*0.8"
[03:15:51] <jepler> yes
[03:15:54] <jmkasunich> slick
[03:16:45] <jmkasunich> there's a way to say "if this_var doesn't exist: set this_var", isn't there?
[03:17:15] <jepler> I side-stepped that by putting the defaults above the 'for ..: exec'
[03:18:10] <jmkasunich> oh, I was thinking farther than that
[03:18:21] <jepler> but yes, there is a way to find out if a global or local variable exists, similar to what I did with hasattr() in vismach
[03:18:30] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/usr_intf/axis/scripts/scaragui.py?rev=1.5
[03:18:52] <jmkasunich> see the block that starts with "# calculate a bunch of other dimensions"?
[03:19:03] <jepler> ah, yeah
[03:19:10] <jmkasunich> I was thinking of making those conditional (if the value exists, don't calc it)
[03:19:35] <jmkasunich> then they could use your exec trick to specify additional params, not just the 6 critical ones
[03:19:59] <jmkasunich> want fatter arms, just add l1_dia=whatever to the command line
[03:20:02] <jepler> >>> 'test' in globals()
[03:20:02] <jepler> False
[03:20:02] <jepler> >>> test = 3
[03:20:02] <jepler> >>> 'test' in globals()
[03:20:02] <jepler> True
[03:20:20] <jmkasunich> is not ! ?
[03:20:28] <jepler> no, it's 'not'
[03:20:41] <jmkasunich> if not l1_dia in globals:
[03:20:51] <jmkasunich> l1_dia = d2 / 5.0
[03:20:56] <jepler> if not 'l1_dia' in globals(): l1_dia = ...
[03:21:14] <jmkasunich> oops, forgot the quotes
[03:21:33] <jepler> tool_angle = math.atan2(d6,d5)*(180.0/3.1415927)
[03:21:37] <jepler> by the way, the constant is math.pi
[03:21:57] <jmkasunich> I figured there was one, but a quick search didn't find it, and it was late
[03:22:01] <jmkasunich> nobody to ask
[03:22:02] <jepler> and actually there are convenience functions math.degrees() and math.radians()
[03:22:19] <jmkasunich> feel free to clean up the cruft
[03:22:30] <jepler> actually I think I'll feel free to call it a night
[03:22:40] <jmkasunich> feel free to clean up the cruft some other time ;-)
[03:22:56] <jepler> see you around
[03:23:01] <jmkasunich> actually, at some point I'd like to explore making classes for 3d manipulations
[03:23:10] <jmkasunich> transforms/matrices, etc
[03:23:24] <jepler> I have to imagine some have already been written
[03:23:25] <jmkasunich> my invert function should be a method of a matrix class
[03:23:29] <jmkasunich> probably
[03:23:43] <jmkasunich> I did a lot of googling for them last night, but I was looking for the code
[03:23:52] <jmkasunich> didn't know how to import a lib even if I found one
[03:24:12] <jmkasunich> anyway, thats a topic for another time
[03:24:13] <jmkasunich> goodnight
[03:28:21] <jepler> >>> from numarray.matrix import Matrix
[03:28:31] <jepler> >>> a = Matrix("1 0 0; 0 2 0; 0 0 1")
[03:28:32] <jepler> >>> a**-1
[03:28:46] <jepler> (requires package python2.4-numarray-ext)
[12:20:35] <cradek_> cradek_ is now known as cradek
[12:21:01] <alex_joni> morning chris
[12:21:16] <cradek> hi
[13:09:12] <rayh> Hi guys.
[13:28:10] <alex_joni> hey ray
[13:28:40] <jepler> hello everyone
[13:28:48] <jepler> rayh: seen the robot screenshots?
[13:29:33] <alex_joni> * alex_joni started to enjoy machining with emc2 :D
[13:29:38] <jepler> rayh: scara:
http://axis.unpy.net/01170693566 puma:
http://axis.unpy.net/01170621073
[13:29:44] <jepler> alex_joni: it's about time!
[13:29:51] <alex_joni> haha, yeah
[13:30:50] <alex_joni> "and you can sit and watch as the hypnotizing robot arm mills your nc file in its virtual world." <- nice :D
[13:32:13] <jepler> I just wish it moved faster
[13:33:04] <alex_joni> what should?
[13:33:19] <rayh> I ran the scara robot a bit yesterday.
[13:33:50] <jepler> alex_joni: I wish the scara moved faster
[13:33:51] <rayh> Wanted to do some testing with g55+ and C offsets.
[13:33:55] <jepler> I suppose I should try changing the ini file
[13:34:02] <alex_joni> jepler: that's teh trick :D
[13:34:15] <alex_joni> btw.. I forgot to commit some sane TRAJ/ ACCEL for scara
[13:34:20] <alex_joni> will do that now
[13:35:36] <alex_joni> with that low accel, the robot moves really sluggish..
[13:35:42] <alex_joni> jepler: should be better now
[13:36:59] <jepler> argh
[13:37:35] <jepler> I forgot -- scara doesn't even run here, because I put some 'limit' blocks between commanded and feedback position, and I get following errors
[13:37:52] <jepler> guess I should take 'em ut
[13:37:56] <alex_joni> hmm.. I don't have those
[13:38:14] <alex_joni> maybe I didn't check out the latest ver here
[13:38:21] <jepler> no, this isn't checked in, it's a local change
[13:38:27] <alex_joni> ahh.. ok :)
[13:38:31] <alex_joni> cp -rf ..
[13:38:36] <alex_joni> cvs co -dPC :D
[13:40:21] <jepler> cvs server: cannot find module `:D' - ignored
[13:40:34] <alex_joni> try :-P
[13:40:50] <alex_joni> did you 'apt-get moo' today ?
[13:44:34] <rayh> What's an 'apt-get moo'?
[13:45:11] <alex_joni> try it
[13:46:11] <rayh> * rayh wonders how much he trusts aj!
[13:46:29] <alex_joni> * alex_joni grins
[13:46:35] <alex_joni> rayh: you can do it without sudo
[13:46:49] <alex_joni> so even if you don't trust me.. it won't fsck too many things up :P
[13:47:21] <rayh> Okay.
[13:48:02] <rayh> cute.
[13:58:09] <rayh> did the parport image go away in the current docs?
[13:58:54] <jepler> it's busted in the HTML version of the docs for some reason I don't understand
[13:59:00] <jepler> as far as I know it's right in the PDF version
[13:59:40] <rayh> I don't see anything but xx.hal as a literal in the user manual now.
[14:00:48] <jepler> "parport block diagram" is on page 54 of
http://linuxcnc.org/docs/2.1/HAL_User_Manual.pdf
[14:03:16] <rayh> thanks
[14:16:00] <rayh> damn it's getting hard to find stuff that I've become acoustomed to attaching to help mail.
[14:46:39] <jepler> anyone with emc2.1 installed from the package will have that diagram on page 74 of the EMC2_User_Manual.pdf which is available from the gnome menu.
[14:46:51] <jepler> er, page 76
[14:48:49] <rayh> I guess that's not the drawing I was remembering from previous manuals.
[14:49:36] <rayh> This one is emc2 specific. It does seem to have a great deal more detail.
[14:50:12] <rayh> I was able to find what I wanted in cvs in the old documents module.
[14:50:29] <jepler> I don't believe anything's been removed completely, but it's possible it would be in the Attic/
[14:51:23] <rayh> IMO the users manual needs to be de-hal'd a bit.
[14:52:28] <rayh> It reads easily for those who know what something like (bit) parport.<portnum>.pin-<pinnum>-out means.
[14:53:12] <rayh> But a simple listing of the effect of standard_pinout.hal in a table form would be a lot easier for a new user to understand.
[14:53:13] <jepler> maybe you were looking for this image?
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/~checkout~/documents/images/pinout.png?rev=1.1;content-type=image%2Fpng
[14:53:30] <rayh> Yep.
[14:53:54] <rayh> and there was a table listing standard pinouts right after it in the lyx that used it.
[14:55:00] <rayh> I got em. Thanks for the help and for letting me vent.
[14:55:15] <jepler> everyone agrees the docs should be better
[14:55:34] <jepler> you have a perspective on the needs that the rest of us may not
[15:11:25] <rayh> Ah. I see that the m5i20 has tables.
[15:11:56] <rayh> Perhaps what is missing from the parport are similar tables for standard pinout and perhaps xylotex pinout.
[15:12:11] <alex_joni> rayh: might be :)
[15:13:48] <rayh> Let me try adding those standard configs in tables and see how it looks.
[15:14:32] <jepler> you'll add them to the chapter called "basic configuration for stepper systems"?
[15:14:58] <jepler> config/stepper.lyx I think it's called
[15:16:06] <rayh> I see it.
[16:41:55] <rayh> jepler, What gtk2 do I need to compile ladder and such?
[16:42:49] <jepler> rayh: I've compiled it with versions as old as gtk+-2.4.17 but breezy and dapper both have 2.6
[16:43:25] <jepler> looks like ubuntu calls the package libgtk2.0-dev
[16:43:30] <rayh> The configure fails to find gtk2 on the latest cd install.
[16:44:05] <jepler> it should be installed by 'apt-get build-dep'
[16:44:45] <rayh> that command complained only about lyx2html
[16:46:08] <rayh> latex2html is the only complaint. Sorry
[16:47:13] <jepler> sounds like sources.list still points at the 2.0 repository, not the 2.1 one. Is this the new 2.1 install CD?
[16:47:31] <jepler> $ apt-cache showsrc emc2 | grep ^Version
[16:47:31] <jepler> Version: 1:2.1.0
[16:47:37] <jepler> do you get something different?
[16:47:43] <rayh> I also get the same set of errors regarding tcl that were mentioned in email.
[16:48:01] <rayh> Yes it's the new one.
[16:49:09] <rayh> No answer to the apt-cache.
[16:50:34] <jepler> does the included version of emc2 run?
[16:50:47] <jepler> or does it get that tcl error?
[16:51:31] <jepler> I'll try the new install/live cd in a vmware tonight and see if I can duplicate any of these problems
[16:51:49] <rayh> It runs
[16:52:07] <jepler> but the one you built yourself gets the tcl error involving "msgcat"?
[16:52:09] <rayh> The config command came back with no tcl.h ...
[16:54:17] <rayh> I've not tried to compile yet.
[16:55:15] <rayh> I'll try an apt-get update and recheck the repositories.
[16:56:07] <rayh> no difference.
[16:57:17] <jepler> oh -- you're not talking about the problem reported by Larry D. O'Cull on the mailing list yesterday, you're talking about configure failing
[16:59:05] <jepler> though I guess he got to the same problem later on
[16:59:10] <jepler> I wonder why apt-get build-dep is broken on the live cd
[16:59:16] <jepler> pastebin your sources.list please
[17:11:13] <rayh> pastebin.ca?
[17:13:10] <jepler> yes
[17:13:31] <jepler> and the output of 'apt-cache showsrc emc2' if you would
[17:15:10] <rayh-cd> http://pastebin.ca/344253
[17:15:32] <rayh> I did remove the source repositories except emc
[17:18:28] <jepler> and 'apt-cache showsrc emc2'?
[17:18:40] <jepler> nothing jumps out at me as obviously wrong
[17:18:44] <jepler> in the sources.list
[17:19:14] <jepler> oooohhhhhhh
[17:19:33] <jepler> you never completed 'apt-get build-dep emc2' because of this error involving latex2html
[17:20:15] <jepler> it's no wonder the following steps fail
[17:20:44] <rayh> okay. I don't find latex2 in dapper
[17:21:37] <jepler> add to sources.list: deb
http://us.archive.ubuntu.com/ubuntu/ dapper multiverse
[17:21:47] <jepler> sudo apt-get update; sudo apt-get build-dep emc2
[17:21:50] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=32001
[17:25:58] <SWPadnos> skunkworks, I'm pretty sure that developer would be Paul, and I'm not sure what the end result was
[17:26:23] <SWPadnos> I think he was working on the Vigilant drivers (or had just gotten them to work) about 2 years ago
[17:26:25] <jepler> there's a driver for the "PCI-ENCDAC 4" (hal_vti) but all I can tell you is that it seems to compile
[17:26:54] <SWPadnos> yeah - I don't know what features of the card(s) are supported (or not)
[17:27:17] <rayh> 72.3 meg of additional download!
[17:27:25] <rayh> Never gonna happen.
[17:27:32] <SWPadnos> heh - see you in a few hours(days) :)
[17:27:50] <SWPadnos> do you have a DVD-rom in that machine?
[17:28:03] <rayh> I don't believe that I've had this kind of an issue before with building emc2.
[17:28:25] <rayh> are there additional dependencies or what?
[17:28:55] <rayh> how would DVD-rom help me now?
[17:29:24] <SWPadnos> it won't help right now, but I'm curious as to whether a DVD with all the build tools would be a generally useful thing
[17:29:48] <skunkworks> Could someone write up a reply? Or ignore? :)
[17:30:05] <rayh> ah. This box does not have a DVD.
[17:30:10] <SWPadnos> if you have a machine that can compile emc2 2.0.x, you can copy the .debs (from somewhere in /var, I think) to a CD/USB stick, and manually install them
[17:30:18] <rayh> I would get one if we had such a disk.
[17:30:25] <SWPadnos> unless it's new stuff that wasn't required before
[17:30:29] <rayh> Although a two set cd would do me as well.
[17:30:33] <SWPadnos> sure
[17:30:34] <jepler> SWPadnos: there are new requirements to build emc2.1 compared to 2.0
[17:30:45] <jepler> but I don't think the live CD had the build tools either
[17:31:21] <rayh> 16h52m28s
[17:32:21] <rayh> No but it was not this much a problem when I installed from the old cd and built emc2 about a month ago.
[17:35:13] <jepler> do one of you board members want to contact this Vigilant Products guy? otherwise, I can do it
[17:35:57] <SWPadnos> I think their cards are a "true analog" version of the Mesa - DAC output and encoder input (plus some extra I/O)
[17:36:29] <cradek> I don't care to be in a position of apologizing for um .. someone else .. being hard to work with
[17:36:55] <cradek> or not keeping up his end of a deal
[17:37:59] <SWPadnos> that's one expensive card
[17:38:10] <jepler> It doesn't have to read like an apology. "That developer left the project over a year ago."
[17:38:22] <SWPadnos> $1000 for 4-channel DAC+encoder + 8 aux I/O
[17:38:22] <alex_joni> hi all
[17:38:26] <rayh> One of the Vigilant guys attended the first fest at Detroit.
[17:38:39] <rayh> Jim something if I remember at all.
[17:38:53] <jepler> this e-mail is from a "John Rowland"
[17:39:07] <jepler> http://www.cnczone.com/forums/showthread.php?t=32001 if you missed the url when skunkworks pasted it
[17:39:10] <rayh> He sent a card set to Paul for writing the drivers for emc.
[17:39:31] <jepler> apparently so
[17:39:34] <SWPadnos> I could have sworn those were PC/104
[17:39:47] <SWPadnos> maybe that was a generic digital I/O card Paul had
[17:40:12] <cradek> SWPadnos: the post says "boards" (plural)
[17:40:24] <SWPadnos> true
[17:40:44] <alex_joni> jepler: you gonna answer that?
[17:41:12] <SWPadnos> maybe suggest that he direct questions to the emc-developers and/or emc-users list ...
[17:41:32] <rayh> * rayh twiddles thumbs waiting for cnczone amid the massive download.
[17:41:34] <alex_joni> or emc-board, it shouldn't matter..
[17:41:35] <cradek> I wonder if a private contact first would be best
[17:41:42] <SWPadnos> probably
[17:41:47] <jepler> alex_joni: I was hoping someone who could sign as a member of the board would contact him
[17:41:55] <alex_joni> but I wonder is it that hard to contact us?
[17:42:11] <jepler> When I try clicking on their "contact the Board of Directors" email link, that just generates errors stating that I must enable javascript (it already is enabled).
[17:42:12] <alex_joni> jepler: I think I can do that by mail..
[17:42:27] <jepler> (he says)
[17:42:40] <alex_joni> I read that..
[17:42:45] <jepler> oh yuck
[17:42:52] <jepler> mailto:%<script language='JavaScript' type='text/javascript'> <!-- var prefix = 'ma' + 'il' + 'to'; var path = 'hr' + 'ef' + '='; var addy12833 = '20emc-board' + '@'; addy12833 = addy12833 + 'lists' + '.' + 'sourceforge' + '.' + 'net'; document.write( addy12833 ); //--> </script><noscript> This email address is being protected from spam bots, you need Javascript enabled to view it</noscript>
[17:42:57] <jepler> TURN THAT BULLSHIT OFF
[17:43:20] <alex_joni> eek.. I had no idea that was there..
[17:43:29] <cradek> oh good effing grief
[17:44:02] <cradek> I guess people would complain if they didn't do that too.
[17:46:17] <skunkworks> So.. I don't have to worry about it? :)
[17:46:34] <cradek> thanks for spotting it
[17:46:47] <alex_joni> jepler: I would gladly turn that off, if I only would find how..
[17:46:54] <alex_joni> maybe your google skills are better than mine :(
[17:49:32] <alex_joni> ah-ha
[17:49:36] <alex_joni> found it
[17:50:08] <alex_joni> jepler: can you check if it's better now?
[17:50:49] <jepler> jas
[17:51:17] <jepler> looks good to me
[17:51:53] <alex_joni> ok..
[17:52:06] <jepler> there's a space at the beginning of the address but it sholdn't matter
[17:55:48] <jepler> alex_joni: you are going to contact the vigilant guy, then?
[17:56:28] <rayh> I think I should. I remember the relationship a bit.
[17:57:10] <alex_joni> the board assigned ray for the task
[17:58:17] <alex_joni> but I would like someone with access to that forum to reply there too
[17:58:38] <jepler> OK
[17:58:56] <rayh> You bet.
[17:59:06] <cradek> thanks ray
[17:59:20] <alex_joni> say that "thanks for letting us know, the board was notified, and will reply by email soon. the problems with cloaking emails on the website have been resolved now. ..."
[17:59:22] <jepler> to say what -- give the contact address, say the website's corrected, and that a member of the board will contact him personally in e-mail?
[17:59:27] <alex_joni> something along those lines
[17:59:39] <jepler> I can do that, I just created (or tried to create) an account on there
[17:59:47] <alex_joni> ok, cool
[18:04:55] <jepler> it doesn't let me post
[18:06:26] <jepler> I think greylisting lost the confirmation e-mail
[18:07:50] <jepler> skunkworks: so if you can post a followup, please do
[18:30:36] <skunkworks> is this ok then?
[18:30:37] <skunkworks> http://www.cnczone.com/forums/showthread.php?p=254293#post254293
[18:34:43] <alex_joni> skunkworks: yeah, pretty ok
[18:42:20] <alex_joni> SWPadnos: I remember the pc104 board too, but that was a Sensoray 526?
[18:42:26] <alex_joni> afaik, it's not by Vigilant
[18:43:03] <alex_joni> SWPadnos:
http://www.sensoray.com/products/526data.htm <- this one
[19:05:42] <rayh> Yep. I believe that Paul got both the vigilant and sensoray cards during trips to NAMES.
[19:11:30] <skunkworks> rayh: did you hear back from vigilant? (too soon I suppose) :)
[19:12:11] <rayh> Still composing the mail.
[19:32:04] <rayh> just sent the reply to vigilant.
[19:32:59] <alex_joni> seems we got the best man for the job
[19:54:04] <alex_joni> hallo Frank :)
[19:55:09] <fjungclaus> N'Abend, Alex!
[19:55:47] <alex_joni> wie geht's ?
[19:58:03] <fjungclaus> Kam gerade von der Arbeit heim, esse zu Abendbrot und kann mich jetzt noch ein paar Stunden um meine Hobbys kümmern. Also gehts mir gut :-)
[19:58:17] <alex_joni> wunderbar
[19:58:51] <skunkworks> hey hey hey - stop that. be nice to the sub-mono-langual people
[19:59:22] <fjungclaus> Alex started that ;-)
[20:39:44] <SWPadnos> alex_joni, yep - that's probably the one I was remembering
[20:44:16] <rayh> is it just me or my isp or is email in a bit of a backlog?
[20:48:00] <SWPadnos> email sometimes seems to act like an inchworm
[20:48:12] <SWPadnos> bunch up, stretch out, bunch up, stretch out ... :)
[20:48:50] <rayh> I couldn't even get a working link to smtp for a bit there.
[20:49:08] <SWPadnos> that's an issue with your ISP then, most likely
[20:49:13] <rayh> suppose we need to apply the notion of rush hour.
[20:49:30] <rayh> in da up 'eh.
[20:49:33] <SWPadnos> heh - yeah. with lots of rubbernecking along the way
[21:14:01] <alex_joni> what's rubbernecking?
[21:14:30] <SWPadnos> slowing down so you can look at why other cars are slowed down (to look at stuff such as accidents and things)
[21:14:49] <alex_joni> ahh.. ok
[21:14:51] <alex_joni> thanks
[21:14:55] <SWPadnos> sure
[22:12:51] <alex_joni> I got some modified kins from the guy with the bot in germany
[22:13:06] <alex_joni> maybe someone (with some math understanding) wants to look at them
[22:13:08] <alex_joni> http://pastebin.ca/344653
[22:15:00] <cradek> RRRRRR!
[22:15:15] <alex_joni> yeah, that's the common way to describe a robot like that
[22:15:18] <alex_joni> 6 rotations
[22:15:30] <alex_joni> a scara is RRTR I think
[22:15:42] <SWPadnos> T = translate?
[22:16:15] <alex_joni> yup
[22:16:41] <alex_joni> "Find solution for control of a 4 DOF SCARA robot KIWI with RRTR configuration via Internet. "
[22:16:57] <alex_joni> seems I was partly right
[22:16:59] <SWPadnos> what are the meanings of the alpha / a / d numbers in the table in the comments?
[22:17:25] <alex_joni> hang on, I'll make a new one (translated)
[22:17:30] <SWPadnos> heh - thanks :)
[22:18:47] <alex_joni> SWPadnos: what's the base of the robot called?
[22:18:52] <alex_joni> below the first joint?
[22:19:02] <alex_joni> socket?
[22:19:06] <alex_joni> base?
[22:19:06] <SWPadnos> I don't know. platform or base maybe
[22:19:14] <SWPadnos> base would make sense to me
[22:19:52] <jepler> get a clear GPL notice, convert the parameters into HAL parameters, and go for it
[22:19:56] <jepler> comments translated into english are a plus
[22:20:11] <alex_joni> http://pastebin.ca/344664
[22:20:20] <alex_joni> jepler: it's mostly the puma code
[22:21:06] <rayh> The design of that bot looked a lot like a puma.
[22:26:42] <alex_joni> yeah, but it seems the puma kins were designed to turn some way his bot can't or something like that
[22:28:08] <jepler> if you're concerned the new code is "too puma-like" then maybe we should make a single module cover both machines
[22:28:41] <alex_joni> jepler: right.. but right now I don't know which is the more general one :)
[22:28:55] <alex_joni> I'll need to read up on this topic..
[22:28:56] <rayh> I don't see a problem with different versions.
[22:29:15] <alex_joni> rayh: if they're 95% the same.. it's just duplicated code
[22:29:20] <rayh> In emc we had several. A couple were only for one-off machines.
[22:29:41] <alex_joni> * alex_joni runs to bed ..
[22:29:50] <alex_joni> good night all
[22:29:55] <rayh> Right. And if we had a way to adjust values after compile it would be nice.
[22:29:57] <rayh> night alex.
[22:30:43] <SWPadnos> see you Alex
[22:49:57] <jepler> rayh: they can be adjusted by making them HAL parameters
[23:09:07] <rayh> I can see params for limits and such but can it handle things like the nature of joints?
[23:09:21] <rayh> lengths of arms?
[23:22:28] <SWPadnos> I think it's possible to do all that stuff with HAL params. I don't think it's the best solution though
[23:23:04] <SWPadnos> there's no reason to have things like arm lengths dynamicallyy changing (unless that's a joint, which is another thing altogether)
[23:32:11] <rayh> In the existing kins like genhexkins the strut length is compiled in.
[23:32:25] <rayh> That would make the kins for each machine unique.
[23:38:46] <jmkasunich> hi guys
[23:39:13] <jmkasunich> for the scara vismach thing, we (jepler) made the arm lengths and other params be command line args
[23:39:26] <jepler> right now it's easy to make a small number of items configured as HAL parameters, but it's true that there's no reason to change them dynamically
[23:39:26] <jmkasunich> we could make them insmod args for the kins modules
[23:39:34] <jepler> there is not a float-type insmod arg
[23:39:41] <jmkasunich> oh
[23:39:42] <jmkasunich> poo
[23:40:04] <jepler> you wanna write 'atof' and get it right? not me.
[23:40:18] <jmkasunich> nope
[23:40:36] <jmkasunich> I don't particularly like using hal params tho
[23:41:50] <jmkasunich> I've gotten into the mindset that params can/should be dynamicallly adjustable
[23:42:13] <jmkasunich> but really, things like this are what they were originally designed for
[23:43:46] <jepler> it might make more sense to swap a segment of the robot arm for another one without shutting down HAL, than changing the position-scale of stepgen (when it is running a mill) would
[23:44:05] <jmkasunich> yeah
[23:44:10] <jmkasunich> theres really nothing wrong with using params
[23:44:18] <jmkasunich> biab
