hi there John
[02:00:47] <jmkasunich> http://dsplabs.cs.upt.ro/emc2/dists/breezy/Release.gpg:
Temporary failure resolving 'dsplabs.cs.upt.ro'
did alex do anything with his server?
try utt instead
(I remember that because I think of Astro, Dino, or Scooby-Doo: "ut-ro")
websites that make you search for a product suck - they should just list them
I agree. and they should publish the prices as well
at least MSRP
(this is a mfgrs site, not dealer)
the other annoying thing is when they categorize things a certain way (like by "application"), and you have to figure out what the hell the web designer was thinking when they did it
right - ballparks are OK for pricing
in this case its a product with lots of variations
but the worst price is "Call for pricing"
instead of listing the general item and letting you see the variations, they make you pick everything before they show you anything
yep - you get that sometimes (like oscilloscopes or power supplies)
or pistols ;-)
* jmkasunich is lusting after a .22 target pistol
you can't buy those over the web, can you?
but you can pick out what you want and have your friendly neighborhood dealer order it
(hence the MSRP)
do you know if anyone has looked into writing emc drivers for Ah-Ha hardware? (or if any are necessary)
nobody has looked into it (that I'm aware of)
I don't know much about Ah-Ha
my old company has a Shoptask with Ah-Ha controls, and one of the guys bought Mach2 to replace it
I wasn't sure if a drop-in replacement might be better
AhHa is hardware isn
though the "ease=-of-use" features of Mach are better than emc at the moment
drives and such?
yes - they have an ISA card, and an external power supply / driver box
I'm not sure what the ISA card is, it may just be an 8255 card
SWPadnos is now known as SWP_Away
Some recent change broke the link to emc2/nc-files in run-in-place
for the mini interface at least.
SWP_Away is now known as SWPadnos
Don't know. I remember it working a while back after some changes alex made.
It is finding the config directory rather than the nc-files
I wonder if jmk's config changes might be the culprit
Just an annoyance rather than a bug
It was working after the change to multiple config directories.
I've only checked stepper/stepper_inch.ini, but PROGRAM_PREFIX was not changed
what's PROGRAM_PREFIX in your ini?
I see it varies a bit across the inis. I just saw one that's ../../nc_files, then there's ~/nc_files ...
Oh. That might be it. I was running the xyza thing.
yeah that's probably my fault. It's ~ on my system.
getting sample configs right is harder than you'd think.
I think I understand at least a part of the problems.
rayh: so how is xyza?
I think I really need someone to write some tp/blending torture tests
ask les for some turkey call programs ;)
that would be great to have
if I do it, I'll just write the cases I've thought about, making them useless
if you have the tests, what will you do with them? Check that they don't violate constraints when run? By eye?
by eye with the yellow blends, and run stepper without headroom so the constraints are checked closely
besides using stepper config, I wonder if you could create a HAL component that keeps the minimum or maximum value of its input as its output
I'm sure you could
that seems easy to do (even I could do it)
I guess "could" is the wrong term
I wonder if it would be useful
min/max, and min/max derivative would probably be useful
a general "derivative" component
that exists in blocks, it's called ddt
oh forget it then
a "run this forth (or other tiny language) program" component?
that's not there, but jmk has talkedabout it
a "math formula" component
with this talking about kinematics, I don't know how that fits in with HAL, but having a HAL component flexible enough to specify new and interesting kinematics without recompiling sounds good ..
good but possibly too slow
it would have to use a bytecode interpreter kind of thing
(we don't want to be parsing infix -> postfix in the kernel, I think)
how often are the kinematics run? Once per servo cycle?
I bet 10-100 bytecode instructions would be perfectly doable at that rate
hmmm. I'd take a look at the hexapod kins to get an example of the necessary complexity
I don't know a thing about kinematics but I think I could write the bytecode interpreter
not in forth though, right?
I'd probably write a stack-based bytecode interpreter, and that's practically forth.
heh. does GCC even do forth?
jepler: take a peak at genhexkins.c from emc1
I don't wish anyone would have to put that into a HAL module ;)
Maybe we can get Bryan Register to write it for us.
/* Enter Newton-Raphson iterative method */
#define FAIL_CONV_ITERATIONS 150
I met him at a code fest a few years back.
I guess I've underestimated the complexity of kinematics
jepler: that is one extreme example :D
why isn't there some simple, closed form for this?
it's the math, I think
jepler: it's not a linear transformation
and that file is for generic hexapods
aka you can define a lot of things for your specific hexapod
jepler: look at the pumakins
those are more likely, common
at least there's no looping
but clearly my estimate of 100 instructions is very low compared to real life
The hexapod kinematics are different. You might look at the scara stuff that Sagar did.
His work was formula driven rather than matrix.
then the next thing is to make cradek's emc2-dev deb support compilation of new modules so that it's easy for users to write and install "new stuff" without building all of emc.
There you go.
wherever you've gone
I suppose, although I have no way of proving that
heh, I really like that picture of aunt tillie ;)
well, aunt bessie
well, aunt bessies
I don't understand why ubuntu doesn't have a gftp package.
Hi Ray... I have it installed.... not sure what repository it came from
opps wrong window.... bunch of gcc updates available
ah found it. Thanks.
rayh: I notice that cp1 hasnt made it into the emc2 distro.... I think it is still useful
any plans on adding it? I think there is a tcl tools directory already
You bet it is. I'd like to redraw the front page of it a bit and add the step thing you were speaking of.
Right. I've got a bit of work to do putting gpl headers in there. Let me look it over.
I didnt send you the step shaft thing, because it is pretty specific to my mill/drill/lathe... Ie it uses X and Y for turning
Oh. Okay. Well let me see what I can do to revisit that stuff. It is really useful at times.
there is no reason it could not be changed to use normal axis definitions (maybe programmable)... are there many people using emc on lathes? one doesnt hear much
mostly it seems that we hear "EMC doesn't do threading, I'm using Mach" ;)
what is your email... I can send you my latest
I just put an image in http://www.linuxcnc.org/Dropbox/pipethread.png
I believe that there is a problem with the interp recognizing or setting axis names.
how does tkbackplot use the ABC axes when mapping to the 2D screen?
the plot looks good to me, though I may not know what I'm looking for ;)
It rotates around x0
for the a axis
y0 for the b axis
and z0 for the c axis.
ok. that's what it looks like in the plot (to me, anyway)
by offsetting y some you can see the rotation of a
now I'm confusted but that is easy these days.
The plot shows that the cradek tp does work though.
ok. web seminar starting now - I'm really out for a bit :)
axis doesn't do anything with the ABC axis information, so its display will be pretty useless for machines with angular axes.
well it displays the numbers in the coordinate readout of course
so it's perfectly usable, just the preview is not what you might want
I'm pretty sure that command in the screenshot will show as a straight line in axis
yes it does
g0x1y1z1a180 -> straight line
[19:28:47] <jepler> http://www.linuxcnc.org/Dropbox/pipethread.png
how can it know the radius?
does it assume radius=Z?
ray said "It rotates around x0 for the a axis"
I think maybe he means the line along the X axis
ok that makes sense
I think you often set up that way (tooltip on the rotation axis is Z=0)
yeah .. if you have one rotational axis, and you make it go along a machine axis, I see how you could plot the tool position relative to the unrotated workpiece
we could add that easily enough... it's a simple polar to rectangular conversion
anything more than one rotary table is not so obvious.
so basically axis would take the incoming point, and transform the XYZ coordinate with a rotation matrix like [[1 0 0] [0 c s] [-s c]] for the A axis, then add it to the backplot?
for the preview plot, segments where "A" changes would have to be broken down, because you can't connect the endpoints with a straight line anymore
you'd also want to change the orientation of the tool cone
yes I think that's it
you're right about straight lines for g0/1 not working anymore...
My head hurts when I try to imagine the shape you'd get with G2 ... A-
a shape you probably don't want
but fwiw I think it "works"
great, that means there's no need to make it work in axis
wouldn't we get it for free, since arcs already break up into lines?
I'm sure the current code doesn't interpolate "A" when it breaks up the arc
but it should not be hard to add
cradek: some gcc updates on ubuntu today
yeah I got them a few days ago
there was a bug in flex I think
the gnu lexer
k.. I guess
what happened to mike in #emc ?
SWP & me were trying to help him get a grip on HAL
he is running 2.6.15-something
gawd.. what's wrong with cvs again?
cradek: I see speed jumps on every servo cycle
looks almost perfect, but there are some irregularities
I don't understand
probably the segments are very short
let me post a pic so you can see
[20:24:23] <alex_joni> http://solaris.cs.utt.ro/emcstuff/spiral2.png
that looks pretty good to me
what is your accel constraint? 4 divs?
I'm running sim-AXIS
so I guess so
* alex_joni looks
20 in TRAJ
and 20 on the axes
it jumps a bit over 20 on the first move
no, it's 12-13
5 mv/div? Yeah, I read it as <15
it looks like it has the accel to reach the new requested velocity within one servo cycle most of the time
looks like your accel is so high that your accels all happen in 1 or 2 cycles
yeah what he says
yup.. I'll try a lower accel, see what happens
I'd like to see this at low accel too
also to screw with it, try setting X and Y to different accels
how about 2 ?
cradek: we're on the same wavelength :)
you should see actual blends then I bet
alex_joni: did you mean your program to be 34 inches across?
* alex_joni is lost
your ste.ngc program is huge - 34 inches
* alex_joni can't remember
the screenshot you just posted
oh did I get my tabs confused?
that's jepler's spiral
ok.. you got me worried :)
forget it, sorry
cradek: SPLENDID graphs at 1&2 accel
taking another one
cradek: spiral 3-5
cradek: got them?
on 5 I increased gain for accel
it's really very low
so blending is great
X maxaccel was what?
let me do that again with G61
if it's 1, these spikes are too high
1 on X, 2 on Y
can't tell which is which
I'm sad to see that
Xacc is green in spiral5
and the peak to peak is > 4 divs
hrmm.. yes :(
those are all g1 moves right?
I wonder if the blend runs for one too few or one too many cycles
G61 looks fine to me
alex_joni: with g64 is most of the plot yellow?
I might have the worng emc2-axis
none is yellow
I saw a few glitches during accel, usually dropping toward zero.
what emc2 are you running?
I wondered if it might be some sort of rounding error that was catching up.
are you sure it's a recent head?
alex_joni: are jogs yellow?
let me try cvs up again
That was head tuesday
alex_joni: if they're not yellow, your axis is too old
emc2-axis 1.2rc2-1.0 AXIS front-end for emc2
alex_joni: that won't tolerate G64 Pxxx, you should build emc2head and axis both from source
alex_joni: there are no packages yet
ok, got an url to a tgz?
cradek: shouldn't 1.2rc2 be fine for showing the yellow?
jepler: I think so, if it works, but I'm not sure it will even run with the canon change...?
cradek: oh right
I think you get a symbol error at startup
I bet alex is not running new (emc2) code
cradek: but 1.2rc3 would be fine
cradek: might be so
I removed the debs
and updated my local copy
that'll do it for sure
alex_joni: btw you can get axis via anonymous cvs now
(but rip doesn't conflict with the debs)
cradek: axis does conflict with the debs
oh right, /usr/share/axis
why is it called axis-ps436 ?
alex_joni: A tool called "cvsps" lets you view CVS as a series of patch sets (which is what newer systems, like svn, do). A patchset, unlike an RCS revision, uniquely designates the revision of the whole source tree.
So you have patchset 436 in that tarball
cradek: yikes :( error: invalid Python installation: unable to open /usr/lib/python2.4/config/Makefile (No such file or directory)
sudo apt-get build-dep emc2-axis
apt-get build-dep emc2-axis
E: Unable to find a source package for emc2-axis
your sources.list is old
* alex_joni checks his sources
make a deb-src line
ok, that works :)
I really need to install axis more frequently
only whenever you break the old version by changing canon :-)
usually installing the packages will be just fine
cradek: you're lucky I don't feel like looking at the XYZUVW stuff now
that probably would totally turn canon tits up :)
alex_joni: I think xyzabc work 100%
yes, I agree
except when ABC are linear
no I bet that works too
if you set LINEAR_UNITS and ANGULAR_UNITS the same
a/v constraints are honored for all coordinated moves now
I'm getting some warnigns during the compile :)
I am.. just pointing out
alex_joni: how's the update coming?
cradek: it's yellow all over ;)
alex_joni: I would like to see a new accel plot if you can do the same test
the screenshots look like they're ok
it's hard to tell if it's a problem with sampling or it actually goes over the value
* alex_joni puts them up in a second
done, the xpos*
and the xvel*
cradek: see what I mean with sampling problem?
what are the urls?
[21:23:52] <alex_joni> http://solaris.cs.utt.ro/emcstuff/xpos,xvel,xacc,xjerk-1.png
[21:23:58] <alex_joni> http://solaris.cs.utt.ro/emcstuff/xpos,xvel,xacc,xjerk-2.png
[21:24:03] <alex_joni> http://solaris.cs.utt.ro/emcstuff/xvel,xacc1,yacc20,yvel.png
ok I do not think those count as violations
right, sampling problem I guess
I think that's caused by stepgen's time quantization
hmmm - does simulation by just feeding cmd-output -> position-fb work?
that should test the TP at least
ok, so any quantization problems wouldn't matter then ;)
cradek: TRAJ should be min(X,Y,Z) ?
or max ?
shuold be MAX, I'd think, since the individual axes should limit to their own settings
actually, it could be sqrt (X^2 + Y^2 + Z^2)
should quite likely be more than max like swp says
depends what you want
TRAJ max is the tooltip max accel
AXIS max are the axis max accel
set them however you want :-)
ok, I used max() for now
and the lower of the two will control, since you fixed that :)
SWPadnos: I fixed it better, it gives the actual right value now
oooohhh - cool!
if xacc=yacc=zacc and you move from 0,0,0 to 1,1,1 it will acc at acc*sqrt(3)
ha, or whatever the answer works out to be
unless TRAJ is < sqrt(3)
I think it's sqrt(3)
yes, I think tooltip is limited by traj correctly
should be sqrt(sum of squares of all axes)
yeah sqrt(3) then
cradek: the plot looks excelent
even at those high feeds/accels
and that's with different accels? that's a harder case for blending
200 vs. 1200
we should test if blend tolerance is still right with different accels
obviously the blend will not be symmetrical, but I want it to be within tolerance
I can try G64 P0.2
did les see that plot?
less blending now
boy that was some nice tp work.
jepler: still there?
alex_joni: yeah sorta
ok, I'm seeing some bad updates on the axis plot
probably because of too much speed
it's kinda an insurmountable problem
[22:14:07] <alex_joni> http://solaris.cs.utt.ro/emcstuff/cds-g64p0.1-fo2020.png
it's interesting that the yellow can come completely after the bend
oh, btw.. I have a feature request.. if it's not too hard ;)
I see that running emc2 at a really low period on a slow computer.
for example on rotating, when you reach the right extent of the desktop, make it jump to the left extent
if you get what I'm meaning
Yeah, but I don't think Tk even has a command to warp the pointer
maybe I just don't know what it's called
# warp cursor to $widget (jump)
what's that? It's not Python or Tcl
$cursor->warpto( X,Y )
Warp the cursor to the specified X,Y screen coordinate.
[22:18:22] <alex_joni> http://search.cpan.org/~dunniganj/Tk-CursorControl-0.4/CursorControl.pm
that's some perl thing
that's what google says.. I have really nfc
that confirms that Tk doesn't have a builtin way to do it, I think
seems perl, as he's talking about CPAN
% event generate . <Motion> -warp yes -x 0 -y 0
actually, Tk does .. it's just in a surprising place and poorly documented
[22:21:56] <alex_joni> http://tcl.sourceforge.net/faqs/tk/#misc/warp
that kinda disagrees :D
I'm not sure wether requiring "8.3+" is a new requirement or not
I think 8.4 is required by the debs
yeah, but that's because it's the version python2.4 is linked with on ubuntu
jepler: there is one more thing .. but I'm having mixed feelings about that
setting the debug level
of emc? axis?
axis doesn't have a concept of debug levels
there's a NML message for that
here's where I go to aunt tillie mode .. how often is anybody gonna use that !?!?
I am using it ;)
once in a while..
especially when sim.ini defines it like crap, and the machine can't move fast enough because of the messages printed by debug
but I guess I can edit a file..
it's just bothersome to stop emc, change, restart
maybe a reload ini would be something?
that would have other very interesting applications