Back
[11:22:39] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[15:16:16] <alex_joni> 'lo
[16:13:03] <cradek> good morning
[16:15:31] <alex_joni> hi chris
[16:15:53] <cradek> hey
[16:16:02] <alex_joni> what's up?
[16:16:37] <cradek> hope to finish my vacuum table today
[16:16:45] <cradek> it's done except for the "wiring"
[16:16:45] <alex_joni> sounds nice
[16:16:49] <SWPadnos> that sucks
[16:16:51] <SWPadnos> :)
[16:16:54] <alex_joni> wiring is fun
[16:17:04] <cradek> I need to find or make a fitting to hook up a vacuum line to it
[16:17:14] <cradek> then, get that attached to my pump
[16:17:26] <SWPadnos> what kind of fitting does the pump have?
[16:17:28] <cradek> then, I'll find out that the pump is totally wrong
[16:17:45] <SWPadnos> heh
[16:17:54] <cradek> the pump seems more like a vacuum cleaner that's made to run without air flow
[16:17:56] <SWPadnos> at least you've got it all planned out ;)
[16:18:04] <cradek> I don't know if it'll have anything like enough vacuum
[16:18:31] <SWPadnos> how big is the table?
[16:18:38] <cradek> about 4x6"
[16:18:40] <alex_joni> 12 seats
[16:18:59] <alex_joni> oh, that small?
[16:19:07] <SWPadnos> what's the hole spacing?
[16:19:24] <cradek> .4"
[16:19:28] <cradek> alex_joni: it's for use on max
[16:19:38] <alex_joni> ah, nice then
[16:20:38] <cradek> the holes are .07 or so I think
[16:24:42] <cradek> "15 inch h2o max"
[16:24:51] <cradek> http://surpluscenter.com/item.asp?UID=2007092911190014&item=16-1139&catname=
[16:26:11] <SWPadnos> hmmm. so 1 mmHg should be ~0.75 in H2O ?
[16:26:23] <SWPadnos> what's that in PSI? ;)
[16:26:28] <cradek> uhh
[16:26:32] <SWPadnos> err - no, wait
[16:26:38] <SWPadnos> 1 atmosphere is 32 feet
[16:26:40] <SWPadnos> of water
[16:27:06] <SWPadnos> so 15" is 1.25 / 32 atmospheres
[16:27:27] <SWPadnos> or roughly 1/2 psi
[16:27:29] <cradek> units says 1atm is ~ 34 ft water
[16:27:35] <SWPadnos> close enough ;)
[16:27:48] <cradek> chris@rover:~$ units '15 feet water' psi
[16:27:53] <cradek> * 6.5029126
[16:27:57] <SWPadnos> inches
[16:27:58] <cradek> well that was easy
[16:28:13] <SWPadnos> about 1/2
[16:28:16] <tomp> 15 inches
[16:28:37] <cradek> 150 holes at .22 sq inch is 33 sq inches
[16:28:52] <SWPadnos> I don't think that's the calculation you need
[16:29:04] <cradek> oh I'm not surprised by that really :-)
[16:29:06] <SWPadnos> heh
[16:30:14] <SWPadnos> remember - vacuum works on the entire of the container. if you have thin ridges around the holes (just a grid pattern, for example), then the vacuum will operate on essentially the entire workpiece area
[16:30:23] <SWPadnos> err - entire surface of the container
[16:30:58] <SWPadnos> the smaller the surface area though, the less friction will keep the piece from sliding
[16:31:21] <SWPadnos> (with thin ridges in a grid pattern, you have lots of hold-down, but very little friction)
[16:31:50] <SWPadnos> with no ridges, you have almost no hold-down, since it's only the area of the holes, but lots of ffriction from all that nice contact area between the holes
[16:32:21] <SWPadnos> so solve for a maxima of (hold-down * contact area)
[16:32:49] <SWPadnos> at least, that's how I think it should work. I could be totally wrong
[16:33:09] <cradek> I'm not smart enough to figure it, so I'll just try it
[16:33:40] <SWPadnos> make sure you try to slide stuff around when you're experimenting
[16:34:13] <cradek> for engraving pcbs, it will have to handle very little shear
[16:34:18] <SWPadnos> I think one thing some folks do is put a slightly compressible, high friciotn gasket around the table
[16:34:20] <SWPadnos> true
[16:34:45] <cradek> cutting out the completed board probably won't be possible
[16:34:53] <cradek> bbl, I'll let you know :-)
[16:34:56] <SWPadnos> not in one pass
[16:35:09] <alex_joni> cradek: before you go
[16:35:20] <alex_joni> * alex_joni wonders if it's too late :)
[16:35:50] <SWPadnos> 16 seconds. man - that's a lot of "internet time" :)
[16:36:38] <alex_joni> yeah, probably
[16:38:37] <tomp> does the vacuum table use blocking plates to cover where the work is not? if so, and those plates had vacuum lines, and the surface was ribbed/gridded then maybe no holes are needed.
[16:43:08] <jmkasunich_> 33cfm - I guess he doesn't have to worry about leaks
[16:43:56] <alex_joni> hi jmk
[16:44:05] <jmkasunich_> hi
[16:46:08] <SWPadnos> heh - true. that should be about 100 miles/hour with those small holes :)
[16:46:39] <jmkasunich_> well, that is the zero pressure flow
[16:47:49] <jmkasunich_> on the plus side, he probably doesn't have to worry about covering unused holes
[16:48:42] <alex_joni> checking for lyx... none
[16:48:42] <alex_joni> checking for lyx-qt... (cached) none
[16:48:42] <alex_joni> configure: error: no LyX, documentation cannot be built
[16:48:53] <alex_joni> any ideas? (without looking at configure?)
[16:49:57] <jmkasunich_> apt-get lyx-qt?
[16:50:14] <alex_joni> it is installed
[16:50:25] <SWPadnos> delete the configure cache
[16:50:25] <alex_joni> which lyx-qt
[16:50:25] <alex_joni> /usr/bin/lyx-qt
[16:50:25] <SWPadnos> ?
[16:50:35] <alex_joni> which lyx-qt
[16:50:35] <alex_joni> /usr/bin/lyx-qt
[16:50:39] <alex_joni> sorry :D
[16:50:46] <alex_joni> SWPadnos: which is ..
[16:50:57] <SWPadnos> err - configure.cache or something?
[16:51:01] <alex_joni> config.status
[16:51:03] <alex_joni> ?
[16:51:07] <SWPadnos> yeah - sure, that could be it?
[16:51:14] <alex_joni> doesn't help
[16:51:21] <alex_joni> make clean doesn't either
[16:51:25] <SWPadnos> there may even be a configure option to do it
[16:52:12] <jmkasunich_> OT, related to the vacuum table thing:
http://www.trident.on.ca/orifice-air-flow.htm
[16:52:42] <SWPadnos> heh - it doesn't go low enough for 15" water :)
[16:52:50] <jmkasunich_> nope
[16:53:07] <jmkasunich_> 2" mercury ~= 24" water
[16:53:27] <alex_joni> hrmm.. --cache-file=/dev/null doesn't help
[16:53:31] <jmkasunich_> so figure a maximum of 0.3 cfm per open hole
[16:53:33] <SWPadnos> I thought mercury had a density of 14
[16:53:35] <alex_joni> rebuilding the configure doesn't either
[16:53:39] <jmkasunich_> SWPadnos: could be
[16:53:52] <SWPadnos> yep - 13.6
[16:54:02] <jmkasunich_> I used 12 as an approximation, because 1 atm ~= 30" hg and 30' h20
[16:54:12] <SWPadnos> I had been thinking it was 19, but that's Osmium
[16:54:47] <SWPadnos> err - no, that's 22.61. Hmmm what the heck is 19 then?
[16:54:57] <SWPadnos> (other than some stupid number stuck in my brain)
[16:55:04] <jmkasunich_> I think if I was cradek I would have made the holes smaller than 0.07"
[16:56:23] <jmkasunich_> hmm, maybe drill 0.2" or so "dimples", with a 0.030 or so hole at the bottom of each one
[16:56:41] <jmkasunich_> that gives you limited flow thru open holes, but large suction area for closed ones
[16:57:25] <alex_joni> well, this sux
[16:57:46] <alex_joni> I just put another command to test for lyx-qt somewhere earlier int he configure script, and that made it work
[16:57:52] <alex_joni> once I remove it, it fails again
[16:58:14] <jmkasunich_> I'm doing a CVS up, lemme try it
[16:58:40] <alex_joni> I always get the (cached) on the checking for lyx-qt line
[16:58:50] <jmkasunich_> cd src
[16:59:01] <alex_joni> ./configure --enable-build-documentation
[16:59:36] <SWPadnos> I wonder if the lyx check also checks for lyx-qt, sso it's always cached by the time the lyx-qt check is done??
[16:59:43] <jmkasunich_> I get the same error
[16:59:43] <alex_joni> nope
[16:59:52] <jmkasunich_> checking for lyx-qt... (cached) none
[16:59:52] <jmkasunich_> configure: error: no LyX, documentation cannot be built
[16:59:53] <alex_joni> I bet it's the "none" in AC_PATH_PROG
[17:00:11] <SWPadnos> well, you've clearly gone beyond my knowledge of configure :)
[17:01:01] <SWPadnos> ah - Gold is pretty close to 19 (and Uranium) - maybe that's what I was thinking of
[17:09:49] <alex_joni> * alex_joni wonders why it worked before
[17:10:06] <jmkasunich_> there was a change in that area not long ago
[17:10:11] <alex_joni> * alex_joni looks in cvs logs
[17:10:13] <jmkasunich_> jepler fixed something to make it work with gutsy>
[17:10:24] <alex_joni> "Fix lyx detection for 7.10 -"
[17:10:28] <alex_joni> yup
[17:10:44] <alex_joni> haha
[17:10:55] <alex_joni> he just did the opposite of what I did to make it work
[17:11:31] <jmkasunich_> hmm, he also used a different version of autoconf to generate configure from configure.in
[17:12:55] <alex_joni> that shouldn't matter
[17:13:08] <jmkasunich_> I know, just making an observation
[17:15:26] <alex_joni> * alex_joni thinks he has a fix
[17:17:06] <alex_joni> jmkasunich_: can you cvs up and test?
[17:17:51] <jmkasunich_> ok
[17:18:10] <alex_joni> ty
[17:19:04] <jmkasunich_> looks OK
[17:19:06] <jmkasunich_> (ran configure)
[17:19:13] <jmkasunich_> running make now
[17:19:32] <alex_joni> CIA is gone, so I don't expect any fail-messages on #emc
[17:19:33] <jmkasunich_> we should ask jepler to test on his 7.10 system
[17:19:38] <alex_joni> when he's around..
[17:20:04] <alex_joni> * alex_joni watches
http://www.linuxcnc.org/compile_farm/
[17:20:23] <jmkasunich_> I don't think the farm builds documentation
[17:20:48] <jmkasunich_> but my test is doing that now, and it seems to be working fine
[17:20:50] <alex_joni> running "./configure --enable-simulator --disable-build-documentation "
[17:21:01] <jmkasunich_> I thought so
[17:21:11] <alex_joni> * alex_joni goes back to reading/fixing docs
[17:21:18] <SWPadnos> alex_joni, you accidentally removed a bunch of other stuff in that commit
[17:21:28] <alex_joni> SWPadnos: from configure.in ?
[17:21:36] <alex_joni> I don't think so..
[17:21:50] <SWPadnos> err - no, from configure
[17:22:00] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/configure.in.diff?r1=1.142;r2=1.143
[17:21:59] <jmkasunich_> configure is generated from configure.in by autoconf
[17:22:07] <jmkasunich_> alex used the older version of autoconf
[17:22:09] <alex_joni> SWPadnos: configure is different by more than 1k lines
[17:22:16] <SWPadnos> ok
[17:22:22] <alex_joni> didn't bother reading the diff :D
[17:22:29] <alex_joni> it _should_ work just the same
[17:22:30] <jmkasunich_> I think most of us have autoconf 2.59
[17:22:37] <SWPadnos> if configure is autogenerated on everyone's system, then why is it in cvs?
[17:22:45] <jmkasunich_> jepler's 7.10 box probalby has 2.61
[17:22:59] <alex_joni> SWPadnos: it only gets generated if you install autoconf
[17:23:02] <jmkasunich_> because we don't want autoconf to be a build dependency
[17:23:18] <alex_joni> and you specifically run autoconf
[17:23:32] <jmkasunich_> I think any developer who changes configure.in needs to run autoconf himself
[17:23:37] <SWPadnos> ok - so the change to configure is potentially important to everyone except - oh I don't know - alex and jeff :)
[17:23:38] <alex_joni> jmkasunich_: indeed
[17:23:59] <alex_joni> SWPadnos: didn't get that
[17:24:26] <SWPadnos> in other words, configure is whet 99% of people who compile EMC use - most people don't use autoconf themselves
[17:24:32] <alex_joni> indeed
[17:24:42] <jmkasunich_> as long as the GNU folks didn't bust something when they updated autoconf from 2.59 to 2.61, the generated configure file (even if it varies greatly) should do the same thing
[17:24:51] <SWPadnos> there are changes to configure based on which version of autoconf is used , either they're good, they're bad, or they don't matter
[17:24:55] <jmkasunich_> SWPadnos: right
[17:25:04] <alex_joni> they shouldn't matter
[17:25:14] <alex_joni> the changes I expect are in the way the scripts are written
[17:25:17] <SWPadnos> heh "shouldn't" is a great word :)
[17:25:19] <jmkasunich_> as long as configure.in doesn't use any autoconf 2.61 specific features or such
[17:25:29] <alex_joni> maybe they found ways to make some searches faster or the like
[17:25:34] <alex_joni> but no functionality change
[17:25:41] <SWPadnos> ok. I was just noticing some things like better support for crappy shells and that kind of thing
[17:25:45] <SWPadnos> dunno if it matters
[17:26:15] <alex_joni> we use platforms without crappy shells :D
[17:26:23] <SWPadnos> sez who?
[17:26:28] <alex_joni> sez ze board
[17:26:36] <SWPadnos> I wonder if one version or the other works better with busybox
[17:26:40] <alex_joni> s/use/support/
[17:26:44] <SWPadnos> heh
[17:26:55] <alex_joni> busybox reminds me of buildroot
[17:27:03] <alex_joni> that's the craziest project I've seen so far :D
[17:27:10] <SWPadnos> heh
[17:27:31] <SWPadnos> I don't think I'll be using busybox on these units I'm working on now, but I may try later
[17:27:41] <SWPadnos> if so, I guess it's up to me to be sure that configure works :)
[17:27:43] <alex_joni> buildroot really works great
[17:28:07] <jmkasunich_> I'm trying to find a history page for autoconf (to see the differences between 2.59 and 2.61)
[17:28:17] <jmkasunich_> 404 so far
[17:28:24] <SWPadnos> ok - was buildroot derived from Bill Gatliff's "make cross" scripts?
[17:28:54] <alex_joni> http://www.mail-archive.com/autotools-announce@gnu.org/msg00023.html
[17:29:07] <alex_joni> SWPadnos: heck if I know
[17:29:12] <SWPadnos> heh
[17:29:48] <SWPadnos> he (Bill) talked about those scripts a few years ago at ESC, I think there were a couple of derivatives since then
[17:30:10] <alex_joni> it's a nice project, you download it start configure
[17:30:17] <alex_joni> and then you select a lot of things you want
[17:30:28] <alex_joni> compiler version, kernel sources, busybox version, etc
[17:30:38] <alex_joni> and it starts to download stuff, configure and compile everything
[17:30:38] <SWPadnos> and then go get coffee :)
[17:30:50] <alex_joni> yup, return 3-4 hours later
[17:31:06] <alex_joni> I used it for an ARM boardf
[17:31:08] <SWPadnos> nah, grab a 16-core workstation and come back 20 minutes later :)
[17:31:30] <alex_joni> after that I made a cpio archive
[17:31:39] <alex_joni> and put that inside a 2.6 kernel
[17:32:24] <jmkasunich_> bbl
[17:32:35] <SWPadnos> see ya
[17:32:48] <SWPadnos> yeah, I think I'll head out for a bit as well. bbl
[19:05:23] <fenn> SWPadnos: "the smaller the surface area though, the less friction" is not true - friction is proportional to coefficient of friction and force only. area only applies when you start using sticky things like glue
[19:05:59] <SWPadnos> um - no
[19:06:15] <SWPadnos> I don't think so
[19:06:52] <SWPadnos> it should be the integral of coefficient of friction * downward force over the area over which the force is applied
[19:10:58] <SWPadnos> hmmm. I could be wrong there. but it's time to go eat, so I'll think about it later
[19:19:12] <fenn> i'll save you the digging on wikipedia: "The maximum possible friction force between two surfaces before sliding begins is the product of the coefficient of static friction and the normal force: Fmax = μsN"
[19:24:18] <fenn> hyperphysics has this to say: "Almost every simple statement you make about friction can be countered with specific examples to the contrary."
[20:08:47] <jmkasunich_> I wish the westside market (
http://www.westsidemarket.com/) was on the east side
[22:08:33] <alex_joni> pretty quiet in here
[22:20:35] <alex_joni> did I mention I hate axes/joints ?
[22:26:43] <alex_joni> cradek: emccanon.cc: getStraightVelocity() calculates max. machine speed based on AXIS_MAX_VELOCITY[*]
[22:27:11] <alex_joni> but those are actually JOINT_MAX_VELOCITY[*] for nontrivkins, and are likely to be wrong
[22:33:53] <fenn> well, it should use joint* at least
[22:34:15] <fenn> imho there's no need at all for axis_max_velocity
[22:34:32] <alex_joni> actually there is
[22:34:38] <fenn> only vector velocity
[22:34:51] <fenn> cartesian vector that is
[22:34:55] <alex_joni> right, and it's calculating that from axes_max_vel
[22:35:11] <fenn> ugh, why not just have a vector_max_velocity
[22:35:22] <fenn> only one
[22:35:23] <alex_joni> I don't understand
[22:35:36] <fenn> all you care about is how fast the robot/tool/spaceship is moving right?
[22:35:41] <alex_joni> right
[22:35:52] <fenn> not how fast it's going in some arbitrary direction in space
[22:36:02] <alex_joni> well, not quite
[22:36:07] <alex_joni> this is while planning the move
[22:36:14] <fenn> i dont see why it would matter
[22:36:26] <alex_joni> when interp reads a new move
[22:36:41] <alex_joni> it puts it into the queue along with the speed the move should be performed at
[22:37:00] <alex_joni> if the speed is greater than the machine can handle, the TP will plan it at that larger speed
[22:37:14] <fenn> and that's a vector velocity isnt it? the feed the interp sends (F50)
[22:37:38] <alex_joni> yeah, but you can't always do 50
[22:37:51] <alex_joni> so canon calculates the max machine speed for this precise move
[22:37:59] <alex_joni> say it's a move .2 in X, 1 in Y and .5 in Z
[22:38:21] <alex_joni> it looks at X,Y,Z'max speeds, and calculates the overall max_speed
[22:38:38] <alex_joni> TP will chose lower(F50, machine_max) for planning
[22:39:43] <alex_joni> am I making any sense?
[22:39:43] <fenn> yes
[22:39:46] <fenn> does emc actually do that?
[22:39:50] <alex_joni> yes
[22:39:56] <alex_joni> emccanon.cc does that
[22:40:04] <fenn> could you point me to line number?
[22:40:12] <alex_joni> sure
[22:40:39] <alex_joni> line 686
[22:40:43] <alex_joni> STRAIGHT_TRAVERSE
[22:41:02] <alex_joni> at line 737 it calls getStraightVelocity()
[22:41:17] <alex_joni> 738 for getStraightAcceleration()
[22:41:37] <alex_joni> the vel goes to ini_maxvel
[22:42:41] <fenn> i think "straight" is just what i was calling "vector velocity" because it doesnt do any calls to kinematics?
[22:42:56] <alex_joni> right, it does _not_ call any kinematics
[22:43:28] <alex_joni> but you can't have one vector (precalculated) for a machine
[22:43:40] <fenn> so how can it know how fast the machine can move in cartesian space based on joint constraints?
[22:43:43] <fenn> if it doesnt use kins
[22:43:48] <alex_joni> it can't
[22:43:52] <alex_joni> and that's why I said it's wrong
[22:44:17] <fenn> ok the answer to 'does emc actually do that' should have been 'no' :)
[22:44:31] <alex_joni> it does, but only for trivkins
[22:44:53] <fenn> well sure, i can multiply n-dimensional topological manifolds in my head, but only by 1
[22:45:20] <alex_joni> I'm not sure I see a way to fix this
[22:45:52] <fenn> the velocity/accel constraints will change over the work envelope. you have to average them across the move somehow
[22:46:13] <fenn> or take the minimum over the move
[22:46:24] <alex_joni> right, that's what my robots do
[22:46:45] <alex_joni> but still.. having the start & endpoint of a move
[22:46:58] <alex_joni> you need to run the path through kins to see what the speeds will be
[22:47:06] <alex_joni> or maybe I am missing something
[22:47:20] <fenn> right, you can't just calc the start and end, you have to find the minimum along the path
[22:47:48] <fenn> and we still havent gotten into feed override or adaptive feed :)
[22:47:49] <alex_joni> I bet here is where jacobians fit in
[22:48:22] <alex_joni> adaptive feed is easy
[22:48:26] <alex_joni> it only goes slower
[22:48:33] <fenn> jacobian is (currently, for hexapod at least) only used for iterative solving
[22:48:42] <fenn> (i think)
[22:49:22] <alex_joni> it's out of scope for me too
[22:49:25] <fenn> if you can transform a position you can transform a velocity or accel using the same matrix
[22:49:57] <fenn> right?
[22:50:08] <alex_joni> * alex_joni isn't sure
[22:50:21] <fenn> well, you'd need the position too
[22:50:42] <alex_joni> I'd say (by guts) you'll have a slightly bigger matrix
[22:50:47] <alex_joni> which contains the previous one
[22:50:53] <SWPadnos> you can't transform a velocity the same way as a position
[22:51:17] <SWPadnos> consider a polar robot doing a straight traverse
[22:51:35] <SWPadnos> the rotational speed necessary is dependent on the minimum radius over the excursion
[22:51:52] <SWPadnos> but that's not "obvious" from the endpoints
[22:52:12] <fenn> SWPadnos: i'm just talking about velocity at a point
[22:52:35] <fenn> lets use your minimum radius
[22:52:56] <alex_joni> I don't think you can write inversekins that do velocity
[22:53:11] <alex_joni> forward maybe
[22:53:20] <alex_joni> forward = cart -> joint
[22:54:21] <fenn> the point is where the path is closest to the joint center
[22:55:10] <alex_joni> yes and no
[22:55:15] <SWPadnos> polar was just easiest to think about for an example
[22:55:26] <alex_joni> imagine a move where the path is closest to the joint center during accel
[22:55:33] <fenn> * fenn is regretting using this example already :)
[22:55:45] <alex_joni> in that case the cart speed might be lots slower than lateron
[22:55:51] <SWPadnos> I'm sure it's much more complex for a puma-style robot, which may have multiple solutions for a given XYZ position
[22:55:51] <alex_joni> and the joint speed just the same
[22:56:06] <alex_joni> SWPadnos: lets ignore that for a while
[22:56:23] <SWPadnos> ignoring :)
[22:56:31] <alex_joni> (the multiple solution part)
[22:56:38] <SWPadnos> ok
[22:56:40] <jmkasunich_> if you can transform position, you can transform two positions that are V*dt apart, and from that calculate velocities
[22:56:57] <SWPadnos> jmkasunich_, that's true for an average velocity between two points
[22:57:01] <jmkasunich_> but you'll have to do that all along the path
[22:57:10] <SWPadnos> and it's prefectly valid for points that are close together
[22:57:14] <SWPadnos> exactly
[22:57:27] <alex_joni> that sounds like quite an overhead
[22:57:36] <SWPadnos> so it becomes a cal;culus example (if you try to find minima/maxima), or a looping problem
[22:57:47] <alex_joni> minima is what we need
[22:58:00] <fenn> ok so back to jacobians (derivative of the transform)
[22:58:14] <jmkasunich_> where is it written that we need the minima?
[22:58:21] <jmkasunich_> all we need to do is obey machine constraints
[22:58:24] <fenn> so you don't exceed the joint limits
[22:58:26] <alex_joni> jmkasunich_: it's not written
[22:58:38] <alex_joni> but currently that's the way emc2 does it
[22:58:46] <jmkasunich_> if 90% of the move can be done at the Fword speed, but 10% needs to be slowed down to satisfy machine constraints, just slow down the 10%
[22:59:00] <alex_joni> the alternative is to make TP aware of joint limits
[22:59:07] <jmkasunich_> ah, I see
[22:59:15] <fenn> its a granularity problem
[22:59:18] <jmkasunich_> currently the limits are applied before the motion is queued
[22:59:24] <alex_joni> right
[22:59:34] <jmkasunich_> that just plain won't work with non-trivkins
[22:59:49] <alex_joni> because of FO
[23:00:00] <alex_joni> and nonlinearity of the max_feedrate
[23:00:11] <alex_joni> I mean machine_max_feedrate
[23:00:29] <jmkasunich_> max rate in cartesean space?
[23:00:33] <alex_joni> for nontrivkins you have a max_feedrate (machine capability) along any given direction
[23:00:52] <alex_joni> and TP takes care of clamping FO if it goes higher than that
[23:01:02] <jmkasunich_> for non-trivkins, max_feedrate (in cartesean space) is a vector field
[23:01:37] <alex_joni> http://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/Vector_field.svg/394px-Vector_field.svg.png
[23:02:09] <fenn> looks about right
[23:02:21] <jmkasunich_> yep
[23:03:01] <fenn> and how do we derive this vector field?
[23:03:11] <jmkasunich_> not easily
[23:03:49] <fenn> is it not just a transform of the max joint velocities?
[23:03:51] <alex_joni> * alex_joni rides on the vectorian tractor
[23:04:07] <jmkasunich_> * jmkasunich_ has hunger
[23:04:13] <fenn> round and round she goes
[23:04:18] <alex_joni> fenn: it's actually a composition of max joint velocities
[23:04:40] <fenn> right, minimum of all of them
[23:05:31] <fenn> not calculus-minimum, more like min()
[23:05:48] <alex_joni> * alex_joni feels fenn would end up with an empty vector field
[23:06:12] <alex_joni> if you take all possible moves in account, you might get a lot of places where the min() is actually 0
[23:07:05] <alex_joni> * alex_joni gets dizzy
[23:07:23] <fenn> polar robot
[23:07:24] <jmkasunich_> * jmkasunich_ is dizzy too
[23:08:13] <alex_joni> I think the 'trick' is to have a TP which knows joint limits
[23:08:21] <fenn> if the arm is fully extended (colinear) the max velocity along the direction of the arm is 0
[23:08:47] <alex_joni> fenn: you don't want to get near inflection? points
[23:08:47] <fenn> but that only applies to the very edge of the work envelope
[23:08:47] <jmkasunich_> fenn: that gets into another topic - workspace limits
[23:09:14] <fenn> i'm just saying that the zero-velocity areas are not just random
[23:09:15] <jmkasunich_> again, emc assumes that workspace (cartesean) limits are the same as joint limits
[23:09:19] <alex_joni> there are a couple 'special' places for robots
[23:09:31] <alex_joni> where you can get/need infinite velocity
[23:10:07] <fenn> infinite joint velocity
[23:10:07] <alex_joni> jmkasunich_: I don't think you can define a cartesian workspace
[23:10:26] <alex_joni> fenn: infinite needed joint velocity
[23:10:32] <fenn> right
[23:10:50] <jmkasunich_> alex_joni: you can define a workspace in cartesean coords, but not using a simple set of limits
[23:11:07] <alex_joni> jmkasunich_: ok, I just wouldn't know how to express it
[23:11:13] <jmkasunich_> it might be a torus, or intersection of tori, or something even weirder
[23:11:30] <alex_joni> oh, it's quite weirder than that :D
[23:11:49] <fenn> i think you're talking about different things
[23:12:23] <fenn> alex is talking about the range of motion of the machine, jmk is talking about where you want the end-effector to go
[23:13:08] <fenn> the range of motion is a nD space
[23:13:11] <alex_joni> http://www.famielectronic.ro/img/r500caract.gif
[23:13:14] <jmkasunich_> * jmkasunich_ needs to make food
[23:13:20] <alex_joni> here's one example
[23:13:31] <alex_joni> fenn: end-effector
[23:13:38] <fenn> yes that's a 2d projection of the range of motion
[23:13:46] <fenn> er, 2d cross section i mean
[23:13:50] <alex_joni> and you need to rotate that
[23:13:52] <alex_joni> right
[23:14:13] <fenn> it just happens to be (mostly) symmetrical
[23:14:25] <alex_joni> notice you'll get overlapping parts (where the multiple solutions happen)
[23:15:02] <alex_joni> but even in the regular space you get multiple solutions, but as I said.. let's not go there
[23:15:07] <fenn> they dont really show the overlaps
[23:15:32] <alex_joni> no, you only have one cross-section
[23:15:50] <alex_joni> but if you imagine it in 3D, rotated 360 degrees, then you can 'see' the overlaps
[23:16:37] <fenn> by overlaps you mean arm-up arm-down?
[23:16:43] <fenn> or something else?
[23:18:16] <alex_joni> hmm.. let me try to explain
[23:18:23] <alex_joni> you see that 2D cross-section
[23:18:54] <alex_joni> there are places the robot can reach in the front, and places in the back.. right?
[23:19:16] <alex_joni> now if the robot would be rotated 180 degrees from the joint 0, they would be swapped
[23:20:02] <alex_joni> following so far?
[23:20:13] <fenn> i cant really tell how that robot moves from the sketch actually..
[23:20:39] <alex_joni> well, n/m then
[23:20:43] <alex_joni> it's not that important anyways
[23:20:56] <fenn> ok
[23:21:01] <alex_joni> http://www.famielectronic.ro/img/fanuccaract.gif
[23:21:09] <alex_joni> here's another sketch
[23:21:12] <alex_joni> maybe it's a bit more clearer :D
[23:21:41] <fenn> thats not the same robot
[23:21:44] <alex_joni> no
[23:21:46] <alex_joni> but similar
[23:22:04] <tomp> and it shows the extra limits of the motor box intersecting the normal cup range of motion
[23:24:20] <fenn> anyway. how would the TP "know" joint limits?
[23:25:07] <tomp> hard to believe the side view of j2 and j3 are really circular, should be a cam
[23:25:27] <alex_joni> fenn: they get passed at loading time
[23:26:20] <fenn> tomp: the workspace is mostly circular because j2 is doing most of the work at the edges of the envelope
[23:26:47] <fenn> alex_joni: and what does that get you? dont you still need to run stuff through kinematics a zillion times?
[23:27:17] <alex_joni> hmm
[23:27:23] <alex_joni> maybe you can do it on the run
[23:27:27] <alex_joni> slow things down as you hit limits
[23:27:47] <fenn> *bam*
[23:27:59] <alex_joni> joint speed limits I mean
[23:28:21] <fenn> that was the sound of your drives exploding
[23:28:52] <alex_joni> nope it wasn't.. I know that sound too well
[23:28:53] <alex_joni> :D
[23:32:52] <fenn> TP currently does things by "segments". do those segments correspond directly with g-words?
[23:33:01] <tomp> tp knows cartesian targets, could it be fed joint targets? ( if the desired cartesian target was already reduced to joint ) then tp's task might be simpler & more flexible.
[23:33:24] <fenn> tomp: yes we've discussed this before, i like the idea but others are skeptical
[23:33:31] <tomp> k
[23:48:24] <fenn> tomp: i like the idea of sending a time-parameterized function in joint-coordinates to realtime, and then the only thing the machine has to do in realtime is to solve the equations for that particular time-coordinate
[23:49:06] <fenn> then it does PID on those values and everything should be hunky-dory
[23:50:30] <fenn> this has nothing to do with what we were talking about though..
[23:50:45] <alex_joni> * alex_joni needs sleep
[23:51:21] <alex_joni> different topic: looked at docs today
[23:51:27] <alex_joni> they look good (great actually)
[23:51:55] <alex_joni> * alex_joni isn't sure what's missing from the user manual..
[23:52:05] <fenn> classicladder
[23:53:50] <alex_joni> that's integrators manual
[23:54:03] <alex_joni> I think..
[23:55:06] <fenn> i generally look at the html
[23:55:49] <alex_joni> fenn:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Documentation
[23:56:03] <alex_joni> feel free to add stuff there, and bold it out for me please
[23:56:22] <fenn> classicladder A PLC using HAL for all I/O <- that's all i see in the pdf
[23:56:54] <alex_joni> yeah, I meant earlier that classicladder docs are missing from the integrator manual, not from user
[23:57:08] <alex_joni> they are missing nonetheless
[23:57:53] <fenn> the classicladder wiki page has a lot of raw material that just needs shaped up (a lot)
[23:58:26] <fenn> right now it reads like a blog
[23:58:55] <fenn> Stepper tuning?
