Lerneaen_Hydra: I just have a minute to talk, but I wanted to ask you about G76, the threading canned cycle
the only one really documented on the wiki page is the Fanuc and it's crazy, I don't want to use it
some numbers in the gcode have implied decimal points and others don't
do you know if there is a more sane one that we can use?
I've modified emc2 so that the kinematics can be selected by name when motmod is loaded. But it looks like the nontrivial kinematics (e.g., genhexkins) actually have to be modified to match the geometry of the machine.
is there any point in checking in this change?
that is, the source code has to be modified
I'd say that it should be checked in, if it doesn't disrupt existing configs
(ie, like you must specify kinematics, which would break any existing configs)
no, it defaults to "trivial"
ok. in that case, I'd say it's an excellent first step toward user-created kins
another good one, though not required, would be some sort of method to make user modules, without needing to rebuild all of axis (similar to the way you can build a kernel module out-of-tree)
err - emc, not axis (not enough caffeine)
yes, I understand
right now, this still links all the available kinematics into motmod at compile time -- you just get to choose which one gets called
ah - ok
so you more or less made an array of function pointers, and select which group gets used?
hmmm - as a side note, do you know how to load multiple shared libraries that have functions with the same name?
(like init or cleanup ...)
I would have guessed that it would work OK as long as you don't use dlopen(... | RTLD_GLOBAL )
it may be - I was thinking about userspace HAL modules, and run-time linking
this program loads two shared libraries and calls the function 'f' in each one: http://emergent.unpy.net/files/sandbox/multi.tar.gz
err -thanks ;)
it was not much work
as you'll se
heck, the tar is 650 bytes
I was wondering if you had gotten curious enough to try it
I'm booting a Linux machine so I can mess with it
that could be a way to get a userspace HAL working
* jepler tries to figure out a way that kinematics could be a separate module, but without the module loaded it would default to trivial.
jepler: does the emc1 tp look much better than what you had done?
skunkworks: I don't know about the new planner in bdi4emc. the emc1 planner was terrible -- it frequently disobeyed machine constraints.
skunkworks: based on the graph posed by matt t. last week it looks like it does a bit better at keeping the velocity up when contouring, but I have no way of knowing if it actually obeys machine constraints or not.
skunkworks: I looked at emc1's quickstep driver and it looks like that driver will respect machine acceleration and velocity limits, but not by giving a following error. it just tries to get to the commanded position as fast as it can.
jepler - how about loading a specified kins modulle, or pointing at (a) built-in functions or (b) loading trivkins if nothing is specified
but again, I don't run the version of emc on bdi so this is speculation based only on reading the source code
SWPadnos: if it was OK to break all the .hal files I would require the user 'loadrt trivkins' and then just let the kernel's dynamic linking take care of it.
though trivkins is a no-op, right?
ie - the ioutput coordinates are identical to the input coordinates, though they are a copy
can it work if you replace the fwd and rev kins fcuntions with function pointers, and just default them to the trivkins functions (suitably renamed, of course)
if a module is loaded, change the pointers
it's also probably not too much overhead to make the kins functions into wrappers (as you've probably done already), and do something like if (!module_loaded) deafult_kins_func()
sorry to spam the channel with that
for some reason, /msg logger_devel help won't give the same text
[15:59:25] <jepler> http://emergent.unpy.net/files/sandbox/newspeed2.png
3 graphs of velocity vs time, with the horizontal scales approximately the same
(2 seconds per div in the halscope photos)
the recent improvement (to use full accel instead of half accel in many cases during contouring) makes a big difference
from top to bottom: emc2 with merging and accel fix, p.03. emc2 without accel fix, p.03. bdi4emc, e.03
I wonder what the scale is on the BDI plot
and how high that last vel mag peak actually is, since it goes off the top of the chart
I don't know much about the plot from bdi4emc
it's hard to say which is better without more data, but they sure look comparable to my eye
though the emc2 plots look less ragged
at least the first one does ;)
I think the 2006-06-19 plot looks the best, 2006-06-12 looks the worst
yeah there's a big improvement between 12 and 19
bdi4emc looks in between the two
although on -19 there is some vel variation at cruise that bdi4emc doesn't have
yeah, but I think there's some unknown amount of smoothing in the bdi4emc plot
what's the vertical resolution on the emc2 plots?
but bdi4emc has much lower spikes
SWPadnos: 1 inch/sec/div
the top machine speed is 72 ipm, or 1.2 (?) ips
the commanded speed is 1000mm/minute, or .656 in/sec
I'm pretty sure the emc2 -19 plot shows it finishing in less time than bdi4 but with the horizontal scaling I had to do I'm not sure
but they're within a few %
where is the g-code for this? (I thought Matt T had sent it to the list)
I can't decide if this is useful or if it's a pissing contest
ah = ok ;)
yeah, I should probably leave bdi4emc out of it
but I did want to show that emc2 improved compared to when I posted my graphs
well, if it results in smoother motion, and/or a "better" TP, then it's more than a pissing contest
I'm sad that we've duplicated so much work and that we have a disparate set of features because of it
yeah - the e.03 vs p.03 acutally makes the interps incompatible
yes, and gratuitiously so
matt T suggested in an email that paul use the same format we did when he put that in, but he didn't choose to
ah - well that would have been nice
cradek: can you remember what test we were doing when I decided to increase the number of mergeable segments from 100 to 1000?
the crazy file from skunkworks?
oh, I know--it was the 4000-line 2-inch parabola file
we were just talking about you
11:22:51 <jepler> cradek: can you remember what test we were doing when I decided to increase the number of mergeable segments from 100 to 1000?
11:23:31 <cradek> the crazy file from skunkworks?
I do what I can :)
I am glad it had a use.
Lerneaen_Hydra: yell if you're around, I want to bother you about lathes some more
I'm trying to figure out how to do cutter comp for lathes
right now you can only do cutter comp in XY
I can't decide whether I should allow XZ as well (and specify it in the ini file) or generalize it somehow, maybe basing it on the active plane
the problem is the algorithm is going to end up different because of tool shape issues
I'm tempted to use the active plane, but that has the potential of breaking existing gcode programs
currently the plane is only used for arcs
you can set plane to XZ to do an arc, then leave it there and do cutter comp (which comps in just XY)
are you sure?
as long as you comp just lines
so if you do an arc, it doesn't get comped (which is going to do something screwy I think)
the documentation says it's an error if the XY plane is not selected when you program G41 or G42
see page 119 of http://linuxcnc.org/EMC2_User_Manual.pdf
that text is almost certainly the same as the old NIST document
CHK((settings->plane != CANON_PLANE_XY),
I didn't see it
so I would break that
you'd make some formerly improper programs valid
that's just fine
still this is just half the issue, the tool table has to be different
that I can't help you with
well maybe I can just add optional columns to it
yeah maybe that's the ticket
clearly you should be using xml
ok the new restriction is you can't switch to a different plane with comp on
that lets you still program G_17 (xy) with comp on, which you could do before
sounds like a plan
hmm, do left and right comp make sense on a lathe?
say you're cutting on the outside
whether you cut in +z or -z, you'll want to be +x of the work
but that's either "left" or "right" depending on which way Z goes
if you're boring, it's the opposite way but the problem is the same
I guess a lathe program is usually not going to cut back and forth, it will cut in one direction
I bet it should have been an error to switch out of g17 during compensation
I think it was
but you could program the current plane during comp (which I'm still allowing)
at first I thought I should disallow g17/18/19 during comp, but that'll break old programs
cursed inverse time feed rates
yoohoo? cradek= I'm here now ;)
yes, the fanuc spec is rather... non-intuitive, to say the least
I prefer the siemens one (I only know of EMCO's bastardised version, which will no doubt need changes as it doesn't allow an angled thread exit)
I'm doing radius comp now, but I want to tackle g76 soon
can you figure out the sanest g76 and document it on that same page for me?
g67? whatever it is
It uses the format of (IIRC) CYCLE97(parameters)
so changing it to a gcode is probably good
it would be nice if it were something cam software can put out
or do they just use g33?
as for the actual way the parameters are lined up, it sucks. It's probably best to make something from scratch
my cam software can either do g33 or canne
if I enter how it's made
there's no sane existing canned threading cycle??
as for the spec, as long as you have all these parameters, it should be good: pitch, speed (rpm/css), approach/retreat angle, lead in/out (typically specified as n counts of pitch, ie a pitch of 3 and lead in of 2 would give a lead in of 6 units), degression factor (1.0 for constant chip volume, 0.0 for constant increment, possibly other values inbetween for a blended result), total depth,...
...outer diameter, cut increment, number of passes, final increment, start depth, and spring cuts,
not that I know of, unfortunately
I'm not sure if heidenhein has a good one
cradek: IRT cutter compensation, EMC needs to support all the nine cutter positions to be competive with commercial systems, though some are rarely used they are still valid (I think I've used them all except 1 and 5)
so you don't think it matters how I define g76?
no, not really
I'm sending a mail with descriptions about the different things to your mail, is that ok? the cradek at users.sourceforge.net one?
can you put it on the wiki page instead please?
I'm still crossing my fingers hoping for some help on some of this, I want to keep it all public
It'll be messy though
any suitable page?
a new one maybe? or on the end of the previous page you made?
I'll append it
cradek: any thoughts?
sorry, I'm back now
wow that's a lot of stuff
darn, I bet you're gone for the night
still here for a little while
but now cradek is gone... haha
huh. I'm comparing the behavior of the "greedy" and "douglas" methods of removing trajectory points based on a distance comparison, and to my surprise "greedy" does better (has fewer output points) on my first input data
74 output points from 1000, instead of 114 output points
8488 distance computations instead of 8167
jepler: do you know if cradek left?
* Lerneaen_Hydra pokes cradek
Lerneaen_Hydra: no idea
now I have more questions about radius comp
oh, ok. shoot
if I am turning (not boring) and I cut in +z, the comp is "right" but if I do the same cut in -z the comp is "left"
is this normal, or is there "outside" (turning) and "inside" (boring) comp?
what do you mean by "cut in z+"
from z0 to z1 for instance
uh, I'll do a quick image
g41/42 are right/left now, I just wonder if lathes do the same thing
if so it seems strange
it's not the same
Im adding it to the wiki
hmm, now I'm starting to become uncertain...
[22:24:12] <Lerneaen_Hydra> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Lathe_Advanced_Features
this is IIRC
oh good!! that's how it works
ok I'm starting to think I can make it work
yes very clear with the picture
yes I thought it would be easier to understand with it
heh, that page is starting to get a bit big. think that something should be done about it if it gets a lot bigger?
oh -- there was a bug in the "greedy" version as I rewrote it for my test program
now they give a much more similar number of output points
Lerneaen_Hydra: I'm not too worried about that
on my simple test, "douglas" now gives many fewer
jepler: what is this program you are talking about?
Lerneaen_Hydra: when turning a continuous function (or even a discontinuous but high-resolution function) into a series of linear movements for machining, you have to chose which points on the function you'll touch
oh, becuase of accel/deccel?
oh, no, now I get it
can emc read in functions?
as in f(x)=sin(x) etc etc?
ignore that for now
you want to mill some surface, and your g-code came from a very dumb program that outputs scans in X separated by .001 inch: "G0 X1.001 Z???" "G0 X1.002 Z???"
you want to simplify that path into a similar path, but without going more than .003 inches away from the original one
oh, ok. like a form/function that's not straight or circular
ooh, sounds nice
is it an external app or something in emc?
I've now implemented two different methods. One, which I call "greedy" is in emc2 HEAD and enabled when you program G64 Pnnn
oh, it stays within the g64 tolerance?
it works by moving to the first point specified, and then gathering up points. Each time, it checks the distance from the intermediate points to the next point. If it's over the tolerance, then it actually moves to the previous point (because that's within the P-distance) and starts over again
I call it "greedy" because it makes its decision about a point as soon as it gets it, this is a comp sci term that I may be slightly misusing
oh, that sounds like it could be very cpu intensive for small values of P
the other method is called "douglas" after the person who discovered it. It's recursive: start with all the points, then find the one that is farthest away from the line drawn from the first one to the last one. If it's further away than tolerance, then divide the problem in two, with the points on either "side" (before and after) the furthest-away one
if the point isn't further than tolerance, then you're done (with this portion of the problem, anyway)
oh, that sounds more efficient
it seems to depend on the data
for a simple function, greedy makes fewer comparisons and outputs more points
er, makes more comparisons and outputs more points
for 3d_chips, douglas makes more comparisons but outputs fewer points
it's not entirely clear why, but it seems like each one is better in some cases
cradek: I'm going to go soon, but was there anything else you were unsure of?
thanks again for all your help
sure, I'm glad to help
except for it working completely wrong, compensation in XZ is done :-)
it shouldn't be that hard to adjust, right?
simple matter of programming
okay, goodnight then
sounds like you and jeff are both quite busy
yeah I guess so
I took vacation and programmed most of today, which was nice
I have a lot of vacation to burn this month before it renews