I feel long winded, so here is some free information. Feel free to discard whatever you like from it.
Theoretically you could do that with the uno, but the mega just a more powerful uno. If know how to code an uno, you can code the mega. It is just more code to follow, so a bit more complex, but the same language.
Once calibrated, the arduino mega has all the limits internally except the z axis which is in testing and can be included. Since the maslow does not home itself each time you turn it on like a stepper-driven 3D printer, limit switches are not really very helpful except when things go really south. Responsible CNC users observe their systems and don’t let them run wild without supervision (like some children in the walmart). I wired a set of light switches with romex on my frame, so if anything goes wonky, I turn it off. There is an outlet at the bottom center of the back of the frame for my router to plug in and it is switched by one of the light switches and it runs through a relay toggled by AUX1. My dust collector goes through an outlet switched by another light switch, and the electronics go through a third one. I also have big red emergency off switches on each side of the system to cut everything, but I really never use them and often use the pause or stop button on my controller instead of killing power. It has never run off the work space. It has limited out on the z axis from a fat finger or a loose set screw error and it has halted itself with a sled-not-keeping-up error when the router power cord caught on a cutout and the sled stopped moving. It worked and stopped like it was supposed to.
3D printers have limit switches as a way of ensuring positional accuracy. The Maslow has encoders on each motor to keep track and those values are stored in the eeprom on board. As long as you don’t yank power from the mega during a move, you won’t need to mess with it unless you do jump a chain tooth (put sprockets at 12:00 and reset chains), which can happen, though its occurance is rare. It may actually be easier to mess up the gcode by using incorrect post processor settings than the hardware.
The M2 folks with the DUE processors are the ones who probably need the limit switches because their firmware doesn’t have a sled-not-keeping-up error. You tell it to move and it will move.
If it doesn’t move because of no power to the shield, it will wait until you plug the shield in and then it will move like hours later unless you reset it (I tested this).
For some of the hating on the Mega, they are actually a pretty stable and reliable platform. The users of the DUE have had some mixed results thus far. I don’t know the statistics because the forum usually only gets wind of something if there is a problem. There have been a few errant sleds possibly due to incompatible firmware/makerverse versions (most all were M2 versions that ripped the ring apart), but if you are using a Mega and webcontrol, your chances of runaway sled are very very slim (make sure your gcode doesn’t use the R command) and that you have the correct firmware for your board version.
