Is G-code a good enough output from CAM?

I'm new to CNC machining (although I've done some manual milling on a small machine and done some prototype work with Solid Edge and Pro/DESKTOP). But CAM and G-code are new areas to me.

CAM seems according to most sources to be the process of producing G-code out of a part drawing. But to be able to produce a sensible tool path, wouldn't one need to know a lot about the actual machine and tool combination, like: can the machine handle climb milling, what's its maximum acceleration, what's the maximum spindle speed and machine feed rate, how deep a cut is possible, etc.? So generated G-code is specific to a certain machine?


On the whole, I guess path planning comes down to a compromise between surface speed and chip load, given the machine's characteristics; acceleration limitations, velocity and spindle speeds etc. (?)

Think about a finishing cut going around a corner of small (but nonzero) radius: to keep the chip load up, one would need to either accelerate sharply or lower the spindle speed around the corner.

Or, again, think about a radial finishing cut along an edge. To keep the chip load up the feed rate would need to be very high (due to the small radial engagement). (If the machine can't keep up, what would be the best strategy: to lower the chip load, or to lower the surface speed?)


When produced by a CAM program, G-code looks sort of like a lossy compatibility layer (between drawing and machine) to me. Am I missing something, or is this actually the case (due perhaps to a lack of other/better standards)?

With "G-code-less" CAM directly in the machine controller, one would perhaps not need things like the "naive CAM detector", feedrate & spindle override, G61/G64 path control etc.? Is this how it works in larger commercial machines?

Yes

Yes

Yes (if the machines acceleration rates are to low, such that it could not accel/decel from the feed rate to 0 within the radius of the tool used. if the machine is fast enough to do this then, no.)

I don't completely follow this question. But if the machine can't keep up something must slow down.

Yes, there can be some loss, but you get this anytime you convert data from one form to another. If properly configured any data loss should be significantly lower than your machines accuracy capabilities.

I don't think so. All of the "bigger" machines I have used run exclusively on g-code. And even if a machine can run "CAM-less" I do not think it would remove the need for smoothing and override features. In fact it would probably increase the need for them.

So basically, if you only enter pretty much all your machine and tool data into the CAM package, you will get a G-code tool path that can be run optimally on your machine, and without the risk of "cut corners" etc.? I.e. the machine would be able to follow the tool path to its accuracy limits and no further optimization of the tool path would be necessary.

What Path Control Mode would one use for such a tool path? Perhaps G61/Exact Path Mode and the G64 modes would all work and give identical results?

I guess what's confusing me is the existence of different path control algorithms and the naive CAM detector, and also the fact that G-code seems to be "the" format for hobbyists sharing parts with each other. But if I've understood things correctly, then, the existence of the former is due to bad ("naive") CAM programs, and the exchange of G-code for parts is simply due to a lack of understanding (or caring less about tool life and accuracy of the finished part than simplicity)?

Find a Cam program with a EMC/linuxCNC post that's 3 or 4 axis.
(Try Meshcam, free trial, and easy to start using with lots of power for 3d stuff)
If you can't standard fanuc Gcode should work with tweaks, or perhaps modify a post if you can. A post puts the coordinates in a readable fashion so your controller can use it.


G64 to me is extremely important, and I will tell you why.
Lets say you are machining some rolling waves, like a futuristic table,
Also lets assume you're doing G1 or straight line feeds. (Since Nurbs aren't there yet)
So you have a ton of little points, and you do not wish or care to precisely follow each point. You already tried it with exact stop and wondered why the heck your machine is so slow. To add to it you had a stall since the machine was so erratic.

But you then entered in G64P .01 at the top of your Gcode file, and everything is cutting fast with the machines velocity almost constant.

Why would that happen? Because it's setting a tolerance for each point, thus it doesn't have to slow down much to hit each point. Toss on a Q variable, and you can skip points/lines altogether. The CAM was "naive" since it gave you far too many lines of gcode, and you fixed it with G64P Q.01 or whatever.

If you want accuracy and are scared about cutting corners set a sane value for G64p or just go exact stop if you most, or if you are handwriting things you can selectively make things exact stop.

You have to remember that nothing in the world of reality is perfect. There is always some range of tolerance. The secret is to know the range of tolerance for your machine, and work within it. If your machine is only capible of holding 0.005 to command movements to 0.0001 is a waist of time. By giving the control a little "wiggle room" speed and smoothness of motion can be improved dramatically.

Maybe a small example will help you understand this a little better. Say you wanted to mill a square. with a machine that can accelerate from 0 to your chosen cutting speed in say 1/4 inch. You are going to mill with a 1/2 inch tool. The simplest code would be 4 points. The machine is going to have to come to a complete stop in each corner to do this. Now change the code so the machine does a 1/4 inch radius at each corner, now it can flow around the corner but the piece is still square. In G61 mode the machine will still have to stop at each point in the code (all 8 of them), but with G64 turned on it will move at full speed around the piece without a stop, and since all changes in direction are within the acceleration capabilities of the machine it will still precisely follow the commanded path. Problems arise once you add instantaneous changes in direction and arc radii smaller than your acceleration capability. Now the control is going to have to slow down to follow the commanded path. Knowing how close to the path you can live with lets you set that dimension with G64PXXX and the control will slow down as much as it has to to maintain that tolerance.

I think the reason hobbyists tend to exchange g-code is because they often don't have good access to quality cam software, so this becomes the easiest way for them to get some code for their machine.

Professionals don't share code for a couple of reasons. First code they might give away is potentially hurting their business. 2nd they realize that a machine is best served by code that is generated and tuned specifically for it, so it is better to start with the original engineering files and generate your own code.

I think that what I'm trying to get at, is that if the CAM software knows about the machine's constraints, it should never output a tool path that the machine could not follow. I.e. one would get a smooth path with no accelerations greater than the machine's maximum.

With a tool path such as this, there would be no need for the machine controller to compromise between speed and accuracy, since those decision would already have been made by the CAM software (which should be able to make more informed decisions, since it knows all about the part to be made). No matter how short the moves, the machine would always be able to follow them correctly (to its tolerance limits).

And what I'm beginning to understand now is that this should be possible with G-code as long as the feed rate is constant. If I understand correctly, feed rate changes in G-code is "instantaneous", which of course is impossible for a real-life machine to live up to (requires infinite acceleration).

Unfortunately most CAM programs are not that smart (not even close) and they can only ever be as good as the person setting them up. Also there are still the situations where the shape that must be milled is impossible to mill optimally no matter what the machines capabilities. Such as an inside corner, which will require at least an approximation of a full stop and therefore will never have optimal chip-loading. So the control is left to muddle along and make the best of it and usually it is good enough.

Ok, I think I get the picture. I absolutely agree now that in many cases the machine controller needs to be able to "tweak" the tool path to be able to run it at all. Interesting discussion I think! Thanks!