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