Post by Cliff HuprichPost by Kirk GordonYou're wrong, wronger, and wrongest, Cliff. Where do you get these
ideas?
Years of real world shop programming?
On what world, exactly?
Post by Cliff HuprichPost by Kirk GordonI decide which kinds of motion need linear acceleration
characteristics, and which should be exponential, and how to set
the DIFFERENT parameters that go with rapid and feed moves,
precisely for the purpose of making the machine go as quick as
possible without beating itself to death.
And you would beat them to death with G01 Fxxxx?
Here's the facts and details. You can think what you like.
The grinder model that I build most often will rapid (G0) at 600IPM,
or 10 inches per second. It typically has a linear accel/decel profile,
with a time constant set at 150ms. To get from sitting still to 10 IPS
in just .15 seconds means an acceleration of 10/.15, or 66.6667 inches
per second per second.
This same machine has a maximum useful cutting feedrate between 20
and 30 IPM. That has nothing to do with the machine design, really.
It's just what grinding wheels and typical materials need in order to
work best. The machine needs to be extremely accurate, and to make VERY
smooth and neat transitions from one cutting move to the next. I set
the maximum G1 cutting rate at 80 IPM, and use linear accel/decel mode
with a time constant of 20ms. 80 IPM is 1.3333 inches per second, so to
get to that speed from a standstill in .02 seconds means an acceleration
of 1.333/.02, or 66.6667 inches per second per second.
Neat how they both work out the same, huh? That makes it real easy
to choose the right size ballscrews and servo motors.
If I were to attempt a rapid move with G1 (assuming I set the max
allowed feedrate at something fairly quick), then the G1 accel/decel
type and time constant would be applied to whatever feedrate was
programmed. Let's say, just to be conservative, that I choose only half
of the normal rapid rate, and program G1 F300.0. 300 IPM is 5 inches
per second. To get to that speed in just .02 seconds would mean an
acceleration of 250 inches per second per second - nearly four times
more than a G0 move would require, even though the machine is only
moving half as fast. That means four times as much force on the
ballscrew, and the thrust bearing, and the brackets and fasteners that
support those things. It also means four times more strength required
in the places where all the moving stuff is mounted, and where the
rigidity of the machine is realized.
Of course, I COULD set a softer accel/decel for the feed moves, but
then there's that little problem of grinding workpieces properly, and of
getting the smooth and precise transitions I want between moves. My
customers, for some reason, seem to think that those things are important.
Under the circumstances described above, even with the G1 "rapid"
moves going just half as fast as real rapid moves, some serious,
precise, and expensive parts of the machine would need to be AT LEAST
four times stronger than with G0 rapids.
With regard to whether the machine would beat itself to death,
consider this: I normally plan a safety margin of about 100% into the
kind of mechanical things we're talking about here. If you used G1 for
300 IPM rapid moves, you'd eat up all of that safety margin, and STILL
be creating DOUBLE the worst case forces that critical machine
components have been designed for. And if you tried to use ALL of the
600 IPM rapid speed, so your cycles didn't slow down, then you'd exceed
the machine's maximum, worst case design parameters by a factor of 300%.
Yes, I could build the machine to withstand that. All I'd need would
be bigger ballscrews, and bigger thrust bearings, and bigger, heavier
mountings for both, and bigger castings and bases to accomodate the
other oversize stuff. Then I'd need bigger servo motors to deliver the
bigger accelerations, and bigger drives to run the bigger servos. And,
since everyting about the mechanical part of the machine has gotten
bigger and heavier, the new motors will need to be MORE than 4 times as
powerful as the old ones. Maybe 5 or 6 times, before I'm finished with
all the new engineering, and finished adding new safety margins.
And when all that's done, I'll only have to charge another $10,000 or
$20,000 for my machines, and everybody will be happy.
Or, just in case my customers have something better to do with $10 or
$20 thousand dollars of their money, I can leave the design like it is,
and use rapid moves for rapid, and feed moves for cutting, and promote
the idea that foolish, short-sighted, half-assed programming techniques
are not a good idea.
Post by Cliff HuprichPost by Kirk GordonAnd your question about how/why there'd be too many feedrates to
edit tells me that you haven't actually done what you're suggesting
to the person who asked the original question.
Do they have a mill or a lathe or a .....? And YOU are thinking ONLY
of MDI programming, ala jb.
The problems, and the most basic of sound procedures, apply to any
machine, and to any programming method.
Post by Cliff HuprichYou have a lot of such dogleg issues with your lathes?
Everybody does. It's called "programming". You move around the
tailstock, and you watch out for chuck jaws, and you try not to drag a
grooving tool sideways through the work at rapid speeds on your way out
of a groove, and little stuff like that. Machining centers are even
more interesting. There's more axes to move, and more stuff to watch
out for, and a wider range of tool types with different lengths and
diameters, and... You really ought to try this stuff, Cliff. It's
loads of fun.
Post by Cliff HuprichPost by Kirk GordonI'm assuming, incidentally, that the machine in question actually
HAS the capacity use G94/G95. Not all do. If you attempted to use
IPR throughout the program, then the G1 rapid moves would be a
nightmare. You'd either have to set a constant RPM and calculate
some chip load that would give you the motion speed you wanted, or
you'd have to deal with the servos moving slowly at large
diameters, and attempting IMMENSE speeds when the tool got close to
center.
Postprocessor functions ...
I don't care if you use a post processor, a food processor, or just a
wild guess. Constant surface speed control is an IMPORTANT feature on
almost any lathe. If you have to program constant revs, then you're
limiting your machine in some serious ways that affect efficiency, tool
life, workpiece finish and quality, and more. Or, if you happen to have
G94/G95 functions available, then you're going to have programs that are
harder to read when they appear on the operator's screen in the shop.
And they'll be harder to proof, and harder to optimize, and harder to
maintain. And that makes no sense!
And, when you suggest that a postprocessor is the answer to the
questions involved here, you confess some VERY strange ideas about good
shop practice. You don't seem to mind that EVERY rapid line in a whole
program, and EVERY cutting line in a whole program, would need to have a
feedrate specified, and re-specified, in order to keep switching back
and forth from G1 cutting moves to G1 rapid moves. And you seem to
think that editing such a program is for the CAM system to worry about,
and not an issue for actual human beings. That's nonsense.
Think about this little example. The programmer uses the CAM system
to spit out, say, a couple hundred lines of code for the VMC. The
operator sets it up, proofs the program, cuts the first part, and then
takes it to the inspection room to get it blessed. Then, all that
remains is a little bit of tweaking with speeds and feeds, just to get
the finishes right, and to make the tools last a long time, and to cut a
little fat out of the cycle time. If you do things my way, that
probably means shop-floor, MDI editing of a single feedrate at the top
of each tool's operation. If we do things your way, it means many, MANY
lines of code that have F numbers in them, that all have to be changed -
without mistakes - just to optimize a single tool's operation. Should
we REALLY take this back to the programming room, and have them send us
a whole new piece of code? Or would it make more sense for operators to
get it all dialed in just once, easily and quickly, and then send the
optimized stuff back to the programmers for storage and future use?
And what if it takes a couple tries to get things right? What if the
operator wants to experiment with the feedrates, before he settles in to
let things run production? Does the whole thing get reprogrammed every
single time? Not in my shop it doesn't.
Of course, we're talking about a program that's already fit to run,
and that's been proofed and found to be free of serious problems. But
how did we get to that point? Well, we loaded up the program, and set
all the offsets, and then carefully stepped through the program with the
rapid over-ride switch turned down to... Oh. Waitaminute. The rapid
over-ride only works on G0 moves; and we aren't using those. And the
feedrate over-ride dial now controls everything, so we'll be cranking
that way to the left for every "rapid" move we want to watch carefully,
and then cranking it back where it belongs when it's time to cut
something, and then hoping we can actually tell the difference between
what's supposed to be fast and what's supposed to be slow, when we're
manually juggling every move in the whole damned program. You don't
like MDI editing, Cliff? Then you're really gonna HATE full manual
feedrate control, every time somebody tries to proof a brand new
program. And it'll be especially fun when somebody loses his rhythm and
cranks the dial the wrong way at just the wrong time.
Post by Cliff HuprichPost by Kirk GordonThis wouldn't be as much of a problem on a machining center, where
most feedrates are in IPM anyway; but machining center programs are
generally MUCH more complex than the silly little thing shown
above, and there's be feedrates in practically every other line!
Jesus!
Never done much CAD/CAM programming?
The front-end software on my grinders IS a CAM system. I wrote it.
I've used other, standard systems; but I don't claim to be an expert
with any of those. The issue here isn't where the programs come from;
but what they look like, and how they act, when you load them into a
real machine tool.
Post by Cliff HuprichPost by Kirk GordonSo, the right way to answer the original question is to learn sound
procedures, or proper parameter settings, so that G0 is a real and
useful part of the programms.
Good programming practices always matter .... in part because you
don't always know what machine xyz you have never seen before will
actually do today ... Knowing machine xyz allows you to write or
configure a good post for it.
If your main concern is to configure a post, rather than to use good
all-around methods, and to put good programs in your machines and make
good parts, then you're already pointed in exactly the wrong direction;
and I wouldn't let you in my shop even to sweep the floors.
KG
--
I'm sick of spam.
The 2 in my address doesn't belong there.
