If you're interested in Open-Source CNC you should check out two of my Open-Source projects. https://camotics.org/ a CNC simulator and https://buildbotics.com/ a CNC controller. I'm somewhat surprised neither of these were mentioned.
Some firmwares support arcs (smoothieware, which is based on GRBL) but it still breaks the arcs down to segments.
I would have thought the printer would support arcs even if the slicer doesn't. There is work going on to support arcs in slic3r (automatic detection of arcs) but it will be irrelevant for printers that don't support it. It's would also be possible for a slicer to import step files and find such surfaces. One can also approximate other curves with fewer gcodes if they use arcs vs lines - splines even fewer.
I assume most of the modern ones do but some of the older 3d printing firmware use a very butchered version of the gcode "standard" which eliminate or rename many of the unused codes.
I'd think it would be useful to integrate the two, instead of the CAM software just firing-and-forgetting toolpaths.
Damage/safety issues: operating the milling machines incorrectly, or in an untimely manner.
Related to latter point: lack of hard real-time processing in the upstream software?
(Both are these are solvable, it's interfacing with the machine in any standardized way that is not)
Your question is somehow similar to "why can't the C code directly control the CPU"?
What I'm thinking of is something like a CAM workspace in FreeCAD. That is, something like would let you take your model, generate and inspect a toolpath (or flip through possible toolpaths), and produce a part. The CAM software would get feedback from the controller, so it could follow what was going on.
It might also be possible to make adjustments, or pause the run, based on sensors. For instance, if you could detect chatter, you could slow down the feed rate; if you could detect a broken tool, you could pause the run and ping the operator.
Detecting chatter is not that easy. Slowing down may be wrong, sometimes it is better to speed up.
Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project.
Errr? Detecting chatter is easy, and in fact, the latest spindles output the current tool vibration rate over your choice of fieldbus. That's fairly basic, much more advanced things are done.
"Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project."
Why? Toolpaths are already adjusted on the fly. Integrating CAM does not make this particularly harder - any of these machines have hardware motion planning anyway. Adding another FPGA or two to accelerate 5 axis movement calculation would not materially change their cost.
In some cases, it is.
There are integrated CAM + Machines depending on industry and price point. (see woodwop, etc, which are the interface to the machine)
The motion planning aspects can be taken care of (despite other comments), beckhoff, for example, does real time plc on windows machines by isolating cpus away from windows. i have no problem using it as a plc. They also support CNC control.
Outside of software like that, it's usually being taken care of by an FPGA card and that's a pain in the butt. Assume you can solve this.
You still have the next problem: Actually driving the machine.
First, the low level
Most of the servos in these machines are using pulse train inputs of some sort. That's what the FPGA cards are doing, generating the pulse outputs, etc.
It's only in the past 5 years that things like "drive my servo over ethercat instead" became viable.
They use simple relays, etc to control safety/limit switches/you name it.
Now i could use an ethernet based field-io. So i'd say they are actually now there (in the past 5 years) for the low level. I can run all my field io/spindles/servos off ethercat now, for example. I do, in fact, outside of servos (my cnc software can't drive them over ethercat yet)!
5 years ago i couldn't do this.
Okay, so that's one level up. Now i can at least drive it from the CAM software in some standardized way if i knew what was what. Which is your next problem - knowing what anything does. Which io's are the limit switches. How do you home the machine or execute a tool change? How do i turn on the vacuum? Which drives go with what axes?
There is no standardized way of describing this, such that a piece of CAM software could actually do anything.
We'll get there, mind you, but it'll be a while.
I would prefer my (probably expensive) machine to kind of "know" what it's physical limits are and guarantee that executed commands adhere to them.
The assumption that there is a cam workstation, and that it's in an office building, is certainly not one i would make. I wouldn't also say "will never make much sense".
You seem to have some particular set of users in mind for which you believe it wouldn't make sense. Okay - i'm not sure that changes that there are plenty of sets of users for which it will?
I even gave you examples of high end wood machines that have CAM directly integrated. There are many.
(They can also be programmed offline, but)
As for "knowing" the physical limits.
That's not actually possible since it there is no way to self-configure it even if everything did talk to each other. They don't know their own physical orientations (and it would be very expensive/hard to do that, and you'd still be guessing in the end)
Most of the non-safety/accessory programming is essentially explaining enough of the physical orientation and placement of things to the motion control that it can do something.
CAM workstation (running some "generic" CAM package with machine specific configuration) in some office building was the precondition, in that case it will never make much sense to control a machine's servos from that workstation, in my opinion.
Integrating the CAM within the machine itself is something else, and yes, stuff like that existed for very long time, but that is something completely different IMHO.
The machine controller "knows" the physical limits because somebody configured it (and "locked" it). It would be hard to guarantee the integrity of this configuration if you put it on an arbitrary workstation to run CAM and machine control.
Wait, so even the really high-end gear in high-end names like DMG Mori don't use something like millimeter radar, ultrasound or machine vision to confirm that real-world orientations at least correspond to within a few orders magnitude accuracy of what is expected? If so, then mad props to you machining guys working with such expensive kit without continuous closed loop monitoring conditions; you re-e-a-a-ally like to live on the wild side.
Steppers are great, but anything big needs a servo, as the steppers get to expensive and too slow very quickly.
Edit: We are adding step and direction outputs which could be used to control an external servo driver. You can actual access these outputs now of you are alright with soldering some headers on to the main board.
In the future, we do plan to make a servo version of the Buildbotics CNC controller.
Anything bigger, many people seem to like ClearPath servos. Price to performance seem to be pretty good.