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