You asked for it... but I'd suggest considering a new 'build' thread once you start accumulating parts and have a fairly serious plan. Otherwise your/our educational journey in this thread may muddy the waters with interesting tangents...
Disclaimer: I'm not an expert, I don't know everything. I'm a hobby guy who's been dabbling in this sort of stuff for a while.
Let's start with the basics like Jim did earlier; forgive me if I'm repeating anything. To accomplish Computer Numerical Control you need:
1. A computer of some sort. Anything from a single microchip to 'sky's the limit'. Can be a PC, can be an custom embedded computer. Can be an Arduino, ESP32, whatever.
1a. In fact, there are very likely going to be multiple 'computers' in whatever system you build. The Galil motion controller is a computer, the VFD for your spindle motor is a computer, and there will be another computer (PC) that acts as a user-interface between the Galil and you.
1b. To keep it simple, when I refer to a 'computer' I'm referring to the thing you interface directly with, can accept (more-or-less) human-readable commands, and is a very flexible consumer-grade thing. It wasn't built with a single purpose in mind, unlike a motion controller or VFD or 'smart' servo drive, but you can load CNC-dedicated software on it that is designed to communicate with the other computer-like devices in the system.
2. Software of some sort. You tell the software what you want and it does the heavy lifting number-crunching and signaling. Can be Windows software, software flashed to an Arduino, can be custom software for a custom computer. 10 million variations. Mach3, KmotionCNC, Jim's custom Galil stuff, UCCNC, Centroid, LinuxCNC, Mach4, the list goes on.
3. Stuff that moves in meat-space. Motors, actuators, solenoids, air cylinders.
4. Things that drive those motors in response to signals from the computer. Computers, as a rule, do not handle the volts/amps required to actuate big motors. They need an intermediate device that can handle the electrical requirements of the meat-space motors and actuators.
5. Sensors, switches, buttons, etc. Devices that tell the computer (or you) information about what's going on in the real world. The linear encoders Jim's suggested are in this category, as is the big red ESTOP button you're bound to install. Limit switches, pressure transducers, rotary encoders, all of your control buttons/switches. This is where things can get complicated - how much information do you and the computer need to safely accomplish your goals?
6. One or more devices that helps 'glue' those five things in to a working system. These can be an ethernet hub, a 'break out board', custom-built boards/devices that have lots of ways to connect the various bits together. All of the bits above usually have different voltages, signal types, signal speed, and amps, not to mention about 10 billion various electrical connector types. Browse through the Mouser or Digi-Key section for 'connectors' some day and you'll ask yourself why electrical component designers want to make the world insanely complicated.
The 'glue' device can be a separate item, or it may be built-in to the PC, motion controller, or other device. Hobby-level stuff usually uses a separate glue device ("BOB") that the PC & motion controller connect to. They then use the BOB to signal the drives and receive inputs from the various sensors/switches. Think of a 3D printer 'board'. It has a motion controller built-in, and sockets for multiple stepper drives, as well as places to connect limit switches, bed heaters, and other aux devices. Everything plugs in to that board. At the other end of the complexity scale, a BOB can be as simple as a board that connects to a PC's printer port and has terminals you can stick wires in. No chips - just terminals directly connected to the PC.
Applying this to your servo drives... I'm aware of three fundamental methods of commanding the drives to move the motors. There may be others:
1. Digital input (step & direction, A leads B, CW/CCW pulse). For S&D - an electrical pulse is sent to the drive, and the drive is pre-programmed to move the motor a certain amount per pulse. A different signal is also sent to indicate the direction of rotation. The other types of digital input are similar for this simplified explanation. The thing to keep in mind is that the pulses do not carry information other than their simple presence/absence. It's like morse code, but with dots and no dashes. The receiving device has to know what to do with the signals ahead of time.
2. Analog input (0-10v, +/-10v, 4-20ma, etc.). In this case a voltage is sent to the drive that represents the amplitude of a command.
2a. For really 'dumb' drives - known as amplifiers - the signal represents some percentage of maximum amps the drive is capable of producing. They just amplify the input signal. Send it 0v, nothing happens. Send it +10v and it responds with maximum amps to the motor. There is no feedback between the motor and the amplifier.
2.b Other drives can do some figurin' and convert the analog signal to a speed value, torque value, or position. Those drives require feedback - either on the motor itself or on the load - to achieve the commanded result. These drives may be capable of also using digital inputs (see #1), either in addition to, or instead of, the analog signal.
3. Last is, for lack of a universal term, Information input. This very broad category includes anything where you are sending packets of information to a drive/amp that is pre-programmed to know what to do with the info. Examples: MODBUS, Ethercat, CANbus, ASCII, ad naseum. Instead of 'move the value of one pulse, do it again, do it again', you give the drive the equivalent of a sticky note that says "Move to position XYZ, at A speed, using accel/decel value of B, and, by the way, report back when you're done and if anything went wrong."
3a. This category includes communication methods that are very fast as well as those that are rather slow. And some drives/devices are capable of talking with each other to synchronize movement across multiple axis of motion; the 'master' computer just issues a "GO HERE" command and the bank of drives talk to each other and figure out how everybody has to respond to meet the target.
3b. This type of communication really cuts back on wiring and electrical complication (i.e. plug an ethernet cable in each drive and yer done), but it increases the complexity in the software/programming side. You aren't worrying about voltage levels or signal types - you're worrying about communication protocols.
3c. In fact, you will be using this last input type: your PC will be talking to the Galil, Centroid, Kflop, etc. (motion controller) over some sort of communication bus. Maybe even controlling the VFD through MODBUS, too.
Ok, back to your situation. Your drives are "2a" really dumb amplifiers. They take a -10v to +10v signal in, and move the motors using some ratio of output amps to input signal voltage. -10v = full amps one direction, and vice-versa for +10v.
This method of input is very common in older and/or higher-end motion control systems, but is relatively rare in 'hobby-grade' systems. Think of all the 3D printers, cheapo laser engravers, desktop paper printers, DIY robots... those are generally all driven with stepper motors whose drives require a digital input. And the DIY or lower-end stuff that has AC servos also usually take a digital step & direction input.
I suspect the reason for this is that long ago when folks were starting the fiddle with DIY robotics, CNC, and motion control... they were using desktop PC's that were capable of outputting digital signals with no other hardware required. Converting a computer's digital signal to a stable, precise analog signal isn't child's play (don't look at the PWM signal, nothing to see here), so using stepper motors and digital input stepper drives was fairly cheap and easy. It still is, and if you design a system fairly well, it'll work fairly well with stepper motors and no feedback to the computer or software driving the thing around.
This is Mach3, and every other CNC software/motion controller that doesn't have any feedback from the mechanism about what's going on. "GO HERE" and the PC & user just assume everything went well.
The next step up is to close the feedback to the drive. The drive is smart(ish), and knows if the command isn't being followed properly. This can be a motor encoder, and in some cases a load/position encoder. If the motor isn't responding to the command properly, the drive can report a fault or - depending on many factors - try to 'catch up' by goosing the motor a bit, or slowing it down. Whatever is appropriate.
Last step up in the food chain is to close the feedback to the actual motion controller, whether that's the PC or a dedicated device like the Galil or Kflop. If the motion controller knows how all the motors/actuators are operating - in real time - it can adjust everything on the fly to achieve the precision required of the system.
This is Jim's plan. You will have a PC with some sort of CNC software. That software will, via an ethernet cable, tell the motion controller (Galil) what it wants done. The motion controller will then plan the 'trajectory' of all the axes, figure out how each motor or actuator must move, and output signals to the various drives to achieve the desired position of each axis, at the appropriate speed and acceleration/decel rate. The motion controller will be receiving precise location data continuously and it uses that to calculate/recalculate the signals being sent to the motors.
The PC software may get information back from the motion controller, but likely it will not. The PC may be getting info from the various other sensors (limit switches, air pressure sensors, etc.) and uses that to issue/change commands to the motion controller. This last part depends on the software, as well as what sensors and 'glue' device being used.
For your particular situation, here's a start - some DC servo drives I mentioned earlier:
https://www.machdrives.com/bra.aspx
http://shop.cncdrive.com/index.php?productID=509
https://www.copleycontrols.com/en/products/xel-230-18/
I'm not necessarily advocating those particular items, but they're examples of drives that can use a signal input type different than the ones you have and drive a brushed DC servo.
The first and third can take both motor encoder and load encoder signals in... meaning the drives will correct for any position deviation due to mechanical backlash in the system. Nice, but if your motion controller is capable of receiving load encoder info, is it necessary?
The last one (Copley) is powered directly by AC line voltage, while the first two require DC to power them (need a transformer). And the Copley Xenus can take multiple input types (digital, analog, information), drive multiple motor types (DC brushed or 3-phase brushless), and act as a stand-alone motion controller unconnected to anything else.
Unsurprisingly it's rather expensive.
That's enough for now. Digest it, and while you're rummaging around on the internet looking at mysterious electrical devices and software see if you can mentally categorize what that 'thing' is and how it fits in to the big-picture I've outlined above.
-Ralph
