Back
[00:21:27] <cradek> alex_joni: the solution to debug messages slowing your machine down is to not use gnome-terminal
[00:37:34] <SWPadnos> or wait for gnome 2.1.4 terminal, which can cat /usr/dict/words (or whatever) in 1 second
[02:04:33] <jepler> cradek: the new tp isn't in the debs, is it?
[02:05:03] <jepler> (I removed the headroom from a stepper config and got a joint following error)
[02:06:02] <jepler> SWPadnos: I'll believe it when I see it; will they also make the terminal emulation work right finally?
[02:06:29] <SWPadnos> good question
[02:06:53] <SWPadnos> there was an article on the changes in gnome, and I recall the terminal being one of the big speedups
[02:06:55] <jepler> I still get bad screen refreshes sometimes, from common programs like mutt and screen
[02:06:59] <jepler> programs that I trust much more than gnome-terminal
[02:07:11] <SWPadnos> heh - no clue on what bugs are left ;)
[02:07:34] <SWPadnos> http://www.gnome.org/~davyd/gnome-2-14/
[02:08:17] <SWPadnos> it'll be out in a week, we can see the real story then
[02:08:29] <jepler> I wish they'd add rxvt-unicode to the comparison graph of terminal speed
[02:08:47] <SWPadnos> or a text (even fbcon) console
[02:10:29] <jepler> I see they're searching for ever dumber program names
[02:10:43] <SWPadnos> gotta get the most use of the 'g' as possible
[02:10:46] <SWPadnos> or more
[02:10:49] <jepler> Isn't Sabayon some kind of sexual stimulation device? I remember reading about it once.
[02:11:45] <jepler> "To help users who utilise remote X windows, Metacity will mark windows that are running on a different host to Metacity itself."
[02:11:58] <jepler> this sounds like a good idea. I haven't seen it in a window manager before
[02:12:03] <jepler> the rest is either old hat or new tripe
[02:12:07] <SWPadnos> yep - that one was pretty cool
[02:13:10] <SWPadnos> some of the multimonitor snap tuff also looks good (though it isn't exactly version-aking change)
[02:13:13] <SWPadnos> making
[02:13:31] <jepler> cradek could tell us whether icewm snaps to monitor edges or just screen edges
[02:13:36] <jepler> I agree, I'd want to snap to monitor edges too
[02:13:49] <jepler> but I don't have a dual-headed laptop so it doesn't matter so much to me
[02:14:08] <SWPadnos> gnome already does when you drag windows around, but making dialogs/menus appear on a single monitor is a nice thing
[02:14:28] <jepler> it does? I didn't see snapping when I used metacity on ubutu
[02:14:50] <SWPadnos> hmmm - maybe it doesn't, but I thought it was there
[02:15:03] <jepler> it's been in better window managers for a long time .. maybe even fvwm2
[02:15:48] <SWPadnos> the thing that bugs me is that the panels are only on one monitor, so when you drag a window from the other one, it pops up/down to avoid being over the panels
[02:16:08] <jepler> eek, I just found a pretty weird blend from the new tp
[02:16:15] <SWPadnos> oh?
[02:18:05] <jepler> it may have been while I was moving the feed override slider too
[02:18:13] <SWPadnos> at least gedit is now tabbed, like kate ;)
[02:18:16] <cradek> uh-oh
[02:18:29] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/weird-blend-1.png
[02:18:37] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/stepper_inch.ini
[02:18:41] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort.ngc
[02:18:47] <jepler> hi cradek
[02:19:12] <cradek> hi
[02:19:21] <SWPadnos> hmmm - so it blended the g0 and then the g[23]?
[02:19:21] <cradek> jepler: are your axis accels different or the same?
[02:19:28] <cradek> maxaccels and maxvels
[02:19:35] <jepler> different
[02:19:58] <jepler> I ran again without touching feed override (left it at 115%) and ran from line 15 .. got essentially the same blend
[02:20:06] <cradek> this looks like another premature-blend case
[02:20:23] <cradek> the thing on the left is an arc?
[02:20:38] <cradek> oh duh, I see the gcode
[02:20:43] <SWPadnos> I'm not sure I'm seeing what was intended - which arc was first?
[02:20:51] <jepler> the arc at the left was first
[02:20:52] <cradek> the left one
[02:21:07] <SWPadnos> ah, ok
[02:21:19] <jepler> I've written a program that generates these terrible tangled programs
[02:21:28] <cradek> I see that!
[02:22:27] <SWPadnos> hmmm - the TP would tend to blend early with high FO, because at higher speeds, decel needs to begin sooner
[02:22:41] <SWPadnos> but when you reduce the FO, the expected speed is lower
[02:23:01] <cradek> jepler: is this straight g64 mode?
[02:23:05] <cradek> (the default)?
[02:23:12] <jepler> there's another weird case near line 47
[02:23:25] <jepler> cradek: I didn't change it away from the default. It's not the one with tolerance specified.
[02:23:26] <SWPadnos> there's no G64 in the program
[02:23:35] <cradek> ok
[02:24:31] <jepler> the good news is that my modified stepper_inch.ini has no headroom specified, but I haven't gotten a following error yet .. at line 133 so far.
[02:24:42] <cradek> that's good news
[02:24:48] <cradek> just don't try to jog :-)
[02:25:38] <cradek> I know it's a pain, but can you tell me if it does the same wrong thing if you set the maxvel/maxaccels all the same?
[02:26:04] <cradek> I don't have an immediate "aha!" for this one like I did the last one
[02:26:27] <cradek> I need to go to my real computer, brb
[02:27:08] <jepler> cradek: happy to .. I'll let you know in a few
[02:28:14] <SWPadnos> I can't quite see the shape of that blend. Is it in a single plane?
[02:29:59] <jepler> cradek: it's much better .. "sane" even .. with identical maxes
[02:30:06] <jepler> SWPadnos: no .. the two arcs are different planes too
[02:30:17] <cradek> jepler: it touches the g1 somewhere?
[02:30:24] <cradek> somewhere other than an endpoint
[02:30:28] <SWPadnos> ok. I see that the arcs are in different planes, but the squiggle wasn't really identifiable with one perspective ;)
[02:30:41] <SWPadnos> it looks like it doesn't
[02:31:10] <jepler> cradek: yes. more or less in the middle
[02:31:11] <SWPadnos> or strangely, that it might be trying to blend to the wrong end
[02:32:24] <jepler> the other weird thing around line 47 looks better now too
[02:33:22] <cradek> I suspect you have a low accel, long segment blending into a high accel, short one
[02:33:53] <SWPadnos> ~3.5mm segment length on the G1 move
[02:34:01] <cradek> can you tell if that's sort of the case?
[02:35:05] <jepler> I don't know which axis is which
[02:36:44] <cradek> the code still looks right, I must not understand the problem yet.
[02:36:48] <cradek> oh look, your ini
[02:37:34] <jepler> the straight move in the middle is mostly in XY, I think Z had the smallest accel but also smallest vel
[02:38:01] <cradek> ok so it is probably low accel into high
[02:40:38] <jepler> man with identical axes this is so smooth and pretty
[02:40:56] <cradek> cool, that is by far the usual case
[02:41:13] <cradek> wow, what a gcode file
[02:41:23] <cradek> I finally got your ini running
[02:41:30] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/torture.py
[02:41:45] <SWPadnos> it should be put in nc_files/testing/fuck_my_tp/tort.ngc
[02:41:50] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/torture-noheadroom.ini
[02:41:52] <cradek> oh, it's deathly slow
[02:41:58] <cradek> is that right?
[02:42:15] <cradek> ok I guess the moves are different speeds
[02:42:19] <cradek> sorry for being obtuse
[02:42:20] <SWPadnos> heh, gotta love it when the first line of the program is "from random import *" ;)
[02:42:23] <jepler> yeah it changes the feeds half the time
[02:42:54] <jepler> the slowest axis in the first ini is .4ips, pretty fast by my standards
[02:43:08] <jepler> I forget what I changed them to in the second
[02:43:38] <jepler> hm, I didn't change the things in [TRAJ]
[02:43:42] <SWPadnos> when I next fire up my emc machine, I'lltry that on a machine that does 3 IPS, using a USC looped back into itself
[02:43:45] <jepler> are they important these days?
[02:43:57] <cradek> they are tooltip limits
[02:44:19] <cradek> so they should often be higher than axis limits
[02:50:28] <jepler> hmm
[02:50:42] <jepler> is it g64 p- or g61 p- ?
[02:51:19] <cradek> g64 pxxx
[02:52:37] <jepler> if I write g21 / g64 p.1 should that mean .1mm or .1in?
[02:52:53] <jepler> (I'd say .1mm but I wonder if the implementation gives .1mm or .1in)
[02:52:57] <cradek> good question
[02:53:09] <cradek> * cradek points toward romania
[02:54:02] <cradek> I'm pretty sure I agree it should be .1mm
[02:54:39] <cradek> ooh, I nailed your bug
[02:55:09] <cradek> http://timeguy.com/cradek-files/emc/better.png
[02:55:52] <jepler> eek! I found another weird one
[02:56:00] <cradek> whee this is fun
[02:57:23] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tort2.ngc
[02:57:29] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/weird-blend-2.png
[02:57:34] <jepler> this is using torture-noheadroom.ini
[02:57:58] <jepler> you'll notice there's 2 lines it hardly touches
[02:58:13] <jepler> and a bizarre blend it makes between them
[02:58:35] <jepler> also the blend on the segment after that seems strange ..
[02:59:05] <jepler> both of them seem to be more than .01 away, whether inches or mm
[02:59:50] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/weird-blend-2b.png
[02:59:51] <cradek> looks more like .1 units
[02:59:54] <jepler> (different angle)
[03:00:26] <jepler> I'll update and see if it still looks like that
[03:00:36] <cradek> I don't understand the path, let me run the program
[03:00:41] <cradek> yeah maybe that will help
[03:00:47] <jepler> I don't understand the path either
[03:01:49] <jepler> much better after the update
[03:01:51] <cradek> I get a very believable path on tort2 with your unmodified ini
[03:02:09] <jepler> I wonder if I'd done something to confuse it, or if your change helped
[03:02:27] <cradek> I'll take it out and check
[03:02:51] <jepler> I'm doing that too
[03:03:53] <jepler> it was right even with the change reverted
[03:03:58] <cradek> I agree
[03:04:01] <jepler> assuming I got my usage of 'cvs update -D' right
[03:04:08] <cradek> hmm.
[03:04:18] <jepler> I had issued other g64 p- and at least one g61 p- or g61.1 p-
[03:04:26] <jepler> and modified the file several times
[03:05:18] <jepler> dangit, this was supposed to give repeatability to the testing process
[03:07:08] <cradek> oh I see it
[03:07:13] <cradek> another feed override problem
[03:07:46] <jepler> oh you're right .. I didn't turn my feed rate back up
[03:08:04] <jepler> hooray
[03:08:07] <cradek> feed override sure screws stuff up
[03:08:25] <jepler> yeah I begin to agree with you
[03:08:48] <cradek> well hell
[03:09:17] <jepler> If this program has turned up 2 bugs I feel good about having taken the time
[03:09:52] <cradek> it definitely has
[03:10:10] <SWPadnos> the hard part (or one of them anyway) is that the programmed feedrate can't be considered a constant by the TP
[03:10:22] <jepler> yeah .. it can change at any time
[03:10:29] <cradek> if I leave the FO over 100%, it porks everything
[03:10:32] <jepler> (but in this case the feed override stays at 115% for the whole program)
[03:10:43] <cradek> ok, so you're seeing that too
[03:10:48] <SWPadnos> hmmm, but you can slow down the FO just fine?
[03:11:02] <jepler> SWPadnos: it looks that way, at least for this bug. at 95% it's fine
[03:11:14] <jepler> cradek: so can you find the max FO and do <some calculation> in terms of it? That does suck though
[03:11:16] <SWPadnos> lemme put on my stupid hat for a bit
[03:11:21] <SWPadnos> (oops, it's already on :) )
[03:11:26] <jepler> SWPadnos: ha
[03:11:30] <cradek> no, in this case as soon as you touch FO, even to reduce it, it starts the premature blend
[03:11:54] <jepler> cradek: in this case I wasn't even touching FO
[03:11:59] <jepler> move to 115% and leave there
[03:12:02] <SWPadnos> can you try a very long move, and fiddle with FO during the move?
[03:12:02] <jepler> then run program
[03:12:21] <SWPadnos> hopefully, long enough that there should be no blending while you're fiddling
[03:13:27] <jepler> SWPadnos: that's what I did here. cradek's diagnosis was that when I moved the FO slider it blended the line at that moment instead of when it should have.
http://emergent.unpy.net/index.cgi-files/sandbox/HEAD-funny-blend.png
[03:13:35] <jepler> cradek: I thought you fixed that, though
[03:13:55] <cradek> I did...?
[03:14:01] <jepler> yeah you told me you had
[03:14:08] <jepler> something about not treating something as a constant
[03:14:22] <cradek> seriously, I did fix that one. maybe I just reintroduced it.
[03:14:35] <SWPadnos> hmmm - OK.
[03:14:37] <jepler> that HEAD-funny-blend is the screenshot from the other day
[03:14:50] <jepler> I have to clean the place up before GF gets home .. see you later
[03:14:57] <SWPadnos> I'm booting the emc machine so I can fiddle^Htest here
[03:15:01] <SWPadnos> heh
[03:16:13] <cradek> I bet I made this a *lot* worse when I "fixed" accel
[03:16:23] <cradek> every segment has its very own acceleration now
[03:16:43] <cradek> ok this means I'm going to have to actually understand the problem...
[03:16:47] <SWPadnos> bummer :)
[03:17:18] <SWPadnos> I wish I understood where the trajectory information goes, and on what time scale
[03:17:27] <SWPadnos> I seem to have a mental block on that subject
[03:27:31] <SWPadnos> is it now normal to get a bazillion "Makefile:74: depends/emc/iotask/ioControl.d: No such file or directory" messages on a new build?
[03:27:36] <cradek> yes
[03:27:40] <SWPadnos> ok
[03:27:49] <cradek> it then generates them
[03:27:58] <cradek> unfortunately it's a make "feature"
[03:28:12] <SWPadnos> maybe the check could be quieter ;)
[03:29:17] <SWPadnos> wow - axis is up to ps436. impressive.
[03:43:12] <SWPadnos> tort.ngc is much scarier than I had imagined
[03:45:28] <jepler> SWPadnos: thanks, I think
[03:45:41] <jepler> cradek: I had a patch to fix that, but I was too cowardly to check it in
[03:45:56] <SWPadnos> heh
[03:46:02] <cradek> eh screw that, look at me
[03:46:34] <cradek> just pretend you know what you're doing
[03:46:43] <jepler> actually without generated header files I should take the "include if exists, autogenerate when compiling" approach like the linux kernel
[03:47:07] <jepler> (without built-by-make header files)
[03:50:09] <cradek> ok I have a correct fix I think
[03:51:02] <jepler> yay
[03:52:39] <cradek> thanks a million for your testing
[03:56:26] <SWPadnos> hmmm - it would be good to be able to save axis preview window parameters
[03:56:39] <SWPadnos> (eye, POV, scale ...)
[04:00:50] <SWPadnos> cool. that did fix a weird misblend at 300% FO
[06:17:46] <lilo> [Global Notice] Hi all. One of our main rotation servers is misbehaving. It's back, but dropping users, and has been removed from rotation. We're looking at the issue. Any additional info will be on wallops ( /mode yournick +w )....thanks.
[07:00:34] <SWPadnos> SWPadnos is now known as SWP_Away
[17:04:53] <SWP_Away> SWP_Away is now known as SWPadnos
[19:05:14] <cradek> hi all
[19:05:47] <SWPadnos> hi there
[19:06:12] <SWPadnos> so, I think I hit the "bad cleanup" bug in the run script
[19:06:12] <cradek> 2.1.2.6 in the docs say that while doing arc motion, a rotational axis can also move. Has anyone seen this kind of move or know if anyone uses it? I'm not even sure what the resulting path is.
[19:06:35] <cradek> cool, did you fix it?
[19:06:44] <SWPadnos> npe, I rebooted ;)
[19:06:53] <SWPadnos> I hit it, i didn't find it :)
[19:07:00] <cradek> hmm
[19:07:24] <cradek> if you can reproduce it, might not hurt to file a report or send an email
[19:07:58] <SWPadnos> will do, if I can see similarities in the problem (if I hit it again)
[19:08:16] <SWPadnos> it may have to do with me trying to get a"watch halcmd" going
[19:08:39] <SWPadnos> or there may have been a problem with HAL, that caused watch halcmd ... to fail
[19:08:58] <SWPadnos> There are two types of move that would require circular moves with rotational axes
[19:09:20] <SWPadnos> first, with a rotary table (ie, the workpiece rotates)
[19:09:34] <SWPadnos> consider milling a spiral down the side of a sphere
[19:09:58] <SWPadnos> like milling "pineapples" for a four-poster bed
[19:10:47] <SWPadnos> you want to keep a constant cut depth, so you arc around the workpiece, but you rotate it so that the path corkscrews around
[19:11:10] <SWPadnos> second, with a pivoting head
[19:11:28] <SWPadnos> you cant to make an arc cut in a workpiece, but want to vary the angle of cut
[19:11:46] <cradek> yikes
[19:12:15] <cradek> so would you be surprised by any of the following: 1) this has never worked right and nobody has said anything, 2) it still doesn't work right
[19:12:16] <SWPadnos> oops - want to
[19:12:22] <SWPadnos> nope ;)
[19:12:34] <SWPadnos> I'm just imagining places where it migh be useful
[19:12:47] <SWPadnos> not places where it's a) common or b) necessary
[19:12:50] <cradek> 3) it seems hard to get right so I feel like just disallowing it instead
[19:13:32] <SWPadnos> hmmm
[19:13:45] <cradek> either that or I need someone else to look at it
[19:13:56] <cradek> the problem is in task, not tp - tp has no problem with this kind of motion
[19:14:02] <SWPadnos> if the spec doesn't prohibit it, then I think it should be left in, even if it doesn't work right
[19:14:11] <cradek> the spec specifically allows it.
[19:14:35] <SWPadnos> ok, then I definitely wouldn't disallow it, unless the idea is to print an error because it doesn't work right yet
[19:14:46] <SWPadnos> that error should be printed before machining starts though
[19:14:49] <cradek> well if a case doesn't work, popping up an error seems better than doing something crazy or getting a following error.
[19:15:07] <cradek> yeah that's the idea
[19:15:11] <cradek> but I agree it would be better to fix it.
[19:15:17] <SWPadnos> ok, then that's fine with me
[19:15:26] <SWPadnos> not that that really matters ;)
[19:16:20] <cradek> the problem is figuring out the appropriate accel/vel for the motion
[19:16:37] <cradek> the accel/vel have to be such that the rotary axis doesn't violate its constraints
[19:16:47] <SWPadnos> yeah, feedrates are indeterminate without extra machine configuration information
[19:16:59] <SWPadnos> and tool length
[19:17:00] <cradek> well, the docs say exactly what should happen
[19:17:12] <cradek> that's the only thing I intend to make work
[19:17:21] <cradek> (already did for linear moves)
[19:17:32] <SWPadnos> heh, makes sense to me, though I haven't read the docs recently
[19:19:11] <cradek> for coordinated linear/rotary moves, the feed rate specifies the feed for the linear part, and the rotary moves such that it starts and stops at the same time, with the additional requirement that the rotary axis maxvel/accel are honored (which just may slow down the whole move)
[19:19:22] <SWPadnos> ah, OK
[19:19:36] <cradek> btw an arc/helix is a "linear" move
[19:19:49] <cradek> so, we know the rule, I just can't figure out the math
[19:19:52] <SWPadnos> of course, who could have thought otherwise
[19:20:31] <cradek> well it makes sense to me. not knowing the geometry, I think this spec is pretty much what you want
[19:20:51] <SWPadnos> well, take the total time to complete the linear move, and the total time required to complete the rotary move (assuming top accel and vel), then use the lower of the two
[19:21:21] <cradek> you don't have control over time, just a vel and accel setting for the motion
[19:21:25] <SWPadnos> and scale the other by the ratio
[19:21:39] <SWPadnos> but you can calculate the minimum time needed (I think)
[19:22:12] <cradek> care to take a shot at it?
[19:22:24] <SWPadnos> not this minute, but I may later
[19:22:32] <cradek> I'm not being snide, I'm just sort of hung up on it
[19:23:01] <cradek> it's ARC_FEED() in emc/task/emccanon.cc
[19:23:23] <SWPadnos> I didn't take it badly, I just need to get moving on some other stuff today
[19:23:37] <SWPadnos> ok - I'll write that down so I have a chance of remembering
[19:24:03] <SWPadnos> I added thread execution time and max time to halcmd show thread output today. I'll commit that soon
[19:24:11] <cradek> cool
[19:24:33] <SWPadnos> the max # of cycles in servo-thread was around 150k
[19:24:38] <SWPadnos> running tort.ngc
[19:24:47] <SWPadnos> and fiddling with FO
[19:25:35] <cradek> so at 500MHz I guess that's 300usec
[19:25:38] <SWPadnos> luckily, all I had to do was change one printf, the calcs were already there
[19:25:40] <SWPadnos> yep
[19:26:56] <SWPadnos> oh, how I love copying 100MB files to flash drives over USB 1.1
[19:27:50] <cradek> get a network!
[19:29:21] <SWPadnos> It would have been faster to plug that in ;)
[19:30:20] <SWPadnos> I guess I should also think about getting computers that have USB2 (which my primar ydesktop and laptop both lack)
[19:37:45] <SWPadnos> SWPadnos is now known as SWP_Away
[20:55:24] <lilo> [Global Notice] Hi all. We just experienced a routing outage on a main rotation server. We're moving it out of main rotation and substituting other resources. You'll see people pinging out and coming back. Apologies for the inconvenience.
[20:55:59] <lilo> [Global Notice] We'll provide further information on wallops ( /mode yournick +w ) and if needed another global notice later. Thanks.
