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