First, let me just give you a quick rundown on how this works, since some of it was foreign to me at first. CAD is the program where you draw the 3D part, or 2D if you are working in sheet metal. There are many output formats for CAD, and the *.STL format appears to be the format that most CAD-CAM combos are preferential to. The most popular program these days appears to be SolidWorks. It used to be AutoCAD, but SolidWorks has displaced it for reasons unknown to me. The CAM program (I am using a cheap, but apparently pretty good, program called MeshCAM) takes the STL file and converts the STL file into G code. There are several programs that work with SolidWorks, SolidCam (Different company) being the most popular. This G code is what generates the "Toolpath” that actually does the cutting. Depending on your needs and equipment, you might want to hand edit the G code file to optimize it, e.g., pause it to allow a tool change at a different point than the CAM program chose. The G code files are usually *.nc or *.ngc files. The following website has a number of high quality CAD files that members have posted https://grabcad.com/ So, the end product of digitizing has to be either a file format that the CAD program can read if you want to edit it at all, or a format that the CAM program can read to simply reproduce the part. Technically, it could be a G code file as well, but all you could do is feed it to the next program in line, the Motion Control Program (MCP).
The third program in line is the "motion control program (MCP) ”, which in my case is "LinuxCNC” which runs on the Linux OS on the computer that controls the mill. As I have mentioned before, it is nice to have a computer dedicated to the process with very few interrupts that might cause the MCP to miss something. The MCP interprets the G code and generates the output to the motor drivers. In the case of the stepper motors, the MCP generates two signals to control each motor. One signal is the direction to move (High or Low) and the other signal is a set of pulses of variable number and variable inter-potential interval. The stepper motor moves one step (usually 1.8 degrees) for each pulse, so you can control the distance, speed, and direction that the motor turns. It gets much more complicated in reality in that the MCP has to compensate for things like overshoot, potential harmonics, acceleration lag, and so on. There is no feedback with the typical stepper motor setup, just the assumption that the motor moved one step for each pulse it received. Part of what makes a good MCP is keeping this assumption true, e.g., if you try to accelerate the motor too fast, it may miss a few steps. If the motor meets excessive resistance, it may miss some steps as well. There is nothing you can do about the latter except make good choices about material, feed rates, etc..
A different control algorithm has to be used with servo motors since their structure is not quantized and they respond primarily to input voltage. In this case, however, you have high accuracy position feedback in each axis so the MCP calculates where the tool "Should” be, and generates an error signal to move the tool to the desired location. There is theoretically no possibility of error with servos since the MCP doesn’t make mistakes about where the tool should be, and if it is within the capability of the drive motors, they keep trying until they reach the correct position. In reality, if the tool movement velocity, etc., gets off, it can create machining errors as well, although the dimensions should be correct. So CAD, CAM, MCP, and the underlying OS, along with the motor drivers make up the system, with a position feedback system for servo motor systems. Servos are considered better in general, but are much more expensive, e.g., for the Grizzly, it’s about $3,000 vs $5,500 to do steppers vs servos.
The practical issues are the degree of precision needed. I guess that in the commercial world, shops sometimes have to buy $100,000 worth of measuring equipment just to determine whether the part that they made meets the specifications of their customers. I guess some shops have been nearly bankrupted by large orders, e.g., several weeks worth of production, being returned by the customer because they didn’t meet specs, and the shop’s QA equipment wasn’t good enough to determine this. The parts needed to be measured at the level of less than a ten thousandth of an inch and they could only measure at the ten thousandth level. I’m still learning about the digitizing, but I think it’s pretty difficult to get down to these levels of accuracy. CNC is now routinely down to 0.5 um or better tolerances. With 0.00004 inches/um, we are talking 0.4 ten-thousands of an inch, or 40 one hundred thousandths. A ten-thousandth is a gargantuan distance. I think digitizing accurately is particularly challenging on corners, holes or concave surfaces, etc.. However, I think you can do it at this level of precision if you are good enough and have good enough equipment. Few people are going to want this degree of accuracy, but it does tell you how precise some people need the data to be.
The main thing is that the digitized file needs to be more than a collection of (X,Y,Z) points that describes the surface of the object. The digitizer originally generates a collection of (X,Y,Z) points. It needs to be a file that describes the object in the format that a CAD file would use. I’ll have to investigate what these devices output since it is a formidable task to generate the CAD file from raw data. However, the issue is too obvious, so I would guess that there is a program somewhere that does the conversion, perhaps with a little operator assistance.