Post by Chris RadekYou jump right to the hard questions Jon!
This is the same old problem with G94 (feed in units per minute) mode
being inappropriate when EMC doesn't know what axis motion corresponds
to a "unit" (inch or mm) on the part.
Yeah, I figured.
Post by Chris RadekAs you already know RS274NGC says for coordinated motion for linear
and rotary axes together using G94 mode, the F rate is units per
minute in the cartesian (XYZ) axes only, and the rotary (ABC) axes
move so as to start and stop in a coordinated fashion. For one thing
this means that if the rotary is slow, the cartesian move is slowed
down to stay coordinated with it.
I've done the same thing for UVW and I'll try to describe it as
If any of XYZ are moving, F is units per minute in the XYZ
cartesian system, and all other axes (UVWABC) move so as to start
and stop in a coordinated fashion.
If any of UVW are moving, F is units per minute in the UVW
cartesian system, and all other axes (ABC) move so as to start and
stop in a coordinated fashion.
The move is pure rotary motion and the F word is in rotary units
instead of linear, in the ABC (pseudo)cartesian system, as
http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_32a.html#1010695
OK, this is pretty much as before, just with added linear
coords. What do other manufacturers do for this? We also have
the inverse-time programming, if people need this. It all comes
down to what the CAM system needs to know about the job.
Post by Chris RadekI feel like G94 (feed in units per minute) only really makes intuitive
sense when moving in just one cartesian system. All other types of
(cutting) motion ought to be programmed in G93 (inverse time mode),
and I've been told that this is standard practice. But that being
said, this seemed like a sensible behavior for G94 mode.
Yes, I suppose. The only place I think it might make sense to
do more (and I think it would have to be an option, because it
could get in the way, especially if contrary to industry
practice) would be with the addition of one rotary axis to XYZ.
If the system were defined such that an A axis would be used
where Y=0 and Z=0 would be on the axis of the A, then the
control knows everything it needs to compute tool-center
velocity in 4 axes. For complex surface profiling on a round
part, this could handle the correct feedrate. This would allow
someone to write a fairly simple code to convert some data set
to a toolpath, and let the control handle the feedrate. Maybe
this would be a bad idea, anyway, as there are certain cases
like the side of the cutting tool coming up against a wall that
would need to be dealt with by reducing the feedrate. So, maybe
it is just better to FORCE the user to deal with this at the CAM
stage.
I suppose one other possible case is ALMOST covered by your
above rules, and shouldn't be hard to extend. For a 4-axis
XY UV system, you could program it where the UV velocity was
higher than the XY velocity. (Cutting a cone with the point up
in wire-EDM, for instance.) It might be nice to have a mode
where XYZ and UVW velocities are both computed, and the highest
one limits the feedrate. If I understand what you wrote above,
if the UVW rate exceeds the XYZ rate, the XYZ will still be the
one that controls the machine, as long as there is SOME movement
of the XYZ. This could cause discontinuities in the feedrate
where the UVW is in continuous motion, but the XYZ is sometimes
moving and sometimes not. I can imagine parts where that would
happen. Imagine the point-up cone again, where the hole at the
top of the work is REALLY small, but the XY is moving just a
little. It might be hard to set reasonable feedrates for the XY
to get the feed you want on UV. Of course, inverse-time will
fix it, so maybe that is OK, whenever mixing XY and UV, you just
do EVERYTHING by inverse-time to avoid the feedrate jumping around.
Jon