cradek: any more fallout from the merge of nineaxis?
steves_logging is now known as steve_stallings
.. just more interest in finding solutions for more complex situations like velocity compensation for rotary and compensation for stretched wire (EDM, foam) machines
rotary velocity is computable if you know the center of rotation, so why not make it easier to find the center of rotation
we could define a new type of "offset" setting G code that would allow the program to move to a known place with respect to the center of rotation, and then specify the actual location with paramaters
thereafter velocity comensation could take in to account actual cutting velocity produced by rotary motion until such time as the comp was cancelled
cradek: here's one -- it looks like old .var files don't work if they don't specify the UVW coordinates of each coordinate system
emc/task/emctask.cc 312: interp_error: Required parameter missing
steve_stallings: that seems like a tough problem to solve for general machines..
jepler: yes, that's mostly why I sent that mail warning about var files
cradek: oh you did?
well I probably hid that important information in paragraph 17
it would be nice if emc was more forgiving about the .var file
you know how I like to hear myself type
click - click - clickity click.
the rotary solution is not machine dependent so long as ABC rotate about XYZ as defined in normal manner
machine geometry does not need to be known, only distance from imaginary center of rotation and the tool tip, and that is specified by the programmer using the offset G code
steve_stallings: I can see the easy solution if there's one rotary, but I'm not seeing it for three because I don't see where the "center" is anymore
oh maybe I see what you mean
do we allow more than one rotary axis to move at a time?
throw TLO into the mess and it gets evil fast
oh sure, all 9 axes are coordinated
I understand that people who do 5 axis machining use inverse time mode exclusively - maybe the XYZA configuration is really the only important one to worry about
oops, I missed the obvious, if a rotary motion moves the cutter head instead of the workpiece, then the motion affects more than one linear axis
I suspect people with XYZA machines often just index with A, so this doesn't matter
I think handling XYZA, XYZB, and XYZC, each allowing only a single rotary axis that moves the workpiece, would be a worthwhile improvement
XYZA setups are used for lots of things more complex than indexing, like cutting cams, spiral groves, etc.
do you have a current project/application/customer where this is a problem or is it just ugly that it's the way it is?
sure I'm not saying that it's only for indexing, just that I think it's probably most common
who me, I don't actually cut anything.... 8-)
I am not trying to be difficult, I just wondered because I don't recall any users asking about this
people must be trying combined motion moves, else we would not have heard about the issues
I don't follow
it works as defined in ngc, and it only came up because I explained how it works on the list again
I want to be able to do this type of machining some day. http://www.youtube.com/watch?v=EdWWvnrFA9k
does the current planner properly handle a combined move with a very short linear move and a 180 degree rotary without overspeeding the rotary?
steve_stallings: yes that stuff is 100% right
guessing at method.... evaluate time to make XYZ move and time to make rotary moves, then scale to match slower of the two?
yes something like that
those combined moves used to be terribly buggy but I fixed them all in early '06
OK, I am still remember old problems that cause rotary to attempt impossibly fast motion when linear was short move
yep I remember that too
cradek worked his magic. :)
and there were problems with acceleration being too slow (because it was in degrees or something)
rotaries in old EMC1 really worked pretty badly
but now you can g0 x.001 a90 b180 c270 and get a perfectly sane move
but now you can g0 x.001 y.002 z.003 a90 b180 c270 u1 v2 w3 and get a perfectly sane move
great, sorry for the confusion
nah, no problem
maybe you just haven't used emc much lately
so, if you add an F(eedrate) parameter to the above moves, what is it based on?
my EMC usage is pretty much limited to jogging, need more time, need more time...
^^ I described the F word behavior here
in both of the above moves F is in linear units per minute along the cartesian XYZ move, but it's probably going to be limited by C's motion
(if you were a g1 and you were cutting, you'd probably want to be using inverse time mode)
so the max axis velocity of the rotary axis will slow a linear move if the linear feedrate would exceed the max velocity of the rotary axis, but otherwise the influence of rotary motion on the tool tip speed is ignored
that's what NGC says to do, fwiw
so controlling cutting tip speed during rotary motion is still something that must be controlled by inverse time or fudged linear feed rates
well, not exactly
rotary ONLY motion has degrees/minute feed
but for combined moves, yeah inverse time mode is your friend
the fudging would be no fun - very finicky for combining short linear with long rotary moves
OK, so my idea still has merit, but there is less of a need for it than I thought
yeah I would like for it to work better
Does the ngc pdf have a good explaination how inverse time works?
* skunkworks has never used it.
skunkworks: the idea is you tell it how long the move should take, whatever the move happens to do
now ask if any affordable CAM system provides computations for inverse time mode
what is an affordable CAM system? I've never heard of this
ah - that is easy.
actually I bet there is CAM between hobby and pro grade, that just barely handles greater than 3D...
steve_stallings: have you done any 5 axis cam/cutting?
cnczone would be a place to look.. They pretty much have a forum for all the cam software.
the two lower dollar cam packages I've heard about are synergy and bobcad, and I've not used either but I've heard reports for both ranging from "ok" to "terrible"
no, only watched a machine
I have the rotary axis option for Vector, but it is pretty limited
steve_stallings: me too, and talked to the programmer a bit
steve_stallings: (... and pined for a machine like that)
configuration must be A as trunion on table, and B as tilting head
even then things are handled as imaginary planes, not full 3D
that's not particularly common is it?
the machines I've seen (in person and youtube) had the head doing both rotaries, or the table doing both
I would guess that A on table, B on head is one of the top three configurations
RAB uses it for his Taig
and I have seen it on retrofitted knee mills
since I'll probably never spend money on modern CAM, maybe I should suck it up and learn APT
ah, I just realized that my offset scheme can work with the cutting head in motion, the offset just becomes the distance from the tool tip to the pivot point
now planning the moves is still mucho complex in that mode
I really hope RAB does eventually move his toolkit into a plugin for Rhino
the lathe CSS requires that the absolute homed 0 position of the X axis (without TLO) is the center of rotation of the work. seems like a similar requirement/simplification could be made with your scheme, but I don't quite see it
with XYZA I can sort of see it, you'd home Y and Z so they give the tooltip at the center of A's rotation
but for 5 axis I'm lost
OK, for XYZA first, homing to center of A rotation is not practical due to interference, so you home a known distance away and provide an offset to the imaginary center
well you can set 0 anywhere, even if you can't move there, homing is flexible
so I think that's not a problem
and I don't like the use of the term home, as I prefer a co-ordinate system shift, semantics I guess
or looking at it another way, the offset you are talking about is just the homing parameter
well homing an axis means a certain thing: setting 0 at a certain place in the axis's motion - I agree anything else is semantics
normally velocity is the square root of the sum of the squares of X, Y, and Z velocity
if we add a fourth term as the velocity of the tool tip caused by the rotation we get an approximation that should be usable, though not mathematically prefect
the fourth term would be based on the distance of the tool tip from the center of rotation as computed using the imaginary center and any Y or Z motion (assuming A axis imaginary center)
skunkworks is now known as whoami
whoami is now known as skunkworks